Bind 9.2.0 and 9.2.1 stop resolving external IPs after a bit. HELP

[Danny Mayer]

At 01:38 AM 12/2/02, Mark_Andrews at isc.org wrote:

> >
> > My primary DNS server is up to date on the latest RH patches. It runs
> > Bind 9.2.1. The backup DNS server has not been updated yet and runs
> > 9.2.0. It suffers the same problem, but since it's not under load, the
> > problem does not show itself until the primary DNS fails for a bit.
> >
> > As for making the root name servers mad, I did a packet capture when 
> Bind is
> > running correctly. Looking at it in ethereal,
> > I see an A query to a.gtld-servers.net.
> > a.gtld-servers.net  respoinds back with "Standard Query Responce, Format
> > Error"
> >
> > The request is made again, and this time it works.
> > I see a lot of "Format" errors in my packet capture and this is when Bind
> > is working.
>
>         FORMERR's are responses to EDNS probes.  Named re-tries w/o EDNS.
>
>         Everything sounds like normal.
>
> > When Bind quit working last, I did a quick tcpdump and noticed that it
> > was sending request out, but nothing was coming back. I did not get a
> > chance to do a packet capture or a little sniffing on the external side
> > of the firewall, but the backup DNS server was running fine at the time
> > so I don't think it's firewall or network related. It was just like the
> > root name servers stopped talking to it. Restarting Bind fixed the
> > problem. Next time it goes out, I will be ready.

I suspect that you are never getting to the root servers to check the root
zone, so things stop working when the TTL expires on the root zone.
Does that sound likely?

Danny

>         I was on a doubly NAT'd net the other day and observed the behaviour.
>         As this was in a hotel conference room it wasn't worth expending
>         time and effort to chase the problem down.  Note however the
>         first NAT box was Linux based.
>
>         Restarting named causes named to use a different source port which
>         would allow the NAT to clear state.
>
>         I would be taking packet traces from the outside of the firewall
>         next time it fails.
>
> > Thanks for the tip o the source rpms. When it dies again, I will try
> > that.
> >
> > Thanks
> > Ed
> >
>
>         Mark
>--
>Mark Andrews, Internet Software Consortium
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org