CSE 390 – Advanced
Computer Networks
Lecture 10: DNS
(What’s in a Name?)
Based on Slides by D. Choffnes (NEU). Revised by P. Gill
Fall 2014. Some content on DNS censorship from N.
Weaver.
Administravia
2
 Midterm: 1 week from today
 Study guide posted on Piazza
Layer 8 (The Carbon-based
nodes)
3
 If you want to…
 Call someone, you need to ask for their phone number
 You can’t just dial “P R O F G I L L ”
 Mail someone, you need to get their address first
 What about the Internet?
 If you need to reach Google, you need their IP
 Does anyone know Google’s IP?
 Problem:
 People can’t remember IP addresses
 Need human readable names that map to IPs
Internet Names and Addresses
4
 Addresses, e.g. 220.231.93.18
 Computer usable labels for machines
 Conform to structure of the network
 Names, e.g. www.iuh.edu.vn
 Human usable labels for machines
 Conform to organizational structure
 How do you map from one to the other?
 Domain Name System (DNS)
History
5
 Before DNS, all mappings were in hosts.txt
 /etc/hosts on Linux
 C:WindowsSystem32driversetchosts on Windows
 Centralized, manual system
 Changes were submitted to SRI via email
 Machines periodically FTP new copies of hosts.txt
 Administrators could pick names at their discretion
 Any name was allowed
 alans_server_at_sbu_pwns_joo_lol_kthxbye
Towards DNS
6
 Eventually, the hosts.txt system fell apart
 Not scalable, SRI couldn’t handle the load
 Hard to enforce uniqueness of names
 e.g MIT
 Massachusetts Institute of Technology?
 Melbourne Institute of Technology?
 Many machines had inaccurate copies of hosts.txt
 Thus, DNS was born
 DNS Basics
 DNS Security
 DNS and Censorship
Outline
7
DNS at a High-Level
8
 Domain Name System
 Distributed database
 No centralization
 Simple client/server architecture
 UDP port 53, some implementations also use TCP
 Why?
 Hierarchical namespace
 As opposed to original, flat namespace
 e.g. .com  google.com  mail.google.com
Naming Hierarchy
9
 Top Level Domains (TLDs) are at
the top
 Maximum tree depth: 128
 Each Domain Name is a subtree
 .edu  neu.edu  ccs.neu.edu 
www.ccs.neu.edu
 Name collisions are avoided
 neu.com vs. neu.edu
Root
edu com gov mil org
net uk fr etc.
neu mit
ccs ece husky
www login mail
Hierarchical Administration
10
 Tree is divided into zones
 Each zone has an administrator
 Responsible for the part of the
hierarchy
 Example:
 CCIS controls *.ccs.neu.edu
 NEU controls *.neu.edu
Root
edu com gov mil org
net uk fr etc.
neu mit
ccs
www login mail
ICANN
Verisign
Server Hierarchy
11
 Functions of each DNS server:
 Authority over a portion of the hierarchy
 No need to store all DNS names
 Store all the records for hosts/domains in its zone
 May be replicated for robustness
 Know the addresses of the root servers
 Resolve queries for unknown names
 Root servers know about all TLDs
 The buck stops at the root servers
Root Name Servers
12
 Responsible for the Root Zone File
 Lists the TLDs and who controls them
 ~272KB in size
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
 Administered by ICANN
 13 root servers, labeled AM
 6 are anycasted, i.e. they are globally replicated
 Contacted when names cannot be resolved
 In practice, most systems cache this information
Map of the Roots
13
Northeastern
Local Name Servers
14
 Each ISP/company has a local, default name server
 Often configured via DHCP
 Hosts begin DNS queries by contacting the local
name server
 Frequently cache query results
Where is
google.com?
Authoritative Name Servers
15
 Stores the nameIP mapping for a given host
