On 25. 06. 25 11:33, Johan Stenstam wrote:
Hi Ben,
Thanks for your comments.
On 24 Jun 2025, at 20:42, Ben Schwartz
<[email protected]> wrote:
Per RFC 9461, the SVCB record should be:
_dns.ns1.p.axfr.net <http://dns.ns1.p.axfr.net/>. 10800 IN SVCB
1ns1.p.axfr.net <http://ns1.p.axfr.net/>. alpn="doq,dot,doh”
This uses the prescribed "_dns" prefix and omits the "do53" ALPN ID
(which is not defined and would not help here anyway).
Thanks. We’ll fix that.
Apart from that minor issue, I don't object to this signaling, but I
don't think it is very valuable due to the lack of authentication. I
would prefer to see more deployment of RFC 9539, with further
engineering effort focused on DELEG.
Before we dive in, under what circumstances do we expect clients to
generate queries which trigger answers required for
4.1. Trigger Conditions for Including the OTS Hint
?
Are there stats to show this happens in practice often enough? I would
not expect NS RR 'to self' to be present under usual circumstances.
There are two valid issues here.
1. Lack of authentication:
The goal here is to improve on the privacy of authoritative DNS. Doing
that in a sufficiently simple way to be able to actually make a
difference requires compromises. A fully authenticated mechanism would
require protocol changes and in the end be a distraction from DELEG,
which is not what we want. Hence this opportunistic scheme.
When it comes to value, well RFC9539 suggests doing what call “blind
probing” (also without authentication). What this mechanism adds is
support for making the probing much less blind. It is still probing, and
if the probe fails then the resolver falls back to Do53.
Yes, as jabley and you discussed, it is possible to add an RRSIG SVCB in
some cases, and I think we should do that when possible, but as both
SVCB and RRSIG SVCB can be stripped off, we cannot rely on that being
present. But if the SVCB and RRSIG SVCB is present, then it can be
DNSSEC validated. And that prods the question “who will strip off this
transport signal?”.
My view is that there is clearly no reason to strip it off in the
authoritative end (if you add the transport signal to your service then
your objective is for it to reach the resolvers). And in the resolver
end there is also no reason to strip it off (except of course all sorts
of semi-stupid CPE devices, which hardly matter today).
Therefore my conclusion is that, modulo active attackers, with the
ability to intervene on-path, this signal, including the RRSIG SVCB,
will most likely get through in the vast majority of cases. And that’s
good enough for now, while waiting for the complete solution via DELEG
at some point in the future.
2. Focusing the engineering effort:
My estimate (from having implemented both the authoritative and
recursive side of this) is that 90% of the effort is on the recursive
side. As always. The authoritative side is trivial.
But when it comes to the recursive side the thing is that the transport
signal that we provide via an SVCB from the authoritative server is in
practice identical to the transport signal that we will receive in a
future DELEG-based referral (modulo authentication being intrinsic in
the DELEG case).
Hence, the engineering effort in a resolver to be able to utilize a
transport signal via SVCB will be essentially the same (as in reusable)
when the transport signal at some point in the future comes via a DELEG-
referral. There is no (or at least very little) wasted effort here. It
is the same problem.
I think you are right on this. Most of the implementation on the
resolver side would be the same.
And, thinking of it, would it not be a good idea to sort out any
potential issues with using more transports for authoritative DNS
separately from all the DELEG work? Then when DELEG comes around with
the hard and strictly authenticated transport signal in the future we
already know the consequences?
As mentioned in Security Considerations, there's a new weird attack
allowed by this:
Attacker can inject SVCB into the answer and make resolver waste effort
on trying DoT/DoH/DoQ/DoYouNameIt in a row until it falls back.
I don't think handwaving it away with "just fallback" is good enough of
an analysis. If NXNSAttack and company taught us anything it is that
this needs serious thought.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
