topic Re: TZ usage for Windows DNS debug log (dealing with local timestamp) in All Apps and Add-ons

TZ usage for Windows DNS debug log (dealing with local timestamp)

sylbaea — Wed, 15 Mar 2017 12:15:09 GMT

Hello,

I have many Windows DNS servers deployed worldwide with each one configured with local time.

Unfortunately DNS debug log is writting local time information in the log.

I already read here several answers related to that problem, and all of them suggest to use TZ attribute in props.conf.

I have tried several variants of that without any success so far.
Can somebody please confirm it can work when the TZ syntax is specified on the universal forwarder (not on the indexer) ?

Thanks.

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

woodcock — Wed, 15 Mar 2017 19:33:45 GMT

If you are on version 6.0 or greater, then the TZ value in props.conf on the forwarder has the highest precedence (except for TZ_ALIAS which can override it on the indexer). People forget to upgrade their forwarders all the time so be sure you are versioned high enough.

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

sylbaea — Tue, 29 Sep 2020 13:17:30 GMT

Hello,

Thanks for your feedback.
I do confirm I am using the latest version on my whole infrastructure (indexer, universal forwarder)
I also confirm I do not use TZ or TZ_ALIAS at indexer level for this specific source type.

Would you see a way to troubleshoot and detect why the TZ config is not taken into account by the UF (or by the indexer) ? There is no heavy forwarder in the middle, it goes straight from the UF to the indexer.

Here is what I configured on the UF running on Windows DNS servers:

inputs.conf
[MonitorNoHandle://C:\Windows\System32\Dns\dns.log]
sourcetype=ms:windows:dns:log
source=C:\Windows\System32\Dns\dns.log
disabled=0
index = windns

props.conf
[ms:windows:dns:log]
SHOULD_LINEMERGE=false
NO_BINARY_CHECK=true
CHECK_FOR_HEADER=false
KV_MODE=none
TIME_FORMAT=%m/%d/%Y %I:%M:%S %p
TZ=America/New_York

Note: I tried many config for props.conf (from the above one up to the smallest one just with the TZ row. No change.

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

woodcock — Thu, 16 Mar 2017 21:11:58 GMT

Tell me the value of host for this server and the timezone that it's system clock uses and I will write the configuration for you.

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

sylbaea — Fri, 17 Mar 2017 06:41:34 GMT

Thanks for your help... Please use dummy values, I will adjust, I do not wish to expose that info publicly.

this being said, please note that if you intend to apply TZ by host, it will unfortunately not make it as just this specific sourcetype should be adjusted (the one indexing Windows DNS debug log)... Same UF on same host is collecting plenty of others data (with different sourcetype) where timestamp is ok (event logs, perfmon, etc.)

Regards.

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

woodcock — Fri, 17 Mar 2017 23:42:09 GMT

Nobody uses the TERRIBLE Windows DNS logs anyway. The right way to log DNS flow is with Stream App for Splunk and sniffing the wire. Read about it here (and many other places). Friends don't let friends do Windows:

http://www.rfaircloth.com/2015/11/06/get-started-with-splunk-app-stream-6-4-dns/

Re: TZ usage for Windows DNS debug log (dealing with local timestamp)

sylbaea — Mon, 20 Mar 2017 06:37:43 GMT

Your statement looks a bit definitive and it does not really help to answer my question here... you do not know if I have not tried something else first... I also tried the new Windows DNS Analytic log method without getting required reliability (like others people on this forum based on what I found).

From on what I have been told (I need to check), Stream App does require Winpcap to be installed on the Windows server. Winpcap is something we disagree to install because it does decrease local security. At least this is currently forbidden for us to install it.

Finally (and back to my original question), I am both interested to make this DNS debug logging work but also to understand why I cannot make this TZ modification to be properly applied. Out of the DNS use case, I might have a future need to use TZ again.