
DNSSEC is Open for Beta - tilt
https://blog.cloudflare.com/dnssec-is-open-for-beta/
======
gwu78
"... because DNS, invented in 1983 before the public consumption of the
Internet, does not perform any authentication."

Authentication of what?

An end point? No.

A domainname? OK, I'll play along.

And why would "authentication" of a dommainname be necessary?

Maybe because the end user is communicating with a shared DNS cache operated
by a third party instead of using their own?

But I do not use shared DNS caches. I use my own cache.

Moreover I use CurveDNS which provides encryption of DNS packets in transit
and is at least as good at "authenticating" the proper authoritative server
for each domainname as DNSSEC.

How would DNSSEC serve me?

DNSSEC could be a way for certain groups to maintain control over the use of
DNS. Similar to the way SSL CA system has been used to control the use of
encryption. Both the use of domainnames and SSL certificates are each
commercial in nature (pay to play). They do not have to be, but schemes like
CA system and DNSSEC allow for this to occur via centralisation of authority.

~~~
talideon
Authentication of whether the records have been tampered with or not. That
includes the very authoritative nameserver you fetched them from in the first
place, which might have been compromised. This is why DNSSEC allows zones to
be signed offline by the zone's owner rather than trusting the nameserver.

Even if you run your own DNS cache, some bad actor between you and zone owner
(including the aforementioned authoritative DNS server) can still potentially
provide you with bad data. DNSCurve gives you _encrypted traffic_, but DNSSEC
gives you _accurate results_. They solve two different problems.

~~~
gwu78
"They solve two different problems."

Well-known fact. And truthfully the most sensible approach would be to use
both. Yet I never see anyone doing that.

Given the choice between the two problems, I know which one I consider more
serious.

The results might be "accurate" when stored on the nameserver but if they get
tampered with in transit went sent over the wire then they are not "accurate"
when they are received. In that case DNSSEC does not give me accurate results.

Moreover I am not keen on the widepread sniffing of DNS traffic. Name lookups
and other DNS requests and responses are just as important as HTTP traffic.
Why encrypt one and not the other?

Finally, I could be wrong but I think getting redirected to a bogus nameserver
run by a "bad actor" seems (easier for the bad actor and) more likely than
accessing the correct nameserver without the knowledge it has secretly been
compromised.

~~~
talideon
> The results might be "accurate" when stored on the nameserver but if they
> get tampered with in transit went sent over the wire then they are not
> "accurate" when they are received. In that case DNSSEC does not give me
> accurate results.

Here's where you're wrong. A zone isn't just signed in isolation. If it was,
then DNSSEC would indeed be completely useless. Rather, there's a chain of
trust from the root nameservers up to the nameservers for the domain in
question, and in each case you can request a DS (delegation signer) record to
show that a zone served by a subordinate nameserver hasn't been tampered with.

Now, this has its own issues if you're not a fan of the hierarchical nature of
DNS, but it guarantees that even though the data is sent in the clear, some
bad actor can't modify it in transit without breaking everything.

DNSCurve is a nice bonus, but the guarantee that the records being served
cannot have been tampered with given by DNSSEC is much more fundamentally
important.

~~~
gwu78
"Here's where you're wrong."

Are you sure? If the plain text packet used in DNSSEC is tampered with then
how does DNSSEC ensure I get an "accurate result"? Are you saying failure is
an "accurate result"?

How is this superior to encrypting the packet to protect against tampering?

"A zone isn't just signed in isolation."

This is why I do not care for DNSSEC.

Where is control being placed? This smells much like SSL and the CA system.

I obtain zone files from official zone file access programs and run them in my
own authoritative nameservers, locally.

I can also get zone information from the scans offered at scans.io

"... if you're not a fan of the hierarchical nature of DNS..."

After many years of workarounds, I can deal with that. It's the hierarchical
nature of "trust" in DNSSEC (as in SSL) that is a problem.

I guess we just differ in what we see as more important.

I find it rather absurd that you are actually advising someone running their
own cache to use DNSSEC. The entire raison d'etre for trying to bring DNSSEC
back to life again circa 2008 was cache poisoning.

There are commercial interests pushing DNSSEC. Its advocates will make any
argument necessary to try to justify adoption. Alas, end users are not the
intended beneficiaries.

~~~
talideon
> Are you sure?

