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.
> > 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 <[email protected]> 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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
