• Introduction to DNSSEC
• Measurement methodology
• Result analysis

• Resolves domain names to IP addresses
• ... and has various other uses
• Client/server ≙ resolver/nameserver
• Hierarchical namespace
• Resource records grouped into zones
• Zones served by nameservers
• Delegate subdomain to another nameserver

vs.uni-due.de.       IN  NS   dns1.vs.uni-due.de.
vs.uni-due.de.       IN  NS   dns2.vs.uni-due.de.

dns1.vs.uni-due.de.  IN  A    134.91.78.133
dns2.vs.uni-due.de.  IN  A    134.91.78.131

• Out-of-bailiwick cache poisoning

www.evil-attacker.net.   IN  NS   www.your-bank.com.
www.your-bank.com.       IN  A    6.6.6.6

• Mitigation: ignore out-of-bailiwick resource records
• Vulnerability: solved
• Remote UDP spoofing
• Mitigation: increase entropy in DNS query (transaction ID, source port)
• Vulnerability: expensive attack
• Local UDP spoofing
• Mitigation:
• Vulnerability: easy attack

• 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
• Root DNSKEY is known to the resolver

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  RRSIG DS 8 2 86400 20120812041548 2012080...

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

• CPU and network load increases
• Denial of service becomes easier (e.g. amplification attacks)
• Complexity increases → new bugs
• Rogue DNS redirects are impossible

• e.g. ISP redirecting to advertisement webpage
• e.g. government redirecting to censorship notice
• Administration errors lead to DNS outages

• Root zone is signed since July 2010
• 90/315 top-level domains are signed (29%) [1]
• 9 more are signed without delegation signer

• AD flag ≙ “server authenticated data successfully”
• like an inverted evil bit ☺ [8]
• secure last mile with other measures
• Validating resolver libs available
• hardly used yet
• Validating full-blown recursive nameservers available

• Number of DNSSEC-capable queries vs. total number of queries
• Estimated ~70% of resolvers at K-root support DNSSEC
• How many resolvers have validation enabled?

• 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 - - [07/May/2012:23:28:24 +0200] "GET /ok.png?aa53 HTTP/1.1" 200 413 "http://dnssec.vs.uni-due.de/" "Opera/9.80 (Windows NT 6.1; WOW64; U; en) Presto/2.10.229 Version/11.62"

07-May-2012 23:24:40.590 info: client 62.53.190.69#22782: query: aa53.sigok.verteiltesysteme.net IN A -ED (134.91.78.139)

• 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

• 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 and bad timing
• user closes browser tab prematurely and bad timing
• 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

test.dnssec-or-not.net. 60 IN CNAME 537e07e4883acd6e.dnssec-or-not.net.

• ID is unique to the resolver source IP address
• Resolves to an unsigned A record
• Despite DS record indicating a secure delegation
• A record points to webpage with negative result
• Validating resolver will discard response and retry
• After 3 queries a different A record is returned
• This time correctly signed
• Points to another webpage with positive result
• Static webpages (no JavaScript)

• JavaScript loads 1x1 pixel image from domain name ...
• ... containing a random ID
• ... and a valid signature
• Domain name resolves to the same A record
• But only validating resolvers query the DNSKEY record
• When image has been loaded, script queries server for result
• DNSKEY queried: validation enabled
• DNSKEY not queried: no validation

• Another simple test: http://www.dnssec-failed.org
• Website with broken signature
• Different results possible in mixed validation scenario:
• OS asks validating resolver first → returns failure
• OS falls back to non-validating secondary resolver → returns A record

• Posted in netsec group
• \(>\)1k participants in interactive test
• Autosurf traffic exchanges
• Automatically rotate websites in participants' web browsers
• Mostly unattended visits but in real user environment
• Very few also clicked interactive test
• Hidden test in websites hosted by us
• with webmaster's agreement
• Search engines and word of mouth

