On Tue, Sep 10, 2019 at 08:45:36PM -0700, [email protected] wrote:
> Filename : draft-ietf-dnsop-extended-error-09.txt
Introduction 3rd paragraph (missing verb, extra period):
[...] These extended DNS error codes [are?] described in this
document and can be used by any system that sends DNS queries
and receives a response containing an EDE option.. [...]
With respect to the much discussed caveat:
This document does not allow or prohibit any particular extended
error codes and information be matched with any particular RCODEs.
Some combinations of extended error codes and RCODEs may seem
nonsensical (such as resolver-specific extended error codes in
responses from authoritative servers), so systems interpreting the
extended error codes MUST NOT assume that a combination will make
sense. Receivers MUST be able to accept EDE codes and EXTRA-TEXT in
all messages, including even those with a NOERROR RCODE.
My take is that when the (12 bit EDNS) RCODE and new extended error
are in apparent conflict, I should treat the RCODE as definitive,
and ignore the extended error code. That is, the extended error
can *refine* but not contradict the status indicated by the RCODE.
If that's correct, perhaps it should be stated explicitly. If not
correct, then a clarification is perhaps still in order.
Section 2, 3rd bullet: s/index to/index into/
The INFO-CODE serves as an index to the "Extended DNS
Errors" registry Section 4.1.
Section 2, 4th bullet: s/be take/be taken/
Care should be take not to leak private information that an
observer would not otherwise have access to, such as account
numbers.
I find "such as account numbers" a bit of a non sequitur (what
account numbers?) I'd drop this, or produce a more transparent
example.
Section 3.2 (code 2), may warrant more guidance on when this is
appropriate. AFAIK, there is nothing wrong with all DNSKEY algorithms
being unsupported, provided the same holds for the DS RRset. So,
while I see a use-case for code 3 (all DS unsupported, perhaps to
signal why the AD bit is not set, despite the non-empty DS RRset),
I don't understand when one would use code 2.
Section 3.6, code 6 (indeterminate answer) needs clarification,
since there is no single defintion of "indeterminate" in DNSSEC.
In particular different definitions are given in RFCs 4034 and
4035 (as explained in <https://tools.ietf.org/html/rfc7672#section-2.1.1>).
My take is that with the root zone signed, the 4033 definition
is obsolete, and the correct one is 4035. This should probably
be made explicit:
4035 "indeterminate":
An RRset for which the resolver is not able to determine whether
the RRset should be signed, as the resolver is not able to obtain
the necessary DNSSEC RRs. This can occur when the security-aware
resolver is not able to contact security-aware name servers for
the relevant zones.
4033 "indeterminate":
There is no trust anchor that would indicate that a specific
portion of the tree is secure.
Section 3.8, the text reads:
The resolver attempted to perform DNSSEC validation, but a signature
in the validation chain was expired.
However, there are recent observations of domain where each RRset was
accompanied by both expired *and* unexpired RRSIGs.
https://twitter.com/VDukhovni/status/1171170411712827393
So just *an* expired signature is not really a problem provided
another signature for the same RRset is not expired. So I think
the text could more clearly read "but *all* signatures for an
RRset in the validation chain expired", or some such.
Section 3.13: the text reads:
The resolver attempted to perform DNSSEC validation, but the
requested data was missing and a covering NSEC or NSEC3 was not
provided.
I think that "missing" can be misleading, it is not that the
answer is "missing" from the response, but rather that the
response affirmatively denies the existence of the requested
RRset. So perhaps "but the response denies the existence of
the requested RRset" or something similar.
I find the two sections:
3.16. Extended DNS Error Code 15 - Blocked
3.17. Extended DNS Error Code 16 - Censored
somewhat confusing, it seems that the resolver returning the answer
is reporting second-hand status from an upstream server, but the
language leaves me unsure. Perhaps this can be stated more clearly.
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
