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

[Johan Stenstam <[e-mail]>]

Ben,

> Thanks for the clarification.  It sounds like the intent here is that:
> 
> 1. The SVCB signal is not included in referral responses.

Yes.

> 2. The SVCB signal is acquired during NS revalidation.

No. 

> 3. This avoids the additional work for resolvers to probe port 853.

Yes.

> 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.

Not quite right. The SVCB signal is sent as part of an authoritative response. NS revalidation or not is completely orthogonal to our proposal.

Here is a more complete example (assuming no qname minimization):

* Your cache knows about parent, but not child.parent.
* You query for something in the child.example zone:

{whatever}.child.parent. {rrtype} ?

* You get a referral from an auth server for parent:

Authority:
child.parent.  IN NS ns.provider.com.

* You send the same query to ns.provider.com and get an authoritative answer:

Answer:
{whatever}.child.parent.   IN {rrtype} …

Authority:
child.parent.  IN NS ns.provider.com.

Additional:
ns.provider.com.  IN A 1.2.3.4
ns.provider.com.  IN AAAA 2001::bad:cafe:53
_dns.ns.provider.com. IN SVCB 1 . alpn=doq,dot
_dns.ns.provider.com. IN RRSIG SVCB ...

Now you know that ns.provider.com has the preferred transport DoQ (assuming that you choose to trust this signal). If the RRSIG SVCB is there and you have the DNSKEYs for provider.com I suggest that you validate the SVCB record to improve your trust in the signal, but that’s not mandatory.

* 4 milliseconds alter you want something else in the child.example zone:

{otherstuff}.child.example. A ?

* You send this query over DoQ to ns.provider.com and most likely you will get a response.

In the case where you fail to set up the DoQ session you either fall back to the next preferred transport (DoT in this case) or, last resort, Do53.

* There is zero change to the delegation information.
* There is zero change to the content of the referral from the parent.
* There is zero change to the child.parent zone.
* There is zero change in the sequence of DNS messages are exchanged between which servers.

* The ONLY change is that in an AUTHORITATIVE response from an auth server listed in the NS RRset for “child.parent." the auth server has the opportunity to attach a record to the Additional section:

_dns.{auth server}. IN SVCB 1 . alpn=…

and possibly also an:

_dns.{auth server}. IN RRSIG SVCB ...

Regards,
Johan