Domain Name System (DNS) Learning Goal Foundations of DNS Security - - PowerPoint PPT Presentation

IN3210 – Network Security

Domain Name System (DNS)

Learning Goal

⚫ Foundations of DNS ⚫ Security in DNS:

− Integrity and Authenticity − Confidentiality

2

Foundations of DNS

3

Domain Name System

⚫ Directory services for name resolution ⚫ Requirements:

− support for “real” names (e.g. server01) and “logical” names (e.g. www.uio.no) − support for different kinds of services (e.g. mail) and address formats (e.g. IPv4, IPv6) − distributed data base − local cache

⚫ DNS:

− RFC 1034 − RFC 1035

Host name IP address

4

Name Space Definition

⚫ Domain Name Space

− tree structure − nodes have a "label": 1 – 63 byte − length of root node label = 0 − nodes with common parent must not have the same label

edu gov mil no uio ruter

… …

"unnamed root"

… …

… mn top-level domains

5

Name Space Definition

⚫ Terminology

− Domain Name

▪ dot-separated sequence of labels along path in the name space tree, read from leaf to root ▪ e.g. mn.uio.no

− Domain

▪ "A domain is identified by a domain name and consists of that part of the domain name space that is at or below the domain name which specifies the domain."

− Subdomain

▪ "A domain is a subdomain of another domain if it is contained within that

• domain. This relationship can be tested by seeing if the subdomain's

name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and ""."

6

Image Source: Wikipedia

Country Code TLDs (ccTLDs)

Generic TLDs (gTLDs)

⚫ „Classic“ gTLD:

− .com (commercial) − .edu (educational) − .org (non-commercial) − .arpa (incl. the reserved domain for reverse lookup: in-addr.arpa)

⚫ „New“ gTLDs:

− since 2012: hundreds of gTLDs (e.g. 50 from Amazon, 50 from Google) − Examples: .google, .fun, .berlin, .nyc, . ストア, 書籍

8

Name Space Definition

⚫ Zone concept

no uio

…

… mn

…

jus med

…

9

(mn is actually not an own zone; here just shown for the purpose

• f illustrating multiple zones inside an organization)

Name Space Definition

⚫ Zone concept

− A sub tree of the DNS tree can be defined as zone − A zone is managed by a single organization − A zone operates name server which store information on:

▪ DNS names inside that zone (“authoritative information”) ▪ Further zones “below” that zone (“glue records”)

− Example:

▪ NO zone ▪ Managed by Norid ▪ Manages all names inside the zone (e.g. www.nic.no) ▪ Contains information (“glue records”) on all zones below the NO node (i.e. all .no domains)

10

Name Space Definition

⚫ Responsible for “no" TLD: UNINETT Norid

11

Name Space Definition

⚫ Root name servers

− Root zone name servers hold a list of names and IP addresses

• f the name servers for all top-level domains (TLDs).

− TLD resolution requires using a root server to obtain the responsible authoritative server. − Currently (2019):

▪ 13 root name servers (with names in the form <letter>.root-servers.net, where <letter> ranges from A to M) ▪ operated by 12 independent root server operators ▪ 948 instances http://root-servers.org/

12

from http://root-servers.org/

13

Name Resolution

⚫ Name Servers

− Per zone: two name servers, "primary" and "secondary" − Names servers provide information per node of the related zone

▪ "authoritative data" for "own" zone ▪ "glue data" for querying name servers of delegated subzones

− Common data format (for storing and transmitting DNS data)

▪ Resource Records (RRs)

14

Name Resolution

⚫ Resource Records (RRs)

− common format

▪ owner domain name where the RR is found ▪ type encoded 16 bit value that specifies the RR type, e.g.

A a host address CNAME alias name ("canonical name") MX identifies a mail exchange for the domain NS authoritative name server for the domain SOA identifies the start of a zone of authority

▪ class encoded 16 bit value for a protocol family

