Assume a bundy-auth server has authority for the zone “jinmei.org”, which has the following RRs in its data source:
sec.jinmei.org. 600 IN NS ns.sec.jinmei.org.
3600 IN DNAME example.com.
(Note: this is an invalid zone configuration.)
In this case, BIND 9 ignores the NS and exclusively use DNAME for names equal to or under sec.jinmei.org. BIND 10 still returns a NS referral if we ask for sec.jinmei.org/NS.
There are several problems around this symptom:
naively accepting such a broken configuration at parse/load time may not be a good thing anyway (in this sense BIND 9 is also not really good)
but specifically for BIND 10, since the underlying data source may be non captive, the middle layer of the data source module cannot always assume the data stored in data sources is valid anyway. what should we do?
if we decide to accept this type of half-broken configuration, what should b10-auth return? We could add yet another if-block in the data source code to deal with this case, but, personally, I (jinmei) feel the data source code is already messed up with many such case-by-case fixes and has become to complicated to comprehensive and maintain. So I’d rather solve this issue by revisting the whole logic and refactoring the code cleanly (though I’m not sure if it’s a realistic path)
BIND 10 trac # 321
Assume a bundy-auth server has authority for the zone “jinmei.org”, which has the following RRs in its data source:
(Note: this is an invalid zone configuration.)
In this case, BIND 9 ignores the NS and exclusively use DNAME for names equal to or under sec.jinmei.org. BIND 10 still returns a NS referral if we ask for sec.jinmei.org/NS.
There are several problems around this symptom: