How to make Bind 9 "more clever" ?

[Jim Reid]

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