IN the Internet system CH the Chaos system

• wner

type class TTL rdata

15

Name Resolution

⚫ Resource Records (RRs)

− common format

▪ TTL TTL (Time To Live) describes how long a RR can be cached before it should be discarded. ▪ RDATA type and sometimes class dependent data, e.g. for

A for the IN class: a 32 bit IP address MX a 16 bit preference value followed by a host name willing to act as a mail exchange for the owner domain. NS a host name.

• wner

type class TTL rdata

16

Name Resolution

⚫ Zone file

sample 1

$ORIGIN example.com. ; names not end in a trailing period (.) ; are appended with example.com. $TTL 2d ; default ttl @ IN SOA < some parameters > IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. IN A 10.0.1.5 server1 IN A 10.0.1.5 server2 IN A 10.0.1.7 dns1 IN A 10.0.1.2 dns2 IN A 10.0.1.3 ftp IN CNAME server1 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server2

Name Resolution

⚫ Zone file

sample 2

$ORIGIN example.com. $TTL 2d @ IN SOA < some parameters > IN NS ns1.example.com. IN NS ns2.example.com. IN MX 10 mail.example.com. ns1 IN A 192.168.0.3 ns2 IN A 192.168.0.4 mail IN A 192.168.0.5 ... ; we define two name servers for the "us" sub-domain $ORIGIN us.example.com. @ IN NS ns3.us.example.com. IN NS ns1.example.com. ; sub-domain address records for name server only - glue record ns3 IN A 10.10.0.24

DNS Services and Protocol

⚫ Name resolution interactions

Primary Name Server Secondary Name Server Resolver

(Client)

Cache Application

• ther name

servers zone transfer gethostbyname DNS protocol

• ther name

servers

19

DNS Services and Protocol

⚫ Resolution

− Client request: recursive resolution, i.e. let the name server scan other name servers and return a complete response − Name server to name server request: iterative resolution, i.e. name server collects (partial) responses from other name servers

20

DNS Services and Protocol

⚫ Name resolution interactions

Name Server Resolver

(Client)

Application uio Name Server root Name Server no Name Server mn Name Server ① ② ③ ④

no uio mn

recursive iterative

http://www.mn.uio.no/

21

List of root name servers

DNS Caching

⚫ Forwarding every request to the authoritative server would

produce a large amount of traffic

⚫ Every DNS resolver stores DNS responses in a local cache ⚫ Subsequent requests for same resource will be answered

from the cache

⚫ Entry is erased from the cache after expiration of TTL

22

Name Server mn Name Server

Name IP Expires ... ... ... www.mn.uio.no 129.240.118.130 2019-03-14 12:45:06 ... ... ...

DNS Service and Protocol

⚫ DNS protocol

− Query/Answer protocol − port 53 − TCP or UDP (most common)

23

DNS Service and Protocol

Other Ressource Records

⚫ TXT:

− Arbitrary text − Typical usage:

▪ SPAM interception (see chapter “email”) ▪ Domain verification (e.g. certificate registration, some enterprise services)

− Example:

uio.no. 43200 IN TXT "v=spf1 mx ip4:129.240.10.0/25 include:spf.uio.no ?all" uio.no. 43200 IN TXT "google-site-verification=cDsrExFpfrxrzZukaw2Pyi4J7nQ4Y" uio.no. 43200 IN TXT "dropbox-domain-verification=eovcv1nrw2n5" uio.no. 43200 IN TXT "University of Oslo, Norway"

⚫ PTR:

− Reverse lookup: IP address to DNS name

25

Security in DNS: Integrity and Authenticity

26

DNS Cache Poisoning

Client (maybe also the attacker) DNS server for evil.net (attacker) DNS server (victim)

IP address for www.evil.net ? IP address for www.evil.net? www.example.org: 10.1.2.3 www.evil.net: 10.1.2.4

