Site Search
 

How Secure is Your DNS?

What DNSSEC Can Do for You

ICANN is urgently calling for full deployment of the Domain Name System Security Extensions (DNSSEC) across all unsecured domain names. Increasing reports of malicious activity targeting the DNS infrastructure are being publicly reported. How secure are you?

Paul Ebersman, Neustar's principal engineer and DNS architect, will share timely information about DNSSEC.

From this webinar you will learn the answers to the questions:

  • What is DNSSEC?
  • Why do you need it?
  • What does it protect against?
  • What are the advantages of deployment?

Video Transcript

Welcome to Neustar's webinar, How Secure is your DNS? And what can DNSSEC do for you? Thank you for taking the time to join us.

My name is Benham Malcolm and I'm the product manager for Ultra DNS, a cloud-based Authoritative DNS service. I'll be moderating today's session. Before we get started, I want go a few housekeeping items.

First up, we've allocated time at the end of the webinar for questions and answers. If you'd like to submit a question during the webinar, please do so by typing your questions in the Q&A pod on the left side of your console and be sure to click the Submit button. We'll try to answer as many questions as time allows.

For the best view experience, we recommend you expand the slide viewing area by clicking on the Maximize icon on the top right corner of the Live View window or by clicking and dragging on the bottom right corner of the window to resize it.

The audio for today's session is web streaming only. To ensure the highest quality audio, please close out any other applications you may have open, as these we use bandwidth and may cause latency or disconnect issues with your session. Also please make sure your audio is set to an adequate volume.

Today's presentation is being recorded, and that recording along with the slide deck will be made available within the next few days. It is now my pleasure to introduce today speaker, Paul Ebersman . Paul works for Neustar as a principle engineer and DNS architect.

Previously, most recently, he worked at Comcast as a DNS architect and technical resource on DNS, DHCP, and IPv6. He maintains his involvement in the protocol, development, and use, both internally within Neustar and within the internet community. Through organizations such as DNS Operations Analysis and Research Center — known as DNS OARC — the North American Network Operators Group — known as NANOG — ICF, and ICANN.

Paul first worked on the internet for the Air Force in 1984, supporting TCP/IP and LSI networks. He was employee number 10 at UnionNet and helped build AlterNet and the modem network used by MSN, AOL, and Earthlink. He has maintained his roots in the internet and open source community working for the various internet infrastructure companies, including ISC, Infoblox, and Nominum. He has also been active in operator groups like net org right in various regional network operating groups. With that said, here's Paul. Thanks, Ben. to give you a little idea of the agenda.

I'll be starting out with some DNS basics and some security basics just to give us a common set of vocabulary and context, be explaining the basics of how DNSSEC functions, and then we'll be diving into the guts of this be talking about what DNSSEC actually does and doesn't do and going through some use cases to see where that did and did not apply. And then we'll have a Q&A section at the end.

DNS Basics: Domain Name System

Some basic ideas of DNS — there are several rules that you can play with that are used in DNS. There is the zone owner who actually owns the example.com domain name, whatever it is. The DNS operator and this is whoever runs the publicly available authoritative servers for that domain name.

There is the registrar, and that's who sells domain names and runs TLDs. They may also be the DNS operator as well as the registrar. And then there's the registry operator who runs the actual database for the TLD that registrars sell domain names out of.

There are different types of DNS servers as well. The stub resolver is usually part of the operating system of a user device. It tends to be a dumb resolver. It does nothing but gets configured to ask the upstream recursive resolver for answers and then just accepts those answers back.

The recursive resolver (recursive DNS) does all of the actual work of going through the entire DNS chain and resolving all of it and getting down to the answer that was originally asked and then handing that answer back to the stub resolver. It also usually caches those answers. So if multiple subresolvers are asking for the same name within the time period, it can more quickly respond with that answer.

Authoritative name servers are the ones with the actual zone data for a particular domain for which it's authoritative. This is the basic recursion flaw. I'm not going to go through it here, but I wanted it to be available in the slide deck later. It shows all of the various queries and responses that are actually required by a recursive resolver to get an answer for a user.