• Evaluated hidden test
• All participants of interactive test also loaded the hidden test
• 2.1M DNS/HTTP requests since May 2012
• Grouped by ID into Bernoulli trials
• Δtime between requests \(<\)30s
• 280k trials
• Valid trial requires:
• Both HTTP redirects
• DNS request for sigok and sigfail
• HTTP 1x1 image request from sigok

• 185k valid trials from 58k distinct IP addresses
• Causes for invalid trials:
• Same client visiting several pages + browser caching
• Redirects queried from different IP addresses
• Robots and other noise

• Stateless mapping of client IP address to ID hash
• 32 bit address space mapped to 16 bit ID space
• ID collisions at different times result in different trials → harmless
• ID collisions at the same time → trial useless
• Detect by comparing hash ID to client IP addresses
• Occurred in 11 trials (\(<\)0.01%)

• Both redirects must be queried from same IP address
• HTTP images may be queried from different IP addresses
• Detect by comparing hash ID to client IP addresses
• Occurred in 2.5k trials (1.4%)
• Pool of load-balanced robots or proxy servers
• Enterprise or carrier-grade NAT with multiple IP addresses

RedirOk[client=188.174.44.11[DE 188.174.*.* AS8767 ppp-188-174-44-11.dynamic.mnet-online.de]]
RedirFail[client=188.174.44.11[DE 188.174.*.* AS8767 ppp-188-174-44-11.dynamic.mnet-online.de]]
DNS[resolver=208.69.35.17[NL 208.69.32-36.* AS36692 m7.ams.opendns.com],hostname=sigfail,qtype=A]
DNS[resolver=208.69.35.17[NL 208.69.32-36.* AS36692 m7.ams.opendns.com],hostname=sigok,qtype=A]
SigOk[client=188.174.49.205[DE 188.174.*.* AS8767 ppp-188-174-49-205.dynamic.mnet-online.de]]
SigFail[client=188.174.49.205[DE 188.174.*.* AS8767 ppp-188-174-49-205.dynamic.mnet-online.de]]

• User-Agent differs between HTTP requests
• Occurred in 1.8k trials (1%) → filtered
• Harmless causes:
• User accesses website with two browsers in short time
• Different users behind same proxy IP address
• Browser add-ons doing their own HTTP requests
• Might miss a positive hit in certain situations:
• Two clients behind same NAT IP address using different resolvers
• Uncommon, but happened

• HTTP sigfail query not existing, indicating positive result
• DNSKEY query missing → false positive
• Occurred in 425 trials (0.2%)
• Comparable to estimated ratio of false positive
  
• Limitation: we correlate DNSKEY via IP address, not ID
• Might be a true positive in an uncommon scenario

• Consider each client IP address only once every 24h
• Filter consecutive trials by same client
• Occurred in 115k trials
• Overall: one or more filter conditions apply to 116k trials
• Remaining 69k trials from 54k distinct IP addresses

• 64k trials with HTTP referer

• Operating systems are not DNSSEC-capable (yet)
• Most recursive caches are DNSSEC-capable
• Conservative measurement methodology
• Mixed validating + non-validating resolver → negative result
• Potential false positives → filtered from results
• 69k trials after result cleanup
• 4.4% have validation enabled
• Significant differences per country

[1] ICANN: TLD DNSSEC Report (2012-08-08)

[2] Registro.br: Domínios Registrados por DPN (2012-08-09)

[3] VeriSign: Domains Secured with DNSSEC (2012-08-08)

[4] CZ.NIC: Statistics (2012-07-31)

[5] PowerDNS: Total number of DNSSEC delegations in the .NL zone (2012-08-09)

[6] SIDN: Statistics (2012-07-31)

[7] .SE: Domain Growth per Type (2012-08-09)

[8] S. Bellovin: The Security Flag in the IPv4 Header, RFC 3514 (2003-04-01)

[9] RIPE NCC: Status for k.root-servers.net (2012-08-09)