Embed Size (px)
Citation preview
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 parentmust not have the same label
edu gov mil no
uio ruter
…
…
"unnamed root"
…
…
…
mn
top-leveldomains
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
Imag
e So
urc
e: W
ikip
edia
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 of 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
of 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
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 familyIN the Internet system
CH the Chaos system
owner 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. forA 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.
owner 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
other nameservers
zonetransfer
gethostbyname
DNS protocol
other nameservers
19
DNS Services and Protocol
⚫ Resolution− Client request: recursive resolution,
i.e. let the name server scan other name serversand 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 ServerResolver
(Client)
Application
uioName Server
rootName Server
noName Server
mnName 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
mnName 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 forevil.net
(attacker)
DNS server(victim)
IP address forwww.evil.net ?
IPa
dd
ressfo
rw
ww
.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 forexample.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 forexample.com
DNS server(victim)
IP address forwww.example.com ?
IPa
dd
ressfo
rw
ww
.exam
ple.co
m ?
www.example.com: 10.9.8.7
ww
w.exa
mp
le.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 forexample.com
DNS server(victim)
IP address forwww.example.com ?
IPa
dd
ressfo
rw
ww
.exam
ple.co
m ?
www.example.com: 10.9.8.7
ww
w.exa
mp
le.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
orgedu 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 Tagexa-ksk
Public Key
DNSKEY
Key Tagexa-zsk
Public Key
RRSIG
Key Tagexa-ksk
Signature
RRSIG
Key Tagexa-zsk
Signature
RRSIG
Key Tagorg-zsk
Signature
NS
ns.example.org
.example.org A
250.0.0.1
ns.example.org DS
Key Tagexa-ksk
.example.org
A
250.0.0.8
www.example.org
Key Signing Key(Secure Entry Point) Zone Signing Key
DNSKEY
Key Tagorg-zsk
Public Key
Zone Signing Key
org-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
So
urc
e (E
xam
ple
): W
ikip
edia
name2 A 172.27.182.17RRSIG A 1 3 1000 20060616062444 (
20060517062444 9927 example.org.mMBIXxXU6…uv9aFcPaMyILJg== )
NSEC name4 A RRSIG NSECRRSIG 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
So
urc
e: h
ttp
s://
ww
w.in
tern
etso
ciet
y.o
rg/
DNSSEC: Deployment
42
So
urc
e: h
ttp
s://
sta
ts.la
bs.
apn
ic.n
et/d
nss
ec
DNSSEC: Deployment
43
So
urc
e: h
ttp
s://
sta
ts.la
bs.
ap
nic
.ne
t/d
nss
ec
(30
day
aver
ag
e (1
1/0
2/2
019
-12
/03
/20
19)
DNS Amplification Attack
DNS server
Client A(attacker)
Client B(victim)
AN
Y RR
ww
w.exa
mp
le.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
So
urc
e: h
ttp
s://
blo
g.cl
ou
dfl
are.
com
/rfc
8482
-say
ing
-go
od
bye
-to
-an
y/
DNS Amplification Attack(DNSSEC)
DNS server
Client A(attacker)
Client B(victim)
IP a
dd
ressfo
rw
ww
.exam
ple.co
m ?
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 or intelligence services)
49
Imag
e S
ou
rce:
htt
ps:
//h
ack
s.m
ozi
lla.o
rg/2
018
/05/
a-c
arto
on
-in
tro
-to
-dn
s-o
ver-
htt
ps/
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 existingWeb 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
Imag
e S
ou
rce:
Clo
ud
flar
e
