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

Chris Davis chris.davis at computerjobs.com
Wed Jul 17 20:17:53 UTC 2002



>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? 

The bad NS records are unresolvable but they are accepted and kept in the
cache and are tried until they expire, resulting in name resolution failure.
I would prefer the bad NS records be either:

1- flatly rejected via a "let me see if these contain something other than
just dots and numbers before I cache them" routine

 or

2- dumped if they're all discovered to be unresolvable after they're tried
via a "well heck, I tried all the NSes for this domain but none worked, so
I'm dumping these NS records from my cache" routine.  Where's the sense in
bind holding onto known unresolvable NS RRs?

 or

3- refused by named at startup on the server with the bad NS records.

>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.

The only broken records are NS (and SOA but that's another story).  The A
and MX records that I need are good.  It's not useless at all.  It's just a
little broken but in a very unfortunate way.

> Seems 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_...

That's not all I want.  I also cannot pull up their website with the bad NS
records in my dns cache, making it a browser issue in addition to being a
mail issue, if it's not a dns issue.

However, it is a DNS issue.  

In my opinion, bind should reject malformed NS records rather than inserting
them into the cache, dump them from the cache after they're deemed to be
unresolvable, or alternatively, named should refuse to load zones with
malformed NS records.

Refusal by named to load zone with bad NS RRs is probably the most likely
not to violate RFCs, but it's also the least effective near term solution
because it depends on admins of defective zones to upgrade their bind
versions to a version with the new feature.  Long term, the "named refuses
to load zones with defective NS RRs" routine seems like the best solution to
minimize the problem.

Chris Davis






More information about the bind-users mailing list