I think that if we decide to employ DS the new way to signal the desired
transport protocol, the CDS->DS mechanism might still be used to
"upload" those DSs to the parent (however, it's not allowed by current
RFCs, since CDNSKEY is required whenever CDS exists). (I don't conclude
if this has any effect of usefulness of SVCB at the child apex or just
permanent CDS there.)
Libor
Dne 03. 08. 21 v 23:30 Ben Schwartz napsal(a):
On Tue, Aug 3, 2021 at 5:20 PM Paul Hoffman <[email protected]
<mailto:[email protected]>> wrote:
On Aug 3, 2021, at 2:06 PM, Ben Schwartz <[email protected]
<mailto:[email protected]>> wrote:
>
> On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman
<[email protected] <mailto:[email protected]>> wrote:
>> If the WG is going to go to DS in the parent to have a signed
signaling response, it would make sense that the signal in the
child have an identical format. If we go with that, I'd rather see
CDS be used in the child instead of SVCB.
>>
> I disagree. CDS is explicitly a signal from the Child to the
Parent.
Yes, exactly. This is the best way to get those DS records in the
parent.
Quite possibly, yes, but far from the only way. In fact, CDS record
support is not widely deployed at present.
> It's literally in the name of the RR type. I would not want all
the resolvers in the world to be reading CDS records as part of
the iterative resolution process.
Why is "all the resolvers in the world to be reading" an SVCB
record better?
In the parent, our RR type choices are constrained by a slow-moving
ecosystem, so we may have to reuse the DS RR type in some fashion. In
the child, we don't have this problem, so we can use proper RR types
with purpose-designed semantics, zone file representation, and wire
format.
I'll put together a more detailed proposal and then we can argue about
this some more.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
