Name resolution and performance of DNS
Nigel Walker Raffaele Giaffreda Marc Wennink
BT Advanced Communications Technology Centre Adastral Park
Reasons for studying DNS - 1
• Today
– can be limiting factor in WWW page retrieval
• where does the time go?
– increasing functionality and information load
• dynamic DNS + DHCP, IP6 • entry point to other name systems • security
– main global name resolution system today
Reasons for studying DNS - 2
• Tomorrow
– name resolution a recurring fundamental theme
• URI, URL, URN, DOI, HFN • Java, Corba objects • LDAP / X.500 directories, DEN
– increasing data churn
• personal mobility • object mobility
– ‘resolutions per click’ increasing
• XML
Reasons for studying DNS - 3 edge v.s. core functionality
Applications
www browser message client
Applications
mail servers inter-network routing multi-tasking
www caching DNS
network interface GUI
transport link framing line coding
command interface file driver
Operating system
Network operator
DNS structure
root “.”
Name Servers
edu com primary NS for: edu secondary NS for: edu
org
mil gov
berkeley.edu
primary NS for: berkeley.edu secondary NS for: edu
Resolver
www.berkeley.edu secondary NS for: berkeley.edu
name space
resolving infrastructure 128.32.25.12
www.berkeley.edu ===>
Resolving internet query
2) query for www.bt.co.uk
root name server
3) referral to uk name servers
4) query for www.bt.co.uk
“uk” name server “co.uk” name server
5) referral to co.uk name servers
1) query for www.bt.co.uk
local name server
6) query for www.bt.co.uk
7)
10) 193.113.210.25
8)
resolver
9) 193.113.210.25
“bt.co.uk” name server
“Axion” authoritative for bt.co.uk
Flat tree structure
Steps to reach name server % name servers 60 40 20 0 1 steps 2 steps 3 steps 4 steps5+ steps
Resolution times
1 0.8 0.6 0.4
3 step 1 step 2 step
0.2 0 0.1 1 10 100
4 step
1000
Resolution time (seconds)
Where does the time go?
• Timeouts
– packet loss
• Number of hops
– caching – tree structure
decreasing contribution to delay
• Network and server service times
– link and server load
• Speed of light
– geographical distance
Network congestion
Packet loss rate: DNS 55% Ping 50%
1 Cumulative distribution 0.8 0.6 0.4 0.2 0 0 100 200 300 400 500 Resolution time (ms) ping nslookup
Nameserver overload
Packet loss rate: DNS 62% Ping 33%
1 Cumulative distribution 0.8 0.6 0.4 0.2 0 0 500 1000 1500 2000 2500 3000 Resolution time (ms) ping nslookup
Speed of light delay
Packet loss rate: DNS 0% Ping 0%
1 Cumulative distribution 0.8 0.6 0.4 0.2 0 0 100 200 300 400 500 Resolution time (ms) ping nslookup
Expected effects of transport layer dimensioning
• Timeouts
– less frequent, shorter
• Queuing time (routers, servers)
– network delay reduces (bounded delay QoS) – Nameserver delay reduces
• Number of hops
– becomes less important compared to ...
• Speed of light
– total distance travelled by query
Other performance factors
• Caching
– reduces number of hops – effective for large TTL (ie. nameservers) – cached data reflects user interest
• Zone replication
– mainly for resilience at present – geographical distribution and load balancing – dynamic DNS will make zone replication management easier – 13 root servers
Caching: an example
resolver 110
users 60 120 70 100 root com bt edu mit hp root
edu
100
com
100
time 10 20 30 60
request bt.com mit.edu mit.edu hp.com
queries root, com, bt.com root, edu, mit.edu mit.edu com, hp.com com, bt.com
mit
50
hp
40
bt
50
70 bt.com
Zone replication tree
8
2
5 10
1 1
3
2
Traffic “push” request 125 99 0 10 30 40 60
2
1
2
1
3 6
1
3
3
2 2 2
2
5
77 64
3 distance 10 change rate 2 request rate
2
2 42
Trade-off between total network traffic and request latency
• Minimise total network traffic while satisfying a latency constraint • Limits regardless of distribution mechanism • Useful for testing different protocols
600
Traffic size
400 Pull Push Total traffic
200
0 0 50 100 Latency 150 200
Name resolution futures: some speculation
• Heterogeneous
– more namespaces, more names
• Stable nameservers migrate to core network
– Dimensioned bandwidth
• Geographical distance
– path of requests – latency – transmission costs
Name routing?
Iterative requests
root
edu com
• as performed by local name server • analogous to hop by hop transmission
isi bt isi.edu.root
Recursive requests
root
edu com
• requires low loss • not necessarily bandwidth efficient
isi bt isi.edu.root
Forwarded requests
root
edu com
• efficient use of transmission • requires low loss per request • not part of standard DNS
isi bt isi.edu.root
Routing through namespace
root
edu com ‘hint’ isi bt isi.edu.root ‘hint’
IP routing v.s. Name routing!
Network port target Runs over subnets Next hop router Large fan-out Sparsely populated namespace Routing protocols, tables Slowly varying paths and destinations Autonomous systems ⇔Digital object target ⇔Runs over IP ⇔ Next hop nameserver ⇔ Massive fan-out (106) ⇔ Even more sparsely populated namespace ⇔ Zone replication, glue ⇔ Dynamic paths and destinations ⇔ Autonomous namespaces
Research avenues
• Name properties for different ‘resources’
– human / machine readable – persistent / volatile
• Resolution infrastructure(s)
– replication protocols and strategies – geographic request routing – interworking of subspaces
• Abstract formulations
– information flows – programming perspectives
Conclusions - 1 DNS performance
• Currently limited by packet loss and timeouts • Transport QoS could optimise partition of DNS/WWW bandwidth • Nameserver function similar to router • Collection of nameservers looks like a packet network
Conclusions - 2 Name resolution
• Fundamental component of distributed systems
– information rather than location is the target
• Open issue as to whether any unifying infrastructure could be built
– Wide spectrum of options from existing DNS to overlay ‘name routing’ structure
• Incorporate geography somehow
– efficient use of transport infrastructure – minimises packet loss
• Storing addresses and names of objects could be a future core infrastructure role
Zone distribution mechanisms
Information source at fixed location Legacy of DNS authoritative server Distribution tree
Replication groups Gossip architecture Modification to any server
IP multicast
IP multicast