Opened 9 years ago

Closed 5 years ago

#321 closed defect (wontfix)

b10-auth doesn't handle mixture of DNAME and NS

Reported by: jinmei Owned by: UnAssigned
Priority: medium Milestone: DNS Outstanding Tasks
Component: data source Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.25 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

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)

Subtickets

Change History (9)

comment:1 Changed 9 years ago by stephen

  • Milestone feature backlog item deleted

Milestone feature backlog item deleted

comment:2 follow-up: Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Milestone set to New Tasks
  • Owner set to jinmei
  • Status changed from new to assigned
  • Sub-Project set to DNS

Even without non-captive data sources, we could be acting as a secondary for a server with such a broken configuration, so we need to handle it in the most logical way possible.

Anyway, there has been a revisit of the whole logic and a refactoring of the code. Does this issue still exist? (I admit I am lazy and did not load such a zone to check, sorry!)

comment:3 in reply to: ↑ 2 Changed 8 years ago by jinmei

Replying to shane:

Even without non-captive data sources, we could be acting as a secondary for a server with such a broken configuration, so we need to handle it in the most logical way possible.

Anyway, there has been a revisit of the whole logic and a refactoring of the code. Does this issue still exist? (I admit I am lazy and did not load such a zone to check, sorry!)

Not checked the behavior with a running system either, but according
to the code:

  • in-memory data source rejects loading such a zone in the first place
  • database-based data source prefers NS over DNAME.

Considering the case of non-captive database backend, handling this
case somehow is probably okay, and which behavior wouldn't matter much
as it's half broken anyway. So we should probably be consistent with
BIND 9 and explicitly document it somewhere. That may go to a
separate task?

comment:4 Changed 8 years ago by jinmei

  • Owner changed from jinmei to shane

comment:5 Changed 8 years ago by shane

  • Defect Severity changed from N/A to Medium
  • Milestone New Tasks deleted
  • Owner changed from shane to UnAssigned

Actually I think it is okay to leave on this task.

comment:6 Changed 6 years ago by shane

  • Milestone set to Sprint-20131015
  • Summary changed from b10-auth doesn't handle mixture of DNAME and NS to [kean] b10-auth doesn't handle mixture of DNAME and NS

This ticket involves:

  • Reading the BIND 9 code to see what the behavior is when we get such a broken zone (note that BIND 9 uses stricter rules when reading from zone files then when acting as a secondary).
  • Checking the b10-auth to see what our behavior is in this case.
  • Documenting the BIND 9 behavior and changing the b10-auth to duplicate that (if necessary).

comment:7 Changed 6 years ago by kean

  • Summary changed from [kean] b10-auth doesn't handle mixture of DNAME and NS to b10-auth doesn't handle mixture of DNAME and NS

comment:8 Changed 6 years ago by stephen

  • Milestone changed from bind10-1.2-release-freeze to DNS Outstanding Tasks

comment:9 Changed 5 years ago by tomek

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

DNS and BIND10 framework is outside of scope for Kea project.
The corresponding code has been removed from Kea git repository.
If you want to follow up on DNS or former BIND10 issues, see
http://bundy-dns.de project.

Closing ticket.

Note: See TracTickets for help on using tickets.