On Jun 16, 2015, at 3:50 AM, Tony Finch <[email protected]> wrote: > > Paul Hoffman <[email protected]> wrote: >> >>> "Name Error" as a synonym for NXDOMAIN seems like it is worth >>> including, somewhere. >> >> Are you sure that "name error" always refers to NXDOMAIN? If not, this >> is not a can of worms we should open. > > Absolutely. RFC 1035 section 4.1.1: > > RCODE Response code - this 4 bit field is set as part of > responses. The values have the following > interpretation: > > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist.
Got it. Added to the current meager text for NXDOMAIN. > >>> 5. DNS Servers >>> >>> There are documented uses of "iterative mode resolvers" to mean >>> exactly "recursive mode resolvers" as defined in this section. I had >>> only ever heard the phrase as a knee-jerk objection to the observation >>> that "recursive servers" don't recurse, they iterate. I mention this >>> just in case "iterative mode" as described here does not have a posse. >> >> This has been deferred to the -bis document because of disagreement. > > I think the definitions in the current draft will cause confusion rather > than clearing it up, and fixing them in -bis will be too late, considering > how non-IETF people treat RFCs like stone tablets handed down on a > mountain. The latter is a good point. Because we are pretty sure there will be a -bis, and that it will have new material not just corrections, we should say so right at the top of this document. > >>> There is no mention of "authority-only servers", which I find to be in >>> common usage. >> >> That term appears in exactly one RFC, of which you are co-author. > > "authoritative-only" appears in 7 RFCs. There's a reasonable definition in > RFC 4697 section 2.4 > > [...] > "authoritative-only" name servers, which only serve authoritative > data and ignore requests for recursion. Such an entity will not > normally generate any queries of its own. Instead it answers non- > recursive queries from iterative resolvers looking for information in > zones it serves. That sounds good. Added. > >>> "Wildcard" does not actually have a definition listed; just a note >>> that earlier attempts at providing a definition have been problematic. >>> While the text here seems entirely agreeable, it seems like it would >>> be nice to present at least a cursory definition in this document, >>> even if it needs provisos and references. > > I agree with Joe. Even if the RFC 1034 definition is problematic for > implementers, it's perfectly good for getting the point across to > hostmasters. > > Wildcard: Special treatment is given to RRs with > owner names starting with the label "*". Such RRs are called > wildcards. Wildcard RRs can be thought of as instructions for > synthesizing RRs. (quoted from [RFC1034] section 4.3.3) For an > extended discussion of wildcards see [RFC4592]. OK, we can add this, at the risk of confusing folks more. > >>> "NSEC3": whether not NSEC3 is "quite different" from NSEC depends on >>> your context. Functionally, in the narrow sense of "allows verifiable >>> denial of existence", they are identical. I think it would be clearer >>> to focus on their functional similarities, and point out the >>> additional features of NSEC3 (opt-out and making zone enumeration >>> harder), observing that any particular signed zone must use exactly >>> one of these, not both (so, they are alternatives, and one of them is >>> required). >> >> Disagree. Even in the "allows verifiable denial of existence", they are >> quite different in that the processing needed is very different. The >> "fundamental similarities" are only in what is achieve, not in the way >> of achieving it. > > I agree with Joe, I think the first sentence of the NSEC3 definition > doesn't actually add any information to what is covered by the rest of the > definition. Noted; removed. > > Possibly worth adding: > > [RFC7129] provides additional background commentary and some > context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide > authenticated denial-of-existence responses. Good addition, yes. > > (quoted from its abstract) > >>> "Opt-out": It would be helpful I think to include a sentence or two >>> that illustrates the point of opt-out, e.g. that in a >>> delegation-centric zone with relatively few secure delegations, use of >>> opt-out can reduce the overhead of DNSSEC on zone size. >> >> I searched for supporting material in RFC 5155 that could explain why to >> use opt-out in words that would make sense in this document; I failed. >> If you find some, that would be great. > > Opt-out: The Opt-Out Flag indicates whether this NSEC3 RR may cover > unsigned delegations. (Quoted from [RFC5155], section 3.1.2.1.) > > Opt-out tackles the high costs of securing a delegation to an > insecure zone. When using Opt-Out, names that are an insecure > delegation (and empty non-terminals that are only derived from > insecure delegations) don't require an NSEC3 record or its > corresponding RRSIG recors. Opt-Out NSEC3 records are not able to > prove or deny the existence of the insecure delegations. (Adapted > from [RFC7129] section 5.1) That seems like a good addition as well. Thanks! --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
