Warning: ID mismatch:

Maria Iano maria at iano.org
Wed Sep 8 15:12:12 UTC 2004


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