Odd query issue

Mark Andrews marka at isc.org
Tue Aug 3 23:50:13 UTC 2010


In message <4C58668D.2010705 at chrysler.com>, Kevin Darcy writes:
> On 8/3/2010 7:50 AM, Atkins, Brian (GD/VA-NSOC) wrote:
> > Kevin,
> >
> > Thanks for the good ideas. Here is what I am seeing based on your
> > recommendations:
> >
> > 1. Zone has expired (to confirm: check logs)
> > No errors or notices regarding the zone being expired.
> >
> > 2. Corrupted/truncated journal file (to confirm: check logs, or, shut
> > down gracefully, delete journal and start up again)
> > I've shut down BIND, removed all files under the slave directory, and
> > restarted BIND - no help. Other zones that are delegated from the same
> > server are populated.
> >
> > 3. www.blah.com is a delegation in your slave copy of the zone, and the
> > delegated nameservers are all returning SERVFAIL, are lame, give bogus
> > answers, some combination of the above, etc. (to confirm: do the lookup
> > non-recursively, or a zone transfer of blah.com; if www.blah.com shows
> > as a delegation, query the delegated nameservers directly and see what
> > they return)
> >    
> So, just to be clear: is www.blah.com delegated to another nameserver or 
> set of nameservers? Or is it contained within the blah.com zone itself? 
> My option #3 above referred to a relatively-unlikely scenario where a 
> www.blah.com delegation was (temporarily) present in your slave copy, 
> even though you indicated that on the master server, www.blah.com was 
> contained in the blah.com zone.
> > I am able to query the master directly, without issue as well as perform
> > a zone transfer (though I get an error, ";; communications error to
> > 10.x.x.x#53: connection reset"). I'm assuming that this is due to the
> > fact that the response is greater than 512 bytes perhaps.
> >    
> 
> The 512-byte restriction only applies to UDP.
> 
> Sounds like you may have a problem with performing TCP transactions with 
> the master, most likely because of naively-implemented firewall rules. 
> You can confirm or deny this via the "+vc" (virtual circuit = TCP) 
> option to "dig".
> 
> If TCP between you and the master is completely broken, your zone 
> transfers aren't going to work and the zone will expire, if it hasn't 
> already.  I'd double-check whether the zone is expired, maybe by 
> restarting named with a high debug level.
> 
> It's a little troubling that other slave zones -- I assume that's what 
> you meant when you said "that are delegated" -- from the same master are 
> working. But, are all the EXPIRE settings the same? Maybe this is just 
> the _first_ zone that expired.

Or that the other zones are smaller and this one is big enough that PMTUD
kicks in.
 
> Again, the logs should help here. Are zone transfers succeeding or 
> failing for blah.com and for other zones. If there are failures, what 
> are the error messages in the logs?
>                                                                          
>                                                                      - Kevin
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list