DNS Threats

Some typical DNS attacks or issues that we see in the DNS live, denial of services, one of the most common. This is where you essentially deny the user the ability to get an answer to their question by some means. There's cache poisoning where that caching recursive resolver is fooled into taking an answer that is not what the zone owner wants you to have but what a malicious actor wants you to have.

There are false authoritative servers where someone sets up a fake domain name or domain server, and it gives you answers that the bad guys want you to have, not what the zone owner want you to have. And then if you're able to get the domain owner's credentials, you can potentially modify data within that zone and also point to a malicious server rather than the legitimate server. As a result of all this, you can either get no answer at all, or you can get directed to a fake site. If you are directed to a fake site, it's very common that this is used to either steal log in credentials, give false data, or appear invisibly and eavesdrop on the conversation.

How Does DNSSEC Work?

DNSSEC itself most simply is a public key or asymmetric encryption, much like you would see with the certificate system for the web community with SSH, et cetera. You start with a private key that is kept secure and private and use that for signatures or encryption. And then there is a public key that you give out widely to everyone else, The two use cases of how you use those private and public keys are to encrypt files that only certain people have access to the data within those or to create a digital signature by which if you validate that that signature is correct, you know that whatever was signed, has not been altered, and you got what was originally there.

DNSSEC takes those basic concepts and what it does is zone data to the resource records that you have within the zone file are digitally signed. It also publishes public keys within the DNS in the parents and in the child zones. And you make DNS queries to get the various keys that you'll need to get the signatures as well as the actual resource records that you're querying for. You then use all of those keys and all of those signatures to follow the entire validation chain.

A More Secure DNS

And if all of those signatures match, you know that you got a validated answer. If there's a validation failure, you get no answer at all. You actually get a serve fail in response. So in security parlance, this is fail and closed. If something breaks, you don't get in, or you don't get the answer.

So what kind of problems does DNS solve? First, the basic security concept that most people break things down into. Integrity says whatever was sent has not been altered by anyone in the path. That what the original sender gave out the ultimate receiver gets intact, no more, no less.

Confidentiality is guaranteeing that only those who are authorized to get that information can get that information. No one else can steal or eavesdrop and get it. And availability simply says can I get the information I need when I need it or will somebody be denying me that availability when it's critical that I have that information?

Benefits of DNSSEC

So DNSSEC solves one simple problem, integrity. It guarantees that whatever the zone owner puts into the zone is exactly what the stub resolves and the end device that asked that question gets. What this protects you from is, therefore, cache poison. If I can somehow get a caching resolver to put a different IP address or a different answer into their cache, the next user that asks for that DNS label is going to get what's in cache, which means they will get a malicious answer.

If that caching resolver is a DNS validating resolve and if that zone is signed, that caching resolver can actually validate the entire chain and guarantee that they are getting what the zone owner wants. And if it doesn't validate, they don't put it in cache, and they don't give the answer. The cache poisoning is prevented.

Similarly, if I set up a false authoritative server, the entire chain of DNS has to work if that zone is signed. And that false server probably doesn't have the private keys and the correct key signatures and the rest of it, and they probably changed things so those digital signatures no longer work. So it will fail to validate. The resolver that validates won't give it to you, and you'll be protected.

The other side, though, what doesn't DNSSEC solve? It doesn't solve condensed confidentiality. All DNS answers are by default sent in the clear and clear text. So anybody who is in the network path can see the answer and the response.

There are some point-to-point encryption technologies, such as DNS over HTTPS or DNS over TLS — that are emerging standards, but they are still only point-to-point. They are not end-to-end. It doesn't solve availability. If I can somehow take out the authoritative servers or congest the network path so that the actual answer doesn't get all the way to whoever asked it, I can prevent them from getting an answer. It also doesn't function as autocorrect.

If I fat finger or something in my zone file, it's not going to find that and magically say, oh, you spelled that wrong. So you will get exactly what the zone owner put in their zone, whether it's correct or incorrect. It also doesn't take care of parent zones.

So if I have example.biz as a domain name, I can't guarantee via DNSSEC that biz is OK. That's something that biz has to take care of by signing that TLD zone.

