On Apr 1, 2015, at 1:02 AM, Matthijs Mekking <matth...@pletterpet.nl> wrote: > In section 3 (DNS Message Format) the last three paragraphs discusses > "default TTL", Glue records and Referrals. I wonder if that belongs in the > section about DNS Message Format. To me it sounds like it is more suitable to > be put in the Resource Records section or Zones section.
Good point. TTL should be in "Resource Records", and Referral/Glue should be in Zones. > On page 7, about Priming: typo: resolvrer -> resolver. Fixed. > On page 8, Slave is described. We also know this commonly as a Secondary. The > same applies for Master (just one below), it is also referred to as Primary > (However, then this may become confusing with the term below that: Primary > Master). I added the synonym for slave. How do people feel about "primary" and "master"? > On page 12, about NSEC: It would be nice to add a line on what NSEC does: > > NSEC -- Section 3.2 of RFC 4033 has this to say on the subject of > NSEC: "The NSEC record allows a security-aware resolver to > authenticate a negative reply for either name or type non-existence > with the same mechanisms used to authenticate other DNS replies." > In short, The NSEC record was introduced to provide authenticated > denial of existence. > > The NSEC resource record lists two separate things: the next > owner name (in the canonical ordering of the zone) that contains > authoritative data or a delegation point NS RRset, and the set of RR > types present at the NSEC RR's owner name. (Quoted from Section 4 of > 4034) Great! > On page 12, about NSEC3: I think it is valuable to add one or two lines about > the why of NSEC3: > > NSEC3 -- The NSEC3 record also provides authenticated denial of > existence and, in addition, mitigates against zone enumeration (or > "zone walking") and supports Opt-Out. The NSEC3 resource record > looks quite different than the NSEC resource record. NSEC3 resource > records are defined in [RFC5155]. Ditto! > Should we also define zone enumeration? Only if we agree on a definition. Proposal? > On page 13 KSK and ZSK are described. There is also a notion of a Combined > Signing Key (CSK) [1]. In RFC 6781 this is called a Single-Type Signing > Scheme: "In cases where the differentiation between the KSK and ZSK is not > made, i.e., where keys have the role of both KSK and ZSK, we talk about a > Single-Type Signing Scheme." Would it be worth to add this term to this > document? That seems to be a very new term, maybe premature for this document. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
