In Defense of DNSSEC | Hacker News Reader

In Defense of DNSSEC

shorttext.com

15 pointsjocluteseh64 comments

I read this thing so you don't have to. Here's a summary of what I believe this person's arguments to be. If I've failed to be charitable enough, please do call me out for that.

1. With DNSSEC, SPF, DKIM, and DMARC enabled, email is secure enough to authenticate requests for TLS certificates. Without DNSSEC, it isn't.

2. DNSSEC zone owners control their keys, so DNSSEC doesn't imply that the DNS roots control keys.

3. There is nothing wrong with older cryptosystems and anyways, DNSSEC supports elliptic curve now.

4. The code to make DNSSEC deployable is underway and so it's not valid to suggest that it's too expensive to support.

5. All that's required of DNSSEC deployers is to generate a couple of DNS records, and so it can't be expensive to to deploy.

6. It's specious to criticize DNSSEC for only securing server-server transactions and not browser-server DNS lookups.

7. Nobody ever said DNSSEC would provide end-to-end encryption. DNSSEC reveals hostnames now, but there's something called NSEC5 that's going to make that better.

8. Nobody ever said DNSSEC was going to provide end-to-end security so it's not valid to criticize DNSSEC for not doing that.

9. DNSSEC isn't a replacement for the CA system, but rather a security improvement for DNS, so comparisons to TLS and CA aren't valid.

Well, allow me to retort:

1. SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. Making it secure is the biggest problem in Internet cryptography and we aren't anywhere near solving it. If domain-validated certificates scare you, the solution is to eliminate DV certs.

2. The roots control delegations. The keys you store in your zone don't matter if surveillance targets never see them, because the government-controlled roots switch delegations to zones they control. DNSSEC is a PKI controlled by NSA and GCHQ. That is literally what it is is.

3. DNSSEC is 90s cryptography. 90s cryptography has been discredited. The DNSSEC roots use an archaic flavor of RSA. ECC DNSSEC records break zillions of deployed implementations. The flavor of ECC that DNSSEC supports is also archaic. This stuff is in the FAQ for the post they're rebutting.

4. The phrase "good money after bad" comes to mind.

5. Here is a list of major DNSSEC outages. DNSSEC reliability is komedy gold:

http://ianix.com/pub/dnssec-outages.html

6. No it's not.

7. 7 years ago, this argument would have been written "DNSSEC reveals hostnames now, but there's something called NSEC3 that's going to make that better".

8. There is a finite amount of money and energy to be spent on cryptographically improving core Internet infrastructure, and the many deficiencies of DNSSEC are why virtually nobody credible in the cryptographic engineering community thinks DNSSEC is a good use of that money. We can't spend tens of millions of dollars forklifting in a baroque new cryptosystem that doesn't actually encrypt anything.

9. The sole important application for DNSSEC is storage of TLS certificates.

1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree?

2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control.

3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense.

4. Only if you don't value the hard work by many smart people over a long time.

5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4.

6. Yes it is.

7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self?

8. Again with the 'old' is bad 'new' is better? Got anything else?

9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

However, for a small domain, DNSSEC is terrific.

1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys.

2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC.

3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on.

4. That's not an argument.

5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated.

6. That's not an argument either.

7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant.

8. Non sequitur.

9. I'm not smart enough to understand what this argument means.

> 9. I'm not smart enough to understand what this argument means.

Thomas, I _think_ you are replying to this:

> 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings.

There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys.

People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.

Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?

To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either:

1. Pull the public key from DNS to add to ~/.ssh/authorized_keys

2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys

Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea.

Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.

The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case:

http://tools.ietf.org/html/rfc4255

When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.)

The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key.

Do note this is not a new idea. This RFC was published back in 2006.

The NSA can take any one of their trusted root keys, which I don't think it would be healthy to doubt they are in possession of, and sign a certificate today.

With DNSSEC, they'd have to subvert the entire DNS infrastructure, signed from the top all the way down to the particular domain they want to falsify. But it is somehow this infrastructure you wish to label "NSA controlled"?

What difference does it make whether the program they run to carry out this attack is 100 lines long or 400 lines long? DNSSEC gives NSA and GCHQ this level of control by design. It is a PKI, based on delegations from a root, where the top of the tree is literally controlled by the US and UK governments.

The difference is not in the complexity of the code, but the magnitude of the attack. You would need to subvert every DNS request from a certain client, for the duration of the TTL of all signature points. (Exactly how much harder it is depends on the circumstances, but a travelling target would be even harder than a well known stationary one, even if you control large parts of Internet infrastructure and is willing to use it.)

