
Ask HN: Why is there even a DNSSEC root key? - rvnx
I&#x27;m wondering what&#x27;s the point of the DNSSEC root key.<p>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 ?<p>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&#x2F;browser) trusted CAs ?<p>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...](https://www.redhat.com/en/blog/what-you-need-know-about-first-ever-
dnssec-root-key-rollover-october-11-2018)

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.

------
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](https://www.iana.org/dnssec/files).

A great introduction to DNSSEC + DANE:
[https://youtu.be/BhvU19RJrPY](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](https://youtu.be/A8SgW9y__io)

~~~
tptacek
_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
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](https://tools.ietf.org/html/rfc5011)

[2]: [https://www.icann.org/news/blog/a-key-milestone-in-
protectin...](https://www.icann.org/news/blog/a-key-milestone-in-protecting-
the-dns)

~~~
tptacek
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
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
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
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](https://greatdane.io)

[2]:
[https://developer.apple.com/documentation/dnssd/1823436-anon...](https://developer.apple.com/documentation/dnssd/1823436-anonymous/kdnsserviceflagsvalidate?language=occ#declarations)

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

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

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

~~~
alwillis
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
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
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
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.

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

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

~~~
tptacek
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.

