Per RFC 9461, the SVCB record should be: _dns.ns1.p.axfr.net. 10800 IN SVCB 1 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). 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. --Ben ________________________________ From: Johan Stenstam <[email protected]> Sent: Tuesday, June 24, 2025 8:55 AM To: DNSOP Working Group <[email protected]>; [email protected] <[email protected]> Cc: Erik Bergström <[email protected]>; Leon Fernandez <[email protected]> Subject: [DNSOP] Proposal for opportunistic transport signaling from authoritative servers Hi everyone, The problem with how to get the communication between resolvers and authoritative nameservers to use other, especially more private, transports than traditional UDP and TCP has been known for a long time (and was one of the focus areas of the DPRIVE working group). However it really has not happened. At least not yet. DELEG is obviously going to solve this problem, but that’s still quite a few years into the future. Also, apart from the protocol changes, DELEG will also require changes to the actual zones, to registries, registrars, etc. So it will take time. The question is whether it is possible to do anything *today*, with “today" defined as “within the current DNS protocol”. There really is no point in making a noticeable protocol change for this, if that’s needed, then DELEG is the way to go. I think it is possible to do something today. This is based on an idea that I came up with during the vote between the different DELEG-drafts after the Bangkok meeting. In short the idea is to augment the authoritative server so that: IF the auth server is about to provide an authoritative response (not a referral) AND a name that the server identifies as itself is in the NS RRset either in the Answer or in the Authority sections THEN the auth server will add an SVCB record to the Additional section in the response. Like this: dig @ns1.p.axfr.net p.axfr.net soa ; <<>> DiG 9.20.10 <<>> @ns1.p.axfr.net p.axfr.net soa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50574 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;p.axfr.net. IN SOA ;; ANSWER SECTION: p.axfr.net. 7200 IN SOA when.pigs.can.fly. hostmaster.johani.org. 2023122629 7200 1800 604800 7200 ;; AUTHORITY SECTION: p.axfr.net. 300 IN NS ns1.p.axfr.net. ;; ADDITIONAL SECTION: ns1.p.axfr.net. 300 IN A 77.72.230.63 ns1.p.axfr.net. 300 IN AAAA 2a01:3f0:1:2::63 ns1.p.axfr.net. 10800 IN SVCB 1 . alpn="doq,dot,doh,do53” For the recursive server the first and foremost observation is that all existing resolvers will obviously ignore this, as we all know that the Additional section is not to be trusted. But for this particular use case that’s great, because that means that this is safe to do, no existing resolvers will touch the new SVCB, only upgraded resolvers that understand the provided transport signal. Yes, this is opportunistic, so it is possible that in some cases this added record will be stripped off, typically in edge environments. But in practice that actually doesn’t matter much, as such a massive amount of the DNS traffic is already between global authoritative providers and very large resolver operators and they would have zero incentive to strip the transport signal, opportunistic as it is. Also note that while the added SVCB record should be DNSSEC signed, that is not always possible. But as this is just a hint, even a possible spoofed response will not cause anything more than a failed connection attempt over, eg. DoQ. Also, checking back with RFC9539 (Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS) is useful. RFC9539 describes doing opportunistic “blind" probing of alternative transports for an authoritative server and explicitly asks for a mechanism that could provide transport signaling. Perhaps this mechanism is part of the answer? But does this opportunistic transport signal work in practice? Nothing like running code to find out. The auth server side is almost trivial. The recursive server is obviously a bit more complex. But the complexity has nothing to do with the transport signal as such, it is more about a more complex cache that also needs to deal with transport alternatives, and strategies for retaining the transport information over time. Again, see RFC9539 for complete treatment of all the resolver side issues. We have implemented both the auth server side (in an existing auth server) and a prototype recursive server that looks for the opportunistic transport signal and upgrades subsequent communication accordingly (today we do not implement the full RFC9539 suggested logic, only a small subset thereof). It works just fine. I must say that I’m quite enthusiastic about this. I think this could be really useful. Given that it is easy to deploy gradually and requires zero changes to zones to utilize it (as you see above there are already test zones on the public Internet that use this) it is possibly a rather easy “win” to actually, finally get some privacy into the authoritative DNS space. There is a draft (by my colleagues Erik and Leon and me): https://datatracker.ietf.org/doc/draft-johani-dnsop-transport-signaling/ And there is an open source implementation (again by the three of us): https://github.com/johanix/tdns We would love to have comments: on the idea in general, on the draft and of course on the implementation. That said, please be aware that the implementation is a *prototype*, nothing more, nothing less :-) Regards, Johan
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