But that's not the point. The only point is that between it and the SSL CA infrastructure, the latter is the one NSA has more control over and a much easier time generating certificates for, so the labelling the former "NSA controlled" is slightly disingenious.

You don't like the CA system. I don't either. I go farther, and say "it's a very bad idea to replace the CA system with another hierarchical PKI the top of which is controlled be NSA and GCHQ". I'm not sure I understand your rebuttal to that point.

Because it is not "controlled" by the NSA in any meaningful way (with emphasis on meaningful).

Any such argument would be valid for pretty any global PKI system, if the argument is that they control important parts of the Internet infrastructure. The SSL CA system is even more controlled by the NSA as DNSSEC is.

DNSSEC is much harder to circumvent than the SSL CA system, no matter how you look at it.

So I do not mean to refute that the NSA controls the Internet, the CA system, and DNSSEC (even if I don't believe that's an accurate description). It is simply not a meaningful discussion to have. Even if the NSA can break the Internet, there are other use cases and it still carries great value for everyone.

It's not controlled by NSA? The largest nodes in the tree are literally controlled by them. The corporations that control the root are domiciled in the US. Google's remedy for misuse of any of those zones is to stop being GOOGLE.COM. This is a silly discussion.

> It's not controlled by NSA? The largest nodes in the tree are literally controlled by them.

Perhaps I should thank you, Thomas, for continuing to beat this drum... because it shows extremely clearly how we need to educate more people and be MUCH more clear about exactly how the keys at the root of DNSSEC are maintained. If people fully understand the process, and how it was designed to NOT allow attackers in this way, we could spend our time on much more productive discussions. (Granted, documents such as https://www.iana.org/dnssec/icann-dps.txt do NOT make for friendly reading.)

Thank you for pointing out the work that needs to be done.

The idea that process and policy addresses this problem is wishful! By design and by law, the most popular and important TLDs are controlled by governments, and, particularly, the US and UK governments. The most popular generic TLD after COM/NET/ORG is IO, which is controlled by the world's most unhinged signals intelligence agency.

You are advocating for a PKI that is literally shrink-wrapped around government-controlled namespaces. For a security protocol on the global Internet, that's an utterly unforced error. It boggles my mind that anyone had ever considered it, and I am thankful that it is a dead letter now.

But if NSA controls DNS, by extension they control the TLS CA tree as well. Because domain validated certificates is what everyone relies on for security.

Again, that's the point. You keep pointing out that DNSSEC is somehow government controlled, when what you really mean is the entirety of DNS and CAs put together are, and not specifically just DNSSEC. That doesn't make for a constructive discussion since there is no context of an alternative system. Status quo still leaves us with easily falsified domain validated certificates.

I can agree for the sake of discussion that the DNS and CA system is under government control. So against an intelligence organization with unlimited resources anything built on DNS or certificates would fall, so DNSSEC wouldn't help you there. But against every other attacker in the world it absolutely would (while making the attacks it can't defend against easier to detect).

tptacek:

> Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?

Please remind me again how the NSA/GCHQ can subvert my domain at example.com without anyone else in the chain noticing that?

What makes you think anyone is going to notice? DNS is a distributed system. The NSA is a byzantine attacker. There is no instantaneous convergence on a single answer; CAP applies; a byzantine DNS attacker can deliberately introduce inconsistent answers. Virtually none of the DNS resolvers in the world also function as inconsistent-answer detectors.

There's this weird presumption among DNSSEC advocates that DNS is somehow resilient against targeted attacks (you see it every time an argument lands on "but people will notice that"). No. Not only is that not true, but it's even less true than other protocols where we know that to be true; for instance, BGP4 is also not resilient against byzantine failures, but at least BGP4 updates propagate (BGP4 is like a "PUSH" system in that regard, where DNS is "PULL").

What's even funnier about this "people will notice" objection is that people routinely notice corruption at certificate authorities... and nothing happens to those CAs. Compared to the DNS roots, CAs are trivial to blacklist.

Nobody is going to notice targeted attacks on DNS, but even if they did, nothing will happen; there is no disincentive to those attacks for the attackers.

Thomas,

I perform DNSSEC validation on the edge of my home office network. All my devices use my DNSSEC-validating DNS resolver on my network server-gateway.

That resolver is going to check the DNSSEC chain of trust using DS records all the way up to the root of DNS.

