DNS Security Issues NES 554 for DNS Security

2. 2
DNS: Domain Name System
People: many identifiers:
• SSN, name, passport #
Internet hosts, routers:
• IP address (32 bit) – 128.119.40.12
• unique ID
• “name”, e.g., www.yahoo.com - used by humans
Q: How to map between IP addresses and name ?
Domain Name System:
• distributed database implemented in hierarchy
of many name servers

3. 3
DNS
Why not centralize DNS?
• single point of failure
• traffic volume
• distant centralized
database
• maintenance
doesn’t scale!
DNS services
• Hostname to IP
address translation
• Host aliasing
• Canonical and alias
names
• Many names for a
single host
• Mail server aliasing
• Load distribution
• Replicated Web servers:
set of IP addresses for
one canonical name

4. 4
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
ucf.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers
Distributed, Hierarchical Database
Client wants IP for www.amazon.com:
• Client queries a root server to find com DNS server
• Client queries “com” DNS server to get amazon.com DNS server
• Client queries amazon.com DNS server to get IP address for
www.amazon.com

5. 5
DNS: Root name servers
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
(and 17 other locations)
i Autonomica, Stockholm (plus 3 other
locations)
k RIPE London (also Amsterdam, Frankfurt)
m WIDE Tokyo
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 11 locations)
13 root name
servers
worldwide

6. 6
TLD and Authoritative Servers
• Top-level domain (TLD) servers: responsible for
com, org, net, edu, etc, and all top-level country
domains uk, fr, ca, jp.
• Authoritative DNS servers: organization’s DNS
servers, providing authoritative hostname to IP
mappings for organization’s servers (e.g., Web
and mail).
• Can be maintained by organization or service
provider (paid by the organization)

7. 7
Local Name Server
• Does not strictly belong to hierarchy
• Each ISP (residential ISP, company, university)
has one
• Also called “default name server”
• When a host makes a DNS query, query is
sent to its local DNS server first
• Acts as a proxy (cache), forwards query into
hierarchy

8. 8
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS
server
local DNS server
dns.poly.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS
server
Iterative and Recursive queries
• Host at cis.poly.edu
wants IP address for
gaia.cs.umass.edu
• The query to root DNS
rarely happens due to
cache of all TLD DNS
information at local DNS
server
recursive
iterative

9. 9
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS
server
local DNS server
dns.poly.edu
1
2
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS
server
3
Recursive queries
recursive query:
• DNS client requires DNS
server respond with
either the requested
resource record, or an
error message stating that
the record or domain
name does not exist.
iterative query:
• contacted server replies
with name of server to
contact
• “I don’t know this name,
but ask this server” Reference:
http://technet.microsoft.com/en-us/library/cc961401.aspx

10. 10
DNS: caching and updating records
• once (any) name server learns mapping, it
caches mapping
• cache entries timeout (disappear) after some
time (keep fresh copy)
• TLD servers typically cached in local name
servers
• Thus root name servers not often visited]

11. 11
DNS records
DNS: distributed db storing Resource Records (RR)
Type=NS
• name is domain (e.g.
foo.com)
• value is IP address of
authoritative DNS server
for this domain
RR format: (name, value, type, ttl)
Type=A
 name is hostname
 value is IP address
Type=CNAME
 name is alias name for some
“canonical” (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
 value is canonical name
Type=MX
 value is name of mailserver
associated with name

12. 12
DNS protocol, messages
DNS protocol : query and reply messages, both with same
message format
msg header
• identification: 16 bit # for
query, reply to query uses
same #
• flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative

13. 13
DNS protocol, messages (UDP 53)
Name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used

14. Example
• Let’s check a web example using Wireshark!
• Check MX record:
• nslookup –type=MX just.edu.jo (Under Windows)
• dig mx just.edu.jo (Under Unix)
14

16. DNS main issues
• DNS amplification attacks
• Targeting Domain name system by DDoS attack
• DNS Man in the Middle Attack (redirection attack)
• DNS cache poisoning

17. DNS Security
17

18. Cybersquatting
• Cybersquatting is to register a domain in anticipation of
that domain being desirable to another organization
• Intent to sell to that organization for big profit
• For example, someone registers www.burjkhalifa.com,
since it was named at first www.burjdubai.com
• Sell it for big profit if it is true!
• Domain name purchase is cheap!
• Many organizations have to buy all related domain names
to prevent cybersquatting
• A legitimate example: http://teaparty.com/
• suspicious ones for tea party: http://tparty.com/, http://t-
party.com/
• http://en.wikipedia.org/wiki/Cybersquatting
18

19. Typosquatting
• Register all possible typo domain names for another
organization
• Should a user accidentally enter an incorrect website
address, he may be led to an alternative website owned by
a cybersquatter.
• Could lead to phishing attack (malicious), or increase web
visits (not very malicious)
• For example, for “bankofamerica.com”, a
cybersquatter could register:
• “bankamerica.com”, “bankoamerica.com”,
“bankofamerican.com”, “bankfoamerica.com”, ……
• Domain name purchase is cheap!
19

20. OS DNS Cache Privacy
• Windows OS maintain a local DNS cache
• Command “ipconfig/displaydns”
• DNS cache reveals a user’s browsing history
• Even if the user deletes browsing cache and cookies
• Internet Explorer does not have its own DNS cache
• Cross-platform browser, such as Firefox, has its own
DNS cache
20

22. Flush DNS cache

23. DNS Vulnerability
• Most DNS queries and responses are in plaintext
• No authentication is done for DNS response
• You really has no good way to tell if the DNS response
you get are trustable or not!
• DNS is mostly relying on UDP packets
• IP address spoofing is very easy for UDP packets
• No seq/ack numbers
23

24. DNS Redirection
• There are 3 main different ways to do DNS
redirection
• The first relies on redirecting the nameserver of the
attacker's domain to the nameserver of the target
domain, and then assigning this target nameserver a
fake IP address.
• The second variant relies on redirecting the nameserver
of another, unrelated domain to a fake nameserver.
• The third variant just involves “racing” the real
nameserver to give an answer.

25. DNS redirection
network
attacker
client local DNS
server
hub or
WiFi 1
2
1. Client sends DNS query to its local
DNS server; sniffed by attacker
2. Attacker responds with bogus
DNS reply
Issues:
• Must spoof IP address: set
to local DNS server (easy)
•Must match reply ID with
request ID (easy)
•May need to stop reply
from the local DNS server
(harder)

26. DNS Cache Poisoning
Basic idea: give DNS servers false records and get
it cached
DNS uses a 16-bit request identifier to pair
queries with answers
Cache may be poisoned when a name server:
 Disregards identifiers
 Has predictable ids
 Accepts unsolicited DNS records

27. DNS Cache Poisoning Procedure
• Eve wants to poison attack an ISP DNS server
• Eve transmits a DNS query to this server
• which in turn queries authoritative DNS on behalf of
Eve.
• Eve simultaneously sends a DNS response(reply)
to the server
• spoofing with the authoritative server’s IP
• The ISP’s DNS server accepts the forged response
and caches a wrong DNS entry
• All downstream users of this ISP will be directed to
the wrong website
27

28. Poisoning DNS Cache (1)
• Poisoning: Attempt to put bogus records into DNS
name server caches
• Bogus records could point to attacker nodes
• Attacker nodes could phish
• But unsolicited replies are not accepted at a name
server.
• Name servers use IDs in DNS messages to match replies to
queries
• So can’t just insert a record into a name server by sending a
DNS reply message.
• But can send a reply to a request.

29. Poisoning local DNS server (2)
Local DNS
Server (eg, Berkeley)
Attacker in
Australia:
17.32.8.9
1. DNS query
poly.edu=? 3. DNS reply
poly.edu=
17.32.8.9
2. iterative
DNS queries
authoritative
DNS for poly.edu
Goal: Put bogus IP address for poly.edu
in local Berkeley DNS server
1) Attacker queries local DNS server
2) Local DNS makes iterative queries
3) Attacker waits for some time;
sends a bogus reply, spoofing authoritative
server for poly.edu.

