DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
draft-ietf-dnsext-nsec-rdata-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2004-06-02
|
06 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-06-01
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-06-01
|
06 | Amy Vezza | IESG has approved the document |
2004-06-01
|
06 | Amy Vezza | Closed "Approve" ballot |
2004-05-28
|
06 | (System) | Removed from agenda for telechat - 2004-05-27 |
2004-05-27
|
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2004-05-27
|
06 | Allison Mankin | [Ballot comment] There was a quite clear WG consensus determination on NXT's/NSEC's privacy issues years ago with European regulations and the DNS design in mind … [Ballot comment] There was a quite clear WG consensus determination on NXT's/NSEC's privacy issues years ago with European regulations and the DNS design in mind then. Perhaps the problem was lack of community-wide Last Call at that time. Hmm. |
2004-05-27
|
06 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Yes by Allison Mankin |
2004-05-27
|
06 | Allison Mankin | [Ballot comment] The WG revisiting NO and the privacy issue on NSEC strikes me as an IETF discipline problem. There was a quite clear WG … [Ballot comment] The WG revisiting NO and the privacy issue on NSEC strikes me as an IETF discipline problem. There was a quite clear WG consensus determination on this some years back, with European regulations and the DNS design in mind then. Perhaps the problem was lack of community-wide Last Call at that time. Hmm. |
2004-05-27
|
06 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin by Allison Mankin |
2004-05-27
|
06 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-05-27
|
06 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-05-27
|
06 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-05-26
|
06 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-05-26
|
06 | Harald Alvestrand | [Ballot comment] Reviewed by Mark Allman, Gen-ART Minor things ... + old boilerplate + look for "must" and think about whether it should … [Ballot comment] Reviewed by Mark Allman, Gen-ART Minor things ... + old boilerplate + look for "must" and think about whether it should be "MUST" + the citation to "RFC TCR" since it's an i-d The document seems fine to me. |
2004-05-26
|
06 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-05-26
|
06 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-05-26
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2004-05-26
|
06 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2004-05-26
|
06 | Bert Wijnen | [Ballot comment] Front page (top left) has: Updates: RFC 2535, RFC TCR (if approved) - We normally want the "Updates xxx..." also in the … [Ballot comment] Front page (top left) has: Updates: RFC 2535, RFC TCR (if approved) - We normally want the "Updates xxx..." also in the abstract. I wonder if the security considerations section should have some text about the privacy-concerns that have apparantly been discussed. |
2004-05-26
|
06 | Bert Wijnen | [Ballot comment] Front page (top left) has: Updates: RFC 2535, RFC TCR (if approved) - We normally want the "Updates xxx..." also in the … [Ballot comment] Front page (top left) has: Updates: RFC 2535, RFC TCR (if approved) - We normally want the "Updates xxx..." also in the abstract. |
2004-05-26
|
06 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
2004-05-25
|
06 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2004-05-24
|
06 | Steven Bellovin | [Ballot comment] I'm very concerned by reports that some European sites can't/won't deploy NSEC because they feel it conflicts with European privacy law. I have … [Ballot comment] I'm very concerned by reports that some European sites can't/won't deploy NSEC because they feel it conflicts with European privacy law. I have sympathy for this position -- I wrote my own draft addressing the issue 2.5 years ago. But we have an installed base that uses a similar technique (NXT records), which leaves us with the problem of running code that may not be deployable. |
2004-05-24
|
06 | Steven Bellovin | [Ballot Position Update] New position, Abstain, has been recorded for Steve Bellovin by Steve Bellovin |
2004-05-20
|
06 | Scott Hollenbeck | [Ballot comment] The graphic in section 2.1 should note that the fields are of variable length as described in later text. The length appears to … [Ballot comment] The graphic in section 2.1 should note that the fields are of variable length as described in later text. The length appears to be fixed at 32 units, but no units are specified and there's nothing to note that the fields can be shorter or longer unless one assumes that the "/" characters imply variability. |
2004-05-20
|
06 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-05-20
|
06 | Thomas Narten | [Note]: '2004-05-20: On agenda for next IESG telechat.' added by Thomas Narten |
2004-05-19
|
06 | Thomas Narten | Placed on agenda for telechat - 2004-05-27 by Thomas Narten |
2004-05-19
|
06 | Thomas Narten | State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Thomas Narten |
2004-05-19
|
06 | Thomas Narten | [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten |
2004-05-19
|
06 | Thomas Narten | Ballot has been issued by Thomas Narten |
2004-05-19
|
06 | Thomas Narten | Created "Approve" ballot |
2004-05-14
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-05-14
|
06 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-06.txt |
2004-05-07
|
06 | Thomas Narten | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Thomas Narten |
2004-05-07
|
06 | Thomas Narten | From: Jakob Schlyter To: Thomas Narten Cc: Olaf Kolkman , Margaret Wasserman , Olafur Gudmundsson Date: Thu, 6 May 2004 22:05:19 +0200 Subject: Re: … From: Jakob Schlyter To: Thomas Narten Cc: Olaf Kolkman , Margaret Wasserman , Olafur Gudmundsson Date: Thu, 6 May 2004 22:05:19 +0200 Subject: Re: AD review of draft-ietf-dnsext-nsec-rdata-05.txt > So IETF LC is ending for this document, and I didn't see any comments > (did anyone else)? So am I correct in assuming that this document > needs a revision and then I can send it to the IESG? > > Please confirm (and that the authors agree and understand what changes > are needed). yes, I will make the changes discussed early next week. j |
2004-05-06
|
06 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-04-22
|
06 | Amy Vezza | Last call sent |
2004-04-22
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-04-22
|
06 | Thomas Narten | State Changes to Last Call Requested from AD Evaluation by Thomas Narten |
2004-04-22
|
06 | Thomas Narten | Last Call was requested by Thomas Narten |
2004-04-22
|
06 | (System) | Ballot writeup text was added |
2004-04-22
|
06 | (System) | Last call text was added |
2004-04-22
|
06 | (System) | Ballot approval text was added |
2004-04-20
|
06 | Thomas Narten | State Changes to AD Evaluation from Publication Requested by Thomas Narten |
2004-04-20
|
06 | Thomas Narten | From: Thomas Narten To: Olafur Gudmundsson , Olaf Kolkman , jakob@schlyter.se cc: Margaret Wasserman Date: Tue, 20 Apr 2004 14:56:44 -0400 Subject: AD … From: Thomas Narten To: Olafur Gudmundsson , Olaf Kolkman , jakob@schlyter.se cc: Margaret Wasserman Date: Tue, 20 Apr 2004 14:56:44 -0400 Subject: AD review of draft-ietf-dnsext-nsec-rdata-05.txt I have what I assume are just minor editorial questions/suggestions (see below). If we can get a revised ID out relatively quickly, I'd like to delay the IETF LC until then. But I'm also willing to going forward now with the current draft if revising the document is problematical. Please let me know how you want to proceed. Thomas abstract doesn't satisfy ID nits. neither does title. > This document updates RFC 2535 [3] and RFC TCR [6]. Does this document really update 2535? Seems to me, in _only_ updates [6], since these changes do not apply to NXT. > the name and typecode. The RDATA format for the NXT RR had a > limitation in that, without using a yet undefined extension > mechanism, the the RDATA could only carry information about the > existence of the first 127 types. awkward. Possible replacement: The RDATA format for the NXT RR has the limitation in that the RDATA could only carry information about the existence of the first 127 types. RFC 2535 did reserve a bit to specify an extension mechanism, but the mechanism was never actually defined. > To prevent the introduction of an extension mechanism into a deployed > base of DNSSEC aware servers and resolvers, once the first 127 type > codes are allocated, this document redefines the wire format of the > "Type Bit Map" field in the NSEC RDATA to cover the full RR type > space. better(?): In order to avoid the need to develop an extension mechanism into a deployed base of DNSSEC aware servers and resolvers once the first 127 type codes are allocated, this document redefines the wire format of the "Type Bit Map" field in the NSEC RDATA to cover the full RR type space. > possible range of typecodes, that it is relatively economic in the s/economic/econmical/ > A sender MUST NOT use DNS name compression on the Next Domain Name > field when transmitting an NSEC RR. A receiver which receives an > NSEC RR containing a compressed Next Domain Name field SHOULD > decompress the field value. seems odd that a new RR (not ancient) suggests uncompressing them, when it is clearly a protocol violation to compress them. Seems the last sentence is not appropriate (for NSEC). > Owner names of RRsets not authoritative for the given zone (such as > glue records) MUST NOT be listed in the Next Domain Name unless at > least one authoritative RRset exists at the same owner name. Presumably non-authoritative RRsets have types. Are they included in the type map? In particular, is this question covered by the following text (that occurs later): > Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] > (section 3.1) or within the range reserved for assignment only to > QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in > zone data. If encountered, they must be ignored upon reading. > Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + what does the "+" denote here? Oh. 1 or more, I guess. > [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC > 2308, March 1998. IMO, this reference is not normative. It just explains a SHOULD. |
2004-03-26
|
06 | Thomas Narten | From: "Olaf M. Kolkman" To: "Thomas Narten" , "Margaret Wasserman" Cc: namedroppers@ops.ietf.org, jakob@schlyter.se Date: Wed, 24 Mar 2004 09:16:56 +0100 Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt … From: "Olaf M. Kolkman" To: "Thomas Narten" , "Margaret Wasserman" Cc: namedroppers@ops.ietf.org, jakob@schlyter.se Date: Wed, 24 Mar 2004 09:16:56 +0100 Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson |
2004-03-26
|
06 | Thomas Narten | State Change Notice email list have been change to ogud@ogud.com, okolkman@ripe.net,jakob@schlyter.se from ogud@ogud.com, okolkman@ripe.net |
2004-03-26
|
06 | Thomas Narten | Draft Added by Thomas Narten |
2004-03-12
|
05 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-05.txt |
2004-03-10
|
04 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-04.txt |
2003-12-22
|
03 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-03.txt |
2003-12-17
|
02 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-02.txt |
2003-12-04
|
01 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-01.txt |
2003-12-01
|
00 | (System) | New version available: draft-ietf-dnsext-nsec-rdata-00.txt |