Case Studies: 3 DNS Attacks

Let's get into some case studies now of actual attacks that are alive. And these are things that have happened and that are out in the public. You can Google for them and get more details.

There are four incidents. There was an incident with a Brazilian bank. Wikileaks a popular sort of journal and leaking information site, MyEtherWallet which is a cryptocurrency site, and DNSpionage which is actually an ongoing attempt to gain information on various government agencies.

DNS Hijack and Bank Heist

So the Brazilian bank — what did they actually do? A Brazilian ISP had customers with CP customer premise equipment routers, cheap consumer routers that, as most of those are, were not well maintained, were not well patched, and didn't have terribly good security, threw a bug in their software. The bad guys were able to change the settings. So instead of using the recursive resolvers that the ISP supplied, they actually changed what the router used to their own malicious recursive servers.

Since most of the devices in the home will be a DHCP be told to use the router as their recursive resolver, that resulted in all of the devices at any individual home going off to this malicious recursive resolver. What that resolver did was it answered everything correctly so that it was hard to notice except for a particular bank where instead of giving legitimate a record or IP address, they were sent off to a false website. That false website then stole the login and passwords of the users for those bank accounts. The result was that a number of users got their bank accounts emptied.

Now things that could have helped — obviously, better software and currently patched software for the routers would have made this impossible. If the individual devices themselves had a DNS validating stub resolver DNS seq would have helped. That's unfortunately much less common.

These days, most devices don't have a terribly sophisticated DNS resolver.

And lastly, if the bank had been looking regularly for certs taken out in its name, they might have noticed that someone else got a cert for a machine that they did not run. Wikileaks was a little different and a little interesting. In some ways, they got the domain owner's credentials.

So they simply changed the A records within the zone file and then set up a fake website. The press originally had this as the website has been hacked. It has been defaced, and Wikileaks went in and started poking all around their server and didn't find anything because it wasn't actually their server.

The remediation for this were pretty obvious. Obviously, protecting a credential so that people can't get in the change zone data would have helped. DNSSEC would have helped only if the NSO name server records in the zone and the DS records of the delegation signatures records in the parent, pointing down. If those had been changed, they would have had a chance to notice that someone was playing with their zone. Unfortunately, if you own the domain, you can enable and disable DNSSEC yourself.

DNS Attack Empties a Crypto Wallet

MyEtherWallet was a slightly different twist. They didn't actually get any domain owner's account. They didn't actually change things in the zone. What they didn't said was they noticed that AWS address space wasn't being securely announced.

And so they did a BGP hijacking, a routing protocol hijack so that some of the queries for the AnyCast addressed authoritative servers went to servers that they set up in AWS, not to the legitimate servers. They also, because they had at least some working web servers, managed to come up with a fake web certificate. It didn't look good to everybody, but unfortunately, users click through, anyway.

The result again was that a certain number of people were redirected off to a fake website. They didn't really pay attention to the fact that the website wasn't looking quite clean. They logged in.

Bad guy's got their login credentials and emptied their accounts. So here in mediations there's something called RPKI, which is a way of securing BGP announcements. If they've done that they wouldn't have been able to do the RAF hijack at all.

DNSSEC would have prevented this because if you validated, you would have noticed that this fake DNS server didn't have all the right signatures. It wouldn't have validated. The user wouldn't have even been given in a record. And if they had gone off looking for people setting up certs in their name that were not them, they might have noticed this as well.

Subtle DNS Espionage

Now, the last case — DNespionage, which is still somewhat ongoing, was a very complicated set of hacks. No individual stuff was that hard but what was interesting was that they did so many things. So they started off by trying to get to registrar employees for a couple of registrars who were also registries and running TLDs. They did this with a malware infected document, and they managed to get some credentials.

At that point, they were actually able to get into not just domain owner accounts but they could actually get into the parented to the field these and change who were the sorry, the DNS servers. They were very cagey in that they started slurping up account credentials and making these changes and setting up fake web and fake email IMAP sites only an hour at a time. So one of the two registrars actually was using DNSSEC to secure their information.

