Velocity 2013: Resolution For A Faster Site

Preview:

DESCRIPTION

Akamai's Ido Safruti talks about how DNS affects page load time, and shares his analysis and best practices on newer and less discussed protocols like IPv6, DNSSEC and the impact of open resolvers. To watch the presentation: http://www.youtube.com/watch?v=tshzqEKRFI0

Citation preview

Resolution for a Faster Site

How DNS Affects Page Load Time

Ido Safrutiido@akamai.comWeb Performance Products, Akamai

©2013 AKAMAI | FASTER FORWARDTM

I will not talk about

• DNS pre-fetching (its great, use it!)• Optimizing for # of domains• Other FEO stuff• The pain of redirects on mobile, and HTTPS

©2013 AKAMAI | FASTER FORWARDTM

I’ll also won’t be talking about

Daddy’s Nasty Sons

©2013 AKAMAI | FASTER FORWARDTM

Why is DNS important?

©2013 AKAMAI | FASTER FORWARDTM

http://www.flickr.com/photos/doe-oakridge/8773404536/

The phonebook of the Internet

©2013 AKAMAI | FASTER FORWARDTM

http://www.flickr.com/photos/melissavenable/5422775934/

We just assume it always works

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

Location of DNS root servers, including anycast nodes, identified by their one-letter names. (2008)

©2013 AKAMAI | FASTER FORWARDTM

Resource records

• TTLs• Common types:• A• AAAA• CNAME• NS

• A/AAAA can have multiple records• More on that later

• Results can be different in different locations/times

http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records

©2013 AKAMAI | FASTER FORWARDTM

Let’s see some Data

©2013 AKAMAI | FASTER FORWARDTM

Getaddrinfo() times, Chrome

Windows: upward blip of 1.45% of samples in around 1s (95.90 percentile), due to Windows DNS retransmission timer.Mac: 2 upward blips: 2.11% in around 300ms (91.51 percentile), and another of 1.07% at 1s (97.36 percentile), due to retransmission timers.Linux: upward blip of 1.81% in around 4250-4900ms (99.26 percentile).

OS Mean 10% 25% 50% 75% 90%

Windows 644 <=1 12 43 119 372

Mac 230 0 5 28 67 279

Linux 293 2 12 37 89 279

Source: Will Chan, http://goo.gl/ByZmX Mar 15, 2012

©2013 AKAMAI | FASTER FORWARDTM

DNS failure - Mac

Device: Mac OSX 10.8.4 (mountain lion), Safari 6.0.5Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 1 -> DNS1 (retransmit) 3 -> DNS2 1 -> DNS2 (retransmit) 3 -> DNS3 1 -> DNS3 (retransmit) 3 -> DNS1 9 -> DNS1 (retransmit)---- 21

©2013 AKAMAI | FASTER FORWARDTM

DNS failure - WindowsDevice: Windows 7 (IE9)Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 1 -> DNS2 1 -> DNS3 2 -> DNS1, DNS2, DNS3 4 -> DNS1, DNS2, DNS3 4 -> DNS1 1 -> DNS3 1 -> DNS2 2 -> DNS1, DNS2, DNS3 4 -> DNS1, DNS2, DNS3---- 24

©2013 AKAMAI | FASTER FORWARDTM

Nav Timing data

©2013 AKAMAI | FASTER FORWARDTM

DNS time vs page load time

Source: Akamai RUM data

0 - 10 msec

10 - 25 msec

25 - 50 msec

50 - 75 msec

75 - 100

msec

100 - 200

msec

200 - 300

msec

300 - 400

msec

400 - 500

msec

500 - 600

msec

600 - 700

msec

700 - 800

msec

800 - 900

msec

900 - 1000 msec

> 1000 msec

0.0%

5.0%

10.0%

15.0%

20.0%

25.0%

0

2000

4000

6000

8000

10000

12000

14000D

NS

Tim

e D

istr

ibu

tion P

ag

e L

oa

d T

ime

©2013 AKAMAI | FASTER FORWARDTM

