Warning: ID mismatch:

Ladislav Vobr lvobr at ies.etisalat.ae
Thu Sep 9 11:50:46 UTC 2004


why there would be a constant flood of DNS traffic between two caching
servers? If they are caching only, they should really not talk to each
other, unless you are using some weird kind of forwarding, are you ?

If not, you can specify the filter, based on your source address,
protocol, destination address and destination port. Only the source port
will be random. other things are constant.

Ladislav


Maria Iano wrote:
> At the time, I ran tethereal for a while, but I had to filter for the two hosts res1 and res2 because there is such a constant flood of DNS traffic. When I issued a dig from res1 to res2 (which succeeded every time) the exchange of packets was what you would expect, including the ARP packets to find eachother's machine addresses. When I issued a dig from res2 to res1 (these were what intermittently failed and occasionally produced the ID mismatch error) there were some unexpected errors - ICMP unreachable errors sent to res2 saying that res1 was unreachable. Once I restarted the named process on res1 everything worked fine again, and is still working without issue at this moment...
> 
> Thanks,
> Maria
> 
> On Wed, Sep 08, at 10:58%P so wrote Ladislav Vobr (lvobr at ies.etisalat.ae):
> 
> 
>>Maria Iano wrote:
>>
>>>I have two caching servers, res1 and res2, running BIND 9.2.3 on Red Hat Linux release 8.0 (Psyche). They sit inside a firewall, and forward queries to four different caching servers on the outside, as well as some internal servers authoritative for internal zones. 
>>>
>>>Last week res2 starting being slow and failing resolution intermittently. Dig queries sent from res2 to the outside resolvers worked correctly. Dig queries sent from res2 to res1 worked correctly. However, dig queries from res1 to res2 produced error messages like this:
>>>
>>>;; Warning: ID mismatch: expected ID 3325, got 34596
>>>
>>>with various different IDs produced from different queries. It was late at night (I had been paged) so I went ahead and rebooted res2. This cleared up the issue.
>>>
>>>Now, a week later, this same issue is occurring on res1. res1 is slow to respond to queries and intermittently failing to resolve names. digs issued on res1 pointing to the outside resolvers work fine. Digs issued on res1 pointing to res2 work fine. Digs issued on res2 pointing to res1 produce the ID mismatch errors again.
>>>
>>>I suspect that if I reboot it the error will clear up again, but before I do that I want to try and work out what is going on.
>>>
>>>Any advice?
>>
>>You might possibly use a packetsniffer to see what you send and what 
>>other side received and similiarly for the reply. On linux you can use 
>>tcpdump or ethereal for example. I faced once these messages, when I was 
>>using query-source port 53 on my recursive nameserver, and I patched dig 
>>to use port 53 as a source port as well, than I got lot of these 
>>everytime I issued such a command from the recursive server prompt, but 
>>it was understandable, since regular replies coming to my nameserver 
>>confused dig.
>>
>>



More information about the bind-users mailing list