And so what they were seeing was they were seeing intermittent failures where, for certain periods of time, people's email couldn't connect to their server and download email because DNSSEC was validating. So it was failing. So they weren't getting in a record, so they never connected. The way they got hacked was two of their employees were on a hotel network that required them to use the hotel's recursive resolves, which did not DNS validate.

And when they got the A record for the malicious site, their phones connected and gave their email login and passwords. The bad guys had now registrar credentials and email credentials. At that point, they started doing the same game with customers, both with bought domain names from those registrars. And again, they would turn it on for an hour time, slip them down, and they were able to get the email accounts of a number of government agencies in the Middle East, which was apparently their goal. Other bits that showed that they were at least knowledgeable — they made heavy use of Let's Encrypt.

So when people connected to the fake website, there was a legitimate certificate, and Let's Encrypt which allows you to validate that you should get a certificate one needs by putting a record into your zone. Since they had a fake name server for that hour that they were surfing, they could do that. They set up the fake certificate.

Then they set up or light up the email, and they would slurp up logins and passwords. So what did it mean? Ultimately, they got login credentials for a number of government agencies Remediations on this one — one of the things that might have caught it, everybody was monitoring for changes in things like name servers and DS records and MX and other things.

But frequently, they were doing it once a day. And since these guys were coming internet on for an hour and then going away, they didn't catch it. So doing things much more quickly or much more frequently would have caught this. There's something called registry locks, this is much like locking your credit history where you can go to the three main credit agencies and put a lock on, and no one can open up new accounts in your name with your credit information without going through a much more rigorous set of identity checks to unlock it.

It means that you do have to go through a lot more to be able to change things than your DNS zone, but it's much harder for the bad guys to get to that point too. The odds are good they will not be able to counterfeit all of the credentials that are necessary to unlock that zone. Multi-factor authentication is always a good idea for any login and friend credentials. DNSSEC helped some, but it only helps when you're validating, unfortunately. And while many large recursive farms are now doing the DNSSEC validation, it is not universally there.

And again, if they had gone off looking to see if anybody else was registering certs in their name, they might have noticed some things going on.

Better DNS Hygiene

So what are some of the things that you can do? Everything that you should do anyway for infosec. Credentials, use strong passwords, mixtures of letters, numbers, special characters, 12 characters, 15 characters.

Don't reuse passwords — have a unique password for every place you have to log in. Along those lines use a password manager so that using unique passwords doesn't drive you insane. Use multi-factor to factor multi-factor SMSs — probably the least secure but it's still much better than nothing. Do phishing training for your staff.

A lot of these things start with something like a malicious document or an email pointing you off to malicious website. Use role accounts — one of the problems with accounts also is password recovery frequently has password recovery is I forgot my password. Email me a reset link.

And if this is a disgruntled former employee or someone's personal Gmail account or the email account of the web guys that set up your website originally, but they're a contractor. They've gone away. All of those means that you don't have an easy way of recovering your account, and the bad guys potentially have an easy way of stealing it away from you. So company only so you can revoke it.

Role — so there's no particular person. And critically, always audit all of your access and your log into your accounts on a very regular probably quarterly basis so that you notice things like lack of good recovery accounts and all the rest. Auditing logging is critical.

Monitor not only your own DNS servers but the parent zone servers. Monitor multiple times and hours so that if they are doing things for an hour at a time, you have some chance of catching it. And anything that is a key record or service entry point — mail, web, banking certificates — anything like that, monitor all of those as well.

And monitoring is useful — useless if you don't actually alert. So make sure that any time that you get a monitoring failure or an unexpected change that it goes to someone who will actually act on that promptly and is able to do something to fix that. You have an SSL.

If your users aren't used to the idea of making sure that that little green padlock is on, if they have a bad habit of this is insecure, click OK to go through. And they just click OK.

Bad habit — they need to be trained. And you need to start checking your certs on a regular basis. Check things like certificate transparency logs. Make sure that there aren't odd things going through. Make sure that your certs are actually higher quality certs.

