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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