DNS time by browser type

Source: Akamai RUM data

Only hits with a base page download time <= 169ms

p25_dns median_dns p75_dns p90_dns0

100

200

300

400

500

600

700

ChromeFirefoxInternet ExplorerAndroid WebkitChrome MobileIEMobile

©2013 AKAMAI | FASTER FORWARDTM

DNS by Continent

AS SA NA EU OC AF0

200

400

600

800

1000

1200

1400

1600

DNS by Continent, base page <= 169ms

p25_dnsmedian_dnsp75_dnsp90_dns

SA AS NA EU OC AF0

200

400

600

800

1000

1200

1400

1600

DNS by Continent, all

p25_dnsmedian_dnsp75_dnsp90_dns

©2013 AKAMAI | FASTER FORWARDTM

Distance of users from resolvers – method 1

OC:6.5%

AF:6.9%

SA: 5.0%AS:6.25%

EU: 0.9%>2000 miles NA: 1.9%

July 2012, Akamai

©2013 AKAMAI | FASTER FORWARDTM

Distance of users from resolvers – method 2

OC: 6.8%

AF: 7.3%

SA: 4.7%AS: 5.4%

EU: 1.4%>2000 miles NA: 1.7%

July 2012, Akamai

©2013 AKAMAI | FASTER FORWARDTM

DNS usageAlexa Top 10,000 DNS Marketshare - May 6, 2013

Provider Rank

Websites (out of 10,000)

Marketshare

Marketshare Change

DynECT 1 440 4.40% +6 / +1.382%

AWS Route 53 2 381 3.81% 14 / 3.815%

UltraDNS 3 361 3.61% -2 / -0.551%

DNSPod 4 336 3.36% 5 / 1.511%

CloudFlare 5 314 3.14% 23 / 7.904%

GoDaddy DNS 6 287 2.87% -10 / -3.367%

DNS Made Easy 7 246 2.46% 0

Akamai 8 217 2.17% 10 / 4.831%

Rackspace Cloud DNS 9 156 1.56% -2 / -1.266%

Verisign DNS 10 106 1.06% 5 / 4.95%

Softlayer DNS 11 79 0.79% 0

Namecheap 12 76 0.76% 0

easyDNS 13 76 0.76% -1 / -1.299%

Enom DNS 14 66 0.66% -1 / -1.493%

Cotendo Advanced DNS 15 47 0.47% -11 / -18.966%

Savvis 16 42 0.42% 0

Nettica 17 30 0.30% 0

ZoneEdit 18 29 0.29% 0

Internap 19 27 0.27% 0

ClouDNS 20 21 0.21% 3 / 16.667%

DNS Park 21 17 0.17% 1 / 6.25%

No-IP 22 12 0.12% 0

Zerigo DNS 23 10 0.10% 0

EuroDNS 24 7 0.07% 0

Worldwide DNS 25 5 0.05% -1 / -16.667%

DTDNS 26 2 0.02% 0

CDNetworks DNS 27 2 0.02% 1 / 100%

Total 339233.92

%

Source: Cloud Harmony

9 of top 10 run their own DNS.

The only one that doesn’t?

Hint: they have a DNS service

Amazon.com

©2013 AKAMAI | FASTER FORWARDTM

Fortune 500 DNS Marketshare - May 6, 2013

Provider Rank

Websites (out of 500)

Marketshare

Marketshare Change

UltraDNS 1 36 7.20% 1 / 2.857%Verisign DNS 2 24 4.80% 0Akamai 3 13 2.60% 0DynECT 4 8 1.60% 0DNS Made Easy 5 6 1.20% 0Savvis 6 4 0.80% 0GoDaddy DNS 7 4 0.80% 0Internap 8 4 0.80% 0Rackspace Cloud DNS 9 2 0.40% 0AWS Route 53 10 2 0.40% 0easyDNS 11 1 0.20% 0No-IP 12 1 0.20% 0Enom DNS 13 1 0.20% 0ZoneEdit 14 1 0.20% 0

Total   10721.40

%

