Hi everyone.
I'm attempting to read both drafts in lockstep before we send it to WGLC.
I feel more people need to do this before we rubber stamp both documents.
Here are my notes, ordered by perceived severity:
## DELEG 5.1. Resolvers vs. DELEXT 5.1
A resolver that is DELEG-aware MUST signal in queries that it
supports the DELEG protocol by setting the DE bit to 1 (see Section
4). This indicates that the resolver understands the DELEG semantics
and does not need NS records to follow a referral.
I've generalized DELEG to "Delegation-Extension-aware":
https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/215
This highlighted an implicit assumption:
Client which implements DELEXT/DE=1 must also support DELEG. I.e.
sending DE=1 while NOT implementing DELEG will cause interop problems
because DELEG is in NS-omitting range, so DE=1 client will not see NS
anymore.
I guess we need to add sentence or two to both documents saying - if
you implement this, implement the other protocol as well.
Future extensions might need to invent their own signal if they want
to _replace_ (as opposed to augment) DELEG.
Opinions?
------------------------------
## 3.2. NS-Preserving Delegation Types
The NS-Preserving Delegation Type segment contains types for
delegation mechanisms that are used alongside the existing NS RRset.
I think this is wrong. We don't know what these types might do in
future, but I there already were proposals for "DSver2" record type.
Such type is equally applicable to NS and DELEG, too.
Besides that, I guess all three NS-Preserving/On-Demand/Private
Delegation Types could use something like ~ 'MUST NOT exist on name
without NS or a NS-Omitting Delegation Types'.
This is similar to DS: It cannot exist without an actual delegation.
(It would open can of worms for DNSSEC.)
Or said yet differently, only NS and NS-Omitting Types create a
delegation. The others just ride on that delegation.
## DELEXT 5.3. Algorithm for "Finding the Best Servers to Ask"
2.2.2. If a given SNAME is proven to not have NS-Omitting Delegation
Type RRsets but does have an NS RRset, the resolver MUST copy the NS
RRset into SLIST. The resolver MUST process any NS-Preserving or
Private Delegation Type RRsets according to the specification
defining those types.
I think "The resolver MUST process any NS-Preserving or Private
Delegation Type RRsets according to the specification defining those
types." should get it's own step, like 2.2.3. Now it can be read as if
it applies only to cases with fallback to NS, which I don't think was
intended.
The same remark applies to 5.2. Referrals:
NS-Preserving and Private Delegation Type RRsets present in the
referral supplement the delegation information provided by the NS RRset.
I think it can generally apply to all NS-Omitting types as well.
Same for 9.4. Additional Expert Review Criteria:
A type that supplements the NS RRset should be allocated from the
NS-Preserving segment.
Perhaps "A type that supplements the delegation should be allocated
from the NS-Preserving segment." ?
Nit in 5.3:
This is the same recommendation to bound the amount specified in
[RFC1034] Section 5.3.3.
A missing word? "bound the amount of work"?
------------------------------
## DELEXT 4.1.1. Compact Denial of Existence
This document updates Compact Denial of Existence (CDOE) [RFC9824].
For CDOE enabled servers, the negative response required above is an
exception to the CDOE method, i.e., it MUST be generated as a
conventional Name Error proof ([RFC4035], or [RFC5155] for NSEC3)
rather than as an NXNAME-based NODATA response, and it MUST be
returned regardless of whether the query sets the Compact Answers OK
(CO) flag [RFC9824].
I find this confusing. "Name Error" is defined in 4035 3.1.3 as> Name
Error: The zone does not contain any RRsets that match <SNAME, SCLASS>
either exactly or via wildcard name expansion.
I.e. the name does not exist.
What if the QNAME=delegation point? In that case it should be "No
Data" with the accurate type bitmap, right?
------------------------------
## DELEXT 4. Name Server Requirements
When the value of the EDNS(0) DE flag is 0, the server behaves as a
server that does not implement this specification, i.e., Delegation
Types are processed as ordinary Data Types.
This needs a clarification. 'Delegation Types' are not entirely
ordinary even for DE=0.
On auth side, they still have to cause occlusion of data underneath
them, even for DE=0. That's needed so the server can have only a
single NSEC chain for the zone, and that's really a design requirement
for sane implementation.
(Perhaps mention single-NSEC-chain rule in 6. DNSSEC Requirements, too?)
On the other hand, if auth is configured with both parent and child
zones, then for DE=0 query the zone lookup needs to return *child*
zone so the generated proof of nonexistence can be validated by
unaware client.
On client side, they look like ordinary records, the magic is
restricted to auth.
Compare with DELEG sections A.1 and A.4.1.3.
DELEG text around this is in 5.2. Authoritative Servers and 5.2.2
needs to carry over to DELEXT.
------------------------------
## DELEXT 6.2. Validating a Referral
When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the
DNSKEY RRset of the delegating zone, the validator MUST check the
NS-Omitting, NS-Preserving, and Private Delegation Type RRsets in the
Authority section of the referral against the Type Bit Maps of the
NSEC or NSEC3 record that matches the delegated name. If any are
absent, the referral MUST be considered tampered with, and the
response MUST be ignored.
NSEC3 Opt-out is not covered (sic). If none of the types are present
at all (i.e. delegation only with NS and nothing else) then there is
no "NSEC3 record that _matches_ the delegated name", only a covering
NSEC3.
I think we better make this clear.
Secondly:
If any are absent, the referral MUST be considered tampered with, and
the response MUST be ignored.
Some types might be legally omitted, and what about extra types
present in response but not in the bitmap?
I suggest wording like this:
"""
When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the
DNSKEY RRset of the delegating zone, the validator MUST check the
Delegation Type RRsets in the Authority section of the referral as
follows:
- If an NSEC or NSEC3 RR matching the delegated name is present, the
set of NS-Omitting, NS-Preserving, and Private Delegation Types
present in the Authority section MUST be equal to the set of these
types in its Type Bit Maps field. On-Demand Delegation Types are
disregarded in this comparison.
- If the delegated name is covered by an NSEC3 RR with the Opt-Out
flag set ([RFC5155] Section 8.9), the Authority section MUST NOT
contain any Delegation Type RRsets.
- Otherwise, the referral lacks the required proof.
If any of these checks fails, the referral was tampered with.
"""
I also omitted the trailing "response MUST be ignored" because that's
not what resolvers actually do. They act in an implementation defined
way, but generally not "ignore" it.
Thirdly:
This triggered a thought that we did not mention TC=1 handling
anywhere. I think it can be reasonably derived from existing spec,
just saying it out loud in case people feel differently.
------------------------------
## DELEXT 6.4. Insecure Delegation Proofs
Alternatively, the validator must make sure that the delegation with
an NS record is covered by an NSEC3 RR with the Opt-Out flag set.
I suggest adding word "only", e.g.:
Alternatively, the validator must make sure that the delegation with
only an NS record is covered by an NSEC3 RR with the Opt-Out flag set.
Just to make less likely someone will read this incorrectly.
------------------------------
## DELEXT 4.1. Including Delegation Types in a Referral Response
For DNSSEC-signed zones, the response MUST include DNSSEC proof of
the existence or non-existence of Delegation Type RRsets at the
delegated name.
I guess it should say "For DNSSEC-signed zones and queries with DO=1,"
at the beginning. Or reference RFC 4035 section 3.1 which explains
this, maybe.
------------------------------
## DELEXT 4.2. Explicit Queries for Delegation Types
When the DE flag is set to 1, a query for a Delegation Type MUST
result in an authoritative answer if the queried Delegation Type
exists, or a NODATA response (AA flag set, RCODE=0, empty answer
section).
I would add a sentence to clarify this section applies only to
"QNAME=delegation point" queries. If QNAME is longer then response can
also be referral, NXDOMAIN etc.
------------------------------
## DELEXT 4.3. Queries for type ANY
Queries for type ANY where the QNAME matches a delegation point with
Delegation Types present MUST behave the same way as if a DS record
was present at the delegation point.
I think we misunderstood each other when we discussed this in Vienna.
The ask is: Special handling of Delegation Types for QTYPE=ANY should
be consistent with special handling already implemented for DS.
(Either implementation omits it, or includes it - but please please
make it consistent for all parent-side types incl. DS.)
------------------------------
## DELEG 5.2.1.2. DELEG-aware Clients with NS RRs Present but No DELEG
RRs
According to specification in [I-D.ietf-dnsop-delext], if the
delegation does not have a DELEG RRset, the authoritative server puts
the NS RRset into the authority section of the referral.
Generalized to range:
https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/214
------------------------------
## DELEXT 3.5.1. Criteria for Delegation Type Allocation
The RR type carries information associated with the delegation that
is intended to be processed by a resolver.
I suggest generalizing to mere "information associated with the
delegation" period. I think On-Demand Delegation Types might see
non-DNS usage as well. Made up examples: DBOUND, maybe a new flavor of
CAA, perhaps parent-side RP-equivalent so you can contact domain admin
if the delegation is down etc. (BTW this might be a nice use for DNS
Error reporting - right now it cannot report that all auths seem to be
down, but if it were in parent it could ...)
------------------------------
## DELEXT 5.1. The EDNS(0) DE Flag
Nit:
The diagram and bit definition appears only in section 5.1 but the bit
is referenced already from section 4.
## DELEXT 6.1. The DNSKEY-ADT Flag
The DNSKEY Flags field for Authoritative Delegation Types (ADT)
consists of 16 bits shown in Figure 2.
Huh, I find this formulation really weird. Perhaps something like this?
"The DNSKEY Flags field consists of 16 bits shown in Figure 2. The
Authoritative Delegation Types (ADT) flag is bit 14."
------------------------------
## DELEXT 4.1. Including Delegation Types in a Referral Response
The server SHOULD include the Delegation Extension Required INFO-CODE
34 ("New Delegation Only") Extended DNS Error [RFC8914] specified in
[I-D.ietf-deleg] absent a local policy requiring otherwise.
"the Delegation Extension Required" looks like leftover from previous
version. The registered name is "New Delegation Only".
BTW deleg draft is now referenced as Informative but this reference
probably upgrades it to normative, I think?
----------
## DELEG examples
I've noticed numerous errors and fixed them:
https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/217
I feel there must be more!
Congratulations if you made it this far. Now, where's YOUR review?!
