17

I was previously using OpenDNS on my internal network. I found out today that Comcast has switched over to DNSSec: Comcast DNSSec.

I've done a little research on DNSSec and its benefits. I understand the basics of DNSSec. Pretty much DNSSec signs your DNS request so you won't have man-in-the middle situation happen to your DNS queries. Does a lot of malware use DNS man-in-the middle attacks?

So then I found out OpenDNS doesn't think DNSSec is the ideal solution: OpenDNS opinion on DNSSec. They use something I've never heard before called DNSCurve. Sounds pretty similar to DNSSec. With Comcast's solution you seem to be automatically protected if you use their DNS Servers. Not sure if this is true with OpenDNS or not. They also have a cool tool which I would love to use: DNSCrypt which encrypts your DNS requests. Unfortunately right now it's only for MACS.

So the overall question is: should I make the switch or is OpenDNS with its technology just as secure as DNSSec on Comcast?

coding4fun
  • 303
  • 2
  • 6
  • Hi, and welcome to [security.se]! Thanks for bringing this question here. Since this is your first time here, I recommend reading the [FAQ]. – AviD Mar 15 '12 at 06:37
  • This question makes no sense. OpenDNS business model is to provide the best possible DNS information possible and offer services. So if your using OpenDNS you don't really "need" DNSSec because they can implement their own solution if they want. It seems like you don't understand how DNSSec works, trusting a single party to verify their DNS information, by default obsoletes DNSSec. – Ramhound Mar 15 '12 at 12:52
  • 2
    What your saying doesn't seem right for what i understand of DNSSec. I'm not saying i have a thorough understanding because i don't. How would trusting one party make DNSSec obsolete? How would it stop a man-in-the-middle attack? Someone could intercept your dns query and send back an attackers site rather than the correct site. DNSSec not only protects you from their DNS database being injected with invalid entries (which i think is what you are referring to). – coding4fun Mar 15 '12 at 13:21

4 Answers4

19

DNSSEC and DNSCurve address completely different aspects of DNS security.

First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects the resolver from receiving bad data, but does nothing to prevent MITM or snooping between you and the resolver.

DNSCurve, on the other hand, encrypts communications between recursive resolvers and authoritative servers and allows authoritative servers to sign their data against forgery, but does nothing to protect an end-user client from a bad recursive resolver. OpenDNS's DNSCrypt solution is based on the same technology as DNSCurve, but protects the last-mile between a trusted 3rd party recursive resolver like OpenDNS and the end-client.

As for which is more secure, neither is. They are both secure, however the security is applied in different areas. In either case you are picking which aspect of DNS security is more important, rather than which security tool is stronger.

As for what you should do, that is something only you can decide, but do please consider the following:

  1. You could use Comcast's DNSSEC resolvers and hope no one snoops and MITMs the connection between your machine's and Comcast's resolvers.

  2. You could use OpenDNS's resolvers, connect to them using DNSCurve, and hope that no one feeds bad data to those resolvers, as they do not use DNSSEC. (To be fair, OpenDNS has a very good track record of preventing such attacks.)

  3. You could run your own resolver using freely available open source software such as BIND, PowerDNS, or Unbound; enable DNSSEC on said resolver; and keep the queries on your local network—or better yet, run a resolver on each machine. (This is the best option IMHO, as it addresses the weaknesses of both of the other two options)

Michael
  • 2,391
  • 2
  • 19
  • 36
