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