4. This DNSSEC Talk
• Explain need for DNSSEC
• Point to some implementation
examples
• NASK provides some implementation
plans for .PL
5. Why DNSSEC?
• 5 years ago (2005), talking about
DNSSEC being deployed anywhere
would cause laughter.
• 3 years ago (2007), talking about
DNSSEC being deployed to the root
would result in laughter.
6. Why DNSSEC?
• 2 years ago (2008), Verisign and
ICANN provided proposals about how
the root would be signed.
• On July 15, 2010, the first full
production DNSSEC root zone was
signed. (ask Chris)
• Signing road show:
– ORG & EDU, now
– NET 2010, COM 2011, TLDs...
9. Why DNSSEC?
• What spurred this rapid change in
attitudes?
• Was the world as we knew it about to
end?
• Possibly. Maybe.
10. Why DNSSEC?
• Contemplate for a moment the
amount of trust that we put into the
DNS infrastructure
• If DNS were to suddenly become
unreliable or untrustworthy, what
would the result be?
12. Why DNSSEC?
• There are lots of places for "bad
people" to do "bad things" in the
DNS infrastructure.
• Aren't these the same problems that
DNS has had since 1983? (just like
SMTP, FTP, HTTP)
• Yes, but...
13. Known threats to DNS cache servers
Check out the Cricket Liu webcast
SANTA CLARA, Calif. - (Business Wire) Infoblox Inc., the market leading provider of network infrastructure control
solutions, today announced that it will host a live webcast entitled “Why We Need the Domain Name System
Security Extensions: A Look into the Threats to DNS and How DNSSEC Addresses Them.”
The webcast features DNS expert and O'Reilly & Associates author Cricket Liu, who will discuss cache poisoning
vulnerabilities and what they mean to enterprises worldwide. The free event will be broadcasted live on Tuesday,
September 28, from San Francisco at 9:00 a.m. PDT, along with in-person “viewing parties” in 5 cities across North
America: Seattle, Chicago, Toronto, Philadelphia and Fort Worth, Texas.
DNSSEC is suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information
provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. Additionally, Cricket Liu
will discuss: 1) Interim measures to combat cache poisoning, 2) DNSSEC and why it's necessary for long-term
security; and 3) Automating DNSSEC management.
About 90 minutes, easy to watch, good for IT managers
http://www.infoblox.com/en/resources/webinars/cache-poisoning-and-dnssec.html
16. Kashpuref cache poisoning
• Incorrect NS or A records provided in
glue could by trusted by BIND
nameservers and cached.
• AlterNIC used it to redirect
internic.net to them.
• Bailiwick checking
for glue
17. Birthday Attack Poisoning
www.isc.org A
192.153.154.4
w
w
w
.isc.org
?
192.153.154.4
www.isc.org?
Attacker
caching
recursive
server
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
www.isc.org A
192.153.154.4
V
ictim
C
lient
V
ictim
S
erver
19. PRNG DNS cache poisoning
• Amit Klein, Trusteer
• Message ID's are supposed to be
unpredictable
• PRNG generator had issues
– If MSGID is even, next ID in 1 of just 10
• OpenBSD PRNG fixed
20. Kaminsky
• January 2008 – Life as normal
• February 2008 – Dan Kaminsky
makes contact with Vixie
http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky
21. Kaminsky
• Since then, nothing has been
normal...
• In February, ISC, Microsoft, Cisco
and other vendors were notified of
the new DNS attack vector
• An effort was undertaken to provide
software updates that would be
released simultaneously across
multiple platforms
22. Kaminsky
• "Classic" cache poisoning was known
about for years.
• What was so magical about the
"Kamisky" attack?
• It's all about timing... and scale...
28. Why DNSSEC?
• This vulnerability was a "game-changer"
• Suddenly, caching servers across the
Internet were vulnerable.
(10 seconds – DEFCON 2008)
• While a port randomization work-around
was put into place, it still is not a long-
term fix.
(10 days – Eugeniy Polyakov [sp?])
29. Why DNSSEC?
• In addition to the Kaminsky attack,
what about untrusted environments?
• The hotel that you stay in as you
travel.
• The network that you attach to in the
airport or coffe shop...
30. Why DNSSEC?
• If I run your recursive server, I can
provide you with any response that I
want..
www.google.com => 10.0.0.1
• Does the consumer believe that?
31. Why DNSSEC?
• DNSSEC provides the ability to
validate responses to insure that the
response is unaltered since it left the
authoritative server.
• DNSSEC data can, if you wish, be
ignored.
32. How do I get started?
• Training
– Invest in your staff. The keys to your
kingdom are literally in their hands.
• Server software
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
• Appliances
• Services / outsourcing
– “Bump in the wire”
34. Who do you trust?
• You're an ISP
– Don't take my word for it
– Software vendors? OS vendor? Current DNS?
– IANA? ICANN? (http://www.root-dnssec.org/documentation/ )
– NASK.pl? www.cert.pl?
• You're a user
– ISP example:
• http://www.dnssec.comcast.net/
– OS vendors?
36. Learn how to sign zones
• As an ISP, you're responsible for IN-
ADDR.ARPA and IP6.ARPA delegations.
• Get Alan's DNSSEC tutorial:
http://www.nanog.org/meetings/nanog50/agenda.php
See “Tutorial: DNSSEC Implementation Using Bind 9.7”
• Try some test domains (or your real
domain)
– Publish them in DLV
– Ask your registrar now what they are doing to
prepare for registration of DS records
38. More DNSSEC fun
• http://www.practicesafedns.org/
• Comcast Public Service Announcement
http://www.youtube.com/watch?v=boyl6o7nkLQ
• Statistics:
– http://secspider.cs.ucla.edu/
39. What could go wrong?
• Expired keys (implemented without
monitoring) or bad key rollover
• Firewalls
– Not yours, everyone else's
– TCP blocking
– EDNS0 support
– Packet size limitations
• Human error
– Upstream problems (DS records, Registrar)
– Misconfigured recursive servers (DLV, ITARs)
40. What could go wrong?
The new amplification attack:
% dig isc.org ANY
Try it: Recently 3384 bytes
Need robust caching databases,
possibly pre-filled out of band or
saved state.
