BIND 10 #70: auth server doesn't handle NS query at a zone cut correctly

BIND 10 Development do-not-reply at isc.org
Thu Apr 1 22:09:15 UTC 2010


#70: auth server doesn't handle NS query at a zone cut correctly
--------------------------+-------------------------------------------------
 Reporter:  jinmei        |        Owner:  each                         
     Type:  defect        |       Status:  assigned                     
 Priority:  major         |    Milestone:  03. Authoritative-only server
Component:  Unclassified  |   Resolution:                               
 Keywords:                |    Sensitive:  0                            
--------------------------+-------------------------------------------------

Comment(by jinmei):

 Replying to [comment:12 each]:

 > > I'm afraid you missed my point or I was not clear enough.  What I
 tried to point out is that if the zone was incorrectly set up with the
 following:
 > > [...]
 > > In this case, BIND 9 ignores the NS and exclusive use DNAME for names
 equal to under sec.jinmei.org.  BIND 10 still returns a NS referral if we
 ask sec.jinmei.org/NS.
 >
 > Ah, I see your point now.  Yes, you're right about that last point.
 >
 > If findRRest() returns SUCCESS, that means that there was a DNAME.
 Since the REFERRAL flag is always set if there's a DNAME, that's not
 evidence that the zone is broken.
 >
 > If the zone *is* insane, and there is both a DNAME and NS at the same
 node, the server will usually do the right thing.  For example, if you
 query for foo.sec.jinmei.org/A, the server will process the DNAME and send
 you to foo.example.com, and the spurious NS record will be ignored.
 >
 > However, if you explicitly query for sec.jinmei.org/NS, it will give you
 an answer.  Oops.  I think we should make a note of this and address it in
 Y2, so we have time to be sure the solution is complete.

 (Although it's already in Y2:-) that's fine with me.  Basically, I think
 we should revisit the whole query processing logic in Y2 rather than
 handling each and every bug like this in a case by case manner.  That is,
 we should redesign the architecture of a zone (in BIND10 datasource)
 taking into account lessons we've learned so far.

 > (BTW, will BIND9 load a zone like that?  It seems like it ought to be
 forbidden at load time.)

 Yes, surprisingly to me.  I'd say it's a bug of BIND9.

-- 
Ticket URL: <http://bind10.isc.org/ticket/70#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list