On 1/31/24 15:33, Paul Wouters wrote:
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.
As discussed, DELEG needs a signal to tell the resolver "please expect a DELEG
record or a proof-of-nonexistence". Suggestions were to put this into a DNSKEY flag
at the parent, or into a special-algo DS record repurposed as a flags field.
When re-using DS to carry the DELEG-style information itself (as shown on slide 13 of
Paul's deck [1]), that downgrade resilience comes for free; in a way, it's like a
"verbose" version of the special-DS flag.
In the usual DELEG proposal, we need (1) DELEG and (2) an anti-downgrade flag
(in DNSKEY or DS), whereas with this proposal, only one thing (special DS
record) is needed.
Put more provocatively: Why do two things where one suffices?
Yet more provocatively:
- Let's rename DS from "Delegation Signer" to "Delegation Signal".
- It can carry
* legacy DS records (algo/digest type != 0), and/or
* other kinds of signed delegation information (payload determined by other
fields).
Framed this way, it doesn't sound like bending the concept so much anymore. It
simply is the go-to RRset that's used for signaling delegations.
We already know that existing resolvers don't mind the unsolicited DS. Those
who signal support wouldn't need to be served an NS RRset, though.
[1]
https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/materials/slides-interim-2024-dnsop-01-sessa-initial-reflections-on-deleg-00.pdf
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.
I think that's worth considering.
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
