On 25. 06. 25 16:00, Johan Stenstam wrote:
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.
Ah, now I understand!
That means the proposed protocol would depend on non-minimal authority
sections. I thought the trend nowadays is the opposite, i.e. providing
more and more minimal answers.
Moreover, would that work for TLDs/delegation-heavy zones? I would think
TLD server itself would 'never' send it's own NS in response (unless
queried for it explicitly).
Perhaps a solution could be inverting the EDNS logic in the draft:
Add an option to _request_ this extra data, so we don't have to enable
non-minimal answers on all servers for this?
Petr Špaček
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 ...
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
