
Something about DNS - yxhuvud
http://cdybedahl.github.io/
======
tptacek
This article is well-written, but its consideration of DNSSEC is superficial.

Illustrating example: the article asserts that, unlike X.509, DNSSEC has a
"single root of trust". DNSSEC advocates like to make this point because it
sounds like it makes sense: the DNS tree has a single root, DNSSEC is a PKI
built on the DNS tree, ergo: single root of trust.

But that's not really true. In reality, every .COM name has at least the
equivalent of two CAs: whoever controls .COM, and whoever controls the DNS
root.

What's worse, both .COM and (less importantly) the DNS root are overtly
supervised by the US government. In fact, all of the most popular TLDs, most
especially .IO, are similarly influenced by US intelligence partners.

Further: if you want to analyze X.509 and DNSSEC in terms of "roots of trust",
here's an interesting thing to consider: X.509 has a different kind of "single
root of trust": the browser CA store. When a CA misbehaves, browsers will
blacklist it. When .COM misbehaves, browsers will _not_ be able to blacklist
the TLD operator.

Here's more, of course: [http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
amalcon
VeriSign (.COM) already is a CA, and browsers _cannot_ blacklist them. The CA
is just too popular for that: any browser that did that would be seen as "the
browser that randomly presents scary warnings", no matter how justified.

ICANN isn't, to my knowledge, so I guess the question is whether you consider
ICANN more trustworthy than the least trustworthy of the other 170-odd
organizations your browser trusts.

DNSSEC certainly has other problems, and yes the trust model is bad, but it is
not somehow worse than X.509.

~~~
tptacek
Sure it is: X.509 might be _de facto_ controlled by NSA and GCHQ, but DNSSEC
is _de jure_ controlled by them.

We're in the midst of what will be a decade-long X.509 cleanup effort,
disentangling untrustworthy CAs (all of them) from the outsized role they have
in the Internet trust model. CT logs will play a role. Nuking egregiously bad
CAs will play a role. The adoption of new cheap/free CAs like LetsEncrypt will
play a role. Certificate pinning and HPKP will play a role.

We are _not_ in the midst of _any_ effort at disentangling NSA and GCHQ from
the DNS, nor will we ever be: that entanglement is by design in DNSSEC.

~~~
amalcon
X.509 is _de facto_ controlled by _every major intelligence agency in the
world_ , which is obviously worse than just one.

And the "X.509 cleanup effort" you refer to (really several entirely separate
initiatives) has basically no chance of disentangling CAs from governments.
Certificate pinning is the only piece that can gain traction without explicit
support of governments (except cheap/free CAs, which solve a different
problem). That's great for things you use all the time from a single device,
but otherwise useless.

~~~
tptacek
Why do I care how many intelligence agencies have their hooks into CAs? DNSSEC
is permanently compromised by the two I'm most worried about: NSA and, worse,
GCHQ, the world's most unhinged SIGINT agency.

I gave a whole list of ways in which "the security system formerly known as
X.509" is being repaired. You rebutted basically no part of that list. For
instance: I remain totally unclear on why you think CT logs require government
cooperation.

You've also oversimplified pinning. Pinning isn't simply "trust on first use"
for TLS. It works in conjunction with the CA system. To break a pin, you have
to implicate a CA. That means every time someone tries to deploy a fake CA
certificate, they risk bumping into one of the tens of millions of deployed
browsers that check pins; if they do, the browser vendors get evidence that
the CA is compromised.

~~~
amalcon
OK, then, if you insist on a point-by-point rebuttal:

\- CT logs will play a role.

Requires CA cooperation, and therefore government cooperation because the
largest CAs are owned by governments.

\- Nuking egregiously bad CAs will play a role.

This can only be done for small (i.e. non government owned) CAs, or you create
the perception that your browser does not work.

\- The adoption of new cheap/free CAs like LetsEncrypt will play a role.

This solves a real problem, but a different problem than this.

\- Certificate pinning and HPKP will play a role.

This only helps in two cases: sites I use often and widespread attacks.
Widespread HTTPS MITM is detectable anyway.

~~~
tptacek
Large CAs, including Symantec, are already cooperating with CT. CAs will
enroll in CT because if they don't, they won't be able to sell higher-value
products (like the EV bar) to their users.

The problems with DNSSEC seem so obvious to me, and, obviously, I have
problems taking pro-DNSSEC arguments seriously. I'm curious though; you sound
plenty smart. What is it about DNSSEC that you _actually like_?

~~~
amalcon
Oh, don't get me wrong: I actually like absolutely nothing about DNSSEC.

I just don't think "It has a worse security model than HTTPS" is a true
statement. I think smart people need to keep working on the authentication
problem, because we clearly have not solved it yet -- including with DNSSEC.

~~~
yuhong
Yea, I have been thinking about a DNSSEC2 that would for example uses online
signing for a while now, in addition to things like DNSCurve/DNSCrypt.

------
KaiserPro
One thing I keep on reminding people is that DNS is/was the first scalable,
high distributed, key value store.

Not only that it can be partitioned into subdomains. There is also the concept
of scope, which means you can adjust default records

