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?!
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
