On Wed, 31 Jan 2024, Philip Homburg wrote:
Something I wonder about, certainly after the interim, is how do we discuess
with the wider DNS community the trade-offs that are available in de design
of DELEG such that we get good feedback about priorities.
For example, the current design used two contraints:
1) no creative (ab)use of DS records
I tried to show some of of these in my "Costs of deleg" slide.
A new RRtype has a fairly big cost meassures in years, both in
terms of DNS software, DNS deployment and worse, in Registrar
deployment for Registrant webui elements.
Re-using DS is not nice, but neither was Pseudo OPT, EDNS0, etc.
But it gains us a decade.
2) no extra queries.
I am sure I don't yet fully understand the cost of queries in various
scenarios. This relates to amortization of re-using the same nameserver
for lots of domains. And the deployment of multi-qtype. And caching. And
whether we end up with semi-long lived DoT connections. And TTL.
The net effect in the current design is that current auth. servers cannot
serve DELEG because they don't know that have to include DELEG records in
referrals. So a zone can only start delegating using DELEG if all its auth.
servers (and any other part that might answer queries) has been upgraded.
In a similar way, a validating resolver that lives behind other resolvers
or forwarders cannot support DELEG until all upstream resolvers support DELEG
(the same issue, DELEG records have to be treatet special because they don't
live in the child zone).
For validators on roaming devices such as laptops it can take essentially
forever until all upstream resolvers support DELEG.
I would think roaming devices would (sadly) opt for avoiding the bad
hotspot DNS servers and pick a very big centralized DNS provider, like
one of the Quad's, irrespective of the network's ADD advertisements.
I am slightly more positive than you, but even if you have a 1% failure
on something, people are going to turn things off or back out of things.
Alternatives are:
1) just put it in DS. Certainly if we expect that alias mode will be most
common.
One could argue that non-AliasMode would only be used by professionals,
and AliasMode would be the bulk of "people who don't care and just
outsource their DNS". If you made that assumption, you would not need
DELEG at all, but you would only need SVCB pointing from parent to
the configuration location of the child. You wouldn't need the semantics
of zone cut for DELEG. Of course, this deviates from a plan of
obsoleting direct NS/DS records, but I feel that if we are going to
redesign DNS that drastically, we would be better of taking a huge
step back and thinking about the data model and the transport model
and the RRR model and how we can transition all of those in the right
way. I think we would want a lot more than a DELEG container to embed
DNS 2.0 into DNS 1.0.
And I speak from painful experience of having gone through the migration
in the world of IKEv1 to IKEv2. All the cool things we did became
useless because for each issue, someone didn't implement or deploy in a
way that made the cool thing work. In the end, we had to avoid all our
clever code and just freeze our IKEv1 code and split it from IKEv2
properly and run both independently behind a demux.
2) Store DELEG somewhere else. For example for child.parant store the
DELEG record in child._child.parent. This may require an extra query, that
may or may not be optimized in some way.
I did also mention this in my slides yesterday. I tried to explain (but
sorry I got rushed due to time) that following an AliasMode into a
"configClientXX.bigdns.com" really does mean that zone capabilities live
there and are easilly available, but that nameserver capabilities can be
stored there near the target nameserver, and that there is no real need
to store these in non-AliasMode at the parent. Non-AliasMode names
should have no privacy sensitive content anyway. And non-AliasMode
records should not contain downstream capabilities because it is much
harder to update those records when the nameservers change capabilities
(planned or unplanned)
Note I'm not saying that the current design is wrong. It is certainly the most
elegant way of doing things from a protocol perspective.
I would say the most elogant way is to generalize the solution, and
allocate a few RRtype numbers for "resolve-at-parent" style work. If
we commit to 10 years of DELEG migration, the last thing we want is to
need to start over that process _again_.
In fact, I would argue we should do both. Prepare to keep some RRtypes
into our pocket while we do DS-overload AliasMode now, and see where
that gets us in the next 1-3 years. Then re-evaluate.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
