HTTPS RR in Curl(daniel.haxx.se)
daniel.haxx.se
HTTPS RR in Curl
https://daniel.haxx.se/blog/2025/03/31/https-rr-in-curl/
3 comments
Fetching DNS records about HTTPS over DNS-over-HTTPS. Absolutely ossified.
At least in curl it's an option, not a requirement or even a default.
There are two competing approaches to secure DNS.
1. DNS Security Extensions (DNSSEC).
2. DNS over HTTPS (DoH)
Both are kind of works but it seems that second approach is more practical, because it does not require reconfiguration of the billions of servers and just requires modification of client software which is usually easier to implement for software vendors.
1. DNS Security Extensions (DNSSEC).
2. DNS over HTTPS (DoH)
Both are kind of works but it seems that second approach is more practical, because it does not require reconfiguration of the billions of servers and just requires modification of client software which is usually easier to implement for software vendors.
Those two don't really compete. DNSSEC provides authenticity/integrity without privacy and DoH does exactly the opposite. If anything, you need both in order to secure DNS.
They don't compete in any immediate way, but over the long term, end-to-end DNS secure transport would cut sharply into the rationale for deploying DNSSEC. We're not there yet (though: I don't think DNSSEC is a justifiable deployment lift regardless).
It's worth keeping in mind that the largest cause of DNS authoritative data corruption isn't the DNS protocol at all, but rather registrar phishing.
Honestly, and I think this has been true for a long time, but in 2025 the primary (perhaps sole) use case for DNSSEC is as a trust anchor for X.509 certificate issuance. If that's all you need, you can get that without a forklift upgrade of the DNS. I don't think global DNSSEC is going to happen.
It's worth keeping in mind that the largest cause of DNS authoritative data corruption isn't the DNS protocol at all, but rather registrar phishing.
Honestly, and I think this has been true for a long time, but in 2025 the primary (perhaps sole) use case for DNSSEC is as a trust anchor for X.509 certificate issuance. If that's all you need, you can get that without a forklift upgrade of the DNS. I don't think global DNSSEC is going to happen.
In what way does DoH provide end-to-end security? It doesn't, unless you adopt a different definition of "end-to-end" where the "server end" is an entity that's different from the domain name owner, but you're somehow trusting it to serve the correct/unaltered DNS entries. And even then, they can be tricked/coerced/whatever into serving unauthentic information.
For true end-to-end DNS security (as in authentication of domain owners), our only option is DNSSEC.
At best, you can argue that DoH solves a bigger problem.
For true end-to-end DNS security (as in authentication of domain owners), our only option is DNSSEC.
At best, you can argue that DoH solves a bigger problem.
If you have an end-to-end secure transport to the authority, you've factored out several of the attacks (notably: transaction-driven cache poisoning) that have, at times, formed the rationale for deploying DNSSEC. The most obvious example here is Kaminsky's attack, and the txid attacks that preceded it, which had mitigations in non-BIND DNS software but didn't in BIND specifically because DNSSEC was thought to be the proper fix. Those kinds of attacks would be off the table in a universal DOH/DOT/DOQ world, in some of the same sense that they would be if DNS just universally used TCP.
"True" DNS security isn't a term that means anything to me. Posit a world in which DNSSEC deployment is universal, rather than the sub-5% single digit deployment it has today. There are still attacks on the table, most notably from DNS TLD operators themselves. We choose to adopt a specific threat model and then evaluate attacks against it. This is a persistent problem when discussing DNSSEC (esp. vs. things like DOH). because DNSSEC advocates tend to fall back on a rhetorical crutch of what "true" security of authoritative data meant, as if that had some intuitively obvious meaning for operators.
In a world where DNS message transports are all end-to-end secure, there really isn't much of a reason at all to deploy DNSSEC; again: if you're worried about people injecting bogus data to get certificates issued, your real concern should be your registrar account.
"True" DNS security isn't a term that means anything to me. Posit a world in which DNSSEC deployment is universal, rather than the sub-5% single digit deployment it has today. There are still attacks on the table, most notably from DNS TLD operators themselves. We choose to adopt a specific threat model and then evaluate attacks against it. This is a persistent problem when discussing DNSSEC (esp. vs. things like DOH). because DNSSEC advocates tend to fall back on a rhetorical crutch of what "true" security of authoritative data meant, as if that had some intuitively obvious meaning for operators.
In a world where DNS message transports are all end-to-end secure, there really isn't much of a reason at all to deploy DNSSEC; again: if you're worried about people injecting bogus data to get certificates issued, your real concern should be your registrar account.
You can test it on Debian experimental, or use a Debian container:
$ podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl --version'
Version 8.13.0~rc3-1+exp1 is syncing to the repositories and has HTTPS RR support enabled.
$ podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl --version'
Version 8.13.0~rc3-1+exp1 is syncing to the repositories and has HTTPS RR support enabled.