Opened 9 years ago

Closed 9 years ago

#1063 closed task (complete)

support delegation (NS and DNAME) case for DatabaseZoneHandle::find()

Reported by: jinmei Owned by: vorner
Priority: medium Milestone: Sprint-20110816
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: 4.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

It should run label by label match for both NS and DNAME. At this
moment, glue records don't have to be considered.

This task depends on #1060, #1061, #1062.

Subtickets

Change History (10)

comment:1 Changed 9 years ago by stephen

  • Estimated Difficulty changed from 0.0 to 4

comment:2 Changed 9 years ago by stephen

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

comment:3 Changed 9 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:4 Changed 9 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to reviewing

Hello

This should be ready for review. I must admit the interface of getRRset (a method that scans single domain and finds some RRset in it) isn't really clean, but I didn't think of any better which wouldn't be overcomplicated with objects, etc.

I tried to think of several corner-cases what to test, do you have any idea for more of them?

Should I split the test function? It is getting rather long.

Thank you

comment:5 Changed 9 years ago by jelte

  • Owner changed from UnAssigned to vorner

Again, I pushed some small style fixes.

This may start to get complicated enough to start adding some trace-level logging in find()

I must say I can't immediately think of a much better interface for getRRset()
right now, normally one would use a bitwise flags argument if there are multiple
'options' like this, but direct booleans seem easier given the way is is used.

Regarding tests, splitting them up is probably a good idea :)

One thing we could add is a test where some data is 'hidden' by a delegation (i.e. what happens if i have a bad zone example.org with

sub.example.org. NS ns.foo.bar
www.sub.example.org. A 192.0.2.1

because of the delegation that A record is out-of-zone data, and a good
zone-reader should not accept it, but we may not have control over the db since
we go top down i guess it should just give back the delegation and ignore the
record, but it is a test we can add.

Oh and the somewhat simpler query-for-multiple-levels-below-delegation perhaps, as another
'corner' case (a simple some.levels.below.delegation.example.org. would suffice i think).

For the rest it looks OK.

comment:6 follow-up: Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

The test for below delegation was already there (direct request for ns.delegation.example.org), I added the ones for deeper down. And it isn't broken data, it's glue data ;-)

comment:7 in reply to: ↑ 6 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

Replying to vorner:

The test for below delegation was already there (direct request for ns.delegation.example.org), I added the ones for deeper down.

Yes that's what I meant, cool.

And it isn't broken data, it's glue data ;-)

broken glue data then :p

One final request, can you add the dbname to the log output? (like the first arguments in the other log calls in database.cc)

comment:8 Changed 9 years ago by vorner

  • Owner changed from vorner to jelte

Ah, right, done.

comment:9 Changed 9 years ago by jelte

  • Owner changed from jelte to vorner

ok, lookin good, please go ahead and merge

comment:10 Changed 9 years ago by vorner

  • Resolution set to complete
  • Status changed from reviewing to closed

Thanks, closed

Note: See TracTickets for help on using tickets.