Hi,
from reading:
I expected that desec supports DoT, but if I look at a PowerDNS Recursor with opportunistic DoT enabled I see status is “Bad” (meaning not working as expected):
rec_control dump-dot-probe-map -|grep applied-privacy.net -i
2607:f740:e633:deec::2 applied-privacy.net. 162 Bad 2022-09-16T20:28:55
What is the current status?
If you support Do53, DoT and DoQ it would be nice to have individual states on
https://desec-status.net/ for each protocol.
Hi,
Please file a bug report on GitHub - desec-io/desec-ns: Frontend nameserver for deSEC, implemented as docker-compose application. Can you include whether you observe a difference for connecting via IPv4 or IPv6?
Stay secure,
Peter
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).
thanks for your reply.
https://mailman.powerdns.com/pipermail/pdns-users/2022-September/027842.html
Looks like it’s using a self-signed certificate now; definitely not ready for general use.
I’ll watch this space for when the service is ready; it’ll be really useful for checking records soon after updating, before they propagate.
Hi Seirdy,
Welcome to 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.
Stay secure,
Peter
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.
FWIW, we’re considering to shift to DoQ, and not provide DoT support in the future anymore.
As support wasn’t documented in the first place, we’ll likely shut this down at some point in the future without further notice. We recommend using DoQ instead (which, still, is provided for convenience only and not as a core service).
Stay secure,
Peter
As of today, it looks like DoT works on ns1.desec.io and ns2.desec.io, but only on IPv4. I have not found an easy way to test DoQ (yet).