IP addresses in NS records seem to be breaking hostname resolution

[Kevin Darcy]

David Botham wrote:

> > -----Original Message-----
> > From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> > Behalf Of Kevin Darcy
> > Sent: Wednesday, July 17, 2002 3:38 PM
> > To: bind-users at isc.org
> > Subject: Re: IP addresses in NS records seem to be breaking hostname
> > resolution
> >
> >
> > Chris Davis wrote:
> >
> > > Thank you, David.  Hopefully the phone call from an objective third
> > party
> > > will get them motivated!
> > >
> > > Unfortunately, when I've e-mailed them, and when my "technical
> liason"
> > and I
> > > have spoken with them on the phone, we have had no luck.  Since
> > > nslookup/dig/host tells them their host records resolve fine, the
> > problem is
> > > mine from their point of view.
> > >
> > > That's why I'm looking for something I can do on my side, without
> > boogering
> > > up my configuration, to have the bad NS records rejected or at least
> > dumped
> > > from the cache after failure.
> > >
> > > Hosting my own pacetech-inc.com zone file, though a possibility,
> opens a
> > > door to headaches that I don't care to open.  As time marched on and
> I
> > ran
> > > across more companies with misconfigured NS records, I'd accumulate
> more
> > > than a few zone files for zones that are not mine.
> > >
> > > So, my question is still out there.  Is there any way to reject or
> dump
> > the
> > > bad NS records that contain IP addresses rather than hostnames?
> > >
> > > Of 6,667 NS records in my resolver's cache yesterday, 15 had I.P.
> > addresses
> > > rather than hostnames.  I'd imagine everyone's dns caches look about
> > like
> > > that everywhere percentage wise, statistically speaking.
> > >
> > > 15 of 6,667 being wrong is only two tenths of one percent, which
> isn't
> > much,
> > > but this 2/10 of 1% of failed lookups could be solved if there were
> a
> > way to
> > > dump or reject the bad NS records and use the correct NS records
> > provided by
> > > the GTLD servers.
> > >
> > > These dns failures are exacerbated with multiple failed attempts to
> send
> > > mail, and then support calls and research about lost mail, and now
> this
> > > discussion thread involving all of you!
> > >
> > > It's not my misconfiguration, and it's been very difficult (read
> > > "impossible") to convince the other guy it's his misconfiguration
> > because
> > > everything resolves fine at first glance.  It's caused me some
> > headaches.
> > > I'd like some legitimate defense against it.
> > >
> > > My bet is that everyone everywhere is experiencing a "not
> insignificant"
> > > amount of failures due to this type of problem.
> > >
> > > Would a new bind feature to dump or reject invalid NS records be in
> > order?
> > > Or is there in fact a way to do this already?
> > >
> > > Chris Davis
> > > Site Engineer
> > > ComputerJobs.com
> > >
> > > -----Original Message-----
> > > From: David Botham [mailto:dns at botham.net]
> > > Sent: Wednesday, July 17, 2002 12:08 PM
> > > To: bind-users at isc.org
> > > Subject: RE: IP addresses in NS records seem to be breaking hostname
> > > resolution
> > >
> > > As a follow up, I forwarded this thread to both the soa responsible
> > > email and whois responsible email.  And as an extra bonus, I called
> the
> > > whois admin contact on the phone.  He was happy to here from me and
> said
> > > he would call his ISP and light a fire under...
> >
> > I'm not sure what you're trying to accomplish here. "Reject or dump"
> bogus
> > NS records? The NS records are already unresolvable, how much more
> > "rejection"
> > do you want? If an NS RRset consists of mixture of good and bad names,
> > nameservers will automatically find the good ones after maybe a few
> wasted
> > queries; if the RRset contains only bad names, it's useless anyway.
> Seems
>
> I think what Chris is saying is that the NS RR set obtained from the
> child name servers consisted of only bad names, however, the NS RR set
> obtained from the parent (gtld name servers) contained good ones.  He
> would like to be able to tell bind, to "ignore the child and listen to
> the parent" (if I read him correctly).  I think the point here is that
> "good" information exists from someone who does have some authority in
> the situation and it would be nice to use it.  On the other hand, "bad"
> information is also available from someone who also has authority.  The
> question is, who has more authority, the parent or the child?  Or more
> to the point, who really owns those NS RR's; the owner of the parent
> domain or the delegated domain?
>
> > like
> > what you really want here is a "treat DNS failure as a fatal
> > error" option/setting in your mailer software. That's not really a DNS
> > issue,
> > _per_se_...
> >
> > If you wanted to massively kludge this using DNS, you could a) define
> all
> > 256
> > last-octet TLDs (i.e. the "0" through "255" TLDs) privately on your
> > nameserver,
> > with each zone containing a wildcard pointing to one of your IP
> addresses,
> > b) run a specially-configured nameserver on that IP address, with a
> single
> > root
> > wildcard MX record -- maybe 2 for redundancy :-) -- pointing to the
> > address of
> > a specially-configured mailserver, c) have this mailserver bounce or
> > simply
> > discard any mail sent to it (call it "blackhole").

RFC 2181 is clear on this: authoritative data from the zone itself is more
"credible" than (ranked higher than, replaces) data from referrals.
Throwing away authoritative data based on some heuristic (e.g. "all-numeric
names look suspicious") and falling back to referral data, is clearly not
conformant with the RFC. Zone maintainers already have plenty of ways to
shoot themselves in the foot; this is just one example among many, and is
in the long run self-correcting.

This is an operational problem. Lets not break the standards trying to work
around it.


- Kevin