(In)security of DNS

... for laymen

• “Phone book” of the Internet
• Humans are bad with numbers, ...
• ... but okay with remembering names
• Computer networks operate on numbers
• DNS translates names into numbers
• + a lot of details

... for computer scientists

• Distributed key-value store
• Query-response protocol
• Hierarchical system
• Delegation of responsibility
• Efficient caching capabilities
• Robust and redundant
• Universal information database

Use-cases beyond name resolution

• Mail routing (MX, etc.)
• Trust anchor (X509, SSH, etc.)
• Policy statements for protocols (CAA, DMARC, etc.)
• Additional information (SRV, TXT, etc.)
• Blacklisting (spam mitigation, etc.)
• Malware detection
• Retrieve information (time, IP, Wikipedia, etc.)
• Identity management (ID4me, etc.)
• Channel to exfiltrate data

DNS in detail ...

Delegation

• Responsibility from top to bottom
• Zones are managed independently
• Start at the top (root) (.)
• Top-level domain (TLD) (.com, etc.)
• Second-level domain (SLD, 2LD) (example.com, etc.)
• Sub-domain (www.example.com, etc.)
• ...

Source: Wikipedia

Root name servers

• 13 name servers
• A, B, C, D, E, F, G, H, I, J, K, L, M
• Distributed via anycast
• Currently ~ 950 hosts
• Operated by 12 organizations (Verisign, ICANN, RIPE NCC, NASA, US Army Research Lab, etc.)
• More info: root-servers.org

Historic situation

Source: Wikipedia

Situation in 2006

Source: Wikipedia

Current situation

Source: root-servers.org

Current situation (Germany)

Source: root-servers.org

Second-level domains

• Operated by different (national) organizations
• Verisign, etc.
• DENIC for .de
• Access via registrar
• Delegation of domain to nameservers

Nameservers

• Authorative
• Non-authorative (recursive, iterative)
• (Stub)-Resolver
• Forwarder

Zonefile example

						
$TTL 86400
$ORIGIN example.com.
@   IN  SOA ns1.example.com. hostmaster.example.com. (
			      1  ; serial
			      3H ; refresh
			      15 ; retry
			      1w ; expire
			      3h ; nxdomain ttl
			     )
       IN  NS     ns1.example.com.
ns1    IN  A      192.168.0.1  ; name server
www    IN  A      192.168.0.3  ; web server
						
						

Resolver

• Performs actual name resolution
• Running “somewhere” in the network
• Most “complex” aspect of DNS
• Most endpoints are “stub” resolvers, ...
• ... which expect recursive name resolution

Typical DNS query

Caching

• Caching is inherently built into DNS
• Quick(er) response for common queries
• More users → faster responses
• All records can be cached (A, NS, etc.)
• Multi-level caching
• Upstream resolver → local resolver → OS → browser
• Negative results are also cached
• Timeouts are controlled via TTL

Redundancy & fail-over

• Multiple authorative nameservers
• One primary/master (SOA)
• Multiple secondaries/slaves (NS)
• Kept in sync via zone transfers
• Resolvers will choose nameserver randomly
• In case of failure: Resolvers will try next one

Load balancing

• DNS in itself is already load-balanced
• Multiple authorative nameservers
• DNS can also return multiple records for one query
• Can be used for load-balancing of other protocols

Cool records

• MX
• TXT
• SRV
• ...

Something is missing here ...

Source: memecenter.com

No security at all

• (Mostly) UDP based traffic
• No authentication
• No integrity
• No confidentiality
• No nothing ...

Source: me.me

Security nightmare

• DoS on DNS servers
• Reflection attacks (DDoS)
• Cache poisoning
• DNS hijacking
• Spoofing, suppression, manipulation
• Man-in-the-middle (redirects, phishing, etc.)
• No privacy at all
• ...

Spoofing / Man-in-the-Middle

• DNS responses can be manipulated
• TLS does not offer sufficient protection
• Some ISPs do this for non-existing domains
• “Hackers” do this for phishing / redirections, etc.

Cache poisoning

• Manipulation of DNS caches
• Does not require a MitM position
• Will affect all users of the resolver

Uncached DNS response

Source: Cloudflare

Cached DNS response

Source: Cloudflare

Cache poisoning attack

Source: Cloudflare

Poisoned cache

Source: Cloudflare

Cache poisoning

Historically, bad implemenation bugs, ...

