IP addresses in NS records seem to be breaking hostname resol ution

Chris Davis chris.davis at computerjobs.com
Thu Jul 18 14:19:55 UTC 2002


"A failure at the TLD to resolve a hostname can be temporary."  

But isn't it unlikely enough that all the TLD servers would fail to resolve
an entire set of NS RDATA that a Bind configuration option to [dump the set
of NS RDATA that cannot be "first step" resolved by the set of entire TLD
servers] would be a sensible option for a resolver?

My thinking is that if a set of NS RDATA cannot be resolved by the set of
TLD servers, something is very very likely to be wrong with the RDATA.
Likely enough that I'd prefer my installation of Bind to abandon that set of
NS RDATA, since there's no way (I can see) for them to be corrected without
dumping them from the cache explicitly or via expiration.

All I'm really looking for is a short circuit on the time for getting the
RDATA out of my cache if the TLDs all barf on the set of RDATA, since this
is what HAS to happen before the domain can resolve anything.  Currently it
happens this way.  It just takes a long time.



-----Original Message-----
From: David Botham [mailto:dns at botham.net]
Sent: Thursday, July 18, 2002 9:54 AM
To: bind-users at isc.org
Subject: RE: IP addresses in NS records seem to be breaking hostname
resolution





> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Chris Davis
> Sent: Thursday, July 18, 2002 7:21 AM
> To: 'bind-users at isc.org'
> Subject: RE: IP addresses in NS records seem to be breaking hostname
> resolution
> 
> 
> Bunnies!
> 
> Mark, you're absolutely correct.  That point missed me entirely!
> Now I understand why this type of hostname that matches the syntax of
an
> IP
> address cannot cause Bind not to load the zone, and what Kevin meant
by
> his
> tongue in cheek massive kludging idea.
> 
> This bit of light in my head leads me to my third option, in which a
> resolver that determines an entire set of NS records to be
unresolvable
> dumps that set from its cache.
> 
> There are different levels of "unresolvable."  In the usual level, the
> delegated name server for the hostname says "Host not found."  In
another
> level, no root server can be located to handle the TLD.
> 
> In the event of finding no root server to handle the TLDs for an
> particular
> set of NS RDATA entries, where is the harm in dumping that set of NS
> records
> from a resolver's cache?
> 
> RFC specifies that the delegated name server is believed over the root
> servers, but does it specify that the delegated name server must be
> believed
> when the delegated information is unresolvable?  My question boils
down to
> this:  Does the inability of a particular resolver to find a TLD (or
local
> zone if we're bad) to resolve a hostname absolutely mean that a
hostname
> cannot be resolved by that dns resolver (rather than "was not resolved
by
> the dns resolver")?
> 
> I realize that an update to your hint file might add another root
server
> to
> recognize the unknown TLD.  In this case, the TLD would be picked up
the
> next time hosts in the affected domain are resolved and everything
would
> be
> dandy.

Even a failure at the TLD to resolve a hostname can be temporary.

Dave...
> 
> If this option also isn't an option, help me out!  This is a decent
size
> pitfall causing decent amounts of failures.  If there's a way for Bind
to
> prevent it, how can it be done?
> 
> 
> -----Original Message-----
> From: Mark Damrose [mailto:mdamrose at elgin.cc.il.us]
> Sent: Wednesday, July 17, 2002 10:45 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: IP addresses in NS records seem to be breaking hostname
> resolution
> 
> You seem to have missed the point that the above are *legal*
hostnames.
> As
> a human, it is obvious to you that they were intended as IP addresses.
> Computers are not so good at those kinds of judgement calls.  BIND has
no
> way to know that they are not supposed to be
209.44.8.1.pacetech-inc.com,
> etc.



More information about the bind-users mailing list