If I get back a signed record for www.example.com (meaning an RRSIG), my DNS resolver is going to validate the signatures back up to the root of DNS.

If the signatures don't validate, it's going to give me a SERVFAIL and prevent me from going to whatever site I'm trying to get to.

If the NSA/GCHQ/whomever wanted to redirect me to another site under their control, they could try to send me the record with a valid RRSIG from their own DNSKEY. My resolver is now going to go to .COM (for example.com) and pull the DS record for "example.com". If the DNSKEY and DS don't match, I'm going to get a SERVFAIL and won't get to the site.

Now, the attacker could try to send me their own DS record for the .COM domain... but that's going to be signed by the .COM's DNSKEY ... which again I suppose the attacker could try to send me a substitute.

But now my resolver is going to pull a DS record from the root of DNS for the .COM TLD. That DS record will be signed with the DNSKEY of the root. My resolver is going to validate that signed DS record and compare it with the DNSKEY for .COM. If they don't match, I'm going to get a SERVFAIL.

Now I guess in theory the attacker could try to send me a DS record for the .COM TLD that is signed by their own key... but here's the thing - my local resolver is already pre-loaded with the public key of the root zone as the trust anchor. So it's not going to trust anyone else's records that purport to be the root zone if the signatures don't match the local trust anchor.

So how does the NSA/GCHQ/etc. carry out this attack to redirect me to another site?

I don't understand the point you're trying to make. In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.

The NSA attack assumes an NSA level attacker has access to the root zone's (or someone else in the chain's) private key.

The NSA can then send a key for the .COM TLD that's valid, according to your pre-loaded local resolver, and they can also send a seemingly valid record for example.com.

The CA mechanism used for TLS has the same issue. It's not just theoretical either, Gmail and other Google domains had fake certificates that passed validation issued by CNNIC, China's Internet authority, which was discovered earlier this year.

But here's the thing - the root zone's private key for DNSSEC is not in one place. It is spread across a number of smart cards carried by a variety of individuals spread around the world - specifically so that it could not be compromised by governments or others.

You can see for yourself exactly what kind of process takes place to use the root key to generate new Zone Signing Keys (ZSKs) every 3 months at the IANA key ceremonies: https://www.iana.org/dnssec/ceremonies

It would be an extremely difficult process for an intelligence agency to subvert, even one with essentially limitless resources.

But domains under .COM are exactly as trustworthy as Verisign, right? The root key signing ceremonies are just theater, right?

> The CA mechanism used for TLS has the same issue. It's not just theoretical either...

Exactly. Which is why so many of us are looking for ways to add an additional layer of trust to the CA system used for TLS.

One such mechanism is to use DANE and DNSSEC as an additional mechanism for trust.

tptacek:

> I don't understand the point you're trying to make.

I am trying to understand how the attack you say is possible truly is possible.

> In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.

Verisign operates the .COM TLD registry and has documented in excruciating detail how they handle the security of DNSSEC key material: https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf

Is your assertion that the NSA would order Verisign to bypass those controls and make a change to a DS record (and associated NS records) to redirect people to another site?

If so, how would they do that for just me? It would have to be a much larger redirection of people.

First, Verisign operates the .COM TLD at the pleasure of the US government.

Second, if "just trust Verisign" is enough, we're done: just have the browsers only allow Verisign as the TLS CA for .COM names.

to tptacek's point - an attacker doesn't need to change the root zone. All they need is the root key. (This argument could be equally made of the CA system.)

