
Cloudflare Introduces Universal DNSSEC: Secure DNS for Your Domain - darronz
https://www.cloudflare.com/dnssec/
======
EwanToo
Dupe of
[https://news.ycombinator.com/item?id=10539245](https://news.ycombinator.com/item?id=10539245)
?

~~~
jgrahamc
This is a post of the DNSSEC microsite containing a bunch of information (not
sure who the poster is, it's not someone from CloudFlare) whereas that's a
link the announcement blog.

------
tptacek
I think it's important that those of you who haven't read up on DNSSEC
understand how bad an idea it is:

[https://news.ycombinator.com/item?id=10539418](https://news.ycombinator.com/item?id=10539418)

If DNSSEC had been deployed a few years back, Muammar Gadaffi could
conceivably controlled BIT.LY's TLS keys. Yesterday, today, and tomorrow,
DNSSEC gives the NSA immense control over the TLS keys of sites in .COM, .ORG,
.NET, .CO.UK, .IO, .COM.AU, and many more.

~~~
caskance
That's what it means to have a domain in Libya - you're subject to the
jurisdiction of the officially recognized Libyan government. If you don't want
to have to deal with the whims of a crazy dictator, don't register your
business in his country.

~~~
tptacek
"DNSSEC: everything will be fine as long as everyone moves to domains in
Bouvet Island's .BV. Brought to you by Cloudflare."

~~~
rch
> The centre of the island is an ice-filled crater of an inactive volcano.

Sounds like a combination of the Fortress of Solitude and SPECTRE's volcano
base.

------
gwu78
This is the fourth time in the last 30 days I have seen some blog post about
DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one
about email and DNSSEC written by a Cloudflare employee.

But still no discussion of cache poisoning.

So if a user runs their own personal cache bound to the loopback do they need
DNSSEC?

What if they run their own root?

What if they have local copies of all the zones they need?

DNSSEC gives control to untrusted third parties to periodically determine what
is and what is not a "valid" domain name.

What are the protections against abuse of this control?

I would not call DNSSEC "secure DNS". I would call it "validated DNS".

The question is who is doing the "validation"?

And why should we as users trust them more than the endpoint we're trying to
reach?

~~~
fensipens
> This is the fourth time in the last 30 days I have seen some blog post about
> DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one
> about email and DNSSEC written by a Cloudflare employee.

Absolutely, this is getting out of hand.

Would be easier to just buy HN and replace all top stories with your crappy
DNSSEC ads..

------
danyork
It's great to see this microsite (and the announcement yesterday) as this
rollout by CloudFlare will do two major things to help move DNSSEC forward:

1\. _Simplify_ the process of setting up DNSSEC-signing for so many people;
and

2\. Advance the usage of stronger crypto through the used of ECDSA (DNSSEC
algorithm 13).

The first point will help with getting many more domains signed. The second
point will help those of us who want to see even stronger crypto used within
DNSSEC.

On that last note, I'd also note that there is an Internet Draft submitted
about adding Ed25519 as a new DNSSEC crypto algorithm. You can find it here:

[https://tools.ietf.org/html/draft-sury-dnskey-
ed25519-01](https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01)

Support for this draft within the IETF working groups - and indeed in
implementations - will help make this a reality.

~~~
tptacek
1\. The roots and TLDs remain RSA-keyed.

2\. As recently as months ago, those keys were 1024-bit RSA.

3\. If the zones above those Cloudflare manages are RSA, it doesn't matter if
Cloudflare's own zones are ECDSA.

4\. ECDSA is itself outmoded and dangerous.[1]. Cloudflare has the first
significant deployment of curve-based DNS on the Internet, and because of
standards group torpor, they're forced to use _bad_ NIST-curve DSA, while the
rest of the world has moved on to better curves and deterministic signatures.

5\. It takes just a few hours to write a new draft for ED25519. Pretty much
the entire browser vendor community agrees that TLS needs a standardized
Curve25519; a draft for that was submitted over a year ago, and _still hasn 't
made it out of committee_ because of bikeshedding. Worse: browsers can enable
Curve25519 piecemeal, because TLS is a negotiation protocol. DNS isn't.
Because DNSSEC advocates have pushed deployment of broken '90s crypto, it
could take close to a decade to get Ed25519 deployable in DNSSEC.

The idea that better DNSSEC crypto is just a standards document away is a
pretty good illustration of what has gone wrong with 21+ years of attempted
DNSSEC standardization.

There's a better alternative than DNSSEC, and it isn't DNSCurve: it is
literally "do nothing". Don't break the Internet. Don't create a massive new
deployment of embarrassing old curve crypto. Don't effectively sign keys over
to the NSA. Billions of dollars of commerce flow over the Internet every week
and none of it, not one bit, is protected by DNS security. DNSSEC isn't
useful, it isn't needed, it certainly isn't a priority. It's in this case a
way for Cloudflare to make some extra money, and nothing more.

[1]:
[http://blog.cr.yp.to/20140323-ecdsa.html](http://blog.cr.yp.to/20140323-ecdsa.html)

~~~
danyork
tptacek - the root keys _will_ remain RSA-keyed for some time. The root Key
Signing Key (KSK) is 2048-bit RSA. The root Zone Signing Keys (ZSKs) that are
CHANGED every 3 months (a ZSK key ceremony is in fact happening _TODAY_ ) are
1024-bit RSA.

There was strong interest in changing the algorithm when the KSK is rolled
(when that occurs is still to be decided), but for the moment an algorithm
change will not be part of that.

I don't deny that deployment of ED25519 will take some time. Once approved it
has to be integrated into the signing software. It's also got to be integrated
into the validation side. It's going to take time. So lets get started!

~~~
tptacek
How about, instead of getting started, we accept that DNSSEC is a failed
21-year-long experiment, and figure out a better way to get the moral
equivalent of HSTS and HPKP for email links?

~~~
galois198
In the event that DNSSEC is adopted, what would the best course of action be
to protect sites?

~~~
tptacek
The concern I have with DNSSEC is that if it's adopted --- where "adopted"
means "by the major email providers and by browsers" \--- there's _not_ much
you can do to protect yourself from the SIGINT agencies that control the top
of the DNS tree.

If there was a significant benefit to users for DNSSEC adoption, I'd be my
normal tedious "maybe it's good, maybe it's bad" self. But the benefits aren't
there. Instead, DNSSEC will impose immense operational costs and in some ways
_reduce_ security:

[https://news.ycombinator.com/item?id=10541719](https://news.ycombinator.com/item?id=10541719)

This isn't a hard decision and I don't have a hard time siding with the anti-
surveillance crowd on it.

------
sintaxi
Does this seem ironic to anyone else considering CloudFlares SSL offering
essentially is a MITM attack?

~~~
jerf
The essense of "MITM" isn't the Middle but the fact that the Man is
_unauthorized_ , Eve to Alice and Bob. If Alice and Bob _agree_ to put
CloudFlare (oh, look, the C already works!) in between them, there's a Middle
but there's no [unauthorized] Man.

SSL's purpose isn't to create some sort of quasi-mythical "direct connection"
between Alice and Bob, it's just removing the general Internet as a vector for
many attacks. An utterly critical building block of the global Internet, but
nothing more; certainly not a magic invocation that casts the spell of
Security +1 across the entire communication, neither in fact nor in intent.

It's worth taking a moment to try to explore what the idea of "direct
connection" is that you have in your head, in a world where Bob is probably
already a program generating HTTP with no human interaction in an arbitrarily-
complicated manner, with arbitrarily-complicated combinations of SSL
accelerators, WAFs, and whoknows what other network appliances, even _before_
we consider what it means to assemble a page from JS and images from 10
different domains representing other entities, and where Alice is using a
browser and arbitrary plugins, each of which she is implicitly trusting, and
possibly a proxy. If you examine this closely it becomes surprisingly
complicated.

~~~
Mtinie
"...certainly not a magic invocation that casts the spell of Security +1
across the entire communication..."

I appreciate the whole post, but this is such a wonderfully geeky turn of
phrase that I have to acknowledge it!

------
mtgx
Why not DNSCurve? [http://dnscurve.org](http://dnscurve.org)

I mean, I feel like adoption is so low for DNSSEC already - does it even
matter if it's 0% for DNSCurve or 1% adoption for DNSSEC? Why even bother with
a 20 year old protocol?

~~~
drdaeman
DNSSEC and DNSCurve are completely different matters.

As far as I understand (I may be wrong!):

1\. DNSCurve establishes an encrypted and, optionally, authenticated channel
between you and upstream nameserver. It doesn't do anything about the data
that is served over that channel.

2\. DNSSEC protects the integrity of the data that is served by authoritative
nameserver (and redistributed further) from some rogue adversaries (except for
registries).

About DNSCurve - you should ask your upstream nameserver provider (usually, an
ISP) to support it. Although everyone running a nameserver should do so. But
it's purpose is completely different from DNSSEC is about - even though the
latter's concept is flawed.

------
peterwwillis
Let's not lose sight of the fact that DNSSEC purports to make client
connections more secure.

Does it?

\- If the server in question doesn't have DNSSEC set up: No.

\- If there is a problem with one of the pieces of DNS infrastructure between
the server and client: No.

\- If the DNS resolver server the client is using doesn't support DNSSEC: No.

\- If the client's stub resolver isn't a validating one: No.

\- The user is never notified if DNSSEC is working for them or not. They can
only determine this by making queries with a command-line tool, or when they
get a 'could not resolve domain' error on an invalidly-configured domain.

\---

Compare this to HTTPS, where the only thing the client needs to verify a
secure connection is:

\- The server delivering its certificate and certificate chain to the client

\- The client validates the certificates

\- If it isn't validated the user knows immediately.

You can go ahead and implement DNSSEC for your server, but when it comes to
HTTPS connections, this does not improve user security over what we have now.

------
arca_vorago
DNSCurve and DNSCrypt are the better solutions for slightly different problems
that I think we should be pushing.

~~~
jgrahamc
Come work at CloudFlare! Let's get working on that.

~~~
jedisct1
Are you serious about that?

~~~
jgrahamc
We're interested in making the Internet more secure. Go look at our history.
Why would we _not_ be thinking about ways to secure DNS etc. further?

~~~
deftnerd
Well said!

I know one thing I would like is Cloudflare doing something magical with Sub
Resource Integrity.

Maybe if the source HTML specifies a SRI string, check that the hash in the
HTML matches the hash of the resource before allowing it in your cache for
that website. If it doesn't match, don't cache that resource and don't serve
it.

This would allow sites to enable and enforce SRI without browser support.

------
collinmanderson
Wow. Cloudflare is the perfect company to push DNSSEC forward. DNSSEC seems
incredibly complicated and prone to amplification attacks, and I trust
Cloudflare to get it right. :)