Make sure that it's not just there was an entry in the DNS record or the credit card cleared. Therefore, we gave them a certificate. Some of the good signs that they are doing something more diligent — do they require a CAA record in your DNS, DNSSEC signed? Do they have extended validation where they actually ask for things like letters of incorporation and other proof that you are truly the entity or company that you're claiming to be?

And finally, on all of your critical servers, internal and external, you should have VPN access only and/or ACLs to make sure that you're limiting who can get the backside of your servers. On the DNS side, DNS validation — DNSSEC binding isn't useful if nobody validates to make sure the signatures are OK. It's just extra records in your zone that aren't doing anything for you.

So enable DNS validation on all the resolvers you use. This also means that if there is a validation failure, you'll notice it. If you sign all of your stuff but you don't yourself use the DNSSEC validation, how you're going to notice if something goes wrong? Find all of your zones. And if you can operationally, use registry locking or everything critical.

So to summarize, DNSSEC is a useful and critical piece. It can help with cache poisoning. It can help with fake DNS sites. It can make sure that if somebody is playing games that the users better fail close and don't get an answer than get a malicious answer.

But on the other side, DNSSEC is one single layer in a multilayer defense, and the other layers must be secure in order to make sure DNSSEC works. And there are other things you must do. and at this point, I'd like to turn it over to you folks online and see what questions you may have. Tim?

Related DNS Questions

Thank you, Paul. So we do have a number of questions that have come in, and we'll start with the first one, which came in early on, which is, could you clearly define the difference between a zone versus a domain?

Q: What's the difference between a zone versus a domain?

Yes, and it's actually somewhat muddied. In the purest sense, a zone or zone file or zone cut is one single label between the dots in a fully qualified domain name or FQDM. That's the protocol for your definition. A domain name is that entire label.

So in dot, dot, dot, dot example.biz, biz is a zone file, and it delegates a piece off to company example. And there's a zone example.biz. And within example.biz, there would be a label dot, dot, dot so dot, dot, dot example.biz would be an FQDN and would be a domain name. Next question.

Q: How does DNSSEC relate to DoH and DoT?

All right, next question came in from Kelly. Background about slide number 17, which was you were talking about confidentiality and DOH or DNS over HTP and DNS over TLS DNSSEC. Can you describe a little more well how does DNSSEC relate to doe and dot?

Certainly, so DNSSEC is end-to-end data integrity. Whatever the zone owner put into their zone file and then signed, if I am behind a DNSSEC validating recursive resolve or will know that what I get as an answer is exactly that nothing more, nothing less. But it is in data integrity only in the end anybody who's along that chain can see my question going out, and the answer coming back. DOH and DOT are both an encrypted connection between one DNS server — usually, a fully recursive resolver and an authoritative server.

It can between be between other DNS servers, but it is between one DNS server and another DNS server. And it encrypts the data between the two of them. There is no data integrity because you don't know that the upstream resolver is giving you a legitimate answer or that it's a bad actor who has managed to subvert the machine. But you do know that nobody between those two servers can eavesdrop on it.

So it is point-to-point confidentiality for DOH or DOT. It is end-to-end data integrity for DNSSEC. Thank you. Next question.

Q: What are some issues that you could run into when signing zones for the first time?

All right, next up, what are some issues that you could run into or someone could run into when signing zones for the first time?

There are a number of things that we have allowed that were never according to the DNS protocol rules, but we allowed to work, anyway. That DNSSEC requires us to follow the rules strictly. The most common one is what's called the dotted host where in example.biz, I put a label Foo.bar with that dot there actually into that zone file. What should be there is a delegation in the example.biz zone file for bar.example.biz, which will have a label Foo. We've allowed that, and it actually resolves in regular DNS.

In DNSSEC, however, it doesn't. So that's the most common. But again, anything where we're not following the rules strictly, DNSSEC will expect you to follow the rules more strictly.

All right.

Next up, we have a question from Charlie. And he asks, is there some sort of universal checker for SSL certificates? I mean, how do you read me check for SSL purchased for your domain?

There are some pieces of it like certificate transparency logs and a few other things that you can look for. There is no universal look everywhere on the internet, unfortunately. But you can also look in the logs on your web servers themselves and see if there are odd things in the queries.