Then they can sign anything they like, anytime they like, and only for some small targeted set of the population - and for DNSSEC, that's ONLY if you're checking it anyway. (and if you don't control your recursive resolver or patch your browser, tough cookies). @danyork your edge checking is great.. so I presume you never bring your laptop to a coffee shop. ;)

Let's not be naive.. as far as root keys go, Verisign is a big company and will promptly hand over any and all keys upon receipt of an NSL or court order and probably just an administrative subpoena. That's how you win and keep massive, government-mandated monopolies to run the world.

(To be fair, it's not Verisign's fault that the entire CA system is broken. Oh, wait, actually.. it's exactly Verisign's fault. https://en.wikipedia.org/wiki/Verisign#History )

Let's be clear, though, the root of DNSSEC is NOT handled like the root of any CA system. The process of obtaining the root private key is not something where you just break into some system and grab a file somewhere.

The root zone's private key is actually distribute across a set of smart cards possessed by Trusted Community Representatives (TCRs - people like you and me within the Internet technical community) - some number of whom get together periodically in "key ceremonies" to perform actions that require the root KSK, such as the generation of new Zone Signing Keys (ZSKs) every 3 months in what are called "key ceremonies" - https://www.iana.org/dnssec/ceremonies

The entire process of protecting the root zone's key material are documented at length in what is called a DNSSEC Practice Statement: https://www.iana.org/dnssec/icann-dps.txt

Again, the DNSSEC root zone management is EXTREMELY different from that of the CA system. It was designed to be much more secure and to not allow the kind of penetration we're seeing with the CA system.

I think what tptacek is hinting at is that a nation state could forge roots with their own certificates, creating a separate chain of trust. Given that your internet enabled device does not likely have an DNSSEC validating resolver (with uncompromising trust anchors for the roots) operating on it it's still possible for your device to receive forged responses.

If your Internet-enabled device doesn't have a DNSSEC-validating resolver (with solid trust anchors for the root zone), then this entire conversation is irrelevant.

If your Internet-enable device does have a DNSSEC-validating resolver either on the device or within an acceptable zone or risk[1] then the chain of trust back up to the root zone of DNS will mean that I will notice a substitution and get a SERVFAIL. It may mean that the attacker could DoS me and prevent me from going to a site, but I don't see where I would wind up on the bogus site.

[1] For example, I have a DNSSEC-validating resolver on the edge of my home network. Yes, an attacker could still compromise my home network and send me forged responses. I consider that less likely and am willing to take that risk.

He knows that; he's saying, if GCHQ did that to tamper with a key stored for a .IO name, the world would notice, because they'd all get that poisoned key.

But that's not actually how DNS works.

1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid.

SPF validates that the email account holder is valid.

DKIM signs the message and provides a body hash which is validated against the public key in DNS.

DMARC allows the domain owner to say that the message should trashed or passed.

And DNSSEC allows the DNS root to say that the sending domain is the sending domain.

So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure.

And, yet, you are unwilling to admit this...

I suggest you read the DKIM RFCs, particularly RFC5585

"2.3. Establishing Message Validity

Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."

While I don't purport myself to be a crypto expert, you can't cite an RFC of a protocol as "proof" that something is secure. For example, if people come up with attacks against DKIM after the RFC is created, they don't issue an errata on the RFC listing all possible attacks.

> DKIM signs the message and provides a body hash which is validated against the public key in DNS

And how do you make sure the public key is correct then ? Well, just use DNSSEC !

Well, about #2, people are defending the status quo (where any governemnt anywhere on the world can compromisse a site's key) by arguing that with DNSSEC there'll always be one government able to compromisse any site's key. Calling that a falacious argument is too charitable, it's an outright lie (and I wonder why that piece of propaganda is so pervasive).

About #3 the article simply points that there's nothing wrong with DNSSEC, unless you choose to use bad crypto algorithms. Guess what, any cryptosystem works the same way, TLS included.

About #6, yes, it's specious to criticize DNSSEC because browsers choosed to not support it (unless you are talking from the point of view of a site master wondering how you'll configure your host today - but even then, that's not a valid criticism of the algorithm, it's just reason to not deploy it now).

About #8, yes, that's not valid. DANE is the main end-to-end encryption algorithm that used DNSSEC, so one must either criticize DANE (if able) or shut-up.

Anyway, what a badly formated page. Points #1, 4, 5 and 7 are flaws. Point #7 is a big flaw, and don't hold your breath waiting for it to be solved. I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I can't see where the author is going...

> I'd say about point #9 is that DNSSEC is exactly a less broken CA system.

I'd say DNSSEC is more broken than the current CA system. At least with the current system you can more or less choose a CA to trust (or, more interestingly, a bunch of CAs), that you can change anytime you want. The only thing preventing you to do it is the lack of tools to actually do it, which is why tools such as TACK/HPKP, or Convergence/Perspectives, are needed.

With DNSSEC, there is only one realistic root ever possible (call it ICANN or NSA as you want, that's yet another problem)

> At least with the current system you can more or less choose a CA to trust

Blind illusion. You must trust all of them. Any of them can attest somebody is you any time they want.

The good thing about DNSSEC is exactly that it only has one root. And people can pin second and third level domains, completely escaping it - for some other org, controlled by some other agency, but one can choose what agency to submit their identity.

Fixed formatting a little here: http://shortText.com/6308c7af

Page seems down; cached version: http://webcache.googleusercontent.com/search?q=cache:_q7stvY...

jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure.

jocluteseh: DKIM signs the message and provides a body hash which is validated against the public key in DNS.

tptacek: SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure.

in short: DNSSEC and SMTP hang together by threads. cut one thread and the whole thing collapses. "It's better than what we have right now" isn't an argument because we actually don't have it anyway. tptacek is 100% correct.

> jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure.

Please explain how. The whole point of DNSSEC is to provide a cryptographic validation that the material put into DNS by the operator of a zone is the same information you get out of DNS when you perform DNSSEC validation.

I'm quite tired of seeing the assertion that "DNSSEC can be re-directed" without people actually walking through HOW that redirection can occur. (Thank you in advance for doing so.)

'quite tired' eh :) jocluteseh is the OP arguing for DNSSEC. That's his quote.

tptacek already explained this in some detail in the original article that this article is a rebuttal to.

DNSSEC doesn't secure browser lookups: http://marc.info/?l=namedroppers&m=99635022704707&w=2

DNSSEC only guards against the relatively small problem of cache poisoning for individual records, but it can't even do that properly. It all falls apart w/ MITM and the browser wouldn't even be able to detect MITM since it's relying on a flawed source of truth.

http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Sect...

See tptacek's original post for more info. http://sockpuppet.org/blog/2015/01/15/against-dnssec/

I'll try to post a comment, but my IP address may be rate limited -- I keep getting "You are posting too fast" errors.

In any case, you've made my case for me much better than I could have made it myself. The problem with the 'redirect DNS' argument is that -- it seems -- most people misunderstand that in order to redirect a DNSSEC signed domain, you need to control the 'root' key AND re-sign every domain under that key.

So, can it be done? Yes.

Is it likely to happen? No.

I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.

> I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.

Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?

If the MITM is unable to forge a signature that passes validation, and the browser/whatever complains that the signature is invalid, then the game is not over.

No signature needed. Just hand out whatever you like for the entire zone.

    There are several exceptions to the above example.

    First, if "example.com" does not support DNSSEC, there will be no RRSIG record
    in the answer and there will not be a DS record for "example.com" in the "com"
    zone. If there is a DS record for "example.com", but no RRSIG record in the
    reply, something is wrong and maybe a man in the middle attack is going on,
    stripping the DNSSEC information and modifying the A records. Or, it could be a
    broken security-oblivious name server along the way that stripped the DO flag
    bit from the query or the RRSIG record from the answer. Or, it could be a
    configuration error.

http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...

    If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records.

That's the second sentence in your quote which seems to say you can't hand out whatever you like for the entire zone, given that .com and .net and .edu have all been signed since 2011.

Right.. check the rest of the thread above (what good is a signature that no one checks ;) )

I agree that signatures are of no value unless validation is done... but please do note that current measurements are showing about 13% of all DNS queries globally are in fact being validated:

http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g...

If you scroll down that page you'll see higher statistics, such as 70% of all queries being DNSSEC-validated in Sweden, because almost all the ISPs there are now validating.

In the USA, about 23% of all DNS queries are being DNSSEC-validated:

http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1

So the argument that "no one is checking" is no longer true.

That's excellent data - didn't realize those stats. Thanks for providing them.

> Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?

Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance.

You are much more likely to die by getting run over by an airplane while walking down the road while also holding a Dalmatian over your head, than to have your DNSSEC signed domain redirected.

The edge case that's being argued about NSA taking over DNSSEC is rather over done.

However, if the argument is denial of requests, so as to block traffic, DNSSEC or not matters not - so the argument again -- is not about DNSSEC as a specific service or architecture.

You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption. :)