Joe Sniderman
  • 531
  • 4
  • 7
  • I do not think that pdns-rec (the powerdns recursive resolver) does dnssec at this point. – dfc Jun 26 '13 at 01:25
  • I could be totally wrong about this, but isn't the "DNS resolver" actually built into the client's operating system? (According to Wikipedia it is http://en.wikipedia.org/wiki/Domain_Name_System#Client_lookup) Wouldn't that mean that it's not just Comcast's DNS servers that verify the signature, but also the client's computer which made the DNS request? If that's true, then in reality DNSSEC *does* protect against MITM to some degree. (Though it can't prevent the DNS equivalent of SSL stripping, AFAIK.) – Ajedi32 Mar 17 '15 at 16:58
  • I doubt in-built OS resolvers do anything besides forwarding and caching. Also, it's just DNS there, not DNSSEC. – Pacerier May 22 '15 at 04:44
1

DNSSEC and DNSCurve essentially do the same thing. They allow a client to verify that the records in a DNS response are identical to what the zone owner initially configured. They're not bulletproof; parent zones, registrars and registries can still do whatever they want with zones they are directly or indirectly authoritative for. But it's still better than nothing.

For this to work, zones obviously have to be signed.

Zones signed with DNSCurve are virtually nonexistent. The fact that it adds encryption is, in practice, completely useless; given the number of signed zones, the packet size is enough to guess what the query is.

DNSSEC is getting some traction, but its deployment remains pretty slow. Still, it remains far more deployed than DNSCurve, and popular tools such as openssh and mail servers can take advantage of it.

The most secure scenario is when the verification is done by the client itself. Or at least, if you trust your local network, on the router. Now that dnsmasq supports DNSSEC validation, router firmwares start to support it as well.

Now, by using a 3rd-party resolver and not doing any validation on your own network, you:

  1. blindly trust what the resolver sends to you.
  2. even if the resolver sends you a correct response, the network segment between the resolver and your client remains vulnerable to DNS spoofing.

If you are a Comcast customer, the DNS resolver is as close as possible from your router, and your connection completely depends on Comcast already. If you are using another 3rd-party resolver, every hop between your router and that resolver can be used to potentially hijack the responses.

So, the best option remains using a local DNSSEC-validating resolver such as Unbound.

Malware doesn't care about DNSSEC or DNSCurve. Once your computer is infected, most malware can directly inject whatever they want into your browser, and change your DNS settings if required.

Privacy is a completely different topic, that just began being worked on (see the DNS privacy considerations RFC).

Frank Denis
  • 273
  • 1
  • 4
0

DNSSEC only attempts to provide security, without even any attempts at providing any privacy.

DNSCurve provides both security and privacy.

At the point of a recursive DNS resolver (e.g. Comcast and OpenDNS in your question), the question comes down to whether at least one of these technologies is deployed by the authoritative nameservers of the domain names for which the resolutions are made, and by the whole recursive path needed for the resolution. This point ensures that Comcast/OpenDNS servers themselves would be getting legitimate resolutions from elsewhere in the internet.

However, before their servers could get around to do any resolutions on your behalf, you have to send them your request.

  • If you don't yourself use any software that is savvy in DNSSEC or DNSCurve, then all bets are off.

  • With DNSCurve and the DNSCrypt client from OpenDNS, all your queries are encrypted through DNSCurve, and only OpenDNS can see the actual content, and provide a valid reply.

  • With DNSSEC, you might also have to use something like a local_unbound in FreeBSD. I'm not entirely sure how it works yet — it has only been imported a couple of weeks ago, and documentation is somewhat lacking, but I think it supports forwarding traffic to other recursive servers like the one of Comcast (with forward-addr keyword), where it would supposedly also ensure that DNSSEC validation is taking place.

As such, your question is not specific enough to know your objective; however, it would seem like you're using OpenDNS for a reason, and simply changing your nameserver back to Comcast would not offer any benefits in regards to security.

However, if you're already using OpenDNS, then you should most certainly consider embracing their DNSCrypt client.

cnst
  • 1,884
  • 2
  • 19
  • 30
  • Related: http://security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption – cnst Jan 12 '17 at 20:26
0

I installed Dnssec Trigger which includes Bind on my pc. There is a local key on your machine. I'd like to find a service which includes both DNS protocols since they are not exclusive.

From their website.

Dnssec trigger enables the end-host (laptop or desktop computer) to use DNSSEC protection for the DNS traffic. DNS translates names of computers into IP-addresses used to contact them.

It probes for DNSSEC capable servers and instructs a validator on localhost to use that. If it fails, the user can opt to go insecure.

This means a browser can (often) get DNSSEC capable results. It may trust results from 127.0.0.1 with the ADflag. Or it can do DNSSEC validation itself. This can enable DANE (IETF wg).

One of the last resorts of dnssec-trigger is to use SSL port 443 for DNSSEC. If that fails, it is unlikely that DANE (https, also SSL port 443) can work. Thus, logically, this service is very likely to provide DNSSEC when DANE must have it.