• ... some resolvers accepted any records from additional section of a reply
• ... bad random values
• ... no source port randomization
• ... clever attacks with non-existing sub-domains (Dan Kaminsky, 2008)

Cache poisoning

• Root cause: Queries are based on UDP, ...
• ... unauthenticated data

Cache poisoning

Not a theoretical problem, ...

• “Hacking groups” → cybercrime
• State-sponsored by “bad“ actors ...

No privacy at all

• Traffic is unencrypted
• Lots of metadata (passive listening)
• Problematic on multiple levels
  • ISPs
  • DNS root servers
  • Service providers, e.g. Google, Cloudflare, etc.

Google DNS (8.8.8.8)

Source: xkcd.com/1361/

$ dig +short TXT google-public-dns-a.google.com
"http://xkcd.com/1361/"
						

• Fast Internet for everyone
• Many users, fast responses ...
• No censorship (?)
• Lots of “interesting” metadata
• Could (*) be used for tracking, etc.
• Same is true for Cloudflare, Quad 9, etc.
• ISPs typically see this traffic also ...

“Mitigations”

Source: memecenter.com

Source port randomization

• Use random source port (~ 16-bit)
• Should be unpredictable ...
• ... so attacker cannot know it in advance
• Only used after Kaminsky's attack in all implementations

Transaction IDs

• 16-bit value
• Should be unpredictable ...
• ... so attacker cannot know it in advance
• Included in queries
• Returned in responses
• However, birthday attack ...

DNS 0x20 encoding

• DNS records are case insensitive
• Resolver can query for WwW.ExAmplE.cOm
• Answer will be for www.example.com
• Response contains original query
• (Almost always) “copied over”

DNS 0x20 encoding

• Idea: Use lower and upper case as “key”
• Only real server will know the “secret”
• Additional channel for verification

DNS 0x20 encoding

named[572]: 192.168.1.24#54226: query: mAIl.EXAmPle.com IN A - (1.2.3.4)

DNS 0x20 encoding

• Not all characters are 0x20 capable
• Details are more complicatd
• Short domain names → little entropy
• Long domain names → no interest
• abc.de → 5 bits of entropy

QNAME minimisation

• RFC 7816
• March 2014
• Privacy improvement to DNS
• Do not send full query to upstream servers

Normal query

1. www.example.com
2. → .com
3. www.example.com
4. → example.com
5. www.example.com
6. → 1.2.3.4

Minimised query

1. .com
2. → .com
3. .example.com
4. → example.com
5. www.example.com
6. → 1.2.3.4

Improvement

Original query is not send to upstream servers

QNAME minimisation

• “Trivial” change to resolver
• No change to clients
• No change to protocol
• Issues in some cases
• Some privacy, no security
• “Improvement” after ~ 30 years

Domain Name System Security Extensions

• First RFCs ~ mid 1990s
• Authenticated records
• Based on digital signatures
• “Add-on” to DNS
• Backward compability

Interactive session ...

DNSSEC records

• RRSIG → Signature of ressource records
• DNSKEY → Public-key pair to sign/verify
• DS → Delegation Signer → “Hash of DNSKEY in parent zone”

“Cool” records

• DANE/TLSA
• SSHFP

NSEC

NSEC

• Existing records cannot be manipulated → Good
• What about suppression?
• How to prove that something does not exist?

NSEC

Idea: Present a signed list of all known records

						
    example.com. NSEC name1
    name1        NSEC name2
    name2        NSEC name5
    name5        NSEC example.com.
						
						

NSEC3

• New problem: Zone Walking
• New idea: Hash hostnames → NSEC3 record
• New record: NSEC3PARAM → Salt & iterations & flags

NSEC3 example

						
if810sjvea4lq2uk8b16062fs1q8lhkm.mozilla.org. NSEC3 1 0 1 54763C4B33523C7A IFJD7Q534M15M9HR20FROT0BI0LOPP4V A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
mozilla.org.	NSEC3PARAM 1 0 1 54763C4B33523C7A
						
						

Problems with NSEC3

• Weak hash algorithms
• Trade-off: Resolver vs. performance vs. slowdown
• Hardware-based hashing
• Common hostnames

Now the real fun begins ...

• Actually there are two different kind of keys

Zone Signing Key (ZSK)

• Usually shorter (e.g. 1024-bit RSA)
• Signed by KSK
• Recommendation: Monthly rollover

Key Signing Key (KSK)

