Ask HN: Why is there even a DNSSEC root key?

[rvnx]

I'm wondering what's the point of the DNSSEC root key.

A) If we want to verify that the owner of a domain created a DNS record, why not go through the same process as wildcard TLS certificate issuance ?

Verify ownership of *.example.org Why do we need a new trusted root key (moreover issued in the US) that takes precedence over the bundled (OS/browser) trusted CAs ?

B) If your computer runs a local resolver or goes through a compromised network, can the compromised network replace all the public keys in DNSKEY response (including the answer for root) and make your computer believe that the DNSSEC record is valid ?

[tptacek]

Keys in DNSSEC follow the same delegation of authority that the DNS itself uses, so the question you're asking here is essentially "why is DNS hierarchical".

If your computer runs a normal local resolver and goes through a compromised network, there's nothing DNSSEC does at all to help you. It's a server-to-server protocol; between stub resolvers and servers, the whole protocol collapses to a single "AD" bit in the header that says "trust this packet, your server really did all the signature validation". This is a silly design, and is the reason for things like DoH.

If you're running your own DNS server, attackers can't simply replace the DNS root key; there's a somewhat elaborate process for publishing new ones, which are stored in anchors usually on the filesystem of your DNS server. See Paul Wouters article here:

https://www.redhat.com/en/blog/what-you-need-know-about-firs...

In practice, you can ignore pretty much all of this, because DNSSEC is moribund and almost nobody uses it; in reality, the DNSSEC root private keys could land on Pastebin tomorrow and nothing would "break", and most tech company security teams wouldn't even need to be paged.

[wmf]

The existing CA system was pretty corrupt until Let's Encrypt came along so DNSSEC was designed to be separate.

[solarkraft → wmf]

Isn't the existing CA system not still mostly corrupt?

[tptacek → solarkraft]

That's a bit of a Rorschach question and debating it won't get us very far. Two concrete observations we can make (and, if you like, debate):

1. The cost of TLS certificates is now effectively zero.

2. We trust CAs (in an engineering sense) less than we used to; we have near-mandatory Certificate Transparency now to monitor certificate issuance, and the browser vendors will kill a CA that misissues egregiously, as they've done already with the largest commercial CA.

Knowing what we know now about how this stuff works operationally, we probably would not have designed the CA system we did in the 1990s.

[alwillis]

I'm wondering what's the point of the DNSSEC root key.

In order to have a chain of trust, you need a starting point and the root is the starting point for the DNS. The root key--it's actually the root Key Signing Key (KSK)--enables a DNSSEC-aware resolver to validate the signatures from a TLD (like .com) to your zone example.com.

It’s the same concept X.509 uses. A root certificate is used to sign an intermediate certificate which signs the certificate you get from Lets Encrypt, for example. Your browser trusts that certificate because it can cryptographically validate the signatures back to the root certificate.

Because of the flexibility of DNSSEC, if for whatever reason, you choose to not trust the root KSK, you can use a different entry point and create your own island of trust.

If we want to verify that the owner of a domain created a DNS record…

DNSSEC is for authenticating the data in DNS records, not for verifying ownership or identity. When a DNSSEC-aware resolver validates a signed zone, we know the DNS records haven’t been tampered with.

The DNSSEC chain of trust is separate from the X.509/Web PKI chain of trust; DANE (DNS-based Authentication of Named Entities) can be used to bridge these two chains.

Remember: DNSSEC only deals with digital signatures; X.509/Web PKI deals with certificates, which is a public key + an identifier.

If your computer runs a local resolver or goes through a compromised network, can the compromised network replace all the public keys in DNSKEY response (including the answer for root) and make your computer believe that the DNSSEC record is valid

Short answer: no.

Longer answer: All DNSSEC-aware resolvers--BIND, Unbound, Knot, etc.--have the root KSK built-in, so they don't rely on the network for it.

Since the resolver already has the root KSK, the validation of the corrupted signatures would fail.

Since the root KSK is the public trust anchor for DNSSEC, it’s widely available and easy to check: https://www.iana.org/dnssec/files.