Alexa Top 1,000 DNS Marketshare - May 6, 2013

Provider Rank

Websites (out of 1,000)

Marketshare

Marketshare Change

DynECT 1 79 7.90% 0

UltraDNS 2 63 6.30% 1 / 1.613%

Akamai 3 48 4.80% 0

AWS Route 53 4 34 3.40% -1 / -2.857%

DNSPod 5 32 3.20% 0

DNS Made Easy 6 21 2.10% 0

GoDaddy DNS 7 14 1.40% 0

Cotendo Advanced DNS 8 11 1.10% -1 / -8.333%

Verisign DNS 9 10 1% 0

easyDNS 10 10 1% 0

CloudFlare 11 8 0.80% 1 / 14.286%

Rackspace Cloud DNS 12 7 0.70% 0

Namecheap 13 6 0.60% 0

Softlayer DNS 14 5 0.50% 0

Enom DNS 15 5 0.50% 0

Internap 16 3 0.30% 0

Savvis 17 3 0.30% 0

Nettica 18 2 0.20% 0

ClouDNS 19 2 0.20% 0

ZoneEdit 20 2 0.20% 0

DTDNS 21 1 0.10% 0

EuroDNS 22 1 0.10% 0

No-IP 23 1 0.10% 0

Worldwide DNS 24 1 0.10% 0

Total   36936.90

%  

Source: Cloud Harmony

©2013 AKAMAI | FASTER FORWARDTM

Source: Catchpoint DNS direct agents, testing the [ab].ns.facebook.com name servers

Asia stats influenced by China

©2013 AKAMAI | FASTER FORWARDTM

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

IPv6

http://www.flickr.com/photos/yukop/7350636534/

©2013 AKAMAI | FASTER FORWARDTM

Standard request flow

-> Request A record-> Request AAAA record<- Receive CNAME/A record<- Recursively resolve

Resolver (caching) will send full recursive in a single response.Host will cache each record with appropriate TTLApps/Browser – receives host/IP, but no TTL.

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack DNS behavior - basics

OS: Windows XP 5.1.2600 Service Pack 3 Connection: tcpopen foo.rd.td.h.labs.apnic.net

Time (ms) Packet Activity

0 → DNS Query for AAAA record foo.rd.td.h.labs.apnic.net 581 ← AAAA response 2a01:4f8:140:50c5::69:72 4 → DNS Query for A record for foo.rd.td.h.labs.apnic.net 299 ← A response 88.198.69.81 3 → SYN to 2a01:4f8:140:50c5::69:72 280 ← SYN + ACK response from 2a01:4f8:140:50c5::69:72 1 → ACK to 2a01:4f8:140:50c5::69:72 ------ 1168

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack DNS behavior - basics

OS: Mac OSX 10.8.4 (mountain lion) Connection: tcpopen foo.rd.td.h.labs.apnic.net

Time (ms) Packet Activity

0 → DNS Query for A record for foo.rd.td.h.labs.apnic.net 0 → DNS Query for AAAA record foo.rd.td.h.labs.apnic.net 521 ← AAAA response 2a01:4f8:140:50c5::69:72 0 ← A response 88.198.69.81 1 → SYN to 2a01:4f8:140:50c5::69:72 166 ← SYN + ACK response from 2a01:4f8:140:50c5::69:72 1 → ACK to 2a01:4f8:140:50c5::69:72 ------ 689

©2013 AKAMAI | FASTER FORWARDTM

DNS failure – Mac – IPv4 + IPv6 - ChromeDevice: Mac OSX 10.8.4 (mountain lion), Chrome 27Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 A 0 -> DNS1 AAAA 1 -> DNS1 A (retransmit) 0 -> DNS1 AAAA (retransmit) 3 -> DNS2 A 0 -> DNS2 AAAA 1 -> DNS2 A (retransmit) 0 -> DNS2 AAAA (retransmit) 3 -> DNS3 A 0 -> DNS3 AAAA 1 -> DNS3 A (retransmit) 0 -> DNS3 AAAA (retransmit) 3 -> DNS1 A 0 -> DNS1 AAAA 9 -> DNS1 A (retransmit) 0 -> DNS1 AAAA (retransmit)---- 21 not available because DNS lookup failed