Yes, very sure. Because I actually had to sit down and read the relevant RFCs
way back because it's part of my job as somebody who works for a domain
registrar. Here's a quick overview for anybody who hasn't had the time to

You can't tamper with a record that's been signed. It won't validate against
the matching RRSIG record, and the only way you can generate those is if you
have the private key. And how do you validate those? Well, that's what the
DNSKEY record is for: it contains the public key, and is used to validate the
signatures in the RRSIG records.

Now, assuming you trust that modern crypto works, all that assures that
records published in the zone cannot possibly be tampered with, but it doesn't
prevent two things: the insertion of additional records and that the DNSKEY
record is legit. For the former problem, NSEC/NSEC3 records exist.

[I'm not going to go into how NSEC/NSEC3 records work, because they're without
a doubt the single most complicated part of DNSSEC. The rest of DNSSEC is
trivial compared them, especially the mechanisms in NSEC3 records that
mitigate against zone enumeration.]

So far so good, but while all that allows you to verify the integrity of the
records you've queried, an intermediary could strip all those additional
records that allow you to check their integrity or spoof them. You need to ask
somebody, and given the inherently hierarchical nature of DNS, that somebody
is the parent zone, which is where DS records come in: they prove that (a) the
zone is meant to be signed and (b) that the DNSKEY record in the zone is
legit. The same process is used right up to the root servers, whose contents
is verified using the trust anchors supplied with your OS.

> If the plain text packet used in DNSSEC is tampered with then how does
> DNSSEC ensure I get an "accurate result"? Are you saying failure is an
> "accurate result"?

Failure tells you that the results you've got back have been tampered with.
And that's a good thing. If somebody's feeding you poison, you need to know
that.

I'll take a denial of service over somebody draining my bank account, and even
then it needn't result in a DOS if you choose to ignore the fact that you've
gotten bogus data.

> Where is control being placed? This smells much like SSL and the CA system.

Your problem isn't with DNSSEC, but with DNS.

> I obtain zone files from official zone file access programs and run them in
> my own authoritative nameservers, locally.

Which registries do you have agreements for zone file access with? And even if
you have access to that information, you still have to get the zonefiles for
the individual domains published in the registry's zone. How do you fetch
those? I'm pretty sure that you don't have access to, say, the zones published
on ns-22.awsdns-28.com, unless you happen to work for Amazon. So you're
trusting somebody to fetch that likely incomplete that data for you from the
_real_ authoritative nameservers.

What you're running isn't an authoritative nameserver, not in the normal
sense. You might be using it in authoritative mode to serve some scraped data
locally, but effectively you have have is a little more than sophisticated
/etc/hosts file and a bunch of blind faith that the sources you got the data
from originally didn't tamper with it.

> I can also get zone information from the scans offered at scans.io

In other words, a third party who happens to have gathered the data, but who
may just have tampered with it, and you have no way of knowing. All you have
is blind trust that they're giving you good data. They could be feeding you
complete junk for all you know. But DNSCurve makes sure that junk is
transmitted super securely.

> After many years of workarounds, I can deal with that. It's the hierarchical
> nature of "trust" in DNSSEC (as in SSL) that is a problem.

It's _DNS_ whose nature is hierarchical. The hierarchical nature of DNSSEC is
a consequence of DNS being hierarchical.

> I guess we just differ in what we see as more important.

Yes, we do. I want to make sure the DNS records being served to me aren't
junk. You want to fetch them using a gold-plated pipe, even if they happen to
be total junk.

As I wrote before, DNSSEC and DNSCurve solve two totally different problems.
In an ideal world, we'd be using _both_.

> I find it rather absurd that you are actually advising someone running their
> own cache to use DNSSEC.

When did I write that? The only thing I've talked about is the importance of
being able to verify the integrity of the data you've fetched.

> There are commercial interests pushing DNSSEC. Its advocates will make any
> argument necessary to try to justify adoption.

For what benefit? What do they get out of it?

DNS hosting providers don't get much out of it except having to serve more
data. Registrar's don't get much out of it except of yet another EPP extension
to implement that no registry implements the same way and yet another
obligation if they're on the 2013 RAA. Registries don't get anything out of it
except having to serve more data. Registries don't charge for DNSSEC, and it's
no more in a registrar's interest to charge to send DNSSEC requests up to the
registry than it is to charge for nameserver or contact updates. DNS hosting
providers could charge, and some do, but given the choice between using using
the likes of OpenDNSSEC and stabbing yourself in the eye with a pencil, the
latter will typically win out. And if you're a masochist like me, you can use
a hidden primary and treat all the visible authoritative nameservers as
secondary nameservers, so if your DNS hosting provider allows zone transfers,
you don't have to pay anything extra because the DNS hosting provider doesn't
have deal with securing the private key and all the implied expense of doing
so.

