TL;DR:
Fun links shared:
Presenter: Tale
Published the -02 after the interim, adopted the taxonomy discussed
there, minor nits. Ready for WGLC "soon":tm:
Presenter: Paul Hoffman
Started a non-RFC draft (draft-hoffman-deleg-roles) to allow everyone to
raise their opinions before technical solutions are mostly developed.
DNS researchers and logging applications are a secondary audience for
this work. We should stay focused on what resolvers need to do instead
of over-designing for secondary use cases.
There are three models (let me know if there are more) that describe how
this protocol could work listed below. We should pick exactly one to
develop a protocol against.
=======
Ralf: I think anything other than "parent delegates" will lead to
trouble.
Wes: Imagine there are properties that are authoritative only on the
parent versus others only on the child. Not advocating for mixed, but
challenging us to think about this situation if it exists.
Ray: There are also cases where the parent and child are the same server
Philip: If we ever decide to put DNSSEC info in DELEG, more than
resolvers will be stakeholders
Peter: We should be thinking about the trust model of how one ends up at
the child (if the parent only has hints)
Presenter: Paul Hoffman
The big question: do we use an omnibus RRtype with fields for every
datum DELEG needs to carry (example: SVCB) or use a new RRtype for each
DELEG feature?
Reusing SVCB: implementations already know how to parse it, but if we
use SVCB, we are limited to SVCB parameters which were designed for HTTP
use cases which may or may not adapt to future needs of DELEG.
Defining new RRtypes gives us total flexibility, but also force
implementors to add support.
What about the situation where a newer DELEG feature requires that an
older feature MUST NOT be present? Which approach will allow us to
support cross-feature interactions more effectively?
EPP/RDAP? Try not to think about this right now. That said, consider
omnibus means only updating one record but individual records means
targeted updates rather than always updating the entire thing when one
little thing changes.
Want feedback from developers on feasibility of approaches.
======
DKG: there may be multiple delegations -- using individual records would
make this complicated when different delegations have different
properties. Let's do omnibus. (+1 from Erik in chat)
| (Wes | Warren): omnibus allows the resolvers to package additional information that may be useful to the querier, though individual records would make that difficult (they would have to know what to query). |
Ralf: why not use omnibus when the individual approach will be trying to
bundle all records into a single packet for perf reasons anyway?
Petr: my preference is TBD (needs more thought).
Tale: prefer omnibus, but could be done otherwise.
(couple comments missed at the end)
Presenter: Philip Homburg
Intro: current alternatives include (1) using draft-wesplaap-deleg-01
and (2) using draft-homburg-deleg-incremental-deleg-00
H1 through H5 are either addressed or not blocked by both drafts
(example: neither interferes with how DNSSEC would be used with the new
records for H4).
For H6, _deleg allows adding new zones without updating authoritatives
where DELEG requires changes to the authoritatives.
For H7, both allow multiple SVCB or DELEG records, but use of SVCB will
require defining how AliasMode is handled when there are multiple
instances (not RFC forbidden, but not defined either).
For S1, _deleg meets out of the box, and DELEG could too trivially by
mirroring SVCB.
For S2, note that neither tries to replace DS.
For S3, DELEG is a clear winner because it does not require extra
queries. The _deleg approach requires multuple queries when the parent
zone is not signed and has no incremental DELEG records (requiring +1
query).
For S4, _deleg using SVCB is simpler.
For S5, both approaches allow NS records and glue to be derived from the
SVCB or DELEG records (ignoring AliasMode).
For S6, both approaches work.
For S7, both approaches allow DNSSEC signing of delegations.
(no significant differences)
Presenter: Petr Špaček
For DELEG, we can reuse the same expected record hierarchy as the record
lives next to the existing NS record. However, _deleg creates a
side-step at every level.
For DELEG, we need a new special case to specially handle DNSSEC signing
(very few lines of code in BIND at the hackathon). OTOH, _deleg
requires no changes.
For DELEG, we need something like NSEC3 opt-out (DELEG MUST be present
or prove non-existence). OTOH, _deleg requires no changes.
Both can handle aliasing, though they do it differently.
Authoritative changes: DELEG requires changes which ends up making it
more optimized than _deleg default behavior (which will work with no
changes). Similar for deployment.
Summary of impact of each approach to implementors:
*Note: An excellent analysis table was shared on slide 18 in the deck:
https://datatracker.ietf.org/meeting/121/materials/slides-121-deleg-comparison-draft-wesplaap-deleg-01-vs-draft-homburg-deleg-incremental-deleg-00-00
*
=========
(from chat: both DKG and Erik are worried about future testing
complexity of the SVCB / _deleg approach)
Ben: big challenge with DNSSEC is causing an outage if it isn't
bulletproof. Both approaches have similar levels of "scary" we should
take into account.
Peter: Namespace overloading may or may not be an issue, but it is worth
considering the octet overhead of the extra _deleg label, which along
with other SVCB features makes it a less integrated solution. Does
quicker rollout justify this?
Duane: I assumed _deleg would work if it itself was a delegated zone
but today's slides assumed it was always in the parent zone. (correct,
_deleg cannot be delegated)
Lars: does either approach shift the balance of power between the parent
and child operators?
Erik: both approaches seem to work, but which will be easier to test,
maintain, and debug? The _deleg version seemed to have many more edge
cases that may make us unhappy in the long run. Also, having the
underscore label may create a security problem for accidental
registration of this name.
Warren (no hats): DELEG looks more architecturally pure and _deleg
looks like a hack that gets this more quickly deployed (optimizing for
the short term).
Paul: With _deleg, testing is actually much easier (because we only
have to test one side, where DELEG requires testing new authoritative
functionality). The fact that the difficulty is only in the resolver
makes _deleg better.
(Joe from chat with +1s: "We are too accustomed to the horrors of the
same (QNAME, QTYPE, QCLASS) being answerable from both the parent and
child zones, with attendant complexity when (e.g.) parent and child
zones are hosted on the same server. Separating the information in the
namespace avoids that complexity.")
Roy: Paul Wouters has talked about a third proposal of putting DELEG
info in DS records -- I think this is extreme, but should be considered
as well. DS has aliasing and special DNSSEC handling already.
DKG: if this comes down to fast to roll out versus long-term complexity,
we should consider optimizing the new handling by authoritatives to
treat DELEG in the same if-else as DS records and take the DELEG route.
Wes: negative caching works better with _deleg because these queries
can be offloaded to different infra (also to handle significant
differences in TTLs and so forth).
=====================
Chairs: thank you to everyone rapidly iterating on the agenda structure
ahead of the meeting. Next, the chairs will issue a WGLC for the
requirements document
Roy: DNSSEC related stuff should be split out
Warren (hat on): this WG is going much more smoothly than I expected,
well done everyone
Raise of hands for "Based on the presentations today, do you feel you
could choose between DELEG (type) and _deleg (name) approaches?":
Raise of hands for "Do have a preference for the _deleg (name)
approach?":
Raise of hands for "Do you have a preference for the DELEG (type)
approach?"