©2013 AKAMAI | FASTER FORWARDTM

DNS failure – Mac – IPv4 + IPv6 - FirefoxDevice: Mac OSX 10.8.4 (mountain lion), Firefox 22Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 A 0 -> DNS1 AAAA 1 -> DNS1 A (retransmit) 0 -> DNS1 AAAA (retransmit) 3 -> DNS2 A 0 -> DNS2 AAAA 1 -> DNS2 A (retransmit) 0 -> DNS2 AAAA (retransmit) 3 -> DNS3 A 0 -> DNS3 AAAA 1 -> DNS3 A (retransmit) 0 -> DNS3 AAAA (retransmit) 3 -> DNS1 A 0 -> DNS1 AAAA 9 -> DNS1 A (retransmit) 0 -> DNS1 AAAA (retransmit)---- 21 “Server not found”

©2013 AKAMAI | FASTER FORWARDTM

DNS failure – Mac – IPv4 + IPv6 - Firefox (DNS on IPv6)

Device: Mac OSX 10.8.4 (mountain lion), Firefox 22Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 A, AAAA 1 -> DNS1 (retransmit) 3 -> DNS2 1 -> DNS2 (retransmit) 3 -> DNS3 1 -> DNS3 (retransmit) 3 -> DNS1 9 -> DNS1 (retransmit) 9 -> DNS2 1 -> DNS2 (retransmit) 3 -> DNS3 1 -> DNS3 (retransmit) 3 -> DNS1 1 -> DNS1 (retransmit)---- 39 “Server not found”

©2013 AKAMAI | FASTER FORWARDTM

DNS failure – Mac – IPv4 + IPv6 - Safari

Device: Mac OSX 10.8.4 (mountain lion), Safari 6.0.5Connection: 3 name servers, all not responding

Time Activity---- --------- 0 -> DNS1 A, AAAA 1 -> DNS1 A, AAAA (retransmit) 3 -> DNS2 A, AAAA 1 -> DNS2 A, AAAA (retransmit) 3 -> DNS3 1 -> DNS3 (retransmit) 3 -> DNS1 9 -> DNS1 (retransmit) 27 -> DNS2 81 -> DNS2 (retransmit) 243 -> DNS3...

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Protocol failure – OS “native” behavior

OS: Windows XP 5.1.2600 Service Pack 3 Connection: tcpopen foo.rx.td.h.labs.apnic.net

Time Activity

0 → DNS AAAA? foo.rx.td.h.labs.apnic.net 581 ← AAAA 2a01:4f8:140:50c5::69:72 4 → DNS A? foo.rx.td.h.labs.apnic.net 299 ← A 88.198.69.81 3 → SYN 2a01:4f8:140:50c5::69:dead 3000 → SYN 2a01:4f8:140:50c5::69:dead 6000 → SYN 2a01:4f8:140:50c5::69:dead 12000 → SYN 88.198.69.81 298 ← SYN+ACK 88.198.69.81 0 → ACK 88.198.69.81 -------- 22185

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Protocol failure – OS “native” behaviorOS: Mac OS X 10.7.2 Connection: tcpopen foo.rxxx.td.h.labs.apnic.net

Time Activity

