defective NS RDATA -- was IP addresses in NS records seem to be breaking hostname resolution

[Chris Davis]

The NS records must've been rooted in the zone config.  My bad on the
guessed config.  Because, the NS records were not stored as
209.44.8.1.pacetech-inc.com in my cache.  They appeared as:

pacetech-inc    1263    IN      NS      209.44.8.1.     ;Cr=auth
[209.44.8.1]
        1263    IN      NS      216.90.116.7.   ;Cr=auth [209.44.8.1]
        1263    IN      NS      209.44.8.6.     ;Cr=auth [209.44.8.1]
        1263    IN      SOA     joe.pacetech-inc.com.pacetech-inc.com.
hostmast$

As a comparison, some arbitrary correct entries looked like this in my
cache:

NETSCAPE        150988  IN      NS      ns.netscape.com.        ;Cr=addtnl
[192$
        150988  IN      NS      NS1.netscape.com.       ;Cr=addtnl
[192.26.92.3$
        150988  IN      NS      NS2.netscape.com.       ;Cr=addtnl
[192.26.92.3$
cornerstonesg   83505   IN      NS      noc.ios.com.    ;Cr=auth
[169.132.133.1]
        83505   IN      NS      ns.idt.net.     ;Cr=auth [169.132.133.1]
ajilon  24518   IN      SOA     cbru.br.ns.els-gms.att.net.
rm-hostmaster.ems.a$
                20 86400 10000 600000 86400 )   ;Cr=auth [199.191.128.105]
        24518   IN      NS      cbru.br.ns.els-gms.att.net.     ;Cr=auth
[12.12$
        24518   IN      NS      cmtu.mt.ns.els-gms.att.net.     ;Cr=auth
[12.12$
        24518   IN      MX      10 micro1.icsnet.net.   ;Cr=auth
[12.127.16.69]
PDV     53771   IN      A       200.1.171.129   ;NT=11 Cr=addtnl
[192.5.6.30]

(With the $s being truncation by the editor with which I viewed the cache
dump, of course)

So, for this NS RDATA, the TLDs in my cache for the NSes were in fact "1"
and "6," thus being illegal and completely broken and pointless to keep
since they cannot be fixed.  They could only expire or be cleared from the
cache.  Pacetech-inc could hire you or Cricket to come fix their DNS
perfectly but it isn't going to work for me until the bad NS entries are
gone from my cache, no matter what you were to do, because once I get the
bad set of NS RDATA, I can no longer contact any of your nameservers.

In light of the IP address RDATA being rooted, we're back to Plan A as a
possibility:  Rooted IP addresses as NS RDATA are definitely illegal and
should be sufficient cause for Bind not to load a zone.  It should also be
sufficient cause to be dumped (or rejected but current RFC doesn't like
that) from my cache if somebody else is doing it.

Speaking of the RFCs, why bother to accept NS RDATA that's absolutely and
irretrievably broken (specifically, a set of *rooted* IP addresses rather
than hostnames)?  RFC = request for comment, so there's my comment!

Chris Davis
Site Engineer
ComputerJobs.com


-----Original Message-----
From: don at news.daedalus.co.nz [mailto:don at news.daedalus.co.nz]
Sent: Thursday, July 18, 2002 9:41 PM
To: comp-protocols-dns-bind at isc.org
Subject: Re: IP addresses in NS records seem to be breaking hostname
resolution


In article <ah6gih$3e7t$1 at isrv4.isc.org>, David Botham <dns at botham.net>
wrote:
>> @	IN	NS 	209.44.8.1
>
>Chris,  It is important to remember that *all numeric* hostnames are
>legal.  Hence, 209.44.8.1 is a perfectly legal hostname even though it
>does not end in a recognizable TLD.  It is not named's responsibility to

Actually, it does end in a recognisable TLD, assuming that the origin is
itself in one.  The data part of the NS above is not rooted, therefore
it's treated as being below the origin.  The above, if the origin was
foo.example, is equivalent to:

	; origin is foo.example.
	foo.example.	IN	NS	209.44.8.1.foo.example.

But, as I said before, you could determine wihtout needing to do any
external lookups that an address record 209.44.8.1.foo.example did not
exist within the zone file being loaded (i.e. foo.example), and that
there was no sub-delegation to another zone that could contain it.  
Therefore, the delegation is invalid and could be reported as such.  It
could just as easily be:

	; origin is foo.example.
	foo.example.	IN	NS	who-me.foo.example.

and the test would still apply of there was no corresponding address 
record for who-me.foo.example.

-- don