A great introduction to DNSSEC + DANE: https://youtu.be/BhvU19RJrPY

This presentation on DNSSEC and DANE is long but it’s worth your time if you want to understand DNSSEC better: https://youtu.be/A8SgW9y__io

[tptacek → alwillis]

Longer answer: All DNSSEC-aware resolvers--BIND, Unbound, Knot, etc.--have the root KSK built-in, so they don't rely on the network for it.

I believe this is not the case, and that (for instance) standard BIND configurations do automatically update the anchor keys, using the network to do it.

[alwillis → tptacek]

The original question was essentially how can a resolver trust the root KSK if it’s being downloaded using an insecure network.

The short answer is: as a bootstrapping mechanism, they don’t need to download the root KSK as it’s already built-in to the resolver. This avoids the chicken and egg problem: can’t validate DNS requests until we have the root KSK; can’t get the root KSK because you can’t trust the DNS.

Of course, all modern resolvers support RFC 5011 [1] which enables a resolver to securely update the root KSK (or any other trust anchor for that matter) via the network. Resolvers periodically check for updates.

When a new key is available, it takes 30 days of continuous availability before it’s trusted.

Since the root zone was signed in 2010, there’s only been two root KSKs: KSK-2010 and KSK-2017.

KSK-2017 was published to the DNS more than a year in advance to give time for developers, zone operators, and other interested parties time to prepare for the rollover. [2]

It also means resolvers have shipped with both keys since July 2017.

[1]: https://tools.ietf.org/html/rfc5011

[2]: https://www.icann.org/news/blog/a-key-milestone-in-protectin...

[tptacek → alwillis]

You mean all modern DNS cache servers. It is definitely not the case that all resolvers support DNSSEC; the overwhelming majority of deployed resolvers do not.

[alwillis → tptacek]

Certainly not all deployed resolvers support DNSSEC; that goes without saying. I’m sure there’s lots of old software out there.

However, it’s likely the majority of resolvers that have been deployed in the last few years support DNSSEC, even if it’s not (yet) enabled.

And certainly the users of 1.1.1.1, 8.8.8.8, 9.9.9.9, etc. are using DNSSEC-aware resolvers. So the number of users of DNSSEC-aware resolvers will only continue to increase.

[tptacek → alwillis]

Does the macOS resolver support it? Does the iOS resolver support it? Does the Android resolver support it? Then: not so much with the "majority deployed in the last few years".

People using 8.8.8.8 aren't using DNSSEC; their "DNSSEC" is a single bit in the response header that says "yes, we promise, we did DNSSEC".

[alwillis → tptacek]

I said however, it’s likely the majority of resolvers that have been deployed in the last few years support DNSSEC

The word deploy should have been a hint. IT departments deploy resolvers, not consumers. BIND is the most widely used DNS resolver and authoritative server; it’s had DNSSEC support since version 9, released 20 years ago.

People using 8.8.8.8 aren't using DNSSEC…

As far as DNSSEC is concerned, there’s no difference between using 8.8.8.8 or a DNSSEC-aware resolver on their network or laptop. Either one will validate signed DNS records.

Does the macOS resolver support it? Does the iOS resolver support it?

The resolvers in laptops, desktops and smartphones are stub resolvers; all they do forward to a recursive resolver on the internet. If you're a macOS user on Comcast for example, the Mac’s stub resolver forwards to 75.75.75.75, Comcast’s DNSSEC-aware resolver.

This also allows a user of a VPS like Digital Ocean, Vultr, etc. and is running email, web, ssh, etc. to take advantage of DANE features like TLSA, SSHFP, OPENPGPKEY and SMIMEA [1] because their zone is signed and they’re using one of the DNSSEC-aware resolvers like 1.1.1.1, 75.75.75.75, etc.

Regarding macOS and iOS, they both ship with the dnssd framework, which supports DNSSEC. [2] So an app can use DNSSEC to validate DNS records.