0 → DNS AAAA? foo.rxxx.td.h.labs.apnic.net 4 → DNS A? foo.rxxx.td.h.labs.apnic.net 230 ← DNS AAAA 2a01:4f8:140:50c5::69:dead 2a01:4f8:140:50c5::69:deae 2a01:4f8:140:50c5::69:deaf 20 ← A response 88.198.69.81 3 → SYN 2a01:4f8:140:50c5::69:dead (1) 980 → SYN 2a01:4f8:140:50c5::69:dead (2) 1013 → SYN 2a01:4f8:140:50c5::69:dead (3) 1002 → SYN 2a01:4f8:140:50c5::69:dead (4) 1008 → SYN 2a01:4f8:140:50c5::69:dead (5) 1103 → SYN 2a01:4f8:140:50c5::69:dead (6) 2013 → SYN 2a01:4f8:140:50c5::69:dead (7) 4038 → SYN 2a01:4f8:140:50c5::69:dead (8) 8062 → SYN 2a01:4f8:140:50c5::69:dead (9) 16091 → SYN 2a01:4f8:140:50c5::69:dead (10) 32203 → SYN 2a01:4f8:140:50c5::69:dead (11) 8031 → SYN 2a01:4f8:140:50c5::69:deae (repeat sequence of 11 SYNs) 75124 → SYN 2a01:4f8:140:50c5::69:deaf (repeat sequence of 11 SYNs) 75213 → SYN 88.198.69.81 297 ← SYN+ACK 88.198.69.81 0 → ACK 88.198.69.81 --------

226435

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack on Mac + Safari

OS: Mac OS X 10.7.2 Browser: Safari: 5.1.1

URL: www.rd.td.h.labs.apnic.net

Time Activity IPv4 IPv6 0 → DNS A? www.rd.td.h.labs.apnic.net 1 → DNS AAAA? www.rd.td.h.labs.apnic.net 333 ← AAAA 2a01:4f8:140:50c5::69:72 5 ← A 88.198.69.81 1 → SYN 88.198.69.81 270 → SYN 2a01:4f8:140:50c5::69:72 28 ← SYN+ACK 88.198.69.81 0 → ACK 88.198.69.81 1 → [start HTTP session] 251 ← SYN+ACK 2a01:4f8:140:50c5::69:72 0 → RST 2a01:4f8:140:50c5::69:72 ----- 639ms (time to connect)

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack on Mac + Safari, broken IPv6

URL: www.rxxx.td.h.labs.apnic.net

Time Activity IPv4 IPv6 0 → DNS A? www.rxxx.td.h.labs.apnic.net 0 → DNS AAAA? www.rxxx.td.h.labs.apnic.net 299 ← AAAA 2a01:4f8:140:50c5::69:dead 2a01:4f8:140:50c5::69:deae 2a01:4f8:140:50c5::69:deaf 2 → SYN 2a01:4f8:140:50c5::69:dead 0 ← A 88.198.69.81 270 → SYN 2a01:4f8:140:50c5::69:deae 120 → SYN 2a01:4f8:140:50c5::69:deaf 305 → SYN 88.198.69.81 300 ← SYN+ACK 88.198.69.81 0 → ACK 88.198.69.81 1 → [start HTTP session] ----- 1297

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack on Mac + Chrome

OS: Mac OS X 10.7.2 Browser: Chrome 16.0.912.36

URL: www.rd.td.h.labs.apnic.net

Time Activity IPv4 IPv6 0 → DNS A? www.rd.td.h.labs.apnic.net 0 → DNS AAAA? www.rd.td.h.labs.apnic.net 299 ← A 88.198.69.81 1 ← AAAA 2a01:4f8:140:50c5::69:72 1 → SYN 88.198.69.81 (port a) 1 → SYN 88.198.69.81 (port b) 250 → SYN 88.198.69.81 (port c) 48 ← SYN+ACK 88.198.69.81 (port a) 0 → ACK 88.198.69.81 (port a) 0 → [start HTTP session (port a)] ----- 600

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack on Mac + Chrome, broken IPv6

URL: xxx.rx.td.h.labs.apnic.net

Time Activity IPv4 IPv6 0 → DNS A? xxx.rx.td.h.labs.apnic.net 0 → DNS AAAA? xxx.rx.td.h.labs.apnic.net 298 ← AAAA 2a01:4f8:140:50c5::69:dead 0 ← A 88.198.69.81 11 → SYN 2a01:4f8:140:50c5::69:dead (a) 0 → SYN 2a01:4f8:140:50c5::69:dead (b) 250 → SYN 2a01:4f8:140:50c5::69:dead (c) 51 → SYN 88.198.69.81 (d) 1 → SYN 88.198.69.81 (e) 250 → SYN 88.198.69.81 (f) 48 ← SYN+ACK 88.198.69.81 (d) 0 → ACK 88.198.69.81 (d) 0 → [start HTTP session (d)] ----- 909

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks.

