[HN Gopher] Why do we need DNSSEC?
___________________________________________________________________
Why do we need DNSSEC?
Author : gpi
Score : 71 points
Date : 2025-06-19 17:03 UTC (5 hours ago)
(HTM) web link (howdnssec.works)
(TXT) w3m dump (howdnssec.works)
| tptacek wrote:
| We 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.
| immibis wrote:
| We 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 wrote:
| In 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 wrote:
| I 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 wrote:
| My 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.
| avidiax wrote:
| You are mostly right, but I would hope that certain core
| security companies and organizations would get paged.
| Root CAs and domain registrars and such should have
| DNSSEC validation.
|
| Unfortunately, DNSSEC is a bit expensive in terms of
| support burden, additional bugs, reduced performance,
| etc. It will take someone like Apple turning DNSSEC
| validation on by default to shake out all the problems.
| Or it will take an exploitable vulnerability akin to SIM-
| swapping to maybe convince Let's Encrypt! and similar
| services reliant on proof-by-dns that they must require
| DNSSEC signing.
| tptacek wrote:
| SIM-swapping is a _much_ more important attack vector
| than on-path /off-path traffic interception, and are
| closer to how DNS hijacking happens in practice (by
| account takeover at registrars).
| immibis wrote:
| If that happened, we'd revert to pre-DNSSEC security
| levels: an attack would still be hard to pull off (unless
| you own a root DNS server or are reliably in the path to
| one). It's like knowing the private key for
| news.ycombinator.com - it still doesn't do anything
| unless I can impersonate the Hacker News server. But that
| was still enough of a risk to justify TLS on the web.
| Mostly because ISPs _were_ doing it to inject ads.
| tptacek wrote:
| We are demonstrably in "pre-DNSSEC" security levels
| today. DNSSEC has almost no serious adoption.
| iscoelho wrote:
| That's false. Any organization that enables DNSSEC for
| their domains gains its security benefits and prevents
| any potential DNS hijacking.
|
| At this point, your statements border on intentional
| dishonesty. Please be more truthful and responsible in
| your statements.
| tptacek wrote:
| This is an engineering/technical discussion and you're
| not going to be able to name-call your way through it.
| iscoelho wrote:
| It is important. This is unfortunate rhetoric that is harming
| the safety of the internet.
|
| "For instance, in April 2018, a Russian provider announced a
| number of IP prefixes (groups of IP addresses) that actually
| belong to Route53 Amazon DNS servers."
|
| By BGP hijacking Route53, attackers were not only able to
| redirect a website to different IPs, globally, but also
| generate SSL certificates for that website. They used this to
| steal $152,000 in cryptocurrency. (I know I know, "crypto", but
| this can happen to any site: banking, medical, infrastructure)
|
| Also, before you say, RPKI doesn't solve this either, although
| a step in the right direction. DNSSEC is a step in the right
| direction as well.
|
| [1] https://www.cloudflare.com/learning/security/glossary/bgp-
| hi...
| tptacek wrote:
| BGP attacks change the semantic meaning of IP addresses
| themselves. DNSSEC operates at a level above that. The one
| place this matters in a post-HTTPS-everywhere world is at the
| CAs, which are now all moving to multi-perspective
| validation.
| iscoelho wrote:
| As you should be aware, multi-perspective validation does
| not solve anything if your BGP hijack is accepted to be
| global. You will receive 100% of the traffic.
|
| DNSSEC does greatly assist with this issue: It would have
| prevented the cited incident.
| tptacek wrote:
| A BGP attacker doesn't need to alter the DNS to intercept
| traffic; they're already intercepting targeted traffic at
| IP selectivity.
| iscoelho wrote:
| There are 2 ways to pull off this attack:
|
| 1. Hijack the HTTP/HTTPS server. For some IP ranges, this
| is completely infeasible. For example, hijacking a
| CloudFlare HTTP/HTTPS range would be almost impossible
| theoretically based on technical details that I won't go
| through listing.
|
| 2. Hijack the DNS server. Because there's a complete
| apathy towards DNS server security (as you are showing)
| this attack is very frequently overlooked. Which is
| exactly why in the cited incident attackers were capable
| of hijacking Amazon Route53 with ease. *DNSSEC solves
| this.*
|
| If either 1 or 2 work, you have yourself a successful
| hijack of the site. Both need to be secure for you to
| prevent this.
| tptacek wrote:
| In summation, you propose a forklift upgrade of the DNS
| requiring hundreds of millions of dollars of effort from
| operators around the world, introducing a system that
| routinely takes some of the most sophisticated platforms
| off the Internet entirely when its brittle configuration
| breaks, to address the problem of someone pulling off a
| _global_ hijack of all the Route53 addresses.
|
| At this point, you might as well just have the CABForum
| come up with a new blessed verification method based on
| RDAP. That might actually happen, unlike DNSSEC, which
| will not. DNSSEC has _lost_ signed zones in North America
| over some recent intervals.
|
| I do like that the threat model you propose is coherent
| only for sites behind Cloudflare, though.
| iscoelho wrote:
| "I do like that the threat model you propose is coherent
| only for sites behind Cloudflare, though."
|
| The threat model I proposed is coherent for Cloudflare
| because they have done a lot of engineering to make it
| almost impossible to globally BGP hijack their IPs. This
| makes the multi-perspective validation actually help.
| Yes, other ISPs are much more vulnerable than Cloudflare,
| is there a point?
|
| You are not saying DNSSEC doesn't serve a real purpose.
| You are saying it is annoying to implement and not widely
| deployed as such. That alone makes me believe your
| argument is a bit dishonest and I will abstain from
| additional discussion.
| tptacek wrote:
| No, I'm saying it doesn't serve a real purpose. I've
| spent 30 years doing security work professionally and one
| of the basic things I've come to understand is that
| security is at bottom an economic problem. The job of the
| defender is to asymmetrically raise costs for attackers.
| Look at how DNS zones and certificates are hijacked
| today. You are proposing to drastically raise _defender_
| costs in a way that doesn 't significantly alter
| _attacker_ costs, because they aren 't in the main using
| the exotic attack you're fixated on.
|
| If we really wanted to address this particular attack
| vector in a decisive way, we'd move away, at the CA
| level, from relying on the DNS protocol browsers use to
| look up hostnames altogether, and replace it with direct
| attestation from registrars, which could be made
| _arbitrarily_ secure without the weird gesticulations
| DNSSEC makes to simultaneously serve mass lookups from
| browsers _and_ this CA use case.
|
| But this isn't about real threat models. It's about a
| tiny minority of technologists having a parasocial
| relationship with an obsolete protocol.
| xorcist wrote:
| It does certainly make it easier. Sure, we can survive
| without it, but cryptographic signing of dns records is
| useful for a number of things.
| tptacek wrote:
| Counterpoint: no it isn't, which is why virtually nobody
| uses it. Even the attack this thread centers on --- BGP
| hijacking of targeted DNSSEC servers to spoof CA
| signatures --- is a rounding error sidenote compared to
| the way DNS zones actually get hijacked in practice (ATO
| attacks against DNS providers).
|
| If people were serious about this, they'd start by
| demanding that every DNS provider accept U2F and/or
| Passkeys, rather than the halfhearted TOTP many of them
| do right now. But it's not serious; it's just motivated
| reasoning in defense of DNSSEC, which some people have a
| weird stake in keeping alive.
| iscoelho wrote:
| You are again ignoring the fact that DNSSEC would have
| prevented a $152,000 hack. Yes, we are aware
| organizations are not always serious about security. For
| those that are though, DNSSEC is a helpful tool.
| tptacek wrote:
| No, it isn't. It attempts and mostly fails to address one
| ultra-exotic attack, at absolutely enormous expense,
| principally because the Internet standards community is
| so path-dependent they can't take a bad cryptosystem
| designed in the mid-1990s back to the drawing board. You
| can't just name call your way to getting this protocol
| adopted; people have been trying to do that for years,
| and the net result is that North American adoption
| _fell_.
|
| The companies you're deriding as unserious about security
| in general spend _drastically more_ on security than the
| companies that have adopted it. No part of your argument
| holds up.
| iscoelho wrote:
| "at absolutely enormous expense"
|
| Citation? A BGP hijack can be done for less than $100.
|
| "You can't just name call your way to getting this
| protocol adopted"
|
| I do not care if you adopt this protocol. I care that you
| accurately inform others of the documented risks of not
| adopting DNSSEC. There are organizations that can
| tolerate the risk. There are also organizations that are
| unaware because they are not accurately informed (due to
| individuals like yourself), and it is not covered by
| their security audits. That is unfortunate.
| tptacek wrote:
| The cost I'm talking about is _the defender 's_.
| iscoelho wrote:
| Oh stop with the hyperbole. Fortune 500's almost all
| outsource DNS to UltraDNS/Route53/Dyn/Cloudflare. They
| will spend longer having meetings about implementing it,
| rebutting individuals like yourself, than spending 5
| minutes actually implementing it.
|
| I don't understand why this is such a polarizing topic
| for individuals like you. It's as if DNSSEC burned down
| your house. It doesn't make sense to me.
| tptacek wrote:
| I'm not sure what this has to do with anything I've said
| on this thread, but we don't have to keep pressing these
| arguments; I'm pretty satisfied with the case I've made
| so far.
| growse wrote:
| Slack's house literally did burn down for 24 hours
| because of DNSSEC back into 2021.
|
| When you frame the risk as "marginal benefit against one
| specific threat" Vs "removes us from the internet for 24
| hours", the big players pass and move on. This is the
| sort of event the phrase "sev 1" gets applied to.
|
| Some fun companies have a reg requirement to provide
| service on a minimum SLA, otherwise their license to
| operate is withdrawn. Those guys run the other way
| screaming when they hear things like "DNSSEC" (ask me how
| I know).
|
| What percentage of the fortune 500 is served over DNSSEC?
| iscoelho wrote:
| and Slack.com still uses DNSSEC. They appear to not have
| come to the same conclusion.
| tptacek wrote:
| They added DNSSEC because of FedGov accounts that require
| it.
| iscoelho wrote:
| Happy to see security audits doing good work.
| daneel_w wrote:
| Oh. I thought it burned down because of their engineers
| not having fully acquainted themselves with the tool
| before applying it. It's misguided to hold DNSSEC
| culpable for Slack's engineers' goof-up. Like advising
| people against ever going near scissors because they
| might run with one in their hands.
| tptacek wrote:
| LOL.
|
| https://ianix.com/pub/dnssec-outages.html
| daneel_w wrote:
| Miserable list. Now share a link that shows all the
| successful deployments that never had any hiccups.
| growse wrote:
| Apparently the way to do sane risk management is just
| "don't be an idiot"?
| phillipseamore wrote:
| And at least Let's encrypt actually verifies DNSSEC before
| issuing certificates. IIRC it will become mandatory for all
| CA's soon. DNSSEC for a domain plus restrictive CAA rules
| should ensure that no reputable CA would issue a rogue
| cert.
| tptacek wrote:
| It absolutely will not. Most domains aren't hijacked by
| spoofing the DNS to begin with.
| iscoelho wrote:
| "Most domains". Yes, it is possible that nobody bothers
| to DNS hijack your domains. Sadly I've worked for
| organizations where it did happen, and now they have
| DNSSEC.
| tptacek wrote:
| I invite anybody who thinks this is a mic drop to pull
| down the Tranco research list of most popular/important
| domains on the Internet --- it's just a text file of
| zones, one per line --- and write the trivial bash `for`
| loop to `dig +short ds` each of those zones and count how
| many have DNSSEC.
|
| For starters you could try `dig +short ds google.com`.
| It'll give you a flavor of what to expect.
| daneel_w wrote:
| And you still can't seem to make your mind up on whether
| this is because DNSSEC is still in its infancy or if it's
| because they all somehow already studied DNSSEC and ended
| up with the exact same opinion as you. I'm gonna go out
| on a limb and say that it's not the latter.
| growse wrote:
| I've worked for these orgs on this exact problem.
|
| It's the latter.
| tptacek wrote:
| What do I have to make my mind up about? I worked on the
| same floor as the TIS Labs people at Network Associates
| back in the 1990s. They designed DNSSEC and set the
| service model: offline signers, authenticated denial. We
| then went through DNSSEC-bis (with the typecode roll that
| allowed for scalable signing, something that hadn't been
| worked out as late as the mid-1990s) and DNSSEC-ter
| (NSEC3, whitelies). From 1994 through 2025 the protocol
| has never seen double-digit percentage adoption in North
| America or in the top 1000 zones, and its adoption has
| declined in recent years.
|
| You're not going to take my word for it, but you could
| take Geoff Huston's, who recently recorded a whole
| podcast about this.
| zahllos wrote:
| The argument counter dnssec is that if you are trying to find
| some random A record for a server, to know if it is the right
| one, TLS does that fine provided you reasonably trust domain
| control validation works i.e. CAs see authentic DNS.
|
| An argument for DNSSEC is any service configured by SRV
| records. It might be totally legitimate for the srv record of
| some thing or other to point to an A record in a totally
| different zone. From a TLS perspective you can't tell,
| because the delegation happened by SRV records and you only
| know if that is authentic if you either have a signed record,
| or a direct encrypted connection to the authoritative server
| (the TLS connection to evil.service.example would be valid).
|
| So it depends what you expect out of DNS.
| iscoelho wrote:
| TLS doesn't provide any security in this case because TLS
| certificates are generated based on DNS. See Lets Encrypt.
| acdha wrote:
| Isn't this why validation is done from multiple locations
| on different networks? That blocked the 2018 attack and
| RPKI has made it even harder since.
| muppetman wrote:
| DNSSec has caused so many outages at this point it's a joke.
|
| You have to be so insanely careful and plan everything to the
| nth degree otherwise you break everything:
| https://internetnz.nz/news-and-articles/dnssec-chain-
| validat...
|
| The idea is important. What it aims to protect is important.
| The current implementation is horrible, far too complex and
| fraught with so many landminds that no one wants to touch it.
|
| If Geoff Huston is suggesting it might be time to stick a
| fork in DNSSec because it's done, then IMHO it's well cooked.
| https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
| iscoelho wrote:
| Yeah I'm by no means saying the implementation is good.
| RPKI is a joke as well in my opinion. But it's all we have
| right now.
|
| I am saying it is dishonest to discount the real security
| threat of not having DNSSEC.
| muppetman wrote:
| Right OK, I fully agree with you then.
| tptacek wrote:
| What parts do you agree about? Someone making an argument
| that we should return to the drawing board and come up
| with a new protocol, one that doesn't make the "offline
| signers and authenticated denial" tradeoffs DNSSEC makes,
| would probably be saying something everybody here agrees
| with --- though I still don't think it would be one of
| the 5 most important security things to work on.
|
| But the person you're replying to believes we should
| hasten deployment of DNSSEC, the protocol we have now.
| iscoelho wrote:
| I would love to go to back to the drawing board and solve
| the security pitfalls in BGP & DNS. I wish the
| organizations and committees involved did a better job
| back then.
|
| Sadly, we live in this reality for now, so we do what we
| can with what we have. We have DNSSEC.
| muppetman wrote:
| I don't read that reply as them saying we should hasten
| deployment of DNSSEC. If that was the intention of the
| comment then no, I don't agree with that aspect of it.
|
| I saying say I agree with the statement "I am saying it
| is dishonest to discount the real security threat of not
| having DNSSEC."
|
| I believe we do need some way to secure/harden DNS
| against attacks, we can't pretend that DNS as it stands
| is OK. DNSSEC is trying to solve a real problem - I do
| think we need to go back to the drawing board on how we
| solve it though.
| tptacek wrote:
| They definitely believe we should hasten deployment of
| DNSSEC --- read across the thread. For instance: Slack
| was taken down for a half a day owing to a deployment of
| DNSSEC that a government contract obligated them to
| undertake, and that commenter celebrated the contract.
|
| It's fine that we all agree on some things and disagree
| on others! I don't think DNS security is a priority
| issue, but I'm fine with it conceptually. My opposition
| is to the DNSSEC protocol itself, which is a dangerous
| relic of premodern cryptography designed at a government-
| funded lab in the 1990s. The other commenter on this
| thread disagrees with that assessment.
|
| _slightly later_
|
| (My point here is just clarity about what we do and don't
| agree about. "Resolving" this conflict is pointless ---
| we're not making the calls, the market is. But from an
| intellectual perspective, understanding our distinctive
| positions on Internet security, even if that means
| recognizing intractable disputes, is more useful than
| just pretending we agree.)
| belorn wrote:
| A common reason, if not the vast majority of cases, is that
| people mix up which key they publish and which key they are
| actually using. I don't doubt there are a lot of things
| they could do to improve the protocol, but this very common
| problem is fairly difficult to solve on a protocol level.
|
| I remember back in the days when people discouraged people
| from using encrypted disks because of the situation that
| could happen if the user lost their passwords. No disk
| encryption algorithm can solve the issue if the user does
| not have the correct password, and so the recommendation
| was to not use it. Nowadays people usually have TPMs or key
| management software to manage keys, so people can forget
| the password and still access their encrypted disks.
|
| DNSSEC software is still not really that developed that
| they automatically include basic tests and verification
| tools to make sure people don't simply mix up keys. They
| assume that people write those themselves. Too many times
| this happens after incidents rather than before (heard this
| in so many war stories). It also doesn't help that dns is
| full of caching and caching invalidation. A lot of the
| insane step-by-step plans comes from working around TTL's,
| lack of verification, basic tooling, and that much of the
| work is done manually.
| dwattttt wrote:
| > No disk encryption algorithm can solve the issue if the
| user does not have the correct password, and so the
| recommendation was to not use it.
|
| This problem is accurate, but it's the framing that makes
| it wrong.
|
| No disk encryption algorithm can simultaneously protect
| and not protect something encrypted, what you're missing
| is the protocol/practices around that, and those are far
| less limited.
|
| There is heaps of encryption around these days, there are
| people losing access to their regular keys, and yet
| procedures that recover access to their data while not
| entirely removing the utility of having encrypted
| data/disks.
| daneel_w wrote:
| > _You have to be so insanely careful and plan everything
| to the nth degree_
|
| If you're on the root/TLD end of things I agree. Certainly
| not if you're a domain owner or name server administrator
| on the customer end of things.
| burnt-resistor wrote:
| Related:
|
| - ECC vs. non-ECC memory and bitsquatting when people said
| "oh, it doesn't matter and it's too expensive for no
| benefit."
|
| - http:// was, for years, normalized pre-PRISM.
|
| - Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge
| spoofing and metadata collection threat surface.
| rsync wrote:
| "Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge
| spoofing and metadata collection threat surface"
|
| Genuinely curious:
|
| What actor, in 2025, would exist in your threat model for
| DoH ... but wouldn't simultaneously be sniffing SNI ?
|
| I can't think of any.
|
| I cannot think of any good reason to be serious about DoH
| and DNS leakage in the presence of unencrypted SNI.
|
| What am I missing ?
| iscoelho wrote:
| Not saying they are malicious actors, but easy answer
| would be any Public WiFi anywhere. They all intercept
| DNS, less than 1% intercept SNI.
|
| It is also public knowledge that certain ISPs (including
| Xfinity) sniff and log all DNS queries, even to other DNS
| servers. TLS SNI is less common, although it may be more
| widespread now, I haven't kept up with the times.
| growse wrote:
| Isn't the vast majority of TLS connections using SNI
| today?
| iscoelho wrote:
| Yes TLS SNI is ubiquitous. I am referring specifically to
| TLS SNI metadata collection.
| ikiris wrote:
| tls1.3 exists
| nine_k wrote:
| There are two things mixed up. "We need secure DNS" != "we
| need DNSSEC".
|
| There is a huge demand for securing DNS-related things, but
| DNSSEC seems to be a poor answer. DoH is a somehow better
| answer, with any shortcomings it may have, and it's widely
| deployed.
|
| I suspect that a contraption that would wrap the existing DNS
| protocol into TLS in a way that would be trivial to put in
| front of an existing DNS server and an existing DNS client
| (like TLS was trivial to put in front of an HTTP server),
| might be a runaway success. A solution that wins is a
| solution which is damn easy to deploy, and not easy to screw
| up. DNSSEC is not it, alas.
| iscoelho wrote:
| DoH does not solve anything that DNSSEC solves. They have
| almost no overlap.
| pvg wrote:
| That's an pretty damning indictment of DNSSEC.
| ClumsyPilot wrote:
| But TLS relies on having a domain If domain intern depends
| on tls you have chicken and egg problem
| nine_k wrote:
| TLS internally does not depend on a domain in the DNS
| sense, it basically certifies a chain of signatures bound
| to a name. That chain can be verified, starting from the
| root servers.
|
| The problem is more in the fact that TLS assumes creation
| of a long-living connection with an ephemeral key pair,
| while DNS is usually a one-shot interaction.
|
| Encrypting DNS would require caching of such key pairs
| for some time, and refreshing them regularly but not too
| often. Same for querying and verifying certificates.
| TZubiri wrote:
| DoH is like VPNs, used by paranoids and criminals
| mike_d wrote:
| > It is important. This is unfortunate rhetoric that is
| harming the safety of the internet.
|
| DNSSEC was built for exactly one use case: we have to put
| root/TLD authoritative servers in non-Western countries. It
| is simply a method for attesting that a mirror of a DNS
| server is serving what the zone author intended.
|
| What people actually want and need is _transport security_.
| DNSCrypt solved this problem, but people were bamboozled by
| DNSSEC. Later people realized what they wanted was transport
| security and DoH and friends came into fashion.
| iscoelho wrote:
| DNSSEC is about authentication & integrity. DNSCRYPT/DOH is
| about privacy. They solve completely different problems and
| have nothing to do with one another.
|
| There is also no reason we can't have both.
| tptacek wrote:
| If you have secure channels from recursers all the way
| back to authority servers (you don't, but you could) then
| in fact DoH-like protocols do address most of the
| problems --- which I contend are pretty marginal, but
| whatever --- that DNSSEC solves.
| iscoelho wrote:
| Yessir, that isn't possible yet but it would absolutely
| be a solution! I'd love to see it.
| tptacek wrote:
| What's more, it's a _software-only_ infrastructure
| upgrade: it wouldn 't, in the simplest base case, require
| zone owners to reconfigure their zones, the way DNSSEC
| does. It doesn't require policy decisionmaking. DNS
| infrastructure operators could just enable it, and it
| would work --- unlike DNSSEC.
|
| (Actually getting it to work reliably without downgrade
| attacks would be more work, but notably, that's work
| _DNSSEC would have had to do too_ --- precisely the work
| that caused DANE-stapling to founder in tls-wg.)
| acdha wrote:
| That quote is interesting because all of the period reporting
| I've seen says that the attackers did NOT successfully get an
| HTTPS certificate and the only people affected were those who
| ignored their browsers' warnings.
|
| https://doublepulsar.com/hijack-of-amazons-internet-
| domain-s...
|
| https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
| jcranmer wrote:
| I'm sorry, this is just such an incredibly fine-tuned threat
| model for me to take it seriously.
|
| You start with a BGP hijack, which lets you impersonate
| _anybody_ , but assume that the hijacker is only so powerful
| as being able to impersonate a specific DNS server and not
| the server that the DNS server tells you about. You then use
| that specific control to get a CA to forge a certificate for
| you (and if the CA is capable of using any information to
| detect that this might be a forgery, the attack breaks).
|
| And of course, the proposed solution doesn't do anything to
| protect against other kinds of DNS hijacking--impersonating
| somebody to the nameserver and getting the account switched
| over to them.
| iscoelho wrote:
| > I'm sorry, this is just such an incredibly fine-tuned
| threat model for me to take it seriously.
|
| You claim it is fine-tuned, but it has happened in the real
| world. It is actually even better for attackers that it is
| "obscure", because that means it is harder to detect.
|
| > but assume that the hijacker is only so powerful as being
| able to impersonate a specific DNS server and not the
| server that the DNS server tells you about.
|
| Yes, all layers of the stack need to be secure. I am not
| making assumptions about the other layers - this thread is
| about DNS.
|
| > if the CA is capable of using any information to detect
| that this might be a forgery
|
| They are not. The only mitigation is "multi-perspective
| validation", which only addresses a subset of this attack.
|
| > And of course, the proposed solution doesn't do anything
| to protect against other kinds of DNS hijacking
|
| Yes, because other kinds of DNS hijacking are solved by
| HTTPS TLS. If TLS and CAs are broken, nothing is secure.
| throw0101d wrote:
| > _We don 't. If we did, we'd have it by now. It's been over 25
| years of making appeals like this._
|
| See also IPv6. ;)
|
| Edit: currently at "0 points". People, it was a joke. Chill.
| tptacek wrote:
| We very definitely do have IPv6. I'm using IPv6 right now.
| Last numbers I saw, over 50% of North American hits to Google
| were IPv6. DNSSEC adoption in North America is below 4%, and
| that's by counting zones, most of which don't matter --- the
| number gets much lower if you filter it down to the top 1000
| zones.
| throw0101d wrote:
| > _We very definitely do have IPv6. I 'm using IPv6 right
| now._
|
| I'm not. Neither is my home wireline PON ISP, even though
| they have it on their mobile network (but my previous ISP
| did).
|
| Also, every time there's an IPv6 article on HN there are
| entire sub-threads of people saying it's never going to
| come along. -\\_(tsu)_/-
|
| * https://news.ycombinator.com/item?id=44306792
| JdeBP wrote:
| One can hope that someone will give the ISPs in my
| country a metaphorical hefty kick up the arse, especially
| as some of the more niche ones have been happily
| providing IPv6, and business customers can get IPv6, and
| of course _other countries_ are happily embracing IPv6.
| So I wouldn 't say _never_.
|
| But the clear evidence is that past promises of it
| arriving at those major ISPs are very hollow indeed.
|
| It's not the same with DNSSEC in the U.K., though. Many
| WWW hosting services (claim to) support that right now.
| And if anything, rather than there being years-old
| ineffective petition sites clamouring for IPv6 to be
| turned on, it is, even in 2025, the received wisdom to
| look to turning DNSSEC _off_ in order to fix problems.
|
| * https://codepoets.co.uk/2025/its-always-dns-unbound-
| domain-s...
|
| * https://www.havevirginmediaenabledipv6yet.co.uk
|
| One has to roll one's eyes at how many times the-
| corporation-disables-the-thread-where-customers-
| repeatedly-ask-for-simple-moderen-stuff-for-10-years is
| the answer. It was the answer for Google Chrome not
| getting SRV lookup support. Although that was a mere 5
| years.
| JdeBP wrote:
| Well for some value of "we" and some value of "have". (-:
| api wrote:
| If you want the net to support end to end connectivity we
| need IPv6. Otherwise you'll end up with layers and layers of
| NAT and it will become borderline impossible.
|
| A lot of protocols get unstable behind layers of NAT too,
| even if they're not trying to do end to end / P2P. It adds
| all kinds of unpredictable timeouts and other nonsense.
| acdha wrote:
| As a joke, it's not easily distinguishable from trolling and
| since IPv6 is approaching half of all traffic, more in many
| areas, the humor value is limited.
| TZubiri wrote:
| Reminds me of:
|
| https://serverfault.com/questions/1018543/dns-not-resolving-...
|
| Unfortunately the basic thought process is that "it is a
| security feature, therefore it must be enabled" it is very hard
| to argue against that, but it is pretty similar to "we must
| have the latest version of everything as that is secure" and
| "we should add more passwords with more requirements and expire
| it often". One of those security theatres that optimizes for
| reducing accountability, but may end up with almost no security
| gains and huge tradeoffs that may end up even compromising
| security through secondary effects (how secure is a system that
| is down?)
| aspbee555 wrote:
| because 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 wrote:
| This 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.
| burnt-resistor wrote:
| Optional, 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
| anonymousiam wrote:
| Dan 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-solutio...
| tptacek wrote:
| It'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.
| tialaramex wrote:
| Parts 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...
| acdha wrote:
| One 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.
| Avamander wrote:
| We 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 wrote:
| Everyone seems to miss the "single unbreakable pki" aspect that
| necessarily comes along with the design. :shrug:
| 1vuio0pswjnm7 wrote:
| "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
|
| 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 wrote:
| Or run "unbound" as your own local recursive resolver.
| UltraSane wrote:
| DNSSEC is very easy to setup on AWS Route53 and it lets you sign
| any txt record you have which can be very useful.
| coretx wrote:
| DNSSEC offers Zero protection against state actors.
___________________________________________________________________
(page generated 2025-06-19 23:00 UTC)