Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1178 closed task (complete)

NSEC3 support in new data source

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

Description

Like #1176 and #1177, we should also support the ability to include NSEC3 (and
its RRSIG) for negative answers in DatabaseClient::Finder::find() and
when the zone is expected to use NSEC3.
This should be done after #1176. It's probably possible to be done
in concurrent with #1176.

When #1176, #1177 and this task are completed the initial step of
refactoring should be completed (in that it should provide the
same functionality of the current data source with the new API)

Subtickets

Change History (16)

comment:1 Changed 8 years ago by shane

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

comment:2 Changed 8 years ago by stephen

  • Estimated Difficulty changed from 0 to 4

comment:3 Changed 8 years ago by stephen

  • Estimated Difficulty changed from 4 to 5

comment:4 Changed 8 years ago by jelte

  • Milestone changed from Sprint-20110927 to Sprint-20111011

comment:5 Changed 8 years ago by jelte

  • Priority changed from major to minor

comment:6 Changed 8 years ago by jelte

  • Milestone changed from Sprint-20111011 to Sprint-20111025

comment:7 Changed 8 years ago by jelte

As per the discussion on the sprint planning meeting, this ticket will now consist of identifying task needed for this. Once that is done, depending on what needs to be done, we can either make it a meta-ticket (a la #1212) or close this and simply do the created tasks.

comment:8 Changed 8 years ago by kevin_tes

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

comment:9 Changed 8 years ago by jelte

  • Milestone changed from Sprint-20111025 to Sprint-20111108

comment:10 Changed 8 years ago by jelte

  • Milestone changed from Sprint-20111108 to Sprint-20111122

comment:11 Changed 8 years ago by kevin_tes

As RFC 5155(DNS Security (DNSSEC) Hashed Authenticated Denial of Existence)suggests that, there are eight case for NSEC3 Hashed Authenticated Denial of Existence.

First: Name error

If zone is secure and support NSEC3, NSEC3 RRs proves both that QNAME does not exist and that a

wildcard that could have matched QNAME also does not exist,add those to the authority section.[7.2.2]

Second: No data

Include the NSEC3 RR that matches QNAME to the authority section.[7.2.3]

Third: Referrals to unsigned subzone

If there is an NSEC3 RR that matches the delegation name, then that NSEC3 RR MUST be included in the response.
If the zone is Opt-Out, then there may not be an NSEC3 RR corresponding to the delegation. In this case, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. [7.2.7]

Fourth: Wildcard no data

If the zone is secured by nsec3, add nsec3 rr matching QNAME's closest enclosure name and nsec3 rr covering QNAME's next closer name and their signatures to authority section.
If wildcard name found but no QTYPE match, add the nsec3 rr matching wildcard name and its signature to authority section;

Fifth: Wildcard answer

If the zone is secured by nsec3, add nsec3 rr matching QNAME's closest enclosure name and nsec3 rr covering QNAME's next closer name and their signatures to authority section.
If wildcard name and QTYPE found, modify the wildcard rrset name to Qname and add it and its signature to answer section;

Sixth: Wildcard cname answer

If the zone is secured by nsec3, add nsec3 rr matching QNAME's closest enclosure name and nsec3 rr covering QNAME's next closer name and their signatures to authority section.
If the wildcard node match the QNAME and it contains data of RRtype CNAME, copy the CNAME RRset into the answer section, but set its owner to be QNAME.

Since NSEC3 RR was stored by it corresponding hash codes,it should add a ticket to done this work when the zone supports NSEC3,it can generate the hash(QNMAE),to query.

Both Query::process() and find() need update.

If no dispute about the above, i will generate 13 tickets:

First: Name error, both Query::process(),find() need to update ,there add 2 tickets.
Second: No data,both Query::process(),find() need to update ,there add 2 tickets.
Third: Referrals to unsigned subzone,both Query::process(),find() need to update ,there add 2 tickets.
Fourth: Wildcard no data,both Query::process(),find() need to update ,there add 2 tickets.
Fifth: Wildcard answer,both Query::process(),find() need to update ,there add 2 tickets.
Sixth: Wildcard cname answer,both Query::process(),find() need to update ,there add 2 tickets.

Total:13 tickets.

comment:12 Changed 8 years ago by kevin_tes

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

comment:13 Changed 8 years ago by stephen

  • Owner changed from UnAssigned to stephen

comment:14 Changed 8 years ago by stephen

  • Owner changed from stephen to kevin_tes

Some points on the task breakdown above:

  • Many of the responses require a "closest encloser" or "closest provable encloser" proof which returns up to two RRs. I would suggest that one of the tasks be to write the code that will retrieve these RRs. This can then be used in the tasks listed above.
  • As you suggest, the code needs the hashing function in order to operate; that may already be available in a usable form in the code. If not, it needs to be written/modified. (Included in this task may also be the selection of the NSEC3PARAM record - it is allowable for there to be multiple NSEC3PARAM records - and hence NSEC3 chains - in the zone.)
  • The "Fourth: Wildcard no data" section implies there are two separate cases (two sentences start with "If"). In fact it is one case - the response should include the closest encloser proof and the NSEC3 RR that matches the wildcard.
  • Is the sixth case "Wildcard CNAME answer" really a separate case from the fifth case (wildcard answer) - CNAME is not mentioned as a special case in RFC 5155 except in the context of ensuring that the CNAME bit is not set in the Type Bit Maps field.

I have been through RFC 5155 and have summarised its detailed requirements. I think there are two other cases (listed in the section on "Inclusion of NSEC3 Records in Responses from Authoritative Server"):

If no dispute about the above, i will generate 13 tickets:

Finally, perhaps one ticket for each feature (instead of one for find() and one for process()) as the two are closely linked.

A step-by-step approach is sensible, although to avoid people getting in each other's way (as each change is likely to make detailed changes to the find() and process() methods), we might find it easier to do these tickets sequentially.

comment:15 Changed 8 years ago by stephen

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

Tasks created: #1431 through #1438.

comment:16 Changed 8 years ago by shane

  • Feature Depending on Ticket set to NSEC3
Note: See TracTickets for help on using tickets.