Northeastern
Where is
www.neu.edu?
Root edu neu
www.neu.edu
Authority for
‘neu.edu’
www.neu.edu
= 155.33.17.68
Authority
for ‘edu’
Basic Domain Name Resolution
16
 Every host knows a local DNS server
 Sends all queries to the local DNS server
 If the local DNS can answer the query, then you’re
done
1. Local server is also the authoritative server for that
name
2. Local server has cached the record for that name
 Otherwise, go down the hierarchy and search for
the authoritative name server
 Every local DNS server knows the root servers
 Use cache to skip steps if possible
Recursive DNS Query
17
 Puts the burden of
resolution on the contacted
name server
 How does asgard know who
to forward responses too?
 Random IDs embedded in
DNS queries
Root
com
ns1.google.com
www.google.com
asgard.ccs.neu.edu
Where is www.google.com?
Iterated DNS query
18
 Contact server replies
with the name of the
next authority in the
hierarchy
 “I don’t know this name,
but this other server
might”
 This is how DNS works
Root
com
ns1.google.com
www.google.com
asgard.ccs.neu.edu
Where is www.google.com?
DNS Propagation
19
 How many of you have purchased a domain name?
 Did you notice that it took ~72 hours for your name to
become accessible?
 This delay is called DNS Propagation
Root com
ns.godaddy.com
www.my-new-site.com
asgard.ccs.neu.edu
 Why would this process fail for a new DNS name?
Caching vs. Freshness
20
 DNS Propagation delay is caused by caching
asgard.ccs.neu.edu
• Cached Root Zone File
• Cached .com Zone File
• Cached .net Zone File
• Etc.
Root
com
ns.godaddy.com
www.my-new-site.com
Where is
www.my-new-site.com?
That name
does not exist.
 Zone files may be
cached for 1-72 hours
DNS Resource Records
21
 DNS queries have two fields: name and type
 Resource record is the response to a query
 Four fields: (name, value, type, TTL)
 There may be multiple records returned for one query
 What do the name and value mean?
 Depends on the type of query and response
DNS Types
22
 Type = A / AAAA
 Name = domain name
 Value = IP address
 A is IPv4, AAAA is IPv6
 Type = NS
 Name = partial domain
 Value = name of DNS
server for this domain
 “Go send your query to
this other server”
Query
Name: www.ccs.neu.edu
Type: A
Resp.
Name: www.ccs.neu.edu
Value: 129.10.116.81
Query Name: ccs.neu.edu
Type: NS
Resp.
Name: ccs.neu.edu
Value: 129.10.116.51
DNS Types, Continued
23
 Type = CNAME
 Name = hostname
 Value = canonical
hostname
 Useful for aliasing
 CDNs use this
 Type = MX
 Name = domain in email
address
 Value = canonical name
of mail server
Query
Name: foo.mysite.com
Type: CNAME
Resp.
Name: foo.mysite.com
Value: bar.mysite.com
Query Name: ccs.neu.edu
Type: MX
Resp.
Name: ccs.neu.edu
Value: amber.ccs.neu.edu
Reverse Lookups
24
 What about the IPname mapping?
 Separate server hierarchy stores reverse mappings
 Rooted at in-addr.arpa and ip6.arpa
 Additional DNS record type: PTR
 Name = IP address
 Value = domain name
 Not guaranteed to exist
for all IPs
Query Name: 129.10.116.51
Type: PTR
Resp.
Name: 129.10.116.51
Value: ccs.neu.edu
DNS as Indirection Service
25
 DNS gives us very powerful capabilities
 Not only easier for humans to reference machines!
 Changing the IPs of machines becomes trivial
 e.g. you want to move your web server to a new host
 Just change the DNS record!
Aliasing and Load Balancing
26
 One machine can have many aliases
www.reddit.com
www.foursquare.com
www.huffingtonpost.com *.blogspot.com
david.choffnes.com
alan.mislo.ve
 One domain can map to multiple machines
www.google.com
Content Delivery Networks
27
DNS responses may
vary based on
geography, ISP, etc
 DNS Basics
 DNS Security
 DNS and Censorship
