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

[Tony Finch <[e-mail]>]

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.

> > 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.

> > 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.

> > "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].

> > "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.

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.

(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)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Fisher: Northwest 5 or 6, backing west 4 or 5, backing southwest 5 or 6 later.
Moderate. Rain later. Good, occasionally moderate later.