Warning: ID mismatch:

Maria Iano maria at iano.org
Tue Sep 7 15:43:51 UTC 2004


Thank you for getting back to me on this. In this case, I don't think it is the firewall, for two reasons. First of all, res1 and res2 are both inside the firewall and on the same network segment. So they send packets directly to eachother. Secondly, restarting named has fixed the issue.

I didn't have dynamic debugging available :( I have set it up now, but that involved restarting named, which also resolved the issue. Hopefully this won't happen again, but if it does at least this time I can turn on debugging...

Any further ideas you have would be most appreciated!

Thanks,
Maria

On Tue, Sep 07, at 04:33%P so wrote Jim Reid (jim at rfc1035.com):

> >>>>> "Maria" == Maria Iano <maria at iano.org> writes:
> 
>     Maria> I have two caching servers, res1 and res2, running BIND
>     Maria> 9.2.3 on Red Hat Linux release 8.0 (Psyche). They sit
>     Maria> inside a firewall, and forward queries to four different
>     Maria> caching servers on the outside, as well as some internal
>     Maria> servers authoritative for internal zones.  Last week res2
>     Maria> starting being slow and failing resolution
>     Maria> intermittently. Dig queries sent from res2 to the outside
>     Maria> resolvers worked correctly. Dig queries sent from res2 to
>     Maria> res1 worked correctly. However, dig queries from res1 to
>     Maria> res2 produced error messages like this:
> 
>     Maria> ;; Warning: ID mismatch: expected ID 3325, got 34596
> 
>     Maria> I suspect that if I reboot it the error will clear up
>     Maria> again, but before I do that I want to try and work out what
>     Maria> is going on.
> 
>     Maria> Any advice?
> 
> Your firewall is probably broken. A DNS query includes a (random)
> query ID. This is to help a name server match an answer with the
> questions it has asked. The log messages indicate some answers your
> server is getting have different query IDs from the ones it used when
> the queries were made. This is almost certainly caused by your
> firewall messing with the DNS packets as they go by.


More information about the bind-users mailing list