4 ms·
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 boots
by 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 agoYou 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 agoCertainly 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 agoDoes 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 7y agoI 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-anonymous/kdnsserviceflagsvalidate?language=occ#declarations https://developer.apple.com/documentation/dnssd/1823436-anon... [3]: https://apps.apple.com/us/app/1-1-1-1-faster-internet/id1423538627 https://apps.apple.com/us/app/1-1-1-1-faster-internet/id1423... [4]: https://www.apple.com/legal/intellectual-property/tld/dps/ https://www.apple.com/legal/intellectual-property/tld/dps/