So, who is actually benefiting here? The manufacturers of hardware security
modules? As far as I can see, they're the only ones who potentially win big
from a financial point of view from DNSSEC.

~~~
gwu78
You should read my initial comment. I wrote that I use my own cache bound to
the loopback, and not shared with anyone.

I asked what benefit I would get from DNSSEC.

Also, registrars, in general, are not known for their trustworthiness. This is
a system for disseminating public data (i.e., it should be very boring), yet
it has been turned into a "business". This is a recipe for deceit and that's
why it is such a headache for ICANN or anyone else trying to police
registrars. Now, please do not misunderstand, I am not suggesting your
employer is not trustworthy.

The sad truth, as revealed in com.zone and other large zone files, is that
most of the domains registrars sell (rent) are garbage and only used for
"domain parking" and serving ads.

Indeed, the people selling DNS hardware, not to mention consulting, are
benefitting financially from pushing DNSSEC.

To me, that "gold-plated pipe" that I have full control over is far more
important than any third party purporting to "sell" me an entry in a public
zone file or to "authenticate" some public data on my behalf.

I can create, retrieve and manage my own data. What I cannot control is the
hostile network over which it is transferred. I like software that is aimed at
that problem.

~~~
talideon
No, no, I read it. The question is, where did you get that data in the first
place, and how can you trust that it hasn't been tampered with between the
authoritative nameservers and your local cache?

That's where the benefit of DNSSEC is: it allows you to detect tampering, and
you don't have to trust any intermediaries to do so.

With DNSSEC, you don't have to trust the registrar, you don't have to trust
the registry, you don't have to trust the recursive caches. In fact, you
barely have to trust the root nameservers. The only individual you have to
trust is the domain's owner. If any party along the way tries to play silly
buggers, then you get a red flag.

> This is a system for disseminating public data (i.e., it should be very
> boring), yet it has been turned into a "business".

It's been turned into a business because somebody needs to run those
nameservers and, like it or not, that costs money.

> The sad truth, as revealed in com.zone and other large zone files, is that
> most of the domains registrars sell (rent) are garbage and only used for
> "domain parking" and serving ads.

If a registrar has parked a domain, it's because the owner has done nothing
with them, or the owner themselves has parked them for revenue.

> Indeed, the people selling DNS hardware, not to mention consulting, are
> benefitting financially from pushing DNSSEC.

Not that much: one of the strengths of DNSSEC is offline signing. The only
_benefit_ is that DNSSEC requires more traffic, but not _dramatically_ much
once a zone is cached.

> To me, that "gold-plated pipe" that I have full control over is far more
> important than any third party purporting to "sell" me an entry in a public
> zone file or to "authenticate" some public data on my behalf.

A gold-plated pipe full of slurry isn't much good. Again, all the encryption
in the world isn't much good if you can't trust the data itself.

~~~
gwu78
You seem to be assuming that registrars are exempted from this imaginary
problem of "tampering".

Why should I trust the registrar's data? (Your data.)

Why should you trust the registry's data?

Why should we trust ftp.internic.net?

But I guess we can't be sure if ICANN's servers have been compromised, right?

The truth is I am not too worried about the zone files I download. Thousands
of people download com.zone every day. Millions download root.zone.

And I do not care to play the "chain of trust" game that DNSSEC requires.

Every DNS admin nowadays disables AXFR.

They have their reasons.

But to me the principle of downloading zones still makes perfect sense.

I would not use axfr when ssh and rsync are available, but the point is the
same.

Why get IP addresses piecemeal when I can get them in bulk?

Far more efficient. Not to mention reducing the number of opportunities for
tampering.

------
davidu
The use-case for DNSSEC is still far from clear to me. DANE is the closest
thing to a valid use case and it looks like Chrome and others are exploring
better solutions than DANE.

Moreover -- The lack of encryption is still a major issue IMHO. Validation is
great, except that when a record fails to validate the end user experience is
essentially NXDOMAIN which is not a very friendly user experience.

At least with SSL certificate failures, the application has visibility into
the cause of the failure. In DNSSEC, it's hard to distinguish between a failed
validation and any other kind of DNS resolution failure.