Name IP Expires ... ... ... www.example.org 10.1.2.3 2019-03-14 12:45:06 ... ... ...

DNS server for example.org

27

DNS Cache Poisoning

⚫ Attack result:

− Legitimate DNS server stores (wrong) IP address for example.org until the TTL has expired − DNS request for example.org to this DNS server returns the wrong IP address − Client accessed the attacker’s server

⚫ Obstacle for this attack:

− Attacker must wait for a request for evil.net

⚫ Countermeasure:

− DNS resolver accepts only responses for requested names + siblings (e.g. request example.org, response www.example.org)

28

Client (attacker) DNS server for example.com DNS server (victim)

IP address for www.example.com ? IP address for www.example.com ? www.example.com: 10.9.8.7 www.example.com: 10.1.2.3

DNS Cache Poisoning

too late Using source IP address of A (IP spoofing)

A

29

DNS Cache Poisoning

⚫ Countermeasure:

− Query ID

▪ request and response must have same transaction ID

30

Client (attacker) DNS server for example.com DNS server (victim)

IP address for www.example.com ? IP address for www.example.com ? www.example.com: 10.9.8.7 www.example.com: 10.1.2.3

DNS Cache Poisoning

A

Must have same transaction ID

31

DNS Cache Poisoning

⚫ Countermeasure:

− Query ID

▪ request and response must have same query ID ▪ originally: ID is incremented for every request → easy to guess ▪ then (~ year 2000): ID is chosen randomly

⚫ Still attacks possible:

− “just” 216 possibilities − However: rather slow procedure for the attacker:

• 1. Send request
• 2. Guess query ID + send response
• 3. if wrong ID: authoritative response is in the cache

a) wait until cache has expired (between seconds and days) b) back to 1.

32

DNS Cache Poisoning

⚫ Dan Kaminsky attack (2008):

1. Send request for non-existing hostname (e.g. pqz123.example.org) 2. Guess query ID 3. Send response for targeted hostname (e.g. www.example.org) 4. If wrong ID: back to 1.

⚫ Effect:

− No storage in cache → high frequency of attacks

⚫ Countermeasure:

− Chose source UDP port randomly (previously always 53) − Now: 232 possibilities for query ID + source port − Attack harder, but still possible (e.g. distributed attack by botnet)

33

DNSSEC

⚫ Domain Name System Security Extensions ⚫ Goal: ensures authenticity and integrity of DNS records ⚫ History

− 1993: first discussions and requirement analysis in IETF − 1997/1999: first RFCs − 2005: complete new approach: RFCs 4033 – 4035 − 2010: DNSSEC supported by all root servers − 2013: Google Public DNS enables DNSSEC validation by default

34

DNSSEC

⚫ Basic idea: hierarchy of signed zones

• rg

edu gov mil example … … www

35

DNSSEC

⚫ Defines new RR types:

− DNSKEY:

▪ a public key

− DS:

▪ reference to a key in a sub-zone

− RRSIG:

▪ a digital signature

− NSEC, NSEC3:

▪ reference to „next“ existing name

36

.org. .example.org.

DNSKEY

Key Tag exa-ksk Public Key

DNSKEY

Key Tag exa-zsk Public Key

RRSIG

Key Tag exa-ksk Signature

RRSIG

Key Tag exa-zsk Signature

RRSIG

Key Tag

• rg-zsk

Signature

NS

ns.example.org

.example.org

A

250.0.0.1

ns.example.org

DS

Key Tag exa-ksk

.example.org

A

250.0.0.8

www.example.org Key Signing Key (Secure Entry Point) Zone Signing Key

DNSKEY

Key Tag

• rg-zsk

Public Key

Zone Signing Key

• rg-zsk

exa-ksk exa-zsk 250.0.0.8 (root)

37

DNSSEC: NSEC

⚫ What about responses to non-existing names?

− Must also be secured! − Signing „xyz does not exists“ during runtime too expensive − Instead: signed chain of all existing name − name1 → name2 → name4 → name5 → name1

