Thank you
Techi
I'd suggest tcpdump running on both the BIND servers and the client, so
you can match send/receive and show missed packets directly.
Cheers,
Todd.
Thank you
Techi
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
and there is nothing in the bind log files?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Use a packet sniffer (e.g. tcpdump, wireshark) on your DNS servers to
capture the DNS traffic.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
>> No! Log files are indicating any issue! The only indication I have about the
>> problem, is the lack if queries in the log files. No timeouts, no
>> failures. I
>> even tried to query a fake domain. The result was a normal record (with A+).
>> I did not find any error!
>> So, how on earth do I log them?
>
> Use a packet sniffer (e.g. tcpdump, wireshark) on your DNS servers to
> capture the DNS traffic.
>
if you set it to capture only 53 port and to save files up to
reasonable size you can leave it running for 24h without a problem -
wouldnt recommend doing that without specifying port/service.
t
--
bEsT rEgArDs | "Confidence is what you have before you
tomasz dereszynski | understand the problem." -- Woody Allen
|
Spes confisa Deo | "In theory, theory and practice are much
numquam confusa recedit | the same. In practice they are very
| different." -- Albert Einstein
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>conclude that there is no such option, correct?
Well, it depends on the reason for the timeouts. If the packet is
getting lost along the way due to network issues, it would never hit the
server, and you wouldn't have any logs of it.
You could use filters on tcpdump (tcpdump -tt host x.y.z.a && port
53)and setup a script on a remote host to send a stream of queries. You
don't necessarily have to capture all traffic to troubleshoot the
problem. Make sure your servers are time sync'd properly so you can
correlate the logs.
Otherwise, if the issue is happening after the packet reaches the
server, then I'd bump up the debug level and turn on a bunch of logging
and make sure ntp is working fine and start watching logs while
generating a bunch of traffic from a test box.
Cheers,
Todd.