Opened 8 years ago

Closed 8 years ago

#1912 closed defect (fixed)

handle type DS query in database-based data sources correctly

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

Description

Not confirmed, but from code inspection I suspect databsrc/database.cc
doesn't handle type DS query correctly; it would consider it a
delegation (or maybe treat it as an error due to the "NS + other"
check in getRRsets()).

This should be corrected.

Subtickets

Change History (9)

comment:1 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20120529

comment:2 Changed 8 years ago by jinmei

  • Owner set to UnAssigned
  • Status changed from new to reviewing

trac1912 is ready for review.

The change is small and should be straightforward.

Proposed changelog entry:

443.?	[bug]		jinmei
	libdatasrc: fixed ZoneFinder for database-based data sources so
	that it handles type DS query correctly, i.e., treating it as
	authoritative data even on a delegation point.
	(Trac #1912, git TBD)

comment:3 Changed 8 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:4 follow-up: Changed 8 years ago by vorner

  • Owner changed from vorner to jinmei

Hello

The code looks clean, but I'm not sure it is doing exactly what is needed. It surely does return the DS record that is sitting on the delegation point. But what if the query is for a name below the delegation point? That one is not authoritative any more and should be delegated. Or, I think so, I didn't read the specs regarding this, it just seems logical.

What I mean is, if I send a query for example.org./DS to the root server, I should be delegated to the org. zone, not get an NXDOMAIN, which is what I think would happen. Also, we should have a test for just that.

Thank you

comment:5 in reply to: ↑ 4 Changed 8 years ago by jinmei

Replying to vorner:

Hello

The code looks clean, but I'm not sure it is doing exactly what is needed. It surely does return the DS record that is sitting on the delegation point. But what if the query is for a name below the delegation point? That one is not authoritative any more and should be delegated. Or, I think so, I didn't read the specs regarding this, it just seems logical.

You're right, and our current implementation ensures that because the
pure delegation case is handled in findDelegationPoint() before
findOnNameResult(), and the former doesn't treat type DS query as a
special case.

I was aware of this possible confusion, but thought it should be
pretty clear from the implementation and didn't bother to add an
explicit test. But now that it's asked explicitly, I've added a test
case for it.

comment:6 Changed 8 years ago by jinmei

  • Owner changed from jinmei to vorner

comment:7 follow-up: Changed 8 years ago by vorner

  • Owner changed from vorner to jinmei
  • Total Hours changed from 0 to 0.65

Thank you, it now looks OK, please merge.

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

Replying to vorner:

Thank you, it now looks OK, please merge.

Merge done, closing.

comment:9 Changed 8 years ago by jinmei

  • Resolution set to fixed
  • Status changed from reviewing to closed
  • Total Hours changed from 0.65 to 2.15
Note: See TracTickets for help on using tickets.