Outline
28
The Importance of DNS
29
 Without DNS…
 How could you get to any websites?
 You are your mailserver
 When you sign up for websites, you use your email
address
 What if someone hijacks the DNS for your mail server?
 DNS is the root of trust for the web
 When a user types www.bankofamerica.com, they
expect to be taken to their bank’s website
 What if the DNS record is compromised?
Denial Of Service
30
 Flood DNS servers with requests until they fail
 October 2002: massive DDoS against the root
name servers
 What was the effect?
 … users didn’t even notice
 Root zone file is cached almost everywhere
 More targeted attacks can be effective
 Local DNS server  cannot access DNS
 Authoritative server  cannot access domain
DNS Hijacking
31
 Infect their OS or browser with a virus/trojan
 e.g. Many trojans change entries in /etc/hosts
 *.bankofamerica.com  evilbank.com
 Man-in-the-middle
 Response Spoofing
 Eavesdrop on requests
 Race the servers response – Useful for censorship
dns.bofa.com
DNS Spoofing
32
123.45.67.89
Where is
bankofamerica.com?
dns.evil.com
66.66.66.93
123.45.67.89
Where is
bankofamerica.com?
How do you know that a given
nameIP mapping is correct?
66.66.66.93
DNS Cache Poisoning
33
 Until the TTL expires, all queries for BofA to
dns.neu.edu will return poisoned result
 Much worse than spoofing/man-in-the-middle
 Whole ISPs can be impacted!
ns1.google.com
dns.neu.edu
Where is
www.google.com? www.google.com =
74.125.131.26
bankofamerica.com
= 66.66.66.92
Where is
bankofamerica.com?
How will the attacker get his entry into
the cache? 2 ways
34
 1. Tell resolver that NS for victim is at adversary’s
IP
 Issue query: subdomain.attacker.example IN A
 Attacker’s response:
 Answer: (no response)
 Authority Section: attacker.example. 3600 IN NS
ns.target.example.
 Additional Section: ns.target.example. IN A w.x.y.z
Adversary says “authoritative server for my
domain is ns.target.example and oh by the way
here is the IP for it (adversary’s IP)
How will the attacker get his entry into
the cache? 2 ways
35
 2. Redirect the NS record to the adversary’s
domain
 Issue query: subdomain.attacker.example IN A
 Answer: (no response)
 Authority section:
 Target.example. 3600 IN NS ns.attacker.example.
 Additional section:
 Ns.attacker.example. IN A w.x.y.z
