Re: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)

["libor.peltan" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Aug 3, 2021, at 2:06 PM, Ben Schwartz <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman
>     <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy