5 ms·

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

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 7y ago
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 7y ago
  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-protecting-the-dns https://www.icann.org/news/blog/a-key-milestone-in-protectin...
  - tptacek 7y ago
    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 7y ago
      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 7y ago
        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".

tptacek 7y ago

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 7y ago
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-protecting-the-dns https://www.icann.org/news/blog/a-key-milestone-in-protectin...
- tptacek 7y ago
  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 7y ago
    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 7y ago
      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".