If my ISP's resolver doesn't support DNSSEC and I want it for an iOS device, there are apps for that, like Cloudflare’s that gives iOS users access to 1.1.1.1 [3]

Perhaps Apple has more planned; I suspect they didn’t create the .Apple brand TLD for nothing. We’ll see what happens but it has 13 parked domains and is obviously DNSSEC-signed. [4]

    apple.   900 IN SOA a0.nic.apple. noc.afilias-nst.info. (
    1000003970 ; serial
    10800      ; refresh (3 hours)
    3600       ; retry (1 hour)
    2764800    ; expire (4 weeks 4 days)
    900        ; minimum (15 minutes)
    )
    apple.   900 IN RRSIG SOA 7 1 86400 (
    20200317052047 20200225042047 10359 apple.
    Ts3cLQHsuWUuH9RZrYXbNJyh1yuUgob/3zcqiknFvQaa
    Eh0piMqozTeXziVKVBWoejC/AV9XjJEfeMAEs/ccaIsR
    GWDVJCDG/X+b/ocdEuQnYEMvaF9F8rFLgA8ILzru8DI5
    SBCiRNqWtgjwcRuoEZQ6vGf0inm/eJsoJA2z+j4= )

[1]: https://greatdane.io

[2]: https://developer.apple.com/documentation/dnssd/1823436-anon...

[3]: https://apps.apple.com/us/app/1-1-1-1-faster-internet/id1423...

[4]: https://www.apple.com/legal/intellectual-property/tld/dps/

[tptacek → alwillis]

That was a very long way to type the words "no, they don't".

[alwillis → tptacek]

No, that was a comprehensive answer that explained why the question of whether the stub resolvers in macOS or iOS “supports” DNSSEC didn’t make sense to begin with.

But I should clarify further: the Unix part of macOS does what all Unix-style operating systems do: the stub resolver forwards the requests to whatever is in /etc/resolv.conf.

But the Foundation Kit part of macOS indeed supports DNSSEC and has for years; I gave the link to the docs that describe how an app can use it. I suspect Apple and various 3rd parties have been using it for years.

Macs are popular in higher ed and government; I’m sure enough of these accounts required macOS to have DNSSEC capability built-in. Same thing for iOS.

[tptacek → alwillis]

Neither higher ed nor government services require DNSSEC. It's understandable why you'd think they do, because for several years the federal government did require it. They rescinded that requirement. CLOUD.GOV doesn't even support DNSSEC.

By the way, .APPLE? New gTLDs are required to be DNSSEC-signed. It's no surprise that ICANN supports DNSSEC.

[alwillis → tptacek]

It’s not a matter of thinking DNSSEC is required by every government or higher ed account; it’s obviously not.

But different government agencies, colleges and universities have their individual requirements and for some of them, that may include DNSSEC.

Everyone knows all new gTLDs are DNSSEC-signed.

Like most global-scale companies, apple.com isn’t signed because of 40+ years of technical debt as the internet evolved.

But if Apple wanted to utilize DNSSEC features for future services, they could do so by using the .Apple TLD.

[tptacek → alwillis]

Apple can do whatever they want. The fact that their TLD is DNSSEC-signed is not an indication of what they will do, despite your claim to the contrary.

[alwillis → tptacek]

More receipts: a link to the source code for mDNS Responder, the macOS system resolver.

It’s at https://opensource.apple.com/source/mDNSResponder/mDNSRespon....

[tptacek → alwillis]

We've been talking on HN about mDNSResponder for over 5 years. It has un-baked DNSSEC support that macOS has never used. mDNSResponder was replaced by another service (Yosemite's Discoveryd) which had zero support for DNSSEC, but instability forced them to revert back.

The macOS system resolver does not support DNSSEC, has never supported DNSSEC, and the fact that mDNSResponder has/had DNSSEC code is not an indication that they're embracing it. By the way: I have better sources on this than just my opinion of the source code.

[alwillis → tptacek]

Pay attention to the fact that applications can use the DNSSEC support in the networking framework if they wanted to.

That was all.