Dual stack on Mac + Chrome, broken IPv6

OS: Mac OS X 10.8.4 Browser: Chrome 27

Time Activity IPv4 IPv6 0 → DNS A? www.rd.td.h.labs.apnic.net 0 → DNS AAAA? www.rd.td.h.labs.apnic.net 299 ← A 88.198.69.81 1 ← AAAA 2a01:4f8:140:50c5::69:72 1 → SYN 88.198.69.81 (port a) 1 → SYN 88.198.69.81 (port b) 250 → SYN 88.198.69.81 (port c) 48 ← SYN+ACK 88.198.69.81 (port a) 0 → ACK 88.198.69.81 (port a) 0 → [start HTTP session (port a)] ----- 600

Source: Geoff Huston

©2013 AKAMAI | FASTER FORWARDTM

Dual Stack: OS behavior

DNS DNS Timeout TCP Timeout Preference

Windows Serial 21 IPv6

Mac OS (as of Lion)

parallel 21* 75 Fastest*

iOS parallel 45-60 sec Fastest

Native OS behavior – based on “connect()”.Important for native applications.

Lion and IPv6 http://goo.gl/7qxHC: Results from getaddrinfo are now sorted using routing statistics (destination with the lowest min round trip time wins)

©2013 AKAMAI | FASTER FORWARDTM

Dual Stack: Browser

IE 9 Chrome Firefox Safari

# of Connections

2 in parallel 2 in parallel + 1 slightly after

2 in parallel Single connection

Preference IPv6 IPv6 IPv6 Fastest (Mac)

Dual stack – happy eyeballs

NoSerial: wait for timeout

start with IPv6, +300ms IPv4

In parallel Start with first, +calc time add second, etc.

Remember failed IPs

yes yes yes yes

©2013 AKAMAI | FASTER FORWARDTM

http://www.flickr.com/photos/natwilson/4260384198/

©2013 AKAMAI | FASTER FORWARDTM

Multiple records – DNS round robin

$ dig www.akamai.com

; <<>> DiG 9.8.3-P1 <<>> www.akamai.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29543;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:;www.akamai.com. IN A

;; ANSWER SECTION:www.akamai.com. 900 IN CNAME www-main.akamai.com.edgesuite.net.www-main.akamai.com.edgesuite.net. 900 IN CNAME a152.dscb.akamai.net.a152.dscb.akamai.net. 20 IN A 173.223.232.168a152.dscb.akamai.net. 20 IN A 173.223.232.163

;; Query time: 94 msec;; SERVER: 192.168.1.1#53(192.168.1.1);; WHEN: Wed Jun 19 01:24:27 2013;; MSG SIZE rcvd: 142

©2013 AKAMAI | FASTER FORWARDTM

Round Robin DNS

• Resolvers will shuffle results order – for LB effect• Browsers respect the order of records• Good for load-balancing• Good for high availability!

©2013 AKAMAI | FASTER FORWARDTM

Round Robin DNS

• Resolvers will shuffle results order – for LB effect• Browsers respect the order of records• Good for load-balancing• Good for high availability!• Good for high availability?

©2013 AKAMAI | FASTER FORWARDTM

http://www.flickr.com/photos/coast_guard/3220493384/

What happens when things break?

©2013 AKAMAI | FASTER FORWARDTM

IE on Windows (XP – Windows 7)

• 2 parallel connections for each record• Retransmit SYN until TCP time-out: 21 seconds• Only on time-out – try next host.

©2013 AKAMAI | FASTER FORWARDTM

http://tinyurl.com/disap-cat

©2013 AKAMAI | FASTER FORWARDTM

IE on Windows (XP – Windows 7)

