12 ms·
Why do we need DNSSEC?
- egberts1 1y agoYou require DNSSEC before deploying a SSHFP (SSH fingerprint) DNS resource record. Details: https://egbert.net/blog/articles/dns-rr-sshfp.html https://egbert.net/blog/articles/dns-rr-sshfp.html
- tptacek 1y agoWhy would you ever tie your SSH deployment to a global PKI? You are the entire source of truth for what is and isn't authentic in your own fleet. This is what SSH CA's are for.
- aberoham 1y ago[flagged]
- davidu 1y ago[flagged]
- tptacek 1y agoWe don't. If we did, we'd have it by now. It's been over 25 years of making appeals like this. It's a fun site! I'm not entirely sure why the protagonist is a green taco, but I can see why a DNS provider would make a cartoon protocol explainer. It's just that this particular protocol is not as important as the name makes it sound.
- deleted 1y ago[deleted]
- immibis 1y agoWe need a lot of things we don't have. Note that without DNS security, whoever controls your DNS server, or is reliably in the path to your DNS server, can issue certificates for your domain. The only countermeasure against this is certificate transparency, which lets you yell loudly that someone's impersonating you but doesn't stop them from actually doing it.
- tptacek 1y agoIn this case, there's an avalanche of money and resources backing up the problem domain DNSSEC attempts to make contributions in, and the fact that it's deployed in practically 0% of organizations with large security teams is telling.
- iscoelho 1y agoI would say it is more a testament to the unfortunate state of cybersecurity. These "theoretical" attacks happen. Everyone just thinks it won't be them.
- tptacek 1y agoMy rebuttal is that the DNSSEC root keys could hit Pastebin tonight and in almost every organization in the world nobody would need to be paged. That's not hyperbole.
- aspbee555 1y agobecause I can have my certificate authority in my DNS records and my app can verify the CA cert is from a trusted/verified source
- tptacek 1y agoThis would theoretically be possible if browsers did DANE and didn't, because of middlebox fuckery, have to have a fallback path to the X.509 WebPKI because DNSSEC requests get dropped like 5% of the time. But because that is the case, no browser does DANE validation today, and when they did, many years ago, those DANE CA certs were effectively yet another CA; they actually expanded your attack surface rather than constricting it. Even if that wasn't the case --- and it emphatically is --- you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments, most of which have a demonstrated aptitude for manipulating the DNS.
- saurik 1y ago> ...you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments... WebPKI is already making this mistake (due to ACME). DANE at least is honest about it?
- tptacek 1y agoNo, because DANE lacks the transparency capabilities.
- saurik 1y agoThis seems like the wrong trade-off; and, if it really mattered, we--including you--should be working to push DNSSEC/DANE to improve, not for people to double down on WebPKI. Maybe we need to be advocating for DNS transparency, for example; but like, the road to there is through DANE, not through WebPKI: staunchly shilling for WebPKI isn't helping either the situation, the ecosystem, or the landscape. OK, even so, let's examine it? The premise of CT is already a bit dubious: it involves being able to figure out, after the fact, that there was a certificate issued which should not have been issued, and the attack has already been performed. The only reason this makes any sense at all is because it (supposedly) provides an incentive to people not to participate in the attack in the first place... ...but, the assumption of this is pretty much always that the party that is at fault in such a scenario is always the CA. Only, the premise of ACME undermines that: if the government decides to take over the DNS record, Let's Encrypt absolutely will issue the certificate, and it absolutely wouldn't be their fault. If we did punish them for it, then what we are really saying is that ACME is a bad idea within WebPKI. (BTW: a big part of your argument against DNSSEC always relies on "people aren't able to do it correctly", and if we apply that to CT the situation also sucks: as the expiration time for certificates goes lower and lower, the number of certificates I'm being issued goes up and up, and unless I have a durable central log of my requests--and no normal installation does--I can't verify any of the information from CT anyway.) (Yes: we could build that software, so that Apache won't re-issue my certificates without first making sure that the request has been logged durably into a database, and there is software that also goes around scavenging CT to check if my certificate is mis-issued, but I hesitate to be that charitable, given that you have spent years ignoring people who assert that clients, not resolvers, must verify DNSSEC.) (And, to take this as a moment to push back here on another of your refrains: yes, people can get DNSSEC wrong and accidentally publish their keys... but, the likelihood they will do something that dumb--despite not doing so for TLS--is way lower than the almost-certainty that they aren't going to even know what CT is, much less track it--and, critically, report after-the-fact "oops too late" attacks--for mis-issuance.)
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- burnt-resistor 1y agoOptional, alternative standards don't have visibility and don't get used. Without a way to measure, nothing happens. There was once a few, UX-hostile DNSSEC & DANE browser extensions but these never worked well and were discontinued. Purveyors of functional DNSSEC: https://freebsd.org https://freebsd.org
- anonymousiam 1y agoDan Kaminsky showed us why we need DNSSEC. Without it, it's quite easy to MITM and/or spoof network traffic. Some governments like to do this, so they'll continue to make it difficult for DNSSEC to be fully adopted. The original registrar, Network Solutions, doesn't even fully support DNSSEC. You can only get it if you pay them an extra $5/mo and let them serve your DNS records for you. So for $5/mo you get DNSSEC, but you defer control of your records to them, which isn't really secure. https://community.cloudflare.com/t/dnssec-on-network-solutions/354103/2 https://community.cloudflare.com/t/dnssec-on-network-solutio...
- tptacek 1y agoIt's trivial to spoof DNS even with DNSSEC set up, because DNSSEC is a server-to-server protocol. Your browser doesn't speak DNSSEC; it speaks plaintext DNS, and trusts a single bit in the response header that says whether the upstream caching resolver actually checked signatures.
- anonymousiam 1y agoYou can run your own DNSSEC-aware DNS server locally. It's not hard at all.
- tptacek 1y agoYou can run a full-feed BGP4 bird configuration on your laptop too. Sounds awesome.
- deleted 1y ago[deleted]
- ectospheno 1y agoIt is so trivial to do so you wonder why more people don’t. I’d imagine the passionate “dnssec is bad” rants some people go out of their way to post on every comment on this site might be a factor.
- tialaramex 1y agoParts of the inevitable Thomas Ptacek DNSSEC rant remind me of the years of denialism from C++ people before the period when they were "concerned" about safety and the past few years of at least paying lip service to the idea that C++ shouldn't be awful...
- deleted 1y ago[deleted]
- acdha 1y agoOne thing I like about Thomas’ history on this issue has been the focus on UX. I think that “can probably be used safely by an expert who understands the domain” as a failure mode is something we should spend more time thinking about as an architecture failure rather than a minor frictional cost.
- tialaramex 1y agoSure, although in this space Thomas was already entirely happy with the early Web PKI which is completely terrible for this - similar conditions apply. At work this week I was hand-holding a DB engineer who was installing some (corporate, not Web PKI) certs and it reminded me of those bad old days. He's got a "certificate" and because this isn't my first rodeo, I ask him to describe it in more details before he just sends me it to look at. Of course it's actually a PKCS#12 file, and so if he'd sent that the key which is inside it is compromised - but he doesn't know that, the whole system was introduced to him as a black box which renders him unable to make good decisions. Out of that conversation we got more secure systems (fixing some issues that pre-existed the fault I was there to help with) and an ally who understands what the technology is actually for and is now trying to help us deliver its benefits rather than just following rote instructions they don't understand. Anyway, just as we went from "I dunno, I clicked a button and typed in the company credit card details, then I got emailed this PFX file to put on the server" to "Click yes when it asks if you want Let's Encrypt" with both an invisible improvement to delivered security and a simpler workflow, that's very much possible for DNSSEC if people who want to solve the problem put some work in, rather than contentedly announcing that it can't be fixed and we shouldn't worry about it.
- Avamander 1y agoWe don't. It's just an another PKI with operators you can never get rid of if they misbehave. That alone makes it not possible to start relying on it.
- growse 1y agoEveryone seems to miss the "single unbreakable pki" aspect that necessarily comes along with the design. :shrug:
- 1vuio0pswjnm7 1y ago"DNS resolvers are the ones in charge of tracking down this information for you." If one uses them. One can alternatively use iterative queries where no "DNS resolver", i.e., recursive resolver, is used. Many years ago I wrote a system for interative resolution for own use, as an experiment. I learnt that it can be faster than recursive resolution. People have since written software for iterative resolution, e.g., https://lizizhikevich.github.io/assets/papers/ZDNS.pdf https://lizizhikevich.github.io/assets/papers/ZDNS.pdf Unfortunately authoritative servers generally do not encrypt their responses. IMO this would be more useful than "DNSSEC". "And that data is often provided by authoritative servers." What are examples of data not provided by authoritative servers.
- unbindme5 1y agoOr run "unbound" as your own local recursive resolver.
- 1vuio0pswjnm7 1y agoOne could argue the primary (not the only) risk addressed by DNSSEC is third party DNS service, i.e., shared caches accessible from the internet If this is true, then one might assume DNSSEC is generally unnecessary if one is running their own unshared cache only accessible from the loopback or the LAN Software like djb's dnscache, a personal favourite, has no support for DNSSEC NLNet's unbound places a strong emphasis on supporting DNSSEC. The unbound documentation authors recommend using it https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/...
- UltraSane 1y agoDNSSEC is very easy to setup on AWS Route53 and it lets you sign any txt record you have which can be very useful.
- coretx 1y agoDNSSEC offers Zero protection against state actors.
- smitty1e 1y agoAnyone coming after you with acres of hardware will succeed. Security is about being a sufficiently hardened target, so that the lazy attacker seeks easier prey.
- tptacek 1y agoHardware has nothing to do with state actors and DNSSEC; the fact that DNSSEC is essentially a key escrow system does.
- jongjong 1y agoWe don't technically need ICANN the whole DNS system anymore. Anyone could quickly build a public cryptographically secure blockchain-based DNS system where people could optionally sync and query their own nodes (without even going over the wire). People could buy and own their domain names on-chain using cryptocurrency instead of repeatedly renting them from some centralized entity. You could easily build this today by creating a Chrome Extension with a custom URL/address bar which bypasses the main one and makes a call to blockchain nodes instead of a DNS resolver; it would convert a domain name into an IP address by looking up the blockchain. This system could scale without limit in terms of reads as you can just spin up more nodes. I mean it'd be so easy it's basically a weekend project if you use an existing blockchain as the base. Actually Ethereum already did something like this with .ETH domains but I don't think anyone built a Chrome Extension yet; or at least I haven't heard, though it's possible to enable in Brave browser via settings (kind of hidden away). Also, there is Unstoppable Domains.
- acdha 1y agoPeople have been doing that since roughly 2010, so the failures are important to learn why it’s not a weekend project. Adoption is critical for alternate roots, so the first question has to be how something gets enough users for anyone to feel it’s worth the trouble of using: the failure mode of DNS is that links break, email bounces, and tons of things which do server-side validation reject it, so this really limits usage. The other big problem is abuse. Names are long term investments, so there are the usual blockchain problems of treating security as an afterthought but you also have the problem that third-parties have a valid need to override the blockchain (e.g. someone registers Disney.bit and points it at a porn site or serves malware from GoogleChrome.eth). Solving that means that you’re back to trusting the entity which created the system or maybe a group of operators, so the primary appeal is going to be if you can make it cheaper than owning a traditional domain.
- Zaylan 1y agoI’ve honestly never known which sites use DNSSEC and which don’t. Browsers don’t warn you when it’s missing, and most people probably wouldn’t even know where to look. It’s hard to care about something like that, even if it really does matter behind the scenes.
- ndsipa_pomu 1y agoI think you're confusing DNSSEC with HTTPS. DNSSEC is how you go from an internet name to an IP address, so it happens before your browser starts talking to the website.
- Bender 1y agoDNSSEC induced outages aside, I will start signing my zones when: - DNSSEC auto-signing is tightly integrated into all authoritative DNS daemons instead of being a set of scripts, cron jobs and other bolt-on concepts. i.e. I never see a key, a script, etc... The daemon logs everything it is parsing and loading when set to verbose or debug. - My primary and secondary servers and other peoples servers all present a DNSSEC-autosign(ed) capability during AXFR/IXFR negotiation and the server knows what to do with it and what additional sanity checks to perform. - Zone transfers are universally encrypted by all DNS daemons. All of them. Every secondary service one could stumble upon must support XoT Encrypted Zone Transfer. Currently supported by NSD and Bind. RFC 9103. Otherwise this is just a LARP. Optionally also DNS over QUIC RFC 9250 - Primary and Secondary servers do sanity checks to determine if I am about to step on my own landmine and will rudely and hopefully quite offensively refuse to activate any changes if something seems off. - Optionally and optimally I would like to see all of the ROOT servers support DoT with a long lived cert and all that implies. This could be a separate set of physical servers that intercept/DNAT port 853 to cache the load off the actual ROOT servers.