Source (Example): Wikipedia

name2 A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 ( 20060517062444 9927 example.org. mMBIXxXU6…uv9aFcPaMyILJg== ) NSEC name4 A RRSIG NSEC RRSIG NSEC 1 3 10000 20060616062444 ( 20060517062444 9927 example.org. vlDpyqQF8b…QoBh4eGjbW49Yw== )

38

DNSSEC: NSEC

⚫ Example:

− Request: “name3” − Response: “name2 → name4” (signed)

⚫ Problem:

− Adversary can gradually learn all host names (“zone walking”)

39

DNSSEC: NSEC3

⚫ Calculating hash values of all existing names:

− h(name1) = 5238 − h(name2) = 1298 − h(name4) = 3056 − h(name5) = 2149

⚫ Creating and signing an ordered list of hash values:

− 1298 → 2149 → 3056 → 5238

⚫ Request:

− name3 with h(name3) = 4578

⚫ Response:

− 3056 → 5238 signed; proves that 4578 (i.e. name3) does not exist

40

DNSSEC: Deployment

41 Source: https://www.internetsociety.org/

DNSSEC: Deployment

42 Source: https://stats.labs.apnic.net/dnssec

DNSSEC: Deployment

43 Source: https://stats.labs.apnic.net/dnssec (30 day average (11/02/2019 - 12/03/2019)

DNS Amplification Attack

DNS server Client A (attacker) Client B (victim)

ANY RR www.example.com ?

IN NS ns1.example.com. IN NS ns2.example.com. IN MX 10 mail.example.com. ns1 IN A 192.168.0.3 ns2 IN A 192.168.0.4 mail IN A 192.168.0.5 ... ...

Using source IP address of B (IP spoofing)

44

45 Source: https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any/

DNS Amplification Attack (DNSSEC)

DNS server Client A (attacker) Client B (victim)

IP address for www.example.com ?

www A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 ( 20060517062444 9927 example.org. mMBIXxXU6…uv9aFcPaMyILJg== ) NSEC www2 A RRSIG NSEC RRSIG NSEC 1 3 10000 20060616062444 ( 20060517062444 9927 example.org. vlDpyqQF8b…QoBh4eGjbW49Yw== ) ...

Using source IP address of B (IP spoofing)

46

DNSSEC – Summary

⚫ Disadvantages:

− High complexity − Large response messages

▪ DNS amplification ▪ TCP instead of UDP

− Still no browser support − No confidentiality protection

⚫ Advantages:

− Stops DNS spoofing attacks − Can be used as trust anchor for PKIs (DANE)

47

Security in DNS: Confidentiality

48

Privacy Concerns

⚫ DNS messages are not protected from eavesdropping (even

with DNSSEC!)

⚫ DNS request are an easy way of tracking users (e.g. by the ISP

• r intelligence services)

49 Image Source: https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/

DoH and DoT

⚫ Two protocols for adding confidentiality to DNS:

− DNS over HTTPS (DoH) − DNS over TLS (DoT)

⚫ Creates a protected connection between DNS resolver and

DNS server

⚫ DoH vs. DoT

− DoT uses service specific port (853)

▪ might be filtered by firewall/attacker

− DoH uses standard HTTPS port (443)

▪ usually no filtering ▪ easy integration into existing Web server deployment

50

DNS over HTTPS DNS HTTP TLS TCP IP DNS over TLS DNS TLS TCP IP

DoH and DoT

⚫ Problem: Not very widespread ⚫ Possible solution: using public (recursive) name server:

− 8.8.8.8 (Google) − 1.1.1.1 (Cloudflare)

⚫ Remaining/new problems

− trust in DNS server required (even more data for Google?) − no “local” DNS entries (e.g. company Intranet)

⚫ Also a problem (or not?):

− No DNS blocking at the provider

51 Image Source: Cloudflare