DNSSEC "FUD" Buster #1 - "Oh my goodness, where do I begin with DNSSEC?!"
Don't Panic - by John Kristoff, Team Cymru
.ORG, The Public Interest Registry is pleased to announce our first guest blogger for our DNSSEC FUD Buster series. John Kristoff works as a research analyst for Team Cymru, a Internet Security Research company based in Chicago specializing in the 'who' and the 'why' of Internet crime. If you haven't visited their (recently revamped) site recently please do so for details on the extensive work they do for the security community as well as further advice, data and tips to help you make your network more secure: www.team-cymru.org. John is our first guest blogger for our series "DNSSEC FUD Busters" and we are excited to have him share on the .ORG Blog.
John’s posting provides you with some practical guidance in evaluating your own DNS implementation from a security perspective. There is a lot of FUD on the street regarding DNSSEC being overly complicated. For those out there who are in panic mode at the thought of your DNSSEC implementation this is a must read. Just read, breathe and don’t panic.
Arguably the DNS (domain name system) is one of two of the most critical systems, along with routing based on BGP (border gateway protocol), within the system otherwise known as the Internet. Every so often a core system or protocol such as DNS is threatened by a newly discovered architectural flaw, a rediscovered flaw that was never fully addressed (perhaps with an updated twist), or a widespread implementation problem. So far this year DNS, BGP and most recently TCP have all had their share of time in the spotlight as a result of one or more of these types of threats. A two-word response often heard from the CEO of Team Cymru, Rob Thomas is appropriate: "Don't panic." One way to make a bad situation worse is to panic. We get careless, we jump to conclusions and many people just aren't able to do their best work when all they see around them is chaos.
Team Cymru sees a fair share of interesting people and events. However, rarely do the miscreants take an extremely high level of interest in these critical system threats like we often do in the industry. The reason for this is simple: the miscreants already have a tool bag full of tricks. Eventually in the normal course of malware evolution someone may create an easy to use toolkit or module based on the latest critical system threat. Until then however, the critical system threats often don't become widespread pandemics. Don't panic.
When details of the new type of DNS cache poison attack Dan Kaminksy disclosed were first becoming known, we saw some increased activity in the form of people looking for vulnerable resolvers, but it often turned out to be good guys conducting vulnerability surveys or undertaking additional research. Recently an IRC network was initially thought to have been a victim of this new type of cache poisoning. While we may
never know the exact details of the attack, the latest evidence suggests that an authoritative DNS server was compromised. The moral of the story is that we often see what we expect or want to see, especially during stressful situations. Don't panic.
This doesn't mean we automatically write-off popular critical threats as hype, but when they appear we shouldn't have to say to you "Don't panic".
I'd like to review a handful of questions you need to ask and answer when it comes to your own DNS implementation. Your answers may differ from your neighbors, but it is important to ask them. You will be in a much better position to evaluate future threats and formulate a response if you can document your current posture and the trade-offs you had to make in an existing DNS deployment.
1. How many authoritative name servers for your zone(s) do you have?
Two is the de facto minimum, but more might be better.
2. Are your authoritative name servers and resolvers diverse both from a geographical and network perspective?
They shouldn't all be in the same /24 on the same physical LAN.
3. Do parent and child name servers agree on zone delegations?
Things might work if they don't, but often sub-optimally.
4. Are your resolvers open to the entire world?
If at all possible they shouldn't be.
5. Do your resolvers and zones have protection from answer spoofing?
Investigate how well your resolvers and zones stand up to spoofing attacks.
6. Do you know when your registered names(s) will expire, who has access to make changes and how a registrar may help protect from name theft?
Many people don't think about this on a daily basis, so its easy to forget.
7. What other services are running on your DNS servers?
SSH and NTP are reasonable services, properly protected, to run on a DNS server, but do you really need FTP, HTTP, SMTP and Telnet?
8. How do people remotely administer your DNS servers?
Even if your servers are locked down tight, never underestimate the power of SSH brute force guessing attacks or a remote admin's host having been compromised with a key logger installed. We see a lot of both.
9. How much memory (RAM) do you have installed and available on your DNS server?
RAM is often the key resource limitation for many DNS servers. Have not just more than enough, have way more than enough.
10. Are you filtering TCP DNS queries?
You probably shouldn't be. TCP isn't just for zone transfers.
11. Do you have the capability to see what queries are being asked and the overall DNS server health?
Logging and statistics monitoring is also absolutely necessary for successfully mitigating many security threats.
12. Are the DNS system clocks accurate? Have you considered setting the timezone to UTC?
Having an accurate notion of time is critical not only for many protocols to operate properly, but also to ensure you are able to correctly troubleshoot problems and security events across multiple systems and time zones.
13. Have you recently read RFC 2870?
You may not think it applies to you, but it gives some good general advice that is at least in part relevant to most DNS operators.
Now, go forth, do good work and don't panic.
