• Introduction to DNSSEC
• Measurement methodology
• Result analysis

• Domain Name System Security Extensions
• Uses cryptography to achieve data integrity and authenticity
• Note: not confidentiality, not availability
• Sign resource records with private key
• Publish signatures as RRSIG record

example.net.   IN  A     1.2.3.4
example.net.   IN  RRSIG A 5 3 600 20120519... m1TWzfNDMg8NpgTo4i...

• Publish public key as DNSKEY record

example.net.   IN  DNSKEY   256 3 8 BQEAAAABv5hDo9fIU91cSFaDmnNPg...

• Tie DNSKEY with parent zone to create chain of trust

• DS record for secure delegation
• Indicates whether child zone is signed
• Contains hash of DNSKEY
• DS record is signed, too
• Resolver must know a trust anchor (root key) beforehand

verteiltesysteme.net.     IN  NS    ns1.verteiltesysteme.net.
verteiltesysteme.net.     IN  NS    ns2.verteiltesysteme.net.
verteiltesysteme.net.     IN  DS    61908 5 1 3497D121F4C91369E95DC73D8...
verteiltesysteme.net.     IN  DS    61908 5 2 2F87866A60C3603F447658AC3...
verteiltesysteme.net.     IN  RRSIG DS 8 2 86400 20130103051550 2012122...

ns1.verteiltesysteme.net. IN  A     134.91.78.139
ns2.verteiltesysteme.net. IN  A     134.91.78.141

verteiltesysteme.net.     IN  DNSKEY 257 3 5 BQEAAAABy5oBPRz/mSEcFYXlcL...

• Signed zone verteiltesysteme.net
• Domain name sigok with valid signature
• Domain name sigfail with broken signature
• Two web-based resolver tests (interactive, hidden)

• Client-side JavaScript and images
• Load image from sigfail domain name
• Success: no DNSSEC validation
• Failure: go ahead
• Load image from sigok domain name
• Success: DNSSEC validation enabled
• Failure: inconclusive result
• Result is shown to the user and
  POSTed to our webserver

• Load transparent 1x1 pixel images from sigok and sigfail
• Static HTML snippet (no JavaScript)

<img src="http://dnssec.vs.uni-due.de/r/a" alt="" height="1" width="1">
<img src="http://dnssec.vs.uni-due.de/r/b" alt="" height="1" width="1">

• HTTP and DNS requests logged and evaluated offline

• Correlate client with resolver IP address in different server logfiles

77.181.135.120 "GET /ok.png?aa53 HTTP/1.1" 200 413

62.53.190.69#22782: query: aa53.sigok.verteiltesysteme.net IN A -ED

• HTTP redirect to http://ID.sigok.verteiltesysteme.net/ok.png?ID
• Where ID \(:=\) hex(SHA256(client_ip))[0:4]
• Stateless mapping of client IP address to 16 bit ID
• Unlikely to collide at the same time with different clients
• Pre-generated zone with \(2^{19}\) resource record (88 MB)
• Delivers broken signatures without nameserver adaptation
• Vanilla zone layout

• sigfail might fail to load for unrelated reasons → false positive
• Require loading sigok to exclude some fault sources, e.g.:
• failing to receive EDNS0 messages with packet size \(>\)512 bytes
• not loading images or not following cross-domain HTTP redirects
• Some fault sources remain, e.g.:
• network fault
• user closes browser tab prematurely
• Another possible fault: sigfail loads, sigok fails
• Harmless invalid result (false negatives are not possible)
• Same fault pattern like a false positive (occurs with non-validators only) → estimate ratio of false positives

• 4.6M DNS/HTTP requests since May 2012
• Grouped by ID into 562k Bernoulli trials
• Δtime between requests \(<\)30s
• Required requests:
• Both HTTP redirects
• DNS request for sigok and sigfail
• HTTP 1x1 image request from sigok
• DNSSEC validation enabled:
• no sigfail HTTP query OR
• all DNS queries without DNSSEC OK flag

• Removed 203k incomplete trials
• Same client visiting several pages + browser caching
• Redirects queried from different IP addresses
• Robots and other noise

• Seemingly positive result but DNSKEY query is missing
• Indicates false positive
• Occurred in 521 trials (0.14%), comparable to estimate
• Limitation: we correlate DNSKEY via IP address, not ID
• Might be a true positive in forwarding scenario

• Filter positive result when DNSKEY is missing (0.14%)
• Filter duplicate results per IP address within 12h (49.5%)
• Count each client once per browsing session
• For dynamic IP addresses, count different clients on same address
• Xie (2007): time interval between two users on same dynamic IP is \(>\)12h in 80% of all cases
• Filter ID hash collisions (\(<\)0.01%)
• Different client IP addresses with same ID

• No AS is fully protected by DNSSEC
• Most validating clients rely on their AS operator for DNS resolution

• Web clients protected by DNSSEC validation

• Analysis of partial network traces of top-level domain servers
• Gudmundsson for .org in 2010/2011 (0.8% validating resolvers)
• Fujiwara for .jp in Feb 2012 (10.000 validating resolvers)
• Web-based tests
• Wessels (VeriSign): analysis of resolver query pattern
• SIDN: checks whether DNSKEY query occurred

• Download anonymized result set: http://dnssec.vs.uni-due.de
• Willing to contribute?
• Point your friends to our website
• Add HTML snippet to your website
• Some clients use mixed validating and non-validating resolvers
• Get SERVFAIL from validator, fall back to non-validator
• Our test yields negative result in case of mixed validation
• Except when application aborts waiting for name resolution