• 2 parallel connections for each record• Retransmit SYN until TCP time-out: 21 seconds• Only on time-out – try next host.

• Now, consider dual stack with 3 IPv6 records, and 3 IPv4.• IPv6 is prioritized.• If IPv6 is not working – 63 seconds until fallback to IPv4.

• Yes… 21 seconds isn’t that much fun either.

©2013 AKAMAI | FASTER FORWARDTM

Chrome

• 3 parallel connections for each record (1 starting after ~100ms)• Retransmit SYN until TCP time-out: • 75 seconds on Mac• 21 on Windows• ?? On iOS

• With dual stack - happy eyeballs. • 300ms: try alternate protocol

• Why not do the same for alternate host?

©2013 AKAMAI | FASTER FORWARDTM

Firefox

• 2 parallel connections for each record (starting ~800ms apart) • Retransmit SYN, adding 2 connections at a time – prior to time out, • Total of 6-7 connections per host (SYN only)

• Connect to second host not before time-out time • 90 seconds observed on Mac• 21 on Windows

• With dual stack - happy eyeballs. • ?? ms: try alternate protocol

• Why not do the same for alternate host?

©2013 AKAMAI | FASTER FORWARDTM

Safari

• 1 connections for each host• On Mac:• Add connections to next hosts after derived time-out/rtt time (<< TCP timeout)

• On Windows:• Serialized – try new host only when connection timed out (21 sec)

• Retransmit SYN periodically on each connection• Give up after timeout expires on all hosts• Mac = 1 TCP timeout overall!• Windows = # hosts X TCP timeout• ?? On iOS

©2013 AKAMAI | FASTER FORWARDTM

Native OS support

• 1 connections for each record• Retransmit SYN periodically (based on OS schedule)• Continue to next record after time-out• Once all expired – give-up.

©2013 AKAMAI | FASTER FORWARDTM

Recommendations for round robin DNS

• Helpful for load-balancing• Gives some level of high-availability – if you know how to use it• Don’t put a record if you know the IP is down!• Manage your TTLs

• Don’t put multiple records on IPv6!!!

• Seriously – DON’T put multiple records on IPv6.

©2013 AKAMAI | FASTER FORWARDTM

DNS Cache

http://www.flickr.com/photos/fairfaxcounty/7456122122/

©2013 AKAMAI | FASTER FORWARDTM

Local OS

• Local host caches DNS according to instructions• Network change – SHOULD triggers DNS cache cleaning• Moving to airplane mode will

©2013 AKAMAI | FASTER FORWARDTM

Browser cache

Browsers cache DNS records for performance reasons.How?• An application doesn’t get the TTL record from the resolver.

• IE: 30 min• Chrome: 1 min• Firefox: 1 min• Safari: 15-60 seconds

• Chrome DNS client: read Will Chan’s post: http://goo.gl/ByZmX

©2013 AKAMAI | FASTER FORWARDTM

Negative caching

When there is no response for a record, resolvers will cache the “no response” for the TTL defined in the SOA, typically – 1 hour.

From RFC 2308: “its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.”

• Don’t refer to a host before you defined it!• Don’t delete a record if you plan to use it!• Change TTL to 1 sec, and set to some bogus value until ready.

©2013 AKAMAI | FASTER FORWARDTM

Setting TTLS

http://www.flickr.com/photos/shortleafiscute/5831167984/

©2013 AKAMAI | FASTER FORWARDTM

Setting TTLs

Alexa top 1000, TTLs of A records:

80% < 1 hour

They actually change quite frequently!

<1m <2.5m <5m <10m <1h <5h <1d <2d <5d >5d

193 152 34 229 169 154 39 13 4 1

©2013 AKAMAI | FASTER FORWARDTM

Setting TTLs

• Short enough to accommodate failover• Depends on your DNS performance – too short means more DNS activity• Mobile

©2013 AKAMAI | FASTER FORWARDTM

Facebook

www.facebook.com. 3600 IN CNAME star.c10r.facebook.com.star.c10r.facebook.com. 60 IN A 173.252.112.23

