Category: CircleID

Dec 22

Jim Galvin Writing About DNSSEC On CircleID

Jim GalvinWe’ve been very pleased to see Dr. Jim Galvin of Afilias writing a series of articles about DNSSEC over on Circle ID.  Jim has been a long-time friend and supporter of the Deploy360 Programme and has spoken multiple times at our ION conferences. (For example, he spoke at our recent ION Belfast event.)  Jim was also involved with the recent sponsorship of our ION conferences by Afilias.

Anyway, over at CircleID Jim started a series of articles about different aspects of DNSSEC. His articles thus far include:

The three articles provide a good overview of the current state of DNSSEC.  His third article, in particular, dives into an issue that has not been widely discussed – the potential 5-day waiting period during the transfer or a domain between registrars. As Jim notes:

In pre-DNSSEC days this technical issue would resolve itself relatively benignly. However, post-DNSSEC, if the domain name in question is DNSSEC signed, the failure of the domain name to DNS resolve (and hence, validate) results in a security incident. The previously benign “site not found” becomes a scary “you don’t want to go there” message, potentially damaging the credibility and brand of the domain name owner.

He goes on to note what needs to be done to address this issue and concludes:

The current business practices around this transfer policy require urgent coordination amongst registrars so that effective DNSSEC deployment can happen without an impact to the end-user or the domain name owner.

We agree that this is a concern when transferring domains and do hope to see this kind of coordination happening among registrars.

We also hope to see Jim continue writing detailed articles like these over on CircleID.  You can see his writing there on his author page at CircleID.

And if you’d like to learn more about DNSSEC, please visit our Start Here page to begin!

Feb 03

CircleID: Thinking Strategically About the Benefits of IPv6

Mukom Akong TamonI love it when my Monday morning begins by seeing posts like this one:  Thinking Strategically About The Benefits of IPv6 by Mukom Akong Tamon.   Please go over there and read that piece.  He’s absolutely right that we need to be thinking about IPv6 beyond simply the fact that IPv4 addresses are on their way to being exhausted.  I love his conclusion (my emphasis added):

One of these types of organisation will lead the provision of devices, software and services for tomorrow’s Internet, the other type will lose relevance and then will play catch up. Just remember this: The day you see concrete data to show the benefits of IPv6, it means you are already late to the game, that data will be coming from an early mover who is already making a ‘killing’ with IPv6.

Also, check out this great comment on the post (over on Mukom Tamon’s own site) that begins with:

It is in fact, the mobile arena that will deploy IPv6, we as a small company have already migrated to IPv6 and see huge benefits…

Great to see people relaying that they are already seeing the benefits of making the move to IPv6!  (And yes, I think I may try to contact them to find out more about their situation.)

What are you waiting for?  Are you going to be a leader in your field and seize any opportunities that are made possible with IPv6?  Or are you going to wait until the last possible moment?

Jan 16

CircleID: DNS Security Should Be One Of Your Priorities (including DNSSEC)

Circle ID LogoWe were very pleased to see this recent post over at the CircleID site, “Domain Name System (DNS) Security Should Be One of Your Priorities“, by Rick Rumbarger. He makes a number of great points, particularly about the fact that so many people take DNS for granted and don’t give it the attention they should.

Naturally, given our focus on getting DNSSEC deployed, we were delighted to see his paragraph:

Activate DNSSEC On Your Domain Names – DNSSEC counters cache poisoning attacks by verifying the authenticity of responses received from name servers. It effectively prevents responses from being tampered with, because in practice, signatures are almost impossible to forge without access to the private keys. If your DNS provider is not DNSSEC capable… make a switch.

He’s right! DNSSEC is critical for protecting the integrity of the information you get out of DNS queries.   In his paragraph, he talks about the signing of domain names with DNSSEC, but it is important to remember that this is only half the equation with DNSSEC. The other piece you need to do is to enable validation of DNSSEC on your local DNS resolver.

The local validation of DNSSEC information protects the inquiries your computer makes for DNS info, and the signing protects the integrity of your own domain name.

The one point I do take issue with in Rick Rumbarger’s article is his suggestion to outsource ALL your DNS services on both the authoritative side (distributing your domain records) and the recursive resolver side (making inquiries to DNS).  On the authoritative side, I agree that outsourcing DNS services can make a whole lot more sense than running your own DNS servers.  Most of the DNS hosting companies out there have put a great amount of effort into performance, security, DDoS protection and more – and since they are focused on that can provide better protection and performance than many of us can do ourselves (unless, of course, we operate our own data centers).

However, on the recursive resolver side, I am much more of a fan of having the DNS resolution occur as close to the end user as possible. This is particularly true when you enable DNSSEC validation.  Your DNS query is going from the stub resolver on your local computer to the whatever recursive resolvers  you have configured in your computer.  These are the ”DNS servers” in most operating system network control panels and are often supplied via DHCP to computers on a local network.

The connection between your stub resolver and the recursive resolver you use is typically unencrypted and represents an area where an attacker could inject bogus DNS information.  Ideally the connection occurs over a “trusted” network, such as your local area network.  If the recursive resolver is on the edge of your local network and is performing DNSSEC validation from that point on, then the attacker would have to somehow get on your local network in order to attack your DNS queries.

If you can’t have a recursive resolver at the edge of your local network, the next best option to me is to use the recursive resolvers at your ISP . You are then only widening the attack surface to be between your local network and that of your ISPs network.

If you can’t do DNSSEC validation at either your local network edge or your ISP, you then do need to go out and use an external recursive resolver that does DNSSEC validation such as Google’s Public DNS.  However… the attack surface against your DNS queries has now been expanded to include the entire part of the public Internet that is between your computer and Google’s Public DNS servers (to use the example of Google).  An attacker now has a better chance of getting in the middle and injecting false DNS information that goes back to your stub resolver running on your machine.

So for those reasons, I prefer to run the recursive DNS resolver as close to the end user as possible. In the ideal world, the DNSSEC validation might even be performed on the local machine (which can be done today using something like DNSSEC-Trigger) or in the application the user is using.

Outside of that point, I agree with the points Rick Rumbarger raises – and it’s great to see attention being given to this issue of DNS security!

P.S. And to perfectly illustrate one of Rumbarger’s other points about having strong access control for your DNS records there is this post today about how easy it was to get a DNS hosting provider to change DNS records with a simple email message.  This is something that DNSSEC will NOT protect against because the DNS hosting provider is  changing the actual zone file that would then be encrypted with DNSSEC.  It shows again how “DNS security” is really composed of many different layers!