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

[Chris Davis]

> >
> >         Actually 209.44.8.1 isn't a hostname.  Go read RFC 1123 again.
>
>OK, then Chris's point is valid.  Right?  an NS record like:
>
>@	IN	NS	192.168.10.20.
>
>Could legally be a basis to either reject the zone on load, and/or
>reject the record as mal-formed and a name server refuse to cache it.  
>

And an NS record config of this type *should* by default cause a zone to
fail load, because otherwise the only way the (small time) dns operator (who
is most likely to make this configuration error) will ever know anything is
wrong is if someone else from somewhere else calls him and tells him about
it.

The operator's log files will show nothing other than the good resolutions
that occur when clients are using the NS RDATA provided the GTLDs to contact
his dns server and ask for some records.  Once the bad NS RDATA is shipped
out to the clients with the answer their initial requests, the servers
running the bad zones never see requests from those clients again (until the
distant future after the bad NS RDATA expires and everything works again for
a single iteration) and thus are completely unaware there is anything wrong,
and the operator is entirely convinced nothing at all is wrong because his
log files show plenty of successful resolutions from all over the place!

Bind not loading a zone with this type of NS record will short circuit the
whole discovery process for the operator of the zone with the broken NS
RDATA from "days, months, years or never" to "immediate" when he's stuck
with a zone that errors out on load due to the fatal error.

-Chris Davis