Without those, everything collapses, and even if they're there, you still might be in very real trouble and not even know it.

Scenario 1: best of all worlds: you're running an awesome mythical OS (edit: or browser plugin as jocluteseh mentioned below) with up to date root keys and you're trying to get to a single zone and you know the root zone key... but the DNSSEC root key was compromised. No one knew this, because there's no way to detect. Your MITM attacker just forges everything. But you feel secure, since you have DNSSEC. ;)

Scenario 2: you're running some really new fancy OS with a pre-shared DNSSEC root key and you make a query for DNSSEC for a zone that you don't have a key for. The recursor simply tells you that that zone doesn't have DNSSEC records. oops.

Scenario 3: you're running a current OS without any root zone anchors at all. You make a query to your preferred recursive DNS server (probably whatever you were handed via DHCP) and it just lies to you, about everything.

I don't understand your point about probabilities. In each of these scenarios, they're not a 1 in anything chance of getting owned in those circumstances.. that's a 1 in 1 chance. All it took was a MITM. To say nothing of the traffic analysis and complete lack of any sort of encryption for passive MITM's.

> You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption.

First: There are two arguments to be had. One is the server side, and one is the browser side. The server is going to know about the key problem if it happens. The client side browser can know, if the client is using plugins like this one:

https://www.dnssec-validator.cz/

