[DNSOP] Re: Proposal for opportunistic transport signaling from authoritative servers

[Ben Schwartz <[e-mail]>]

Thanks for the clarification.  It sounds like the intent here is that:

1. The SVCB signal is not included in referral responses.
2. The SVCB signal is acquired during NS revalidation.
3. This avoids the additional work for resolvers to probe port 853.

I can understand the logic of this, but most resolvers do not perform NS revalidation, so stacking this capability on top of NS revalidation would limit the number of resolvers that are able to deploy this behavior.  Also, RFC 9539 probing can generally run in parallel to NS revalidation, so it should be faster than waiting to start TLS until after receiving the SVCB hint.

--Ben


________________________________
From: Johan Stenstam
Sent: Wednesday, June 25, 2025 5:27 AM
To: Joe Abley; Ben Schwartz
Cc: Working Group DNSOP; [e-mail]; Erik Bergström; Leon Fernandez
Subject: Re: [DNSOP] Proposal for opportunistic transport signaling from authoritative servers

Hi,

Many thanks for the comments. There are a bunch of things to sort out. Let’s start with the issue of whether this is worthwhile or we should just wait for DELEG.

Using an opportunistic scheme like this is not able to defend against an active attacker. The complete solution is clearly DELEG. Full stop.

My concern with that is that DELEG will not be able to add privacy to a large fraction of the public zones for, well, a rather long time. The reason is that even if the specification was complete tomorrow, and implementations were done next week we would still have to wait for all the registries and registrars to add DELEG support. And after that every single zone will need to be upgraded which will also take years.

I’m not objecting to this, there is just no way around the fact that a major change to the DNS like DELEG will take a long time to reach wide scale deployment. Just like DNSSEC. Or IPv6. Or...

The point with our proposal is that because it is so simple, and because it doesn’t require any changes to the registry/registrar/registrant ecosystem (only providers of authoritative or recursive services need to do anything) this could, if we want, reach wide scale deployment in a fraction of the time.

I argue that we want to add more privacy to authoritative DNS now and the reason we have not done that yet is that we have not (AFAIK) had a sufficiently simple mechanism to provide transport signaling from auth to resolver within the current protocol. And blind probing a la RFC9539 was not not sufficiently attractive (as the odds of it working were low).

This proposal is just an opportunistic hint that says “Hey! I support DoQ, please try it” to allow the resolver to do something like RFC9539, but with open rather than closed eyes and therefore a vastly larger chance of success.

On 24 Jun 2025, at 21:46, Joe Abley <[e-mail]> wrote:
On 24 Jun 2025, at 21:38, Ben Schwartz <bemasc=[e-mail]<mailto:bemasc=[e-mail]>> wrote:

1. An attacker could strip the SVCB record and its RRSIG, resulting in an ordinary delegation response that would be accepted and used without encryption.

True. A client that didn't find a record could query for it which would give it the ability to validate any non-existence, but that sounds like a lot of pointless queries in the situation where the majority of zones don't have this kind of thing deployed (when most referrals don't include a courtesy SVCB).

All of this is true and I am not suggesting actively querying for the SVCB. If the resolver gets the transport signal for free it may use it, that’s all.

2. This is a child-side record, and so presumably also a child-side RRSIG, but the validator may not yet have the child's DNSKEYs.  Fetching those keys (in order to validate the transport configuration) would create additional delay before the query could be sent.

That additional delay can be amortised over the lifetime in the cache of those records needed to provide a chain of trust though. A validator is going to have to do that work at some point.

I agree to the amortization point. However, I want to point out that that we’re not talking about the child’s DNSKEYs, we're talking about the DNS provider’s DNSKEYs. I.e. for the child zone "example.parent.”, with the DNS provider Cloudflare the response would be something like:

…
Answer:
www.example.parent.  IN A 1.2.3.4
Authority:
example.parent.      IN NS ns.cloudflare.com.
Additional:
ns.cloudflare.com.   IN A 5.6.7.8
ns.cloudflare.com.   IN AAAA 2001::bad:cafe:53
ns.cloudflare.com.   IN SVCB 1 . alpn=doq,dot
ns.cloudflare.com.   IN RRSIG SVCB …

And the likelihood of resolvers already having the DNSKEYs of all the major DNS providers is rather high.

3. The parent-side logic to serve this RRSIG, and the coordination channels to get it there, seem complicated.

I guess. It seems approximately as complicated as CNAME flattening which is pretty common.

This part I don’t understand. There is no “parent side logic”. There is no change whatsoever to the delegation information (otherwise this would be a non-starter).

The proposal is to add the transport signal when sending an authoritative response, i.e. an Answer, from an authoritive nameserver (where the auth nameserver will make a statement about its own transport capabilities).

There is no suggestion about changing anything in a referral from the parent.

Assuming it is signed by the ZSK, this also breaks a usual rule of not having parent-side content depend on the child ZSK.

The referral can be processed without it (by using other transports) so I'm not sure it's a dependency.

The downgrade attack seems worth thinking about. I'm not sure how much we need to care about the other things.

I think there may be a misunderstanding hidden here. But as I don’t understand what you’re talking about here I may be wrong…

Regards,
Johan