If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism.
Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain.
Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain.
> In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.
This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.
>For example, people regularly map the most common tracking domains to a black hole in the hosts file for dnsmasq on their internet gateway without doing any kind of HTTPS MitM.
This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.
>If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. [...]
And what does that gain you over DNSSEC+DoT/H other than being non-standard?
> This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.
If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.
You could refuse to send a response for those names, but then the client has to wait for the timeout. You could send a response with an invalid signature, but then the client should discard it and continue to wait for a valid response, and you still have to wait for the timeout.
There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.
> And what does that gain you over DNSSEC+DoT/H other than being non-standard?
It's simpler, more efficient, lower latency, has less attack surface and can't be used as a DDoS amplification vector.
And if you want something standard, why not standardize on DNSCurve? Using DNSSEC over that is only the sunk cost fallacy.
How would a TLS-using protocol be used as a DDoS amplification vector?
>If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.
You can return resolver errors or no data, there is plenty of options for DNS blackholing.
>There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.
You'll need a PKI for that anyway so you can deploy DNSSEC root keys.
> How would a TLS-using protocol be used as a DDoS amplification vector?
Turning off UDP DNS would break everything that still uses it but adding the DNSSEC records makes the UDP responses a DDoS amplification vector even if some clients use TLS.
> You can return resolver errors or no data, there is plenty of options for DNS blackholing.
DNSSEC validates NODATA responses and clients can respond to resolver errors in various ways that amount to more timeouts.
> You'll need a PKI for that anyway so you can deploy DNSSEC root keys.
That's assuming you want to MitM the connection rather than merely log the attempt before dropping it or record it for traffic analysis even if you can't MitM it.
So would DNSCurve.
If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism.
Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain.
Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain.
> In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.
This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.