www.google.com. 300 IN A 74.125.239.51www.google.com. 300 IN A 74.125.239.50www.google.com. 300 IN A 74.125.239.49www.google.com. 300 IN A 74.125.239.52www.google.com. 300 IN A 74.125.239.48

Google

©2013 AKAMAI | FASTER FORWARDTM

Anycast

Hong-Kong

London

NYC

ISP

IX

ISP

T1N

ISP

©2013 AKAMAI | FASTER FORWARDTM

Anycast

Hong-Kong

London

NYC

ISP

IX

ISP

T1N

ISP

10.0.1.X

10.0.3.X

10.0.2.X example.com IN NS10.0.1.110.0.2.110.0.3.1

67% chance of getting a far resolver!

©2013 AKAMAI | FASTER FORWARDTM

Anycast

Hong-Kong

London

NYC

ISP

IX

ISP

T1N

ISP

10.0.1.X

10.0.3.X

10.0.2.X

10.0.10.X

10.0.10.X

10.0.10.X example.com IN NS10.0.10.110.0.10.2

©2013 AKAMAI | FASTER FORWARDTM

CDNs and Distributed Service

Hong-Kong

London

NYC

ISP

IX

ISP

T1N

ISP

10.0.1.X

10.0.3.X

10.0.2.X

©2013 AKAMAI | FASTER FORWARDTM

CDNs and Distributed Services

• Geo and network based mapping of users• Mapping is based on resolvers IP addresses – they issue the requests

©2013 AKAMAI | FASTER FORWARDTM

CDNs and Distributed Services

• Geo and network based mapping of users• Mapping is based on resolvers IP address

• Challenges:• Corporate network/VPN – resolver at the corporate, not close to the user.• Centralized DNS resolvers at ISPs/carriers• Remote resolvers• Open resolvers – sparse, and remote from user!

©2013 AKAMAI | FASTER FORWARDTM

CDNs and Distributed Services

• Geo and network based mapping of users• Mapping is based on resolvers IP address

• Challenges• Edns0 client subnet data.• Extension to DNS to deliver info about the requesting user.• Can make more informed decisions.

©2013 AKAMAI | FASTER FORWARDTM

DNSSEC

• Validates the record• Does NOT encrypt it• Prevents DNS spoofing/poisoning

• Collapse to TCP if frame too large

• Common concerns:• Slow• Not supported

©2013 AKAMAI | FASTER FORWARDTM

DNSSEC

Sample data from a day of DNS traffic of a US based customer:

• Records are cacheable• Need to validate only once• Some resolvers will not validate…• Consider DNSSEC today!

Total Percentage of DNS hits

Total hits 4,487,728 100.00%Total IPv6 hits 204,477 4.56%Total DNSSEC hits 3,552,809 79.17%Total DNSSEC TCP 5,344 0.12%Non DNSSEC TCP 2,406 0.05%

©2013 AKAMAI | FASTER FORWARDTM

http://www.flickr.com/photos/keithburtis/2614418536/

©2013 AKAMAI | FASTER FORWARDTM

Key Takeaways

• Use a distributed, “professional” DNS vendor, • unless you really know what you are doing.

• Don’t set multiple records (round-robin) for IPv6! Just Don’t!• Multiple records (round robin) is good for load-balancing• Be careful when using it for failover/high availability• Set low TTLs (minutes) when using multiple records

• If a server is down – take it out of the rotation! • Failover costs in performance – in some cases over 20 seconds delay.

• Don’t delete a record, even when taking a server down for maintenance• Better to set a low TTL, and even giving a bogus address, to avoid negative TTL• Control your SOA record – to determine the TTL for negative caching.

©2013 AKAMAI | FASTER FORWARDTM

Takeaways for your org/home network

• Don’t enable IPv6 if it works only on your internal network• For corporate/VPN:• Configure the local DNS to be used ONLY for internal resources.• Prioritize using the carrier/default local resolver over the corp resolver.

Thank you!

Ido Safruti, ido@akamai.com

Recommended