How to make Bind 9 "more clever" ?
Jim Reid
jim at rfc1035.com
Wed Oct 16 12:10:09 UTC 2002
>>>>> "Simon" == Simon Waters <Simon at wretched.demon.co.uk> writes:
>> Bind 9 seems to be more strict, so it will not reply
>> answer. Most of the cases, the remote domain's name servers are
>> not all setting correctly or dead.. However, Bind 8 still
>> answer the answer of such domains. How to config Bind 9 to be
>> as "clever" (or maybe "loose") as Bind 8?
Simon> The only problem of this type I've seen is when a zone
Simon> contains an empty list of nameservers. BIND 9 believes the
Simon> empty answer, BIND 8 will restart with the glue from the
Simon> zone above, and ignore the lack of name servers for a
Simon> domain.
This is to be expected. The child zone -- the definitive source of
information for that zone -- contains no NS records. That means
resolving name servers get told authoritatively there are no name
servers for the zone, which is clearly wrong. However the resolving
name server can only believe the answers it is given: garbage-in,
garbage-out. Even if BIND8 restarts the resolution with glue from the
parent, the end result should be the same. All the child zone's
servers should be serving the same zone data which says the zone has
no NS records.
Simon> I know of no workaround in BIND 9 other than fixing the
Simon> zone (which has much to recommend it).
Absolutely. The child zones are broken. They should be fixed. End of
story. This would be a lot quicker than implementing a kludge in BIND9
to tolerate such an aberrant configuration. And even if such a thing
was provided, it would start a slide down a very slippery slope. How
many other fundamentally broken setups should BIND9 accept? Zones with
no SOA record perhaps?
Simon> Either behaviour would appear to meet the RFC's by my
Simon> reading, RFC1034/1035 are a little vague on what
Simon> constitutes bad enough to ignore.
RFC1034 says fairly clearly that the NS records in the child zone are
definitive:
The authoritative data for a zone is simply all of the RRs
attached to all of the nodes from the top node of the zone
down to leaf nodes or nodes above cuts around the bottom edge
of the zone.
Though logically part of the authoritative data, the RRs that
describe the top node of the zone are especially important to
the zone's management. These RRs are of two types: name
server RRs that list, one per RR, all of the servers for the
zone, and a single SOA RR that describes zone management
parameters.
So if a child zone contains no NS records, it is irredeemably broken.
The NS records in the parent for a delegation are not part of the
parent's authoritative data. They're beneath the zone cut. The
definitive information about the delegation lives at the top of the
child zone. In this case, that info is in the children's zone files
that have no NS records.
Simon> I suspect BIND 9 does it this way, as it would make more
Simon> sense with DNSSEC when the answers would be unusuable I
Simon> suspect.
BIND9 provides the correct semantics at a zone cut. BIND8 didn't. The
behaviour in BIND9 is the right thing to do. This also has the side
effect of making BIND9 work properly for DNSSEC.
More information about the bind-users
mailing list