Time : 15 minutes
Presenter : Tim Wicinski (tjw.ietf@gmail.com)
Document :
https://datatracker.ietf.org/doc/draft-homburg-deleg-incremental-deleg/
Chairs' Action : WG discussion
Feedback on previous versions led to:
We are still facing the challenge of how to deal with the zone cut
problem.
It seem that using underscore labels is a best practice for apps and
services.
Check out https://ideleg.net/ which lets you test things, though
wesplaap does not work (because it requires changes to auth servers).
Problem areas:
Questions for the WG focused on the long-term: what authoritative
software will people be running in 30 years?
Geoff: Did you say all auth servers would need to update all at once?
Jim, Ondrej, and Paul all basically saying: this seems to be an outdated
comparison...? This slide does not take into account mailing list
discussion.
Roy: (missed details, TODO: revisit recording)
Time : 15 minutes
Presenter : Authors
Document : https://datatracker.ietf.org/doc/draft-wesplaap-deleg/
Document : https://datatracker.ietf.org/draft-wesplaap-deleg-transport/
Chairs' Action : WG discussion
Greatly reduced content not related to core protocol since requirements
and motivation is covered by requirements draft.
Everything in our draft follows current DNS sematics, which makes it
easier to debug and implement for recursive resolvers, which is where
the greatest complexity is (poll of room showing greater number of auth
implementors than recursive implementors).
This draft also makes QNAME minimalization optional which is sometimes
useful for performance-sensitive cases.
With added EDNS(0) signal, similar to DO for DNSSEC, results in smaller
packets and
ring-fencing" NS to old clients and DELEG to new clients.
One of the older DNSSEC RFCs reserved bits which caused a hiccup, but
after switching to other bits, can show this approach works with
existing resolvers.
Point being: authoritatives are easier to change than recursives. Let's
keep it simple.
Philip: Actually, you can do incremental DELEG without QNAME
minimalization.
Paul: dnsop spent a ton of time on QNAME minimalization and getting it
right. I am uncomfortable with both Ralf's and Philip's comments.
Roy: This should not say anything about QNAME minimalization since it is
unrelated.
Jim: We don't have comprehensive test beds for these edge cases with
QNAME minimalization, DNSSEC signing, and so forth, but we should.
Ondrej: BIND9 will be implementing this for testing, we just aren't
there yet
Willem: Our draft does not require QNAME minimalization.
Willem: We have public tests for our draft with authoritative servers
people should check out.
Tale: We heard that feedback from earlier (that trimming hte draft led
to a lack of useful examples)
Time : 50 minutes
Moderator : Chairs
Questions we will be posing after this discussion:
Warren: DNS is roughly 40 years old now. We should design for this to be
deployed for at least another 40 years and to prioritize
understandability beyond functionality.
Ondrej: We have time to deploy things, let's not do hacky approaches.
Ondrej: who is the target audience of DELEG? No matter which we pick, we
have to update servers.
Ondrej: I teach DNSSEC to students, and +1 to Warren we need to make
this understandable to newcomers.
Ondrej: can you delegate the underscore deleg? (this has been hashed
before, it cannot be an NS delegation either)
Ralf: we can't mix DNSSEC and non-DNSSEC servers in the other approach,
which is a non-starter for me
Peter: "easy as NS deployments" from the requirements doesn't seem to
match needing to update other zones
Peter: incremental means not needing simultaneous updates for all zones
Paul: What H6 says is DELEG MUST be incrementally deployable and not
require a flag day. It has nothing to do with all your name servers or
subset. Both proposals meet the requirement as listed.
Paul: I don't find either draft's introduction clear, but I don't want
to block on that. The adopted draft will get worked on and that will be
fixed.
Tale: +1 to Paul. I think both protocols work for the defined
requirements. I personally think it's DELEG RR; I appreciate IDELEG
allows for an overall easier implementation path, but what is the
long-term benefit? Once widely adopted, I don't see an advantage to
IDELEG that justifies the changes needed to make rollout easier.
Willem: we prevent legacy delegation of underscore deleg.
Willem: IDELEG requires cooperation with the authoritative, but
otherwise both approaches work.
Philip: if the TLDs have to make changes, that should be fine, they're
well organized. Where IDELEG shines is to support the smaller parties
who are not prepared or aware of changes needed.
Roy: I have no technical concerns with either draft. IDELEG optimizes by
not requiring changes from auths and using the underscore labels to work
well with CNAME/DNAME. The costs of doing the tree of underscore labels
will introduce more confusion and not requiring changes to the auth is
undercut by saying it is optimized by then getting adoption by auths.
"In 97% of cases, premature optimization is the root of all evil". I
choose the DELEG draft.
Ondrej: smaller parties don't really do delegations at scale. The
changes are mostly going to be needed from the parties capable of
changing. I don't think IDELEG helps.
Tale: we are going to have a long tail of DELEG and legacy, but at some
point DELEG will be common. At that point, what is the resource
consumption? Doing more work to make IDELEG good for that state doesn't
seem like a good approach.
Philip: I don't see the argument that IDELEG is more complex. IDELEG
gives you use of these other types right away.
Philip: I'm not convinced the big parties even update quickly.
Karl: I keep hearing no changes are needed for auth servers, yet it is
going to need changes for the registry.
Willem: I keep hearing "feelings" arguments. I think it makes sense to
look at a given name and know that it has all the info needed for the
application using that name.
Paul: This room is full of people who know how to manage zone files, but
this will be deployed by people who barely know how to manage zone
files. Both drafts introduce new, weird-looking types that are likely to
be constructed by tooling, not humans. At that point, they will both be
easier.
Ralf: IDELEG is only easier for the auths (and not really), not easy for
anyone else. Let's say Google deploys this: double the size of the total
tree? Smaller resolvers will fall over handling that.
Wes: RFC 7218 taught us a lesson to not use zeroes and ones but to use
readable presentation formats (by changing DANE).
Ondrej: I think from the tech perspective in a recursive that DELEG is
easier than IDELEG.
Mark: IDELEG is not deployable as described today to every zone.
Jim: my gut says DELEG is better, but I'm not sure I could say for sure
one position or the other. We need to be deliberate because we will be
living with this for a long time.
Philip: Existing DNSSEC software has to be DELEG aware to sign the zone
but not IDELEG aware to preserve existing zone signing.
Ondrej: who exactly is wanting to deploy new stuff without upgrading?
Warren: years from now, if I'm teaching DNS to someone, IDELEG feels
hacky ("we added this extra label because it was faster to deploy back
in the day")
Paul: nobody has answered (2) or (3) yet... why are we talking when we
could be raising specific tech soncerns.
(1) 35, 11, 15
wesplaap 32, 7, 9
homburg: 10, 26, 9
Time : time permitting
Presenter : Philip Homburg (pch-dd@u-1.phicoh.com)
Document :
https://datatracker.ietf.org/doc/draft-homburg-deleg-incremental-dnssec/
Chairs' Action : N/A
(we did not get to this)