Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#987 closed defect (wontfix)

b10-auth should chase CNAME in the same zone

Reported by: jinmei Owned by:
Priority: medium Milestone:
Component: b10-auth Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

We discussed this before, and it was open at that time.

According to a recent incident report with BIND 9, there seems to be a
user who relies on getting the chain (at least from the same zone)
even from an authoritative server, so we should support it.

See: https://lists.isc.org/pipermail/bind-users/2011-May/083715.html

Subtickets

Change History (6)

comment:1 in reply to: ↑ description ; follow-up: Changed 9 years ago by each

Replying to jinmei:

We discussed this before, and it was open at that time.

According to a recent incident report with BIND 9, there seems to be a
user who relies on getting the chain (at least from the same zone)
even from an authoritative server, so we should support it.

This is not quite correct. The issue in BIND 9 is that a server can be configured to be both recursive and authoritative. If a server is authoritative for example.com, and receives a request for data in example.com from one of its recursive clients with RD set, then of course it should answer as a recursive server would: with a complete CNAME chain.

But there was a bug in the interface between the BIND 9 recursive query code and the authoritative server code, so that the authority part didn't always give the full chain back to the recursive part. If this had been an interaction between a recursive server and a separate authoritative server, then the recursive server would simply have sent another query for the target name, and assembled the CNAME chain that way. (In fact, it would probably do this even if it had received a complete CNAME chain from the authority server, as the authoritative response isn't necessarily trustworthy for the target name.) But, as this particular recursive server was querying itself, it assumed it had received all the information the authoritative server had, and it returned a broken chain.

What BIND 10 needs to do is ensure that a recursive (RD=1) request gets a complete chain. RD=0 requests don't need to. There may be a slight performance benefit to providing one when possible, but there are costs in security and complexity that IMHO outweigh it.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 9 years ago by jinmei

Replying to each:

But there was a bug in the interface between the BIND 9 recursive query code and the authoritative server code, so that the authority part didn't always give the full chain back to the recursive part. If this had been an interaction between a recursive server and a separate authoritative server, then the recursive server would simply have sent another query for the target name, and assembled the CNAME chain that way. (In fact, it would probably do this even if it had received a complete CNAME chain from the authority server, as the authoritative response isn't necessarily trustworthy for the target name.) But, as this particular recursive server was querying itself, it assumed it had received all the information the authoritative server had, and it returned a broken chain.

Thanks for the clarification, but I'm afraid I really don't understand
how it's related to the internal interaction betwen the hybrid
configuration of auth and recursive in BIND 9.

According to Mark:
https://lists.isc.org/pipermail/bind-users/2011-May/083723.html
"it was a simple bug", and this fix doesn't seem to be relevant to
such an interaction. And, in fact, 9.8.0-P2 with this patch returns a
full chain whether or not the query has the RD bit on.

But in any event. I knew returning a full chain only (in practice)
matters for a query with RD being on. Maybe what you tried to point
out is that this incident was a real problem because the BIND 9 named
in question is a hybrid auth/recursive server and it's not the case
for b10-auth (by definition). If so, I see the point. And if so,

What BIND 10 needs to do is ensure that a recursive (RD=1) request gets a complete chain. RD=0 requests don't need to. There may be a slight performance benefit to providing one when possible, but there are costs in security and complexity that IMHO outweigh it.

for b10-auth I'd rather either

  1. keep the current implementation (because this wouldn't be a problem for an authoritative *only* server), or
  2. always return a full (as much as possible) chain regardless of RD

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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 9 years ago by each

Replying to 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.

comment:4 in reply to: ↑ 3 Changed 9 years ago by jinmei

Replying to each:

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).

I believe the assumption still holds (and if not we'll need to tweak
many other things anyway, so not touching this part at the moment
won't be harmful).

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.

Fair enough. Closing

comment:5 Changed 9 years ago by jinmei

  • Resolution set to wontfix
  • Status changed from new to closed

comment:6 Changed 9 years ago by shane

  • Milestone Year 3 Task Backlog deleted
Note: See TracTickets for help on using tickets.