Second: Here is the root key: https://www.iana.org/dnssec/files

Yep.. in a typical MITM scenario (say, at a coffeeshop or a hotel in a firesheep sort of attack), server side checks won't help you at all since the MITM recursive server could just keep spouting those lying lies :)

It's a bit pointless to argue for or against DNSSEC. It exists, and if you are fishing for larger customers in the hosting business, you already have had to relate to that. It is, for better or for worse, infrastructure.

You can have informed opinions on how to change it, just like you can argue for changes in the TLS protocol to extend it or modernize the crypographic primitives. But a fundamentally different protocol would need a clean start, and would need to offer enough advantages to get people to switch. These global systems takes a decade to change, at best, and it can be done. While I would love for both TLS, IPsec and DNSSEC to have been designed differently from the start (i.e. without X509), that's not where we are today.

As for the basic idea, it is wise to ask yourself: Would it be useful for registrars to prove domain ownership cryptographically? If you think that could be put to good use, you will understand the basic premise and what the protocol was designed for.

Before I pick apart the obvious points, keep this in mind: do you __need__ DNSSEC right now? Not would it be helpful or nice or make things a bit more secure, but do you need it?

> 1. DNSSEC is better than no DNSSEC.

You can't use your argument to defend your argument; this is circular reasoning and therefore illogical.

Also, the commenter has no idea what protocols use crypto in what way as many of them are proprietary.

> 4. [...]There may need to be some software adjustments to fully accommodate DNSSEC. However, there currently exist several DNSSEC plugins, extensions, or modules for several end user browsers. Thus, the code base has already been started, making improvements and merging code bases is the next step.

This is like saying "Replacing cars with driverless cars just requires a software update". Yeah. On every car and road. No biggie. I'll put it all on my Visa.

> In short, if a devops can type a few characters in a DNS record, a devops can deploy DNSSEC within a few hours depending on the domain complexity.

You don't need to be "a devops" to make a DNS record change, but ideally you would call this person the domain name record owner or DNS administrator. This shows little understanding of how DNS is deployed in the real world.

> Generally #6 is specious.

If you consider "we have to upgrade our OS on all our systems - which may range from 1 to 100,000 depending on the organization - to gain a marginal amount of security we didn't need before" to be specious [assuming Windows comes with a validating stub resolver now].

> There is a vulnerability in DNSSEC, that is openly listed in the RFCs, that indicates subdomains are enumerated. [..] However, for simple domains with a few hosts, enumerated architectures should be a minor problem if a problem at all.

"Please ignore this information leak."

> This sockpuppet Anti-DNSSEC rant is inaccurate, incomplete, and presents a picture of DNSSEC that is unsupported factually, mathematically, and architecturally.

"I can't argue the point that we don't need DNSSEC, so let's just throw some hyperbole around and hope nobody notices I don't even try to prove my claims."

Ask HN:

I am asked would I prefer 1. to have a pre-generated cryptographic "signature" of every www page that can be checked against some centralized repository for "authenticity" or 2. to encrypt every www page before transmission or at least have it encrypted in transit?

"Both" is not an valid choice. I have no idea why not; as far as I can tell, they are not mutually exclusive.

Because I mindlessly support SSL (let's encrypt!) I choose option 2 over option 1.

Now I am asked the same question regarding DNS packets. 1. Sign the packets or 2. encrypt them?

Do I still choose option 2 over option 1?

If I choose 1, those DNS requests will be unencrypted plain text like unencrypted HTTP.

Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

> Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

DNSSEC has nothing to do with privacy.

DNSSEC is entirely about the integrity of DNS requests.

DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about.

That's it.

DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.

DNSSEC is probably better described as a mechanism to prevent cache poisoning; which is different from the "modified in transit" case.

DNSSEC isn't very useful for defending against a MITM:

1. If the MITM goal is to block your domain, they still can by dropping the queries or replies.

2. If the MITM goal is to intercept your content, they don't need to rewrite DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here.

Additionally, if the MITM is between you and your resolver: for example in the Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do not validate.

colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query.

Yes, "cache poisoning".

Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there.

If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there.

If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater.

This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.

Thank you for the answers.