30. Poisoning local DNS server (3)
Poisoned local DNS
server (eg, Berkeley)
Attacker
in Australia
17.32.8.9
1. DNS query
ftp.poly.edu=?
2. DNS query
ftp.poly.edu=?
authoritative
DNS for poly.edu
DNS response can provide IP
address of malicious server!

31. DNS Poisoning (4)
• Issues:
• Attacker needs to know sequence number in
request message sent to upstream server
• Not easy!
• Attacker may need to stop upstream name
server from responding
• So that server under attack doesn’t get suspicious
• Ping of death, DoS, overflows, etc

32. DNS Cache Poisoning Prevention
• Use random identifiers for queries
• Make it hard to guess the ID number
• Always check identifiers
• Port randomization for DNS requests
• Deploy DNSSEC
• DNSSEC authenticates the resolution of IP
addresses with a cryptographic signature
• Discussed later!
• Challenging because it is still being deployed and
requires reciprocity

33. DNS Cache Poisoning against Query ID
• Even if a DNS server checks response IDs and use
random IDs, it is still vulnerable to the attack
• Attacker generates a flux of DNS requests and send the
corresponding flux of DNS response back
• If one of the pair has matched ID, the attack is successful
• Birthday Paradox: the prob. Of two persons in 23 people
share the same birthday is more than 50%!
33

34. Some Defenses
• Fact: Most DNS poisoning target local DNS (LDNS) server
• Solution: Configure LDNS to only accept requests from
internal networks
• Why does it need to serve outside users?
• Source-port randomization (SPR)
• DNS query sent out will have two randomized numbers:
• Source port number (destination port always 53)
• Query ID number (16 bits)
• Check DNS response for both of these numbers
34

35. DNSSEC
• Guarantees:
 Authenticity of DNS answer origin
 Integrity of reply
 Authenticity of denial of existence
• Accomplishes this by signing DNS replies at each step
of the way
• Uses public-key cryptography to sign responses
• Typically use trust anchors, entries in the OS to
bootstrap the process

36. DNS Signing
Hard-coded with
TLD’s public keys
TLDs serve as
Certificate Authority

37. DNSSEC Deployment
• As the internet becomes regarded as critical
infrastructure there is a push to secure DNS
• NIST is in the process of deploying it on root servers
now
• May add considerable load to dns servers with packet
sizes considerably larger than 512 byte size of UDP
packets
• There are political concerns with the US controlling the
root level of DNS

38. DDos DNS Attack
• Oct 21, 2002
• Ping packets sent from bots to the 13 DNS root servers. Goal:
bandwidth flood servers
• Minimal impact:
• DNS caching
• rate limiting at upstream routers: filter ping when they arrive at an
excessive rate
• During attack, some networks filtered pings; corresponding root
servers remained up.
• Root server attack is easy to defend: download root server database to
local (default) name servers
• Not much data in root server; changes infrequently
• TLD servers are more volatile
• Similar kind of attack in May 2004, Feb 2007

39. DNS attacks: Summary
• DNS is a critical component of the Internet
infrastructure
• But is surprisingly robust:
• DDoS attacks against root servers have been largely
unsuccessful
• Poisoning and redirection attacks are difficult unless
you can sniff DNS requests
• And even so, may need to stop DNS servers from replying
• DNS can be leveraged for reflection attacks
against non-DNS nodes