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