Universal DNSSEC: Secure DNS for Every Domain
blog.cloudflare.com
blog.cloudflare.com
No, it doesn't. DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates. DNSSEC is far less valuable than its proponents would like you to believe, and it comes at a significant cost to Internet trust: its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
It's understandable that Cloudflare would jump on DNSSEC: the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast. DNSSEC is an opportunity for a company like Cloudflare to make the case that they should manage your infrastructure, not you; the more features like DNSSEC Cloudflare can find, the more market share they'll acquire.
But make no mistake: DNSSEC isn't about helping you with your security issues.
Obligatory: http://sockpuppet.org/blog/2015/01/15/against-dnssec/
You don't use Cloudflare as a DNS provider. Their value proposition [imho] is as a CDN/WAF.
I was genuinely hoping someone like Sucuri or Incapsula had picked it up.
We are among the fastest if not the fastest authoritative DNS provider in the world.
Hold on. This is actively conflating DNSSEC and DANE.
I know your point that the "main feature" of DNSSEC is enabling DANE, and I respect that. But the two domains are still distinct: DNS security and the PKI built on top of that.
DNSCrypt only addresses DNS security, so it should be compared to pure DNSSEC, which obviously does not "cede to the US Government control over TLS keys".
Bad reasoning. You think we'll not deploy HTTP/2 because the head of the committee works for Akamai? Cmon.
DNSCrypt needs a secure resolver and client software. CloudFlare doesn't have either of those things which rather hampers us deploying DNSCrypt.
Behold:
* https://github.com/bitbeans/SimpleDnsCrypt
I'm sure with Filo on your team you could make that happen.
What does CloudFlare have to distribute?
They also open sourced client implementations for end boxes to talk to them or any other recursive securely.
jedisct1 is also looking for work right now, he'd happily implement it all for you I'm sure.
How do both compare ("far better")?
DNSSEC is for server-server, to propagate existing addressbook.
Only DNSCrypt protects your privacy!One additional feature that DNSCrypt has over DNSSEC is that it encrypts queries and responses and thus has some privacy value, on the other hand there probably is nothing privacy-sensitive in DNS queries and responses that will not get leaked by IP addresses and SNI anyway.
DNSSEC solves no meaningful problems on day 1. DNSCrypt solves one meaningful problem on day 1. Long term, if DNSCrypt is deployed widely, it will grow to solve more of the NSA problem, as end-to-end chains of DNSCrypt-protected DNS links are deployed connecting clients to authority servers. But over the long term, DNSSEC's problems don't get any better at all.
Actually, there's a lot. You can learn a tremendous amount from just looking at the NS traffic.
We should rather encourage people to use a local, validating resolver.
There's an argument that DNSSEC might make a marginal dent in protecting email from for-profit criminal enterprises. I don't believe it will, but let's stipulate that it does. It accomplishes that by setting up a new PKI whose roots are de jure controlled by the Five Eyes governments. How can that possibly be worth the gain?
How would exactly have Tunisia stripped STARTTLS [0] if mail servers did DNSSEC+DANE to get pinned TLS certificates?
DNSSEC deters marginal threats at the cost of encouraging serious threats. That's not a good tradeoff.
Why not?
> I am worried about GCHQ.
I don't contest this part.
ISTM this could at least be a transparency win, for average users. If trust went by TLD, we'd know that e.g. using "bit.ly" required trusting the Libyan domain admins. With CAs now, we just get a pile of CAs pre-installed with our OS or browser, and a bit of knowledgeable clicking is required in order to determine which CAs are trusted for any particular transaction. [EDIT: and in a sense, we are still trusting the Libyan domain admins.]
Whether one views the combination of CAs and TLD registrars that we have now as "defense in depth" or "more links in a chain" sort of depends on your threat model. Personally I'm more worried about identity thieves than oppressive governments, but others might have different concerns.
This may not offset the other problems you've identified.
With DNSSEC, we get the knowledge that a .LY domain probably has TLS keys controlled by Libya, and, if we're very savvy, the knowledge that .IO keys are controlled by GCHQ. We don't get consequences (you can't take .IO away from its owners, and Google simply isn't going to move from .COM, which is controlled by NSA), and we only get pinning's security with many more years of effort that haven't yet been sunk into DANE.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
And not all ccTLDs are controlled by that country's authorities, they are normally delegated to other organizations which in some cases may not even be under their jurisdiction.
There's also no movement of control to "governments". The entity that controls the TLD has authority over DNS, today, and the one with authority over DNS are in full control over DLV TLS certificates, today. Any pinning and transparency checks would work unimpeded in a DNSSEC world.
DNSSEC just makes it much harder to improperly get an TLS certificate. Today you just need to annouce their AS for a while, or cache spoof any of the hundreds of CAs. No CA has ever been dropped for signing a certificate by the rules. The only reason we don't see that more is because it's apparently even easier to bribe or force a CA to give them out. NSA certainly doesn't need to attack anything to get certificates issued, today.
I agree that governments control the DNS today.
The problem is that DNS does not in turn control Internet cryptography, and DNSSEC's primary use case is to change that.
That's a strange thing to say. DNS is pretty much the only thing that controls Internet cryptography. The number of non-domain validated certificates is vanishingly small.
Do I understand this correctly?
If there is a blacklist in place, absolutely each and every one of the hundreds of CAs need to adhere to it. One mistake or one exception and I could still get a misissued certificate just as easily as ten years ago.
Google can probably get it revoked very quickly, but we all know how well that works in practice. The only saving grace for the CA system is key pinning, and that's the only reason all those corrupt and/or incompentent CAs were exposed lately. But key pinning is not enough in itself. It is complementary to your certificate validation path(s).
I remain impressed that people who were at best ambivalent about the NSA and Snowden revelations, and other US Gov misdeeds, would use the fear of government control as their primary argument against DNSSEC.
Those folks are right about DNSSEC, of course. Their hemming and hawing about the NSA, Snowden, and the US government, I think history will judge harshly.
Is this me? I was, and am still, quite concerned about many of Snowden's revelations. I'm not as concerned about "passive" NSA vuln research as e.g. EFF are, although active sabotage of standards and deployed infrastructure has got to stop. I don't intend in this thread to rationalize anything, only to find out more about DNSSEC. For instance, why couldn't DNSSEC be used in addition to other methods such as TLS and DNSCrypt? I appreciate your insight in this area, but it's not clear that DDOS amplification (which, if it could be avoided by anyone, could be avoided by CF with their long experience in packet dropping) is enough of an issue to prevent even trying something like this.
"Why isn’t DNSSEC good enough?
DNSSEC attempts to guarantee that domain names are resolved to correct IP addresses. However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:
- Once DNS resolution is complete, DNSSEC does not ensure the confidentiality or integrity of communication between a client and the destination IP.
- No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.
HTTPS guarantees the confidentiality and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies."
And:
"Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.
DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing."
> https://security.stackexchange.com/questions/11566/how-does-...
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.
I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!
If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.
Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.
So it only works reliably when it's broken. What a fantastic security system.
None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.
But otherwise, sure, that works.
If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
That is just an implementation detail is it not? My understanding is that there is nothing stopping a user (or more likely, the suppler of the user's OS) from setting up a local DNS server which verifies DNSSEC records.
> its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
Those governments can already get fraudulent certs issued to them either by directly coercing a CA located within their jurisdiction, exploiting a vulnerability in one of the hundreds of CAs worldwide, or by temporarily falsifying the records of the target domain to trick an unsuspecting CA. The difference with DNSSEC+DANE is that governments can only impersonate domains under TLDs that they control. No longer can Iran impersonate google.com by hacking a Belgium CA.
I'm not going to defend all of the implementation details of DNSSEC. Suffice to say, mistakes were made, but the concept is sound.
So no, I don't concede that this is simply an "implementation detail".
Governments can't simply subvert CAs anymore, because of key pinning. If they do that, there's a very good chance they'll get caught, and when they get caught their CA gets restrictions imposed by the browser vendors, or removed altogether.
There are no meaningful consequences for the hard-to-detect forgeries DNSSEC enables NSA/GCHQ to make. Google can't simply restrict .COM, or switch to another domain. Google Mail just has to live with the security/privacy policies of all the TLDs it operates on, forever, with no recourse.
That's a terribly unsound concept.
The CA cannot automatically detect when a domain has been hijacked, it will issue the certs.
In this situation (with either the present DNS world, or dnscrypt), agencies are frankly 100% as unaccountable as they would be under DNSSEC world, because they still control the TLDs.
DNSCrypt does as little as DNSSEC to fix this issue. Pinning and certificate transparency can help detect under either scenario however.
Another concern in DNSCrypt is how does it handle the MITM problem between DNS servers? Trust on first sight is a lousy unscalable model (what if keys change, what if the badguys are already there before first contact) that is way more vulnerable than DNSSEC to forged replies.
You are falling into the classic trap of "this dosent solve every problem so we cannot permit it to solve any problem" that has held back security for decades.
DNSSEC is real, it is deployable and stuff is capable of supporting it, and it does solve very real issues. That counts.
My point is, of course, that DNSSEC creates more serious problems than it solves. If you think my argument is "DNSSEC isn't perfect and we should wait for perfection", you haven't read what I'm saying carefully enough.
They absolutely do, which is why we have things like key pinning.
I can set up DNSSEC and DANE today, everyone who cares gets an alternative validation path to me, and the Internet is safer because of it.
You can set up DNSSEC and DANE today, but thankfully no browser gives a shit. Key pinning, however, will not only protect you, but will also get the CA that actually coughs up a forged cert for your site locked out of Chrome and Firefox.
Maybe I'm just using the wrong terms, but as far as I can see the number of sites pinned in Firefox is tiny: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... and there is no process for getting sites added to that list.
Could you give the address for the form where I can get my site pinned in Chrome?
You explicitly replied to a post about wanting something better than"trust-on-first-use" and said key pinning solved that problem, so I assumed there was another way. I don't understand what your post was trying to say if there isn't.
Is there some way that HPKP is able to work around the first visit problem?
But apart from the difficulty NSA will have actually isolating your first use to intercept it, the point of HPKP is that they have to get everyone's first use, because when a browser sees a broken pin, it doesn't just go "oh, whatever, pop up an error and move on"; it also gets to freak out and report the broken pin.
With widely deployed HPKP, every hit to a site being MITM'd by someone with a compromised CA is an opportunity for that CA to be forever burned, simply because someone who already had the right cert pinned will trigger an alert.
There is just no way the NSA is going to risk it except in very very specific circumstances they can easily control, (exactly the same situation as HPKP) because, they too will be forever burned, except now they cant just switch to one of hundreds of other CAs, they have burned the root keys to a tld. This will be obvious, this will be screamed about from the rooftops, the key will be rotated + a ton greater scrutiny applied to the process.
Its not like browsers and other people pinning certs are just going to shrug their shoulders and say "aw shucks, i guess we wont worry about it"
Your single registrar becomes your ca (who you already have to trust isnt hijacking your domain and issuing certs for it), not (potentially) every ca on earth.
You can validate dns responses to be at least as real as the root dns servers claim.
Nonpinned certs gain a lot better gaurentees against random CAs. (google cant pin every cert in chrome)
It does not solve the problem of "what if the dns roots are lying to you", but as ca world cert aquisition is tied to that very same issue, neither does normal TLS.
No matter what you are stuck trusting that dns roots arn't being evil in the case of unpinned cert.
At least with DNSSEC you arnt stuck additionally trusting every CA on earth in the case an attacker can mitm, but dosent control said tld.
The level of tampering required for the NSA to fake DNSSEC replies is very evident if you have the cert pinned, and very hard to deny.
As things stand, its very easy to deny it was the NSA when anyone and their dog can have access to a CA cert.
They can not, however, subvert the root zone any more. Not since it was singed in 2010.
(Expecting users to read URIs was always a losing tactic, but surely everyone knows that now with IDNs.)
What I do is to point out that with today's domain validated model, it would make a lot more sense to restrict the validation path to only includes authoritative information about the domain, and to do so in a way that is cryptographically secure.
The fact here is that Verisign can sign anything, today. They can not, however, impact the validation chain that DANE provides.
There are also many millions of use cases where .com does not matter at all.
Name an important domain, and let's see what world government controls its DNSSEC keys.
If you'd like, I will name an important domain with a trivial use case: skatteverket.se. It it the agency responsible not only of taxes but of nearly all personal data: marriages, deaths, everything. They have stringent security requirements for this, and to their users their security is infinitely more important than that of, say Facebook for example.
In what way would their adoption of DNSSEC cede control of anything to the NSA, or to anyone?
I think we can be done now, don't you?
You asked for a domain, any domain, and was prepared to show how Verisign could exercise their control over .com and somehow affect the validation path that DANE provides. At least that's what how I understood you. It's not always clear.
You seem to argue that susceptibility to state level actors is a counterargument to the standard, so I gave one of the few examples I know of who really need to protect against such adversaries.
Apparently my example was somehow a bad one. Take one of the big banks instead then? What could happen to swedbank.se if they signed their delegation with their TLD?
Or why don't you provide an example instead, and show in what way signing it would cede control to the NSA, or to anyone else?
* Every .COM
* Every .CO.UK
* Every .COM.AU
* Every .IO
* Every .ORG
Your response:
* The Swedish tax authority's site.
Again, there are millions of use cases where .com doesn't matter.
You alluded to some control that some large entity (which I only assume to be Verisign) exercise over every important domain. I take it that was never the case?
While a healthy dose of cynicism is appropriate with-respect-to government control of TLDs, in the western world they are still at least nominally accountable to their constituents. Wholesale forgery is not likely to go over well with them, most importantly not with large tech companies. Targeted one-off forgeries would be easier to get away with, but they are also still perfectly doable today.
I have heard that both CeroWRT and OpenWRT support DNSSEC validation. There's also DNSSEC-trigger with Unbound for local DNSSEC validation. Maybe someone on here knows more, but I believe this directly addresses this issue. DNSSEC also is completely orthogonal to things like dprive which encrypt DNS queries. I'm not that familiar with DNSCurve but I believe it functions similar to dprive.
its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
I think you're referring to DANE, and DANE is not intended to replace the CA system, but instead augment it. See my article on this here: http://metafarce.com/adventures-in-dane/. DANE simply provides another means to verify the authenticty of a TLS cert, it doesn't replace the CA system, and having multiple methods for ensuring cert integrity is a net positive for the Internet.
The foundations of our CA system are not sound. Any compromised CA threatens sites secured by all CAs. In addition to specifying a hash of a site's TLS cert, DANE allows a site operator to lock down their trust anchor to the single CA they use.
I also don't get the signing Internet cryptographic trust over to the world governments thing. Please explain how you reach this conclusion. I've deployed DANE on a .com, and I never gave any private keys to anyone. I only needed to provide a hash of my TLS cert to my DNS provider. Granted my DNS provider could change the hash to something else, or redirect my site to somewhere else. Also, the TLD operator for .com could redirect my NS records to somewhere else as well, and then sign it with the TLD's ZSK. But they can already do that without DNSSEC, and I would notice this pretty quickly and attribute the attack to them.
the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast.
This is where I will agree with you. DNSSEC is tough and complicated to deploy. However, this does not mean it has no value. If companies like Cloudflare make it easier to deploy DNSSEC then that is a net win for Internet security.
DNSSEC isn't about helping you with your security issues.
I really like being able to trust what DNS servers tell me. That's an immediate benefit to me and my security.
My understatnding of history as I experienced it is that the resurgence of interest in DNSSEC was due to publicized cache poisoning of shared DNS caches circa 2008.
I run my own local cache on the loopback. I run my own root and other zones. I also use DNSCurve.
Recently there was another one of these DNSSEC advertisement posts from this same company about DNSSEC on the HN front page. (Surprise. How unusual.)
I asked a simple question: What benefit would DNSSEC offer someone like me?
While I did not get any straight answers, I did get blasted with walls of text from some guy working for a domain name registrar.
Perhaps it is not only companies selling consulting and DNS appliances, e.g., on government contracts, that are behind DNSSEC. Maybe it extends to the entire "DNS industry", e.g., people "selling" (renting) domainnames to users. For readers who are unaware, Cloudflare is in this "DNS industry". Their customers must hand over control of their DNS to Cloudflare. Cloudflare's entire approach to "security" depends on this.
DNSSEC is generally a PITA to set up and maintain. This makes it the perfect "service" to sell. If you like to generalize, you could argue this is true for any sufficiently complex networking component. The more complex the set up and management for users, the easier it is to sell them services.
I am an ordinary user who happens to enjoy setting up and managing my own DNS, making databases of IP addresses and even making my own domainnames, so I need a lot of convincing to be interested in something like DNSSEC, managed by third parties.
DNSSEC, as advertised, is a system that focuses on some mythical "validation" of DNS data.
Who decides what DNS data is "valid"?
Does DNSSEC require a "web of trust" model like the CA system?
If yes, why should we trust these third parties more than the endpoint we're trying to reach?
How much will users have to pay to be "validated" in such a system?
If some third party(s) controls what is and what is not "valid" DNS data can they more easily "disable" certain domains?
I could go on.
By contrast, a system for encrypting DNS packets is something I find more interesting and useful. I can set it up without too much effort and I control it. No need for third parties. Once more, it costs me nothing. There is no built-in idea of "web of trust" and I do not need to "purchase" a "valid" dommainname to begin using it.
But I am just a dumb user so what do I know? Go get your DNSSEC, right away.
* DNS TLD operator trust is replacing CA trust. This is specious off the bat since so many CAs rely on the DNS for verifying the origin of a request. Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it. In other words certificate trust is already, implicitly, DNS trust. Even HPKP+HSTS won't save you when the adversary is a state actor and controls DNS, controls a CA, and controls the network.
If you think most targets will cry foul and invoke the Internet Death Penalty upon detecting a violated CA, you're dreaming. Most targets don't even know what a certficate is.
I would be looking for an entirely different trust framework rather than muttering about two that are nearly congruent.
* Server-based validation is a problem. Why? Whether it's a locally running validating recursive resolver, or a validating library you link to your own software, or 8.8.8.8, in every case you're choosing to trust someone else's code and the mechanism by which you invoke it. The only absolute way to resolve this issue is audit/write the validation code yourself.
I.e., this isn't an emergent property of DNSSEC, it's just browser authors being lazy. (See also: lack of SRV record support in HTTP/2).
* DNSSEC doesn't help _me_ with _my_ security issues. Well, for that kind of universal claim we only need one counterexample to make it false. I'm happy to provide one: distribution and validation of my SSH host keys.
It's worse than that. All an attacker needs to do is passively monitor the target domain's emails, and he can get a valid CA-signed certificate. If the attacker can only monitor some networks, not all globally: no problem, since the attacker gets to choose which CA the email gets sent from!
I'm not sure what you're trying to say about "state actors" and HPKP. No matter what happens: the NSA will control the DNS. We all stipulate that they control CAs. DNSSEC does nothing to change this (it actually ratifies it), but HPKP does.
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)
There is a difference between the way TCP/IP works when sites like HowStuffWorks describe it, and the way it works in the real world.
In the real world, when you type a site name into your browser bar, your browser invokes a stub resolver to send a DNS query to a DNS recursive cache server, which is virtually never running on your local machine.
So, however it's supposed to work in theory, in practice there is DNS traffic running between your machine and some server somewhere on the Internet (perhaps very far away on the Internet if you use OpenDNS or Google DNS), and DNSSEC does not protect those queries. They're flying around the network in plaintext protected only by a 16 bit plaintext query ID and somewhat less than 16 bits of entropy in source ports, if you're lucky.
I'm pretty sure I can speak reliably for what that article I linked to claims.
[1] For example, this configuration change is all that's required to enable DNSSEC on Gentoo, and would probably also work on Ubuntu and Fedora: https://wiki.gentoo.org/wiki/Dnsmasq#DNSSEC
The obstacles to changing to IPv6, or to making any changes whatsoever to TCP, just aren't there.
As far as I understand, IPSec + DNSSEC gets similar security guarantees to SSL/TLS without identity certification, so once you have one there isn't any real economic incentive to put massive effort into developing the other.
Exactly! A rare time when we couldn't agree more. I've taken shit on various forums when saying something similar but it's quite obvious when you look at its structure and where the trust is.
EDIT to Add: I'm bookmarking your writeup on DNSSEC. Great summary of the issues. :)
- http://blog.easydns.org/2015/08/06/for-dnssec/
- http://www.circleid.com/posts/20150318_is_dnssec_worth_the_e...
Collectively thousands of words have been written on this topic within HN - and there are stark divisions between those who oppose DNSSEC and those who believe DNSSEC is a helpful and useful method of adding a layer of security to the Internet.
We don't agree. We won't agree.
Meanwhile, those of us who want to see DNSSEC more widely deployed applaud this move by CloudFlare because it both makes deployment simpler for many people and also advances the usage of stronger crypto (ECDSA) within DNSSEC.
This is great news!
* The server/nameserver must have DNSSEC configured properly
(CloudFlare have solved this for their customers)
* Your client's DNS resolving server must support DNSSEC properly
(which they might not, depends on the user's network)
* Your client's stub resolver must verify all DNSSEC records
(most do not currently)
The only time that a user will ever know if DNSSEC is working (for them) is if the server/nameserver are configured correctly, your client's dns resolver supports DNSSEC, your client's stub resolver verifies requests, and then the user tries to look up a known-invalid domain and it gives them a resolving error. Otherwise, they will never know if DNSSEC is in use.
Oh, and you can still MITM the data connection between the client and server even if DNSSEC works.
1. CloudFlare already hosts the DNS for millions of domains. This is now making it VERY easy for those who use CloudFlare to sign their domains with DNSSEC.
2. Because of the competition within the DNS hosting / operator space, this move by CloudFlare will hopefully motivate the other large DNS operators to simplify their own user experience for DNSSEC.
3. For those of us who want to see stronger crypto within DNSSEC, this move by CloudFlare advances the use of an elliptic curve algorithm. Yes, ECDSA has its issues, but by getting it out there: a) it gets people looking at EC algorithms; and b) it gets software providers realizing they need to have their user interfaces adaptable to incorporate more DNSSEC algorithms. (I.e. to realize the list is NOT fixed and will grow over time.)
As I said in another comment ( https://news.ycombinator.com/item?id=10553383 ) there is a draft out there to add Ed25519 as a DNSSEC algorithm:
https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01
This draft needs to be approved through the IETF working groups - and then deployed on both the signing and validation sides of DNSSEC. This will take quite some time and so we need to start as soon as we can.
https://www.mail-archive.com/dane-users@sys4.de/msg00142.htm...
Comcast published TLSA records the other day. So when people like myself who have enabled TLSA in Postfix send email to Comcast users, the SMTP connection is guaranteed to be both encrypted, and the SSL cert validated.
Alternative router firmwares such as Tomato Shibby support DNSSEC validation out of the box, thanks to this.
I wish more and more routers (most of them running dnsmasq) would also do this.
dnssec
#dnssec-check-unsigned
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf