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

[Chris Davis]

I'm afraid we have lost focus of the discussion.  The discussion regards
zones with NS records that incorrectly have RDATA using IP addresses rather
than hostnames.  We are not addressing NS RDATA hostnames that do not seem
to resolve to an IP address.

The config that started our discussion was:

@	IN	NS 	209.44.8.1
@ 	IN	NS 	209.44.8.6
@	IN 	NS	216.90.116.7

This config has since been repaired in the real world.  If you want to test
this, you'll have to look in your cache and find more NS records with RDATA
consisting of IP addresses.

In my case, the affected zone had three NS entries, all of which had RDATA
containing IP addresses, as in the above sample.  Once my resolver cached
the above NS RDATA, absolutely NOTHING short of removing them from my cache
(explicity or via expiration) would allow me to resolve hostnames within
that domain.

It wouldn't matter if the zone administrator corrected his NS records,
because I could no longer contact his name servers.  My zone had "kaput" as
name servers for him.  Nada.  Garbage.  IP addresses.  But IP addresses do
not (forward) resolve to IP addresses as NS RDATA is expected by Bind to do.
Only hostnames do that.  Until the NS RDATA IP addresses disappeared from my
cache, that domain was 100% unreachable via my resolver.   The only way to
re-establish contact was to remove the faulty NS records from my cache and
ask the GTLDs where to find the RRs for the domain.

(How did I get inital contact?  GTLD servers had correct NS RDATA containing
hostnames.)

I am not interested in whether A RRs in NS records successfully resolve to
an IP, because like you guys say, it can always become possible for them to
do so at any time.  My concern is NS RDATA that contains IP addresses only.
These are flat broken and should be rejected by bind at startup, as they
render the domain seriously broken but not wholly unusable.  The domain can
be used successfuly only "very infrequently" by any caching resolver (at a
rate of one successful resolution per NS RDATA expiration timeframe).
"Frequent" use renders the domain useless.  One the NS RDATA IP addresses
get loaded up into my resolver, I lose contact completely.

The check I propose is Bind looking at zones' NS records at startup and
going "Is it a hostname or an IP address?  Hostname = OK.  IP address =
die."   In the "Hostname" case, resolution of the NS hostname is NOT a
concern.

Here is a re-enactment of the situation, taking into consideration that the
faulty NS RDATA consisting of IP addresses was already in my cache.

Me: "Resolver, please resolve mail.pacetech-inc.com."

My resolver:  "The hostname for the dns server resolving pacetech-inc.com
hosts is 209.44.8.1.  Let me resolve the hostname "209.44.8.1" to an IP
address so I may contact that server and ask to resolve the host named
"mail."  Um.  Um.   Um.   This isn't working.  Let me maybe try the other
nameservers 209.44.8.6 and 216.90.116.7.  Um. Um. Um.  I can't resolve any
of these "hostnames."  I quit."

Me: "That's weird. My resolver didn't even send out a single packet in an
attempt to resolve mail.pacetech-inc.com.  That's just wrong."

(Don't worry, I have no aspirations of becoming a playwright.)


-----Original Message-----
From: Cricket Liu [mailto:cricket at menandmice.com]
Sent: Wednesday, July 17, 2002 8:33 PM
To: Kevin Darcy; bind-users at isc.org
Subject: Re: IP addresses in NS records seem to be breaking hostname
resolution

To cite another example, I know administrators who manage the external views
of their zones on internal name servers and have those zones transferred to
their
external name servers.  Depending on their resolution architectures, the
domain
names in the RDATA of their NS records might not be resolvable on the
internal
name server at all.  Shouldn't it still be able to load the zone?

If we check intrazone NS records by looking up their A RRs before loading a
zone, and all of the name servers authoritative for the zone have domain
names
in the zone, how does the first one start?

cricket

Men & Mice
DNS Software, Training and Consulting
www.menandmice.com

Attend our next DNS and BIND class!  See
http://www.menandmice.com/DNS-training/
for the schedule and to register for upcoming classes