• Usually longer (e.g. 2048-bit RSA)
• Recommendation: Yearly rollover
• Requires interaction with registrar (*)

• They need/should (*) be rotated regularly
• Failure in the process will put you offline

Root key rollover

• Original root key 2010
• Rollover planned for 2017
• Delay after some concerns in 2017
• High risk of “breaking the Internet”
• Rollover took place in 2018
• Went smoothly, only little higgups

Deployment rates

• Deployment rates of DNSSEC are low
• Depending on TLD ~ < 5%
• Resolvers validating DNSSEC ~ 10-20%

Validating resolvers, ...

• ... nice in theory
• break some use-cases, e.g. public WiFi hotspots
• Canoncial enabled it by default (in systemd-resolved)
• ... and disabled it again

[...], we found that 31% of domains that support DNSSEC fail to publish all relevant records [...] 39% of the domains use insufficiently strong key-signing keys; [...] 82% of resolvers in our study request DNSSEC records, only 12% of them actually attempt to validate them.

T Chung: A Longitudinal, End-to-End View of the DNSSEC Ecosystem (2017)

#FAIL

• Operating DNSSEC is hard
• Failures are bad → “offline”
• Major DNSSEC Outages and Validation Failures
  • Mozilla
  • DENIC
  • IETF
  • NASA
  • *.in-addr.arpa
  • opendnssec.org
  • ...

(Distributed) Denial-of-Service

• DNSSEC records are huge
• (Mostly) UDP
• Attractive for (reflected) DDoS
• No inherent protection
• Mitigations
  • No open recursors
  • Rate limiting
  • IP source validation

Proponent

• ICANN is always pushing for more DNSSEC deployment
• Dan Kaminsky is a big proponent of DNSSEC [1]

Critics

• Hanno Böck thinks DNSSEC failed and is useless [2]
• Dan J. Bernstein prefers DNSCurve over DNSSEC [3]

DNSSEC conclusion

• Crypto from the 1990s
• Deployment rates are very low
• Deployment (still) too difficult
• Full automation currently hard
• Some security, no privacy
• Enables cool features!
• Only game in town for authenticated DNS

The Last Mile ...

• (Typically) resolvers are not run locally
• Clients can ask for authenticated data via flag
• Clients can check for flag in replies
• Unprotected traffic from client ↔ resolver

Source: makeameme.org

Solutions / proposals / drafts

• DNS-over-TLS (DoT)
• DNS-over-HTTPS (DoH)
• DNSCrypt

DNS-over-TLS (DoT)

• Tunnel: client ↔ (local) resolver
• Based on (D)TLS
• Standardized port (853)
• Security gurantees from (D)TLS
  • Authentication
  • Confidentiality / Encryption / Privacy
  • Integrity

DNS-over-TLS (DoT)

• Easy to implement (stunnel, etc.)
• Well-understood protocol
• Lots of experience from TLS TLS (debugging, certificates, etc.)
• Available on Android, Linux, etc.

DNS-over-TLS (DoT)

• Tunnel is protected, but ...
• ... records itself are not authenticated
• Blocking is trivial
• Opportunistic vs. strict mode
• Certificate validation

DNS-over-HTTPS (DoH)

• Based on HTTPS (i.e. also TLS)
• Web technologies (JSON, URLs, etc.)
• Cannot be blocked “easily”
• Built into browsers (e.g. Firefox)

DNS-over-HTTPS (DoH)

• Main concern: Centralization
• Breaks some use-cases (split horizon, redirects with public WiFi, etc.)
• Works “around” system resolver
• Configuration might not be (easily) possible
• Some security products might no longer work, etc.

DNSCrypt

• First version(s) from ~ 2008
• Protection between client ↔ resolver
• Modern crypto, based on Curve25519
• No RFC, apparently no interested from IETF
• Only limited set of providers (OpenDNS, Quad9, etc.)

DNSCrypt drawbacks

• Requires special software
• Not widely available, compiled, packaged
• DNSCrypt-Proxy on the client
• DNSCrypt-Wrapper on the resolver
• Only limited number of providers (OpenDNS, Quad 9)

Source: heinlein-support.de

• Technology vs. policy/politics
• Details are important & complicated
• You need to trust someone
• Some parties might be more trustworthy than others

Registrar security

• Registrar: Key to the “kingdom”
• “Attacks” on registrars have picked-up, e.g. [1]
• Apparently state-sponsored attacks
• Secure password & 2-FA
• Registry lock for domains
• DNSSEC