DNSSEC

From IIW

Session: Wed Session 3 Space A

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Issue/Topic: DNSSEC explained

Wednesday – Session 2 - A

  • Convener: Esther Makaay
  • Notes-taker(s): Esther Makaay

A. Tags for the session - technology discussed/ideas considered:

#DNSSEC #DNS

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Presentation about DNS vulnerabilities and DNSSEC as a solution.

Excerpt of a presentation given at Infosecurity Brussels. The more elaborate slideshow on this topic can be found at: http://www.slideshare.net/esthermakaay/dnssec-towards-enhanced-internet-security



DNS & vulnerabilities

DNS (domain name system)

  • Road signs
  • Hierarchical and distributed. Highly scalable and robust.
  • Scalable, distributed data, delegated (tree-structure)
  • ‘DNS = the internet’ (no, but it is to the vast majority of the end-users)
  • One of the oldest protocols out there
DNS tree structure
DNS is everywhere

DNS is vulnerable

  • Never designed for trust
  • Nothing really changed since 1983
  • Usage has broadened (functionality and quantity)
  • Everybody wants (to handle) your DNS

Risks:

  • Availability (no DNS – no internet)
  • Integrity (wrong DNS – wrong internet)

DNS integrity

Querying DNS
DNS UDP Packet
Attacking DNS (1)
Attacking DNS (2)

Chances to spoof a resolver (Based on research by Bert Hubert (PowerDNS))
In theory (50,000 queries/second)

  • static source port – 10 seconds
  • random source port – 36 hours

In practice

  • slow attack, 100 queries/second– 30 weeks
  • 50% success after only 6 weeks
Slow attack

The (slow) attack is happening
Scarce media reports about attacks

  • Users from several large ISP’s and telco’s have suffered from misdirection and outages, but also specific spyware, spam and pay-per-click trojans.
  • Customers of a large bank were redirected to fraudulent websites that attempted to steal passwords and install mallware
Statistics show peaks for NXDOMAIN answers (courtesy of SURFnet)

Countermeasures:

  • Patch against attacks
    • add entropy by port randomisation, case sensitivity (DNS 0x20) or EDNS-PING
    • cache time-outs, ask twice/ask thrice, use TCP
  • Monitor your network and servers
    • look for brute force attempts
    • count ‘near misses’ (correct port / failed ID)
    • Restrict queries to the intended users

Or implement DNSSEC

DNSSEC

A set of extensions to DNS which provide:

  • origin authentication
  • data integrity
  • authenticated denial of existence

Metaphor (Olaf Kolkman)

  • Compare DNSSEC to a sealed transparent envelope.
  • The seal is applied by whoever closes the envelope
  • Anybody can read the message
  • The seal is applied to the envelope, not to the message

“The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.” (RFC 4033)

Verifying authentic answers

  • Authoritative servers:
    • Add digital signatures to resource record sets
    • Add public key to domain zone
  • Resolvers:
    • Validate the signatures to the public key
    • Only accept verified responses

Public key cryptography (RSA, DSA, (Elliptic Curve))

  • Private key for signing (protected and hidden)
  • Public key for verification (widely published)

Mini-howto (simplified)

  • Create the keypairs
  • Add the public keys to the zone
  • Sign the zone
  • Publish the signed zone
  • Notify parent
Building the chain of trust
Walking the chain of trust

Validating and resolving

  • Validating resolver needs configured trust anchors
    • Will only need the root zone key in the future
  • Possible types of answers (security status of data – RFC 4035)
    • secure – chain of trust is built from trust anchor
    • insecure – chain of trust can not be built from trust anchor (confirmed)
    • bogus – chain of trust should be built, but can not be built from trust anchor
    • indeterminate – unable to determine whether an RRset should be signed

Resolver will only answer queries that are secure or insecure.

ccTLD deployment forecast 31 December 2010

DNSSEC Software Tools are being developed and have become available:

  • OpenDNSSEC (www.opendnssec.org)
  • Signers: Secure64, Xelerance
  • PowerDNSSEC
  • Windows Server 2008 R2
  • other vendors have (announced) products

Resolver software widely available:

  • Unbound (NLnetLabs)
  • BIND 9.x and up
  • Windows Server 7

OpenDNSSEC OpenDNSSEC takes in unsigned zones, adds the signatures and other records for DNSSEC and passes it on to the authoritative name servers for that zone.

DNSSEC is complex

  • Operational issues
    • Domain transfers result in outage
    • Key rollovers need coördinated timing
    • Multiple scenario’s and policies at different parents
  • One size does not fit all
  • Small errors and bugs take time to resolve

DNSSEC does not

  • protect against packet sniffing
  • provide confidentiality
  • protect against DoS attacks (contrary)
  • protect against phishing, pharming, typosquatting

There will always be other risks!

No real alternatives

  • SSL / TLS
    • Doesn’t prevent cache-poisoning
    • Too heavy to be deployed for name servers
  • TSIG / SIG (0)
    • Not scalable (shared secrets)
    • Only secures transactions, not records
  • DNScurve
    • No operational implementation or widescale deployment yet


What you can do

  • Start resolving and validating DNSSEC
    • Gain early real-life DNSSEC experience
    • Detect and solve issues before the root is signed
  • Put DNSSEC-support in the requirements for new equipment
  • Plan for the future
  • Clean your house:
    • current DNS implementations and administration
    • network-components that impact DNS

Resources and further reading

Retrieved from "https://iiw.idcommons.net/index.php?title=DNSSEC&oldid=3465"