So for things like service discovery you do things like this:

metrics-server.datacenter1.example.com A 10.10.20.1 metrics-
server.datacenter2.example.com A 10.20.20.1

on each client the search scope will be set by the DHCP server. This means
that if you lookup metric-server in datacenter1 you'll get 10.10.20.1, and in
datacenter2 you'll get 10.20.20.1

however it can be a pain in the arse.

~~~
tptacek
It's easy to scale a KV store with no online updates.

------
axaxs
This is pretty good, but some minor nits -

>A name and all the names below it that are not delegated to someone else is
collectively called a zone

I don't understand this statement. For example, the vast majority of the 'com'
zone are NS records for subdomains, and that is considered part of the com.
zone.

The DNSSEC section is decent. NS rrsets don't get signed, and a distinction in
DNSKEY types should probably be pointed out. Also, the talk of 'shadow nodes'
is confusing and I still don't know what they are referring to.

~~~
js2
_I don 't understand this statement. For example, the vast majority of the
'com' zone are NS records for subdomains, and that is considered part of the
com. zone._

The NS records themselves are within 'com' so they are part of the 'com' zone.
It is the NS record itself that forms the delegation. The article elsewhere
makes a mention of "someone else" but of course you can delegate to yourself.
What makes a delegation is an NS record. What makes a zone is really an SOA
record (and the corresponding sibling authoritative NS records in that zone).

FWIW, RFC 1034 and 1035 are very readable.

[http://tools.ietf.org/html/rfc1034](http://tools.ietf.org/html/rfc1034)

[http://tools.ietf.org/html/rfc1035](http://tools.ietf.org/html/rfc1035)

Aside, I always found it somewhat interesting that the DNS RFCs go into the
implementation details of BIND. It's not really relevant to the operation of a
other DNS implementations what the syntax of a zone file should be. Or how
replication (AXFR) should be handled. The SOA record itself contains
information that only BIND even cares about.

~~~
axaxs
Heh, I'm very familiar with DNS and the RFCs. I was questioning the wording of
the statement. "A name and all the names below it that are not delegated to
someone else is collectively called a zone". The names in the com zone are
delegated to someone else, hence the NS records. Just murky wording to me, but
maybe I'm reading it wrong.

------
eridal
Not sure if you're the author, but thanks for the DNSSEC section!

~~~
dvanduzer
The defenses of DNSSEC are a bit confused.

First, the proper comparison for X.509 trusted sources is between the root
anchor and the _browser vendors_ not the specific trust sources chosen by
Mozilla (or Microsoft or whomever).

Second, we _can_ tell how many entities we have to trust, and the author just
counted them: Mozilla's 177 delegates. Arguably, with DNSSEC, we can't tell
how many entities to trust: how many zones has `com.` signed?

Third, X.509 allows the signing of arbitrary names largely because DNS isn't
trustworthy. (And also because DNS isn't the only naming system people care
about.)

Finally, with only one trusted path, there is only one place you need to
attack to fool _everyone_.

~~~
marcosdumay
I'm becoming a serial defender of DNSSEC here :)

You are inverting your second question. Every zone that we trust 'com.' to
sign can only be singed by Verizon. There's one single point of trust here,
you know what it is, and can choose what point you want when getting a domain.

About that one trusted path, you are also inverting the issue. With X.509
there are 100 places you can attack, any one of them being enough to fool
everybody. With DNSSEC you have one single place (more like 3) you can attack,
and can only fool people about a limited number of sites.

Really, DNSSEC is objectively better than X509, as for every flaw in DNSSEC,
there is one equal or worse equivalent flaw on X509. Except of course for the
issue of publishing all the signed names, that is a different trade-off
between DoS protection and obscurity, so you can have a subjective opinion
about.

~~~
dvanduzer
(I assume you meant to s/Verizon/Verisign/ there.)

Are you saying that if I don't trust [current .com delegate] to manage my
naming authentication, I can choose .ly or .io instead? I was trying to point
out that DNSSEC can't do anything about googIe.com or similar i18n-style
attacks.

I'm glad that TACK exists, and I'm glad people like tptacek are advocating for
it. But DNSSEC and X.509 aren't the only two possibilities for the future of
secure infrastructure.

~~~
marcosdumay
Funny thing that TACK and the Google project for certificate transparency have
exactly the same failure point of DNSSEC, in that both will make all the names
public.

TACK is great. Google's certificate transparency isn't. And, yes, we need more
proposals. The more, the better.

And, by the way, yes, it's Verisign, thanks.

------
arca_vorago
Am I the only one whos sad no one is really picking up dnscurve? DJB has some
very interesting things to say about crypto in dns, and there nothing to stop
you from having dnscurve and dnscrypto working with dnssec for a pretty nice
potential future of dns.

------
rylee
Great article. I'm going to start sending this to my DNS-confused friends now!

------
raymondh
Hmm, the link is no longer valid. Has the site moved?

~~~
fcambus
Indeed, check here :
[http://calle.dybedahl.se/dns.html](http://calle.dybedahl.se/dns.html)

------
js2
BTW, since the article doesn't mention it, the C in CNAME stands for
canonical.