I just can't see a world where people enable validating resolvers that reject
non-validating responses. And if that's true, then the entire point of DNSSEC
is largely compromised -- with the possible exception of using DNSSEC to
validate in-line verifications (a la DANE).

~~~
zurn
You can do all kinds of nice DANE-like things. For example keys for SSH,
IPSec, OpenVPN, NFS, etc. "We already have something for web browsers" isn't a
big counterargument.

I agree they should add confidentiality. That shouldn't be too hard since all
the key handling is already taken care of.

------
FullyFunctional
DDoSers [1] around the world rejoice.

[1]
[http://cr.yp.to/talks/2009.08.10/slides.pdf](http://cr.yp.to/talks/2009.08.10/slides.pdf)
[http://cr.yp.to/djbdns/forgery.html](http://cr.yp.to/djbdns/forgery.html)
[http://cr.yp.to/talks/2009.03.21/slides.pdf](http://cr.yp.to/talks/2009.03.21/slides.pdf)
etc etc but also [http://ianix.com/pub/dnssec-
outages.html](http://ianix.com/pub/dnssec-outages.html)

------
mtgx
Why are people pushing DNSSEC adoption when it uses such obsolete crypto? What
happens when 80% of the web adopts it, and then we find out 5 years later that
all of DNSSEC keys can be cracked?

Upgrade the protocol first, then come back telling us how great DNSSEC is.

~~~
FiloSottile
CloudFlare DNSSEC uses ECDSA on P256 and SHA256 exclusively. That's what
modern TLS uses.

[https://blog.cloudflare.com/dnssec-done-
right/](https://blog.cloudflare.com/dnssec-done-right/)

~~~
sarciszewski
Haha Filo did you really call ECDSA modern?

~~~
FiloSottile
Yeah. That's the best thing you can get for TLS certificates now, and most
likely for the next five years. So that's what modern TLS uses, yeah.

I hate it as much as the next cryptographer, and I actually gave talks begging
people to at least do deterministic ECDSA. But there's no EdDSA on the
horizon.

Also, I think Thomas in the sister comment was referring to handshakes, but I
was talking about X509.

~~~
sarciszewski
Fair enough. I'm still hoping we'll see EdDSA (22519 and 448) sooner rather
than later. :)

------
parent5446
Unfortunately, still waiting on AWS Route 53. If only DNSSEC was a worthwhile
enough feature to migrate DNS services.

~~~
stevekemp
Route53 is awesome, but yes it is missing at least two things a lot of people
crave:

* IPv6 nameservers. * DNSSec support.

~~~
antod
AXFR and/or IXFR? RFC 2136 / TSIG compatible updates?

Those would be my personal wish list items ie better
interoperability/compatibility with published standards.

Those things may have been added recently though (I haven't checked in a
while), but I doubt it.

~~~
stevekemp
AXFR is one of those things that is perhaps less valuable - after all _you_
put the data there, via their API, so you have it to-hand.

On that basis you don't need to do a zone-transfer to get the data out, just
use your existing source of truth.

(In my case I upload to Route53 via a git repository and push, and regard that
repository as the source of truth - [https://dns-api.com/](https://dns-
api.com/) )

------
hsivonen
What's the use case? Thanks to TLS, you don't need DNSSEC for the Web. For
email, if your DNSSEC-enabled domain delegates to a provider that isn't
DNSSEC-enabled, you haven't accomplished anything of true value.

~~~
captn3m0
I was gonna reply how we need to prevent DNS queries from being eavesdropped.
But it seems, DNSSEC does not support traffic encryption:

>DNSSEC does not provide confidentiality of data; in particular, all DNSSEC
responses are authenticated but not encrypted. (From the wiki)

However, DNS poisoning attacks are still relevant because not all of the web
is on HTTPS.

~~~
hsivonen
Addressing non-HTTPS Web issues with migration to DNSSEC instead of migration
to HTTPS is totally bogus. It's especially bogus as a use case in the
Cloudflare case, since Cloudflare had HTTPS first.

------
Zash
But will they control the keys? It would be pretty neat if they did not have
to. Like their TLS thing where you still control the private key, but call out
to you to use it.

~~~
throwaway2048
This is actually a lot more managable with DNSSEC because it is designed
around the idea of offline signing of records.

------
steckerbrett
Cloudflare-ternet.

