BIND 10 #987: b10-auth should chase CNAME in the same zone
BIND 10 Development
do-not-reply at isc.org
Thu Jun 2 23:15:24 UTC 2011
#987: b10-auth should chase CNAME in the same zone
-------------------------------------+-------------------------------------
Reporter: | Owner:
jinmei | Status: new
Type: | Milestone: Year 3 Task
defect | Backlog
Priority: major | Resolution:
Component: | Sensitive: 0
b10-auth | Sub-Project: DNS
Keywords: | Estimated Difficulty: 0.0
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by each):
Replying to [comment:2 jinmei]:
> I think I understood the so called security discussion, but as I think
> I stated at that time the security argument for the chain from the
> same zone (from the point of the auth server) isn't convincing. But I
> like keeping the implementation simpler, so I'd support the idea of
> cutting the chain itself for the different reason. So I prefer option
1.
> If we have some reason for b10-auth to return a longer chain, I'd
> rather keep it as simple as possible, i.e, unconditionally do so
> rather than adding an addition condition check for the RD bit.
I essentially agree with this. (I do find the security argument somewhat
compelling, but not especially urgent.)
I haven't recently looked at BIND 10 to see how fully it supports CNAME
chains. I know that in-zone CNAME chains are provided in full by the
original sqlite3 data source code Michael and I wrote, and I gather they
are not provided by the memory data source code that has supplanted it. I
assume that our old plan of having b10-auth only serve authoritative data
and a separate b10-recurse daemon for recursion is still operative. If
those assumptions are correct, then I recommend taking no action to add
CNAME chain support to b10-auth (but do of course make sure b10-recurse
behaves correctly).
The subject header of this ticket specifies b10-auth, so for ''this''
ticket, I recommend no work be done at this time, and that the ticket be
closed.
--
Ticket URL: <http://bind10.isc.org/ticket/987#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list