[belorn]

DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.

[tptacek]

Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.

[belorn]

If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack).

If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server.

If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.

[tptacek]

None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.

[belorn]

TLSA record can specify what specific hash the certificate must have (DANE-EE). You can't solve that with BGP and ACME. The certificate that you get from acme will have a different hash.

With CAA records you can also lock it down to a specific user and method (RFC 8657). How will you solve that with BGP using acme?

[hsbauauvhabzb]

You’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.

[wlonkly]

A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.