PS: DoT and DoQ support is experimental, and not officially announced or documented. It is deployed to collect experience and learn about implications; however, there is no service expectation. The relevant RFCs encourage resolvers to handle things gracefully. – Given that DoQ is now RFC 9250, I would expect DoT to disappear again (not only at deSEC).
No. The DoT and DoQ specifications explicitly leave authentication between the resolver and the authoritative server unspecified (see RFC7858 Section 3.2 and RFC9250 Section 5.1, respectively). (This is explicitly defined differently than for traffic between a client and a resolver.)
One of the reasons is that it’s not a good idea to have DNS service depend on the WebPKI which again depends on the DNS, so the problem has been left to be solved later.
The problem is currently being tackled in the DPRIVE working group of the IETF. It was determined that for the moment, opportunistic encryption is better than creating a catch-22 situation. Their current protocol draft therefore says:
For unilateral deployment, an authoritative server does not need to offer any particular form of authentication.
The simplest deployment would simply provide a self-issued, regularly-updated X.509 certificate. This mechanism is supported by many TLS and QUIC clients, and will be acceptable for any opportunistic connection.
This is what we’re implementing, very conciously. Please also note that resolvers (for now) don’t check the WebPKI anyway, so nothing is gained with such a certificate (although complexity would be added).
I’m sure the working group welcomes additional opinions, so if you’d like to give them feedback, feel free to post on their mailing list.
The question of how to do in-band authentication (within the DNS, without WebPKI) will be tackled afterwards. The protocol community feels like it’s better to not implement quick solutions and change them later, but instead spend sufficient thought on finding a good solution so that it can stay. There are a few ideas around, such as draft-dickson-dprive-adot-auth.
I’m not sure what you mean – once you can observe the records on our servers, they already have propagated.
Ah, whoops! Sorry, I wasn’t familiar with the challenges regarding encrypting authoritative server responses.
Regarding propagation: I meant propagating to other servers. I assume that moments after I update a record, making DNS queries with the desec nameservers will give me updated values before e.g. Google Public DNS. Sometimes this is convenient. Having encryption for this is nice.