I'm not a web expert. So I would recommend that you go poking around in those. The biggest thing, like I said, is checking with registrars that you have some access to or checking in instituting a transparency logs to see if there's something odd.

Unfortunately, the best thing you can do is get your users used to the idea of actually checking for good certificates and the extended validation stuff that turns the barbed wire instead of a padlock. There's so many UI failures on so many browsers that we sort of unfortunately blown that chance. So that's unfortunately about it. Next question.

Q: How to securely integrate between recursive servers and the stub resolvers?

All right, let's see, moving right along. Tyler would like to know if DNSSEC is integrity between the recursive server and authoritative servers. How do security integrate between recursive servers and the stub resolvers?

And unfortunately, the answer is it's an implicit trust. If your ISP resolver or your company resolver chooses to send you an answer and sets the AD bit, which says there was authenticated data i.e. Here's the answer, and it was DNSSEC validated. And you don't check it again. I actually was at a hotel where it's at the AD bit for every response whether it was DNSSEC signed or not.

So truly the only way to be truly sure is to set the DO bit in your query saying DNSSEC is OK, which should signal your recursive resolver to not only give you the answer but give you all of the DNS signatures and all of the keys as part of the whole response. And then your actual stub resolver can be a valid stub resolver.

There's a resolver called stubby, and it's part of the get DNS API project. I believe it's getdnsapi.org is the website with the code — so doing that within your application to make sure that you're actually validating, even as a stub resolver, is the only way to truly be sure.

Q: What are the recommended ways to get stub resolvers to support DNSSEC?

Yeah, along the same line, actually, Tony asked the question, what are the recommended ways to get stub resolvers to support DNSSEC?

And that's similarly you talk to your operating system vendors. Microsoft has at least toyed with what would be involved, but they are unsure that there is enough customer interest to do so. Realistically, if Microsoft and Apple decided to do that, that would be a huge step forward. And then Get DNS API already has stuff available.

And so, obviously, if you're on a Linux-based server, there's no reason at all that you can't do that or run an actual fully recursive caching resolver on your server itself. And that's probably the best way of getting those up. Next question, please.

Q: How do I get started/ready for DNSSEC?

Boy, you're ripping through them here, OK. Next question, you kind of answered already. We'll give it another go here, which was, how do I get to how do I get started/ready for DNSSEC? I think you may have answered most that one already.

Somewhat but obviously, if you've got zones that are already in existence that have been in use for a while, making sure the zones themselves are ready to be signed. And that you're not breaking certain rules. You don't have dotted hosts that if you clean up and make delegations that you don't wind up with things like see names at apex when you actually correctly delegate things out. The bigger thing is much like IPv6 where IPv6 is not something that you simply go out and you turn on in your network. There is a great deal of training and education that your own technical people, your architecture designers, your network engineers, your DNS engineers need to understand first to be able to make good informed questions with your vendors.

There's a lot of stuff that's been automated these days in DNSSEC and new servers and other folks that are doing registrar and zone operator or DNS operator roles for you have a lot of automation to make that easier. But there are still going to be decisions that you as a company need to make. And you need to decide what to sign where.

And so usually, the thing I recommend first is some good basic education. And there are some folks out there. ISC, the folks that write the open source software called Bind, have an excellent training program for doing DNSSEC, their conferences like DNS OARC that have archives of old presentations and videos of presentations with as deep as you ever want to go and beyond in DNSSEC. So that would be where I would recommend that you start.

Q: Where do I begin with the actual setup process?

OK, again, one more question on the same line, and then I'll stop these kind of questions was Ryan would like to know — his question is — Neustar is our TLD. Go Daddy is our registrar. Can you walk through how the actual set up process would work and where to begin?

Usually, as a domain owner, your registrar is where you have the means to put in a DS record in the parent and are the ones that are either going to or not going to support DNSSEC signing at the zones you have with them. If you have a separate registrar DNS operator, then you need to go to the DNS operator, in most cases, to do enabled DNSX signing in your zone and then export DS records that you go over to your registrar account and put in. Part of the fun with this is that this is not in any way standard. When I was at Comcast, we had 8,000 zones that we had, and it was so complex. And we had so many different methods of getting DS records into parents and enabling DNSSEC on signing on the zones that we didn't run on our own name servers that we had a third-party vendor, and that was their job.

