BIND 10 #321: b10-auth doesn't handle mixture of DNAME and NS

BIND 10 Development do-not-reply at isc.org
Fri Aug 27 19:28:44 UTC 2010


#321: b10-auth doesn't handle mixture of DNAME and NS
--------------------------+-------------------------------------------------
  Reporter:  jinmei       |            Owner:                      
      Type:  defect       |           Status:  new                 
  Priority:  major        |        Milestone:  feature backlog item
 Component:  data source  |         Keywords:                      
 Sensitive:  0            |   Estimatedhours:  0.25                
     Hours:  0            |         Billable:  1                   
Totalhours:  0            |         Internal:  0                   
--------------------------+-------------------------------------------------
 See trac #70.

 Assume a b10-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)

-- 
Ticket URL: <http://bind10.isc.org/ticket/321>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list