HTTPS RR in Curl
daniel.haxx.se
daniel.haxx.se
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.
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.
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.
"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.
$ 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.