So we're looking to somewhat more standardize that. But unfortunately, at this point, Go Daddy is one of the registrars that does have automation to make DNS signing fairly straightforward. And I believe they also just then have you cut and paste.

And then it depends on what TLD you're in as to how you get the DS records in. So yeah, go to tech support for both of those vendors, ours and Go Daddy, and see what tools we have to make that available to you. All right, OK. Any other questions?

Q: How do I monitor critical DNS/DNSEC resources?

One more from Steve. So how do I monitor a critical DNS/DNSSEC resources?

Unfortunately, to some degree, it's sort of like saying, how do I monitor my routers? So it would depend on what architecture, who you have, what tools you're already using. The things I can say are you definitely want to make sure that you're doing actual DNS queries of the records that you care about both in your zones and in your parents. If you want to be doing them on a fairly granular level.

Certainly, every 5 or 10 minutes, not every hour, every day. Again, parent and child zones and there are some other things DNSSEC supports. There are some of the large monitoring sites that do have capabilities for doing so. Wright has what they call their Atlas project in Europe, but there are probes all over, there are ways of doing sort of custom.

But you're limited because it's a free service in how many queries you can actually make. Beyond those, there is a website dnsbiz.net that you can use for debugging purposes. But it's not a monitoring site. They have software in Python that you can download and run yourself, but it's a little heavyweight.

Unfortunately, this is another where we're still fairly early on at least in the DNSSEC piece of it and really monitoring. The other thing you want to remember when you're doing monitoring is keep in mind AnyCast and other games that are played on authoritative, so you need to have the queries being done from enough different places that you're actually testing the full fabric. Other questions?

Q: Where and how do I safely store key for DNSSEC zones?

All right, here we go. Question from Gary and Gary asks, where and how to safely store keys for DNSSEC zones?

It varies with where you're doing your signing and how you're doing your signing. If you are doing the signing yourself, usually, what you do is you have what's called a hidden master. And you put the keys on that hidden master, and you very severely limit who can log into that box at all. Or in some cases, you may actually put it in a physical room locked down with no network connectivity or log in purposes and an actual keyboard that you have to go to. There are specialized pieces of hardware called HSM or Hardware Security Modules.

To some degree, I feel that they are security theater, but there are certain military and government contracts that do mandate them, anyway. And there is the magic thing to people actually walk in with physical tokens and shove them into a machine. And it spits out a sign signature, and it generates its own keys. And there's no way of actually getting the key out of it at all.

There's a different method, which we are getting ready to roll out, called signing on the fly where the authoritative themselves that are publicly out there. And they will actually sign their own records as they give them out. And in that case, at least for us, we have them in encrypted portion of memory, and we have a secure channel by which they are updated.

But basically, it's like any other password or any other key. If you're doing Cerberus or you're doing Active Directory, you have certain protocols that you use to make sure that the things that hold the keys to the kingdom are much harder to get into than anything else in your network. And you should treat your private keys and DNSSEC the same.

All right, I think we're getting right at the top of the hour. Benham, anything else?

Well, actually, that closes out our questions that folks submitted thus far. Paul, is there anything else you want to talk about before we wrap up? Any closing thoughts?

Beyond just what I've mentioned, the slide decks are available. And one of the things in the slide deck — there are a couple of things that I have the recommendations for further reading. You've get an email telling you that the video and the slides for this webinar are available.

Please go ahead and download the slides and go through. The other is that the slides also have my email address so please feel free to reach out to me if at some point later you're going through this material and questions come up. And beyond that, thank you very much for your time and attention.

All right, I'd like to once again thank Paul as well stays audience participation, Neustar's webinar, How Secure is Your DNS and what DNSSEC can do for you. We look forward to meeting again at our next webinar. Have a great day. Thank you.

View Full Transcript
 
Related Resources