Hi Ben, Thanks for your comments.
> On 24 Jun 2025, at 20:42, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > wrote: > > Per RFC 9461, the SVCB record should be: > > _dns.ns1.p.axfr.net <http://dns.ns1.p.axfr.net/>. 10800 IN SVCB 1 > ns1.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. 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. 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? Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list -- dns-privacy@ietf.org To unsubscribe send an email to dns-privacy-le...@ietf.org