The attacker has inserted an unrelated piece of
information that will be cached by the server
(that target.example.’s ADNS is
Solution: DNSSEC
36
 Cryptographically sign critical resource records
 Resolver can verify the cryptographic signature
 Two new resource types
 Type = DNSKEY
 Name = Zone domain name
 Value = Public key for the zone
 Type = RRSIG
 Name = (type, name) tuple, i.e. the query itself
 Value = Cryptographic signature of the query results
 Deployment
 On the roots since July 2010
 Verisign enabled it on .com and .net in January 2011
 Comcast is the first major ISP to support it (January 2012)
Prevents hijacking
and spoofing
Creates a hierarchy of
trust within each zone
DNSSEC Hierarchy of Trust
37
dns.bofa.com
Where is
bankofamerica.com?
IP: 123.45.67.89
Key: < >
SIG: x9fnskflkalk
.com (Verisign)
Root Zone (ICANN)
dns.evil.com
IP: 66.66.66.93
Key: < >
SIG: 9na8x7040a3
Does DNSSEC Solve all our
problems?
38
 No.
 DNS still vulnerable to reflection attacks + injected
responses
DNS Reflection
39
 Very big incident in 2012
 (http://blog.cloudflare.com/65gbps-ddos-no-problem/)
 65 Gbps DDoS
 Would need to compromise 65,000 machines each with 1
Mbps uplink
 How was this attack possible?
 Use DNS reflection to amplify a Botnet attack.
 Key weak link: Open DNS resolvers will answer
queries for anyone http://openresolverproject.org/
So how does this work?
40
 Remember: DNS is UDP
 No handshaking between endpoints
 I can send a DNS query with a forged IP address
and the response will go to that IP address
 Secret sauce: a small request that can elicit a large
response
 E.g., query for zone files, or DNSSEC records (both
large record types).
 Botnet hosts spoof DNS queries with victim’s IP
address as source
 Resolver responds by sending massive volumes of
data to the victim
DNS amplification illustrated
41
Hosts infected by botnet
Open Resolver Victim
Src: Victim
Dst: Open Resolver
DNS …
Src: Victim
Dst: Open Resolver
DNS …
Sometimes the DNS resolver
network thinks it is under attack by
the victim!!
Amplification not unique to DNS
42
 NTP is the latest protocol to be used in this way:
 http://www.prolexic.com/news-events-pr-threat-
advisory-ddos-ntp-amplification.html
 (Exploiting NTP Monlist command which returns a
list of 600 most recent hosts to connect to the NTP
server)
 DNS Basics
 DNS Security
 DNS and Censorship
Outline
43
DNS and Censorship
• DNS is a popular protocol for targeting by Internet
censors
 A few things to keep in mind …
• No cryptographic integrity of DNS messages
• DNSSEC proposed but not widely implemented
• Caching of replies means leakage of bad DNS
data can persist
Blocking DNS Names
• Can the censor pressure the registrar?
Name blocked, forever
Blocking DNS Names
 Can the censor pressure the ISPs?
 Just force an entry in the recursive resolver to poison
results for a given domain
 Clients can trivially evade this using alternate DNS
services
 E.g., Google’s 8.8.8.8
 …but this does require client changes
 Also, ISPs must not block third party DNS queries for
this to work
 Initially used by ISPs in the UK to block the Pirate
Bay
This diagram assumes ISP
DNS Server is complicit.
DNS Server
(2.1.2.3)
Types of false DNS responses
Home connection
(2.1.2.4)
3rd Party DNS Server
(8.8.8.8)
DNS QTYPE A
www.censored.com
NXDOMAIN
DNS RESPONSE A
127.0.0.1
DNS RESPONSE A
192.168.5.2
DNS RESPONSE A
159.106.121.75
Block page server
(192.168.5.2)
DNS RESPONSE A
1.2.3.5
(correct IP)
Blocking DNS names
• Option A: get ISP resolver on board
• (Previous slide)
• Option B: On-path packet injection
• Censor injects a DNS response that races the legitimate
reply
• Can be mostly countered with DNS-hold-open:
• Don’t take the first answer but instead wait for up to a
second
• Generally reliable when using an out of country recursive
resolve (e.g., 8.8.8.8, censor packet should win the race)
• Can be completely countered by DNS-hold-open +
DNSSEC
Reading from Web …
 Hold-On: Protecting Against On-Path DNS
Poisoning, H. Duan, N. Weaver, Z. Zhao, M. Hu, J. Liang, J. Jiang, K.
Li, and V. Paxson.
• Idea: Once you receive a DNS packet, wait for a
predefined “hold-on” period before accepting the
result.
• DNSSEC is still vulnerable to these injected packets
and does not make hold-on unneccessary
• Censor can just inject a reply with an invalid
signature: client will reject (denial of service)
• Method: Use active measurements to determine
Hold-on in action
Checking feasibility: RTT
Checking feasibility: ttl
Performance of Hold-on
Lesson: You don’t have to wait that long to get the legitimate reply
Much More to DNS
54
 Caching: when, where, how much, etc.
 Other uses for DNS (i.e. DNS hacks)
 Content Delivery Networks (CDNs)
 Different types of DNS load balancing
 Dynamic DNS (e.g. for mobile hosts)
 DNS and botnets
 Politics and growth of the DNS system
 Governance
 New TLDs (.xxx, .biz), eliminating TLDs altogether
 Copyright, arbitration, squatting, typo-squatting

Dns

  • 1.
    CSE 390 –Advanced Computer Networks Lecture 10: DNS (What’s in a Name?) Based on Slides by D. Choffnes (NEU). Revised by P. Gill Fall 2014. Some content on DNS censorship from N. Weaver.
  • 2.
    Administravia 2  Midterm: 1week from today  Study guide posted on Piazza
  • 3.
    Layer 8 (TheCarbon-based nodes) 3  If you want to…  Call someone, you need to ask for their phone number  You can’t just dial “P R O F G I L L ”  Mail someone, you need to get their address first  What about the Internet?  If you need to reach Google, you need their IP  Does anyone know Google’s IP?  Problem:  People can’t remember IP addresses  Need human readable names that map to IPs
  • 4.
    Internet Names andAddresses 4  Addresses, e.g. 220.231.93.18  Computer usable labels for machines  Conform to structure of the network  Names, e.g. www.iuh.edu.vn  Human usable labels for machines  Conform to organizational structure  How do you map from one to the other?  Domain Name System (DNS)
  • 5.
    History 5  Before DNS,all mappings were in hosts.txt  /etc/hosts on Linux  C:WindowsSystem32driversetchosts on Windows  Centralized, manual system  Changes were submitted to SRI via email  Machines periodically FTP new copies of hosts.txt  Administrators could pick names at their discretion  Any name was allowed  alans_server_at_sbu_pwns_joo_lol_kthxbye
  • 6.
    Towards DNS 6  Eventually,the hosts.txt system fell apart  Not scalable, SRI couldn’t handle the load  Hard to enforce uniqueness of names  e.g MIT  Massachusetts Institute of Technology?  Melbourne Institute of Technology?  Many machines had inaccurate copies of hosts.txt  Thus, DNS was born
  • 7.
     DNS Basics DNS Security  DNS and Censorship Outline 7
  • 8.
    DNS at aHigh-Level 8  Domain Name System  Distributed database  No centralization  Simple client/server architecture  UDP port 53, some implementations also use TCP  Why?  Hierarchical namespace  As opposed to original, flat namespace  e.g. .com  google.com  mail.google.com
  • 9.
    Naming Hierarchy 9  TopLevel Domains (TLDs) are at the top  Maximum tree depth: 128  Each Domain Name is a subtree  .edu  neu.edu  ccs.neu.edu  www.ccs.neu.edu  Name collisions are avoided  neu.com vs. neu.edu Root edu com gov mil org net uk fr etc. neu mit ccs ece husky www login mail
  • 10.
    Hierarchical Administration 10  Treeis divided into zones  Each zone has an administrator  Responsible for the part of the hierarchy  Example:  CCIS controls *.ccs.neu.edu  NEU controls *.neu.edu Root edu com gov mil org net uk fr etc. neu mit ccs www login mail ICANN Verisign
  • 11.
    Server Hierarchy 11  Functionsof each DNS server:  Authority over a portion of the hierarchy  No need to store all DNS names  Store all the records for hosts/domains in its zone  May be replicated for robustness  Know the addresses of the root servers  Resolve queries for unknown names  Root servers know about all TLDs  The buck stops at the root servers
  • 12.
    Root Name Servers 12 Responsible for the Root Zone File  Lists the TLDs and who controls them  ~272KB in size com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net.  Administered by ICANN  13 root servers, labeled AM  6 are anycasted, i.e. they are globally replicated  Contacted when names cannot be resolved  In practice, most systems cache this information
  • 13.
    Map of theRoots 13
  • 14.
    Northeastern Local Name Servers 14 Each ISP/company has a local, default name server  Often configured via DHCP  Hosts begin DNS queries by contacting the local name server  Frequently cache query results Where is google.com?
  • 15.
    Authoritative Name Servers 15 Stores the nameIP mapping for a given host Northeastern Where is www.neu.edu? Root edu neu www.neu.edu Authority for ‘neu.edu’ www.neu.edu = 155.33.17.68 Authority for ‘edu’
  • 16.
    Basic Domain NameResolution 16  Every host knows a local DNS server  Sends all queries to the local DNS server  If the local DNS can answer the query, then you’re done 1. Local server is also the authoritative server for that name 2. Local server has cached the record for that name  Otherwise, go down the hierarchy and search for the authoritative name server  Every local DNS server knows the root servers  Use cache to skip steps if possible
  • 17.
    Recursive DNS Query 17 Puts the burden of resolution on the contacted name server  How does asgard know who to forward responses too?  Random IDs embedded in DNS queries Root com ns1.google.com www.google.com asgard.ccs.neu.edu Where is www.google.com?
  • 18.
    Iterated DNS query 18 Contact server replies with the name of the next authority in the hierarchy  “I don’t know this name, but this other server might”  This is how DNS works Root com ns1.google.com www.google.com asgard.ccs.neu.edu Where is www.google.com?
  • 19.
    DNS Propagation 19  Howmany of you have purchased a domain name?  Did you notice that it took ~72 hours for your name to become accessible?  This delay is called DNS Propagation Root com ns.godaddy.com www.my-new-site.com asgard.ccs.neu.edu  Why would this process fail for a new DNS name?
  • 20.
    Caching vs. Freshness 20 DNS Propagation delay is caused by caching asgard.ccs.neu.edu • Cached Root Zone File • Cached .com Zone File • Cached .net Zone File • Etc. Root com ns.godaddy.com www.my-new-site.com Where is www.my-new-site.com? That name does not exist.  Zone files may be cached for 1-72 hours
  • 21.
    DNS Resource Records 21 DNS queries have two fields: name and type  Resource record is the response to a query  Four fields: (name, value, type, TTL)  There may be multiple records returned for one query  What do the name and value mean?  Depends on the type of query and response
  • 22.
    DNS Types 22  Type= A / AAAA  Name = domain name  Value = IP address  A is IPv4, AAAA is IPv6  Type = NS  Name = partial domain  Value = name of DNS server for this domain  “Go send your query to this other server” Query Name: www.ccs.neu.edu Type: A Resp. Name: www.ccs.neu.edu Value: 129.10.116.81 Query Name: ccs.neu.edu Type: NS Resp. Name: ccs.neu.edu Value: 129.10.116.51
  • 23.
    DNS Types, Continued 23 Type = CNAME  Name = hostname  Value = canonical hostname  Useful for aliasing  CDNs use this  Type = MX  Name = domain in email address  Value = canonical name of mail server Query Name: foo.mysite.com Type: CNAME Resp. Name: foo.mysite.com Value: bar.mysite.com Query Name: ccs.neu.edu Type: MX Resp. Name: ccs.neu.edu Value: amber.ccs.neu.edu
  • 24.
    Reverse Lookups 24  Whatabout the IPname mapping?  Separate server hierarchy stores reverse mappings  Rooted at in-addr.arpa and ip6.arpa  Additional DNS record type: PTR  Name = IP address  Value = domain name  Not guaranteed to exist for all IPs Query Name: 129.10.116.51 Type: PTR Resp. Name: 129.10.116.51 Value: ccs.neu.edu
  • 25.
    DNS as IndirectionService 25  DNS gives us very powerful capabilities  Not only easier for humans to reference machines!  Changing the IPs of machines becomes trivial  e.g. you want to move your web server to a new host  Just change the DNS record!
  • 26.
    Aliasing and LoadBalancing 26  One machine can have many aliases www.reddit.com www.foursquare.com www.huffingtonpost.com *.blogspot.com david.choffnes.com alan.mislo.ve  One domain can map to multiple machines www.google.com
  • 27.
    Content Delivery Networks 27 DNSresponses may vary based on geography, ISP, etc
  • 28.
     DNS Basics DNS Security  DNS and Censorship Outline 28
  • 29.
    The Importance ofDNS 29  Without DNS…  How could you get to any websites?  You are your mailserver  When you sign up for websites, you use your email address  What if someone hijacks the DNS for your mail server?  DNS is the root of trust for the web  When a user types www.bankofamerica.com, they expect to be taken to their bank’s website  What if the DNS record is compromised?
  • 30.
    Denial Of Service 30 Flood DNS servers with requests until they fail  October 2002: massive DDoS against the root name servers  What was the effect?  … users didn’t even notice  Root zone file is cached almost everywhere  More targeted attacks can be effective  Local DNS server  cannot access DNS  Authoritative server  cannot access domain
  • 31.
    DNS Hijacking 31  Infecttheir OS or browser with a virus/trojan  e.g. Many trojans change entries in /etc/hosts  *.bankofamerica.com  evilbank.com  Man-in-the-middle  Response Spoofing  Eavesdrop on requests  Race the servers response – Useful for censorship
  • 32.
    dns.bofa.com DNS Spoofing 32 123.45.67.89 Where is bankofamerica.com? dns.evil.com 66.66.66.93 123.45.67.89 Whereis bankofamerica.com? How do you know that a given nameIP mapping is correct? 66.66.66.93
  • 33.
    DNS Cache Poisoning 33 Until the TTL expires, all queries for BofA to dns.neu.edu will return poisoned result  Much worse than spoofing/man-in-the-middle  Whole ISPs can be impacted! ns1.google.com dns.neu.edu Where is www.google.com? www.google.com = 74.125.131.26 bankofamerica.com = 66.66.66.92 Where is bankofamerica.com?
  • 34.
    How will theattacker get his entry into the cache? 2 ways 34  1. Tell resolver that NS for victim is at adversary’s IP  Issue query: subdomain.attacker.example IN A  Attacker’s response:  Answer: (no response)  Authority Section: attacker.example. 3600 IN NS ns.target.example.  Additional Section: ns.target.example. IN A w.x.y.z Adversary says “authoritative server for my domain is ns.target.example and oh by the way here is the IP for it (adversary’s IP)
  • 35.
    How will theattacker get his entry into the cache? 2 ways 35  2. Redirect the NS record to the adversary’s domain  Issue query: subdomain.attacker.example IN A  Answer: (no response)  Authority section:  Target.example. 3600 IN NS ns.attacker.example.  Additional section:  Ns.attacker.example. IN A w.x.y.z The attacker has inserted an unrelated piece of information that will be cached by the server (that target.example.’s ADNS is
  • 36.
    Solution: DNSSEC 36  Cryptographicallysign critical resource records  Resolver can verify the cryptographic signature  Two new resource types  Type = DNSKEY  Name = Zone domain name  Value = Public key for the zone  Type = RRSIG  Name = (type, name) tuple, i.e. the query itself  Value = Cryptographic signature of the query results  Deployment  On the roots since July 2010  Verisign enabled it on .com and .net in January 2011  Comcast is the first major ISP to support it (January 2012) Prevents hijacking and spoofing Creates a hierarchy of trust within each zone
  • 37.
    DNSSEC Hierarchy ofTrust 37 dns.bofa.com Where is bankofamerica.com? IP: 123.45.67.89 Key: < > SIG: x9fnskflkalk .com (Verisign) Root Zone (ICANN) dns.evil.com IP: 66.66.66.93 Key: < > SIG: 9na8x7040a3
  • 38.
    Does DNSSEC Solveall our problems? 38  No.  DNS still vulnerable to reflection attacks + injected responses
  • 39.
    DNS Reflection 39  Verybig incident in 2012  (http://blog.cloudflare.com/65gbps-ddos-no-problem/)  65 Gbps DDoS  Would need to compromise 65,000 machines each with 1 Mbps uplink  How was this attack possible?  Use DNS reflection to amplify a Botnet attack.  Key weak link: Open DNS resolvers will answer queries for anyone http://openresolverproject.org/
  • 40.
    So how doesthis work? 40  Remember: DNS is UDP  No handshaking between endpoints  I can send a DNS query with a forged IP address and the response will go to that IP address  Secret sauce: a small request that can elicit a large response  E.g., query for zone files, or DNSSEC records (both large record types).  Botnet hosts spoof DNS queries with victim’s IP address as source  Resolver responds by sending massive volumes of data to the victim
  • 41.
    DNS amplification illustrated 41 Hostsinfected by botnet Open Resolver Victim Src: Victim Dst: Open Resolver DNS … Src: Victim Dst: Open Resolver DNS … Sometimes the DNS resolver network thinks it is under attack by the victim!!
  • 42.
    Amplification not uniqueto DNS 42  NTP is the latest protocol to be used in this way:  http://www.prolexic.com/news-events-pr-threat- advisory-ddos-ntp-amplification.html  (Exploiting NTP Monlist command which returns a list of 600 most recent hosts to connect to the NTP server)
  • 43.
     DNS Basics DNS Security  DNS and Censorship Outline 43
  • 44.
    DNS and Censorship •DNS is a popular protocol for targeting by Internet censors  A few things to keep in mind … • No cryptographic integrity of DNS messages • DNSSEC proposed but not widely implemented • Caching of replies means leakage of bad DNS data can persist
  • 45.
    Blocking DNS Names •Can the censor pressure the registrar? Name blocked, forever
  • 46.
    Blocking DNS Names Can the censor pressure the ISPs?  Just force an entry in the recursive resolver to poison results for a given domain  Clients can trivially evade this using alternate DNS services  E.g., Google’s 8.8.8.8  …but this does require client changes  Also, ISPs must not block third party DNS queries for this to work  Initially used by ISPs in the UK to block the Pirate Bay
  • 47.
    This diagram assumesISP DNS Server is complicit. DNS Server (2.1.2.3) Types of false DNS responses Home connection (2.1.2.4) 3rd Party DNS Server (8.8.8.8) DNS QTYPE A www.censored.com NXDOMAIN DNS RESPONSE A 127.0.0.1 DNS RESPONSE A 192.168.5.2 DNS RESPONSE A 159.106.121.75 Block page server (192.168.5.2) DNS RESPONSE A 1.2.3.5 (correct IP)
  • 48.
    Blocking DNS names •Option A: get ISP resolver on board • (Previous slide) • Option B: On-path packet injection • Censor injects a DNS response that races the legitimate reply • Can be mostly countered with DNS-hold-open: • Don’t take the first answer but instead wait for up to a second • Generally reliable when using an out of country recursive resolve (e.g., 8.8.8.8, censor packet should win the race) • Can be completely countered by DNS-hold-open + DNSSEC
  • 49.
    Reading from Web…  Hold-On: Protecting Against On-Path DNS Poisoning, H. Duan, N. Weaver, Z. Zhao, M. Hu, J. Liang, J. Jiang, K. Li, and V. Paxson. • Idea: Once you receive a DNS packet, wait for a predefined “hold-on” period before accepting the result. • DNSSEC is still vulnerable to these injected packets and does not make hold-on unneccessary • Censor can just inject a reply with an invalid signature: client will reject (denial of service) • Method: Use active measurements to determine
  • 50.
  • 51.
  • 52.
  • 53.
    Performance of Hold-on Lesson:You don’t have to wait that long to get the legitimate reply
  • 54.
    Much More toDNS 54  Caching: when, where, how much, etc.  Other uses for DNS (i.e. DNS hacks)  Content Delivery Networks (CDNs)  Different types of DNS load balancing  Dynamic DNS (e.g. for mobile hosts)  DNS and botnets  Politics and growth of the DNS system  Governance  New TLDs (.xxx, .biz), eliminating TLDs altogether  Copyright, arbitration, squatting, typo-squatting

Editor's Notes

  • #54 Potential project, create a browser plug in that implements hold-on.