On 14. 09. 21 18:25, Brian Haberman wrote:
Hi all,
In the interest of moving work forward, the chairs would like to
solicit reviews for
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02
We are especially interested in implementer and operator views on the
approach described in the draft.
Here is a review with my BIND hat on:
3. Proposal
This draft proposes a way to convey a glue RRSet inside a DS record,
enabling authenticated delivery of arbitrary RR types as part of the
delegation response.
Nit: Multiple RR sets, not just one. Also see below discussion about
"glue" and siblings.
3.1. Encoding
The non-standard RR format worries me - it requires yet another parser
to save ~ 8 bytes per RR. I'm not sure if it is worth the trouble. Maybe
it is, but it increases the complexity and fragility of the whole thing.
4.2. In-bailiwick referral
I believe the document needs to consider also sibling glue:
The in-bailiwick definition in
https://datatracker.ietf.org/doc/html/rfc8499#page-25:
includes sibling glue:
"In-bailiwick" names are divided into two types of names for name
servers: "in-domain" names and "sibling domain" names.
A real-world sibling glue example:
$ dig @d.gtld-servers.com youtube.com NS
;; QUESTION SECTION:
;youtube.com. IN NS
;; AUTHORITY SECTION:
youtube.com. 172800 IN NS ns2.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
Currently, this glue cannot be encoded as in-bailiwick, even though it
_is_ in-bailiwick of com.
Now what?
- Should the resolver ignore sibling glue if DSGLUE is present? Then we
are missing protection.
- Or should auth add an unsolicited google.com DSGLUE to the response?
Then we are asking for trouble with delegation cycles and/or packet bloat.
- Or ...?
A related problem is how registries handle sibling glue. I think this
needs serious rethinking:
- How does DSGLUE relate to host objects in a registry?
- Would registries be okay with accepting DSGLUE, which overrides
sibling glue generated by registry from other sources?
This situation needs serious thought because sibling glue is extremely
common in com. Summary based on com. zone file serial 1630540823:
RRs | 392 220 980 |
NS RRs | 373 888 200 | of all delegations |
delegations | 156 365 332 | 100,0 % |
delegations with NS name in the delegated domain | 522 066 | 0.3 % |
delegations with NS name in another com domain | 126 182 455 | 80.7 % |
delegations with NS name outside com domain | 38 442 739 | 24.6 % |
Average number of NS records per delegation: 2.4.
3.3. Allowed RR types
Recipients implementing this specification MUST accept the NS, A, and
AAAA RR types in DSGLUE. Support for the other allowed RR types is
OPTIONAL.
Recipients MUST ignore any unauthenticated TLSA records.
Nit: I think readers might appreciate list of optional RR types defined
in this document.
6.2. Publishing DSGLUE records
In order for the child to publish DSGLUE records, the parent must
allow the child to publish arbitrary DS records or have specific
support for this specification.
If the parent supports CDS [RFC8078], child zones MAY use CDS to push
DSGLUE records into the parent. Note that CDNSKEY records cannot be
used, because (1) the child cannot publish CDNSKEY records with the
required owner name and (2) the child cannot guarantee that the
parent will use the VERBATIM digest to produce the DS record.
Is there any indication/information that registries doing CDNSKEY are
willing to support also CDS for this purpose? I think e.g. CZ is going
CDNSKEY only because it allows them to select DS hash and to do checks.
6.4. PKI and DANE for Authenticated Encryption
TODO: Move some of this text into a different draft.
I agree with the TODO. IMHO it does not belong here. Let's focus on how
to get signed data from a parent to a resolver and not prescribe its
semantics in _this_ document.
Similar to Vladimir Cunat, I'd instead consider this draft in
combination with drafts that describe the uses of DSGLUE as one "working
package." It is hard to see all interactions without that.
--
Petr Špaček @ ISC
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
