Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

[Paul Hoffman <[e-mail]>]

On Jun 16, 2015, at 3:50 AM, Tony Finch <[e-mail]> wrote:
> 
> Paul Hoffman <[e-mail]> 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