SlideShare una empresa de Scribd logo
1 de 78
Descargar para leer sin conexión
Resolution for a Faster Site
How DNS Affects Page Load Time

Ido Safruti
ido@akamai.com
Web Performance Products, Akamai
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
The phonebook of the Internet

©2013 AKAMAI | FASTER FORWARDTM
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

©2013 AKAMAI | FASTER FORWARD
http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records
TM
Let’s see some Data

©2013 AKAMAI | FASTER FORWARDTM
Getaddrinfo() times, Chrome
OS
Windows
Mac
Linux

Mean
644
230
293

10%
<=1
0
2

25%
12
5
12

50%
43
28
37

75%
119
67
89

90%
372
279
279

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).
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.5
Connection: 3 name servers, all not responding
Time
---0
1
3
1
3
1
3
9
---21

Activity
---------> DNS1
-> DNS1 (retransmit)
-> DNS2
-> DNS2 (retransmit)
-> DNS3
-> DNS3 (retransmit)
-> DNS1
-> DNS1 (retransmit)

©2013 AKAMAI | FASTER FORWARDTM
DNS failure - Windows
Device: Windows 7 (IE9)
Connection: 3 name servers, all not responding

Time
---0
1
1
2
4
4
1
1
2
4
---24

Activity
---------> DNS1
-> DNS2
-> DNS3
-> DNS1, DNS2, DNS3
-> DNS1, DNS2, DNS3
-> DNS1
-> DNS3
-> DNS2
-> DNS1, DNS2, DNS3
-> DNS1, DNS2, DNS3

©2013 AKAMAI | FASTER FORWARDTM
Nav Timing data

©2013 AKAMAI | FASTER FORWARDTM
DNS time vs page load time
14000

12000
20.0%
10000
15.0%

8000

6000

10.0%

4000
5.0%
2000

0.0%

0
0 - 10 10 - 25 25 - 50 50 - 75
msec msec msec msec

75 100
msec

100 200
msec

200 300
msec

300 400
msec

400 500
msec

500 600
msec

Source: Akamai RUM data
©2013 AKAMAI | FASTER FORWARDTM

600 700
msec

700 800
msec

800 900
msec

900 - > 1000
1000 msec
msec

Page Load Time

DNS Time Distribution

25.0%
DNS time by browser type
Only hits with a base page download time <= 169ms
700

600

500
Chrome
400

Firefox
Internet Explorer
Android Webkit

300

Chrome Mobile
IEMobile

200

100

0
p25_dns

median_dns

p75_dns

Source: Akamai RUM data
©2013 AKAMAI | FASTER FORWARDTM

p90_dns
Velocity 2013: Resolution For A Faster Site
Distance of users from resolvers – method 1
EU: 0.9%
>2000 miles

AS:6.25%

NA: 1.9%

SA: 5.0%

July 2012, Akamai
©2013 AKAMAI | FASTER FORWARDTM

AF:6.9%

OC:6.5%
Distance of users from resolvers – method 2
EU: 1.4%
>2000 miles

AS: 5.4%

NA: 1.7%

SA: 4.7%

July 2012, Akamai
©2013 AKAMAI | FASTER FORWARDTM

AF: 7.3%

OC: 6.8%
DNS usage
Alexa Top 10,000 DNS Marketshare - May 6, 2013
Websites
(out of
10,000)

Marketshar Marketshare
e
Change

Provider

+6 / +1.382%

AWS Route 53

2

381

3.81%

14 / 3.815%

3

361

3.61%

-2 / -0.551%

DNSPod

4

336

3.36%

5 / 1.511%

CloudFlare

5

314

3.14%

23 / 7.904%

6

287

2.87%

-10 / -3.367%

7

246

2.46%

0

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

Source: Cloud Harmony

4.40%

Akamai

Amazon.com

440

DNS Made Easy

Hint: they have a DNS service

1

GoDaddy DNS

The only one that doesn’t?

DynECT

UltraDNS

9 of top 10 run their own DNS.

Rank

26

2

0.02%

0

CDNetworks DNS

27

2

0.02%

1 / 100%

3392

33.92%

Total
©2013 AKAMAI | FASTER FORWARDTM
Alexa Top 1,000 DNS Marketshare - May 6, 2013
Provider
DynECT
UltraDNS
Akamai
AWS Route 53
DNSPod
DNS Made Easy
GoDaddy DNS
Cotendo Advanced DNS
Verisign DNS
easyDNS
CloudFlare
Rackspace Cloud DNS
Namecheap
Softlayer DNS
Enom DNS
Internap
Savvis
Nettica
ClouDNS
ZoneEdit
DTDNS
EuroDNS
No-IP
Worldwide DNS

Total

Rank
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Websites
(out of
Marketsha Marketshare
1,000)
re
Change
79
7.90%
0
63
6.30%
1 / 1.613%
48
4.80%
0
34
3.40%
-1 / -2.857%
32
3.20%
0
21
2.10%
0
14
1.40%
0
11
1.10%
-1 / -8.333%
10
1%
0
10
1%
0
8
0.80%
1 / 14.286%
7
0.70%
0
6
0.60%
0
5
0.50%
0
5
0.50%
0
3
0.30%
0
3
0.30%
0
2
0.20%
0
2
0.20%
0
2
0.20%
0
1
0.10%
0
1
0.10%
0
1
0.10%
0
1

0.10%

369

36.90%

Fortune 500 DNS Marketshare - May 6, 2013
Provider
UltraDNS
Verisign DNS
Akamai
DynECT
DNS Made Easy
Savvis
GoDaddy DNS
Internap
Rackspace Cloud DNS
AWS Route 53
easyDNS
No-IP
Enom DNS
ZoneEdit

Rank
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Websites
(out of
Marketsh Marketshare
500)
are
Change
36
7.20%
1 / 2.857%
24
4.80%
0
13
2.60%
0
8
1.60%
0
6
1.20%
0
4
0.80%
0
4
0.80%
0
4
0.80%
0
2
0.40%
0
2
0.40%
0
1
0.20%
0
1
0.20%
0
1
0.20%
0
1
0.20%
0

Total

0

Source: Cloud Harmony
©2013 AKAMAI | FASTER FORWARDTM

107

21.40%
Asia stats influenced
by China

Source: Catchpoint DNS direct agents, testing the [ab].ns.facebook.com name servers
©2013 AKAMAI | FASTER FORWARDTM
©2013 AKAMAI | FASTER FORWARDTM
IPv6

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.

©2013
http://www.flickr.com/photos/yukop/7350636534/AKAMAI | FASTER FORWARD

TM
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 TTL
Apps/Browser – receives host/IP, but no TTL.

©2013 AKAMAI | FASTER FORWARDTM
Dual stack DNS behavior - basics

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

Avoid data theft and downtime by extending the
Time (ms) Packet Activity
security perimeter outside the data-center and
0
→ DNS Query for AAAA record foo.rd.td.h.labs.apnic.net
protect from increasing frequency, scale and
581
← AAAA response 2a01:4f8:140:50c5::69:72
sophistication
4
→ DNS Query for A record for foo.rd.td.h.labs.apnic.net of web attacks.
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
Dual stack DNS behavior - basics

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

Avoid data theft and downtime by extending the
Time (ms) Packet Activity
security perimeter outside the data-center and
0
→ DNS Query for A record for foo.rd.td.h.labs.apnic.net increasing frequency, scale and
protect from
0
→ DNS Query for AAAA record foo.rd.td.h.labs.apnic.net
sophistication of web attacks.
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 - Chrome
Device: Mac OSX 10.8.4 (mountain lion), Chrome 27
Connection: 3 name servers, all not responding
Time
---0
0
1
0
3
0
1
0
3
0
1
0
3
0
9
0
---21

Activity
---------> DNS1 A
-> DNS1 AAAA
-> DNS1 A (retransmit)
-> DNS1 AAAA (retransmit)
-> DNS2 A
-> DNS2 AAAA
-> DNS2 A (retransmit)
-> DNS2 AAAA (retransmit)
-> DNS3 A
-> DNS3 AAAA
-> DNS3 A (retransmit)
-> DNS3 AAAA (retransmit)
-> DNS1 A
-> DNS1 AAAA
-> DNS1 A (retransmit)
-> DNS1 AAAA (retransmit)
not available because DNS lookup failed
©2013 AKAMAI | FASTER FORWARDTM
DNS failure – Mac – IPv4 + IPv6 - Firefox
Device: Mac OSX 10.8.4 (mountain lion), Firefox 22
Connection: 3 name servers, all not responding
Time
---0
0
1
0
3
0
1
0
3
0
1
0
3
0
9
0
---21

Activity
---------> DNS1 A
-> DNS1 AAAA
-> DNS1 A (retransmit)
-> DNS1 AAAA (retransmit)
-> DNS2 A
-> DNS2 AAAA
-> DNS2 A (retransmit)
-> DNS2 AAAA (retransmit)
-> DNS3 A
-> DNS3 AAAA
-> DNS3 A (retransmit)
-> DNS3 AAAA (retransmit)
-> DNS1 A
-> DNS1 AAAA
-> DNS1 A (retransmit)
-> DNS1 AAAA (retransmit)
“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 22
Connection: 3 name servers, all not responding

Time
---0
1
3
1
3
1
3
9
9
1
3
1
3
1
---39

Activity
---------> DNS1 A, AAAA
-> DNS1 (retransmit)
-> DNS2
-> DNS2 (retransmit)
-> DNS3
-> DNS3 (retransmit)
-> DNS1
-> DNS1 (retransmit)
-> DNS2
-> DNS2 (retransmit)
-> DNS3
-> DNS3 (retransmit)
-> DNS1
-> DNS1 (retransmit)
“Server not found”

©2013 AKAMAI | FASTER FORWARDTM
DNS failure – Mac – IPv4 + IPv6 - Safari

Device: Mac OSX 10.8.4 (mountain lion), Safari 6.0.5
Connection: 3 name servers, all not responding
Time
---0
1
3
1
3
1
3
9
27
81
243
...

Activity
---------> DNS1 A, AAAA
-> DNS1 A, AAAA (retransmit)
-> DNS2 A, AAAA
-> DNS2 A, AAAA (retransmit)
-> DNS3
-> DNS3 (retransmit)
-> DNS1
-> DNS1 (retransmit)
-> DNS2
-> DNS2 (retransmit)
-> DNS3

©2013 AKAMAI | FASTER FORWARDTM
Protocol failure – OS “native” behavior

OS: Windows XP 5.1.2600 Service Pack 3
Connection: tcpopen foo.rx.td.h.labs.apnic.net
Time
0
581
4
299
3
3000
6000
12000
298
0
-------22185

Activity

Avoid data theft and downtime by extending the
→ DNS AAAA? foo.rx.td.h.labs.apnic.net
security perimeter outside the data-center and
← AAAA 2a01:4f8:140:50c5::69:72
→ DNS A? foo.rx.td.h.labs.apnic.net protect from increasing frequency, scale and
← A 88.198.69.81
sophistication of web attacks.
→ SYN 2a01:4f8:140:50c5::69:dead
→ SYN 2a01:4f8:140:50c5::69:dead
→ SYN 2a01:4f8:140:50c5::69:dead
→ SYN 88.198.69.81
← SYN+ACK 88.198.69.81
→ ACK 88.198.69.81

Source: Geoff Huston
©2013 AKAMAI | FASTER FORWARDTM
Protocol failure – OS “native” behavior
OS: Mac OS X 10.7.2
Connection: tcpopen foo.rxxx.td.h.labs.apnic.net
Time
0
4
230
20
3
980
1013
1002
1008
1103
2013
4038
8062
16091
32203
8031
75124
75213
297
0
--------

Activity
→ DNS AAAA? foo.rxxx.td.h.labs.apnic.net
→ DNS A? foo.rxxx.td.h.labs.apnic.net
← DNS AAAA 2a01:4f8:140:50c5::69:dead
2a01:4f8:140:50c5::69:deae
2a01:4f8:140:50c5::69:deaf
← A response 88.198.69.81
→ SYN 2a01:4f8:140:50c5::69:dead (1)
→ SYN 2a01:4f8:140:50c5::69:dead (2)
→ SYN 2a01:4f8:140:50c5::69:dead (3)
→ SYN 2a01:4f8:140:50c5::69:dead (4)
→ SYN 2a01:4f8:140:50c5::69:dead (5)
→ SYN 2a01:4f8:140:50c5::69:dead (6)
→ SYN 2a01:4f8:140:50c5::69:dead (7)
→ SYN 2a01:4f8:140:50c5::69:dead (8)
→ SYN 2a01:4f8:140:50c5::69:dead (9)
→ SYN 2a01:4f8:140:50c5::69:dead (10)
→ SYN 2a01:4f8:140:50c5::69:dead (11)
→ SYN 2a01:4f8:140:50c5::69:deae (repeat sequence of 11 SYNs)
→ SYN 2a01:4f8:140:50c5::69:deaf (repeat sequence of 11 SYNs)
→ SYN 88.198.69.81
← SYN+ACK 88.198.69.81
→ ACK 88.198.69.81

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.

226435

Source: Geoff Huston
©2013 AKAMAI | FASTER FORWARDTM
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
Avoid data theft and downtime by extending the
IPv4
IPv6
0 → DNS A? www.rd.td.h.labs.apnic.net
security perimeter outside the data-center and
1
→ DNS AAAA? www.rd.td.h.labs.apnic.net
333
← AAAA 2a01:4f8:140:50c5::69:72 from increasing frequency, scale and
protect
5 ← A 88.198.69.81
sophistication of web attacks.
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
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 theft and downtime by extending the
Avoid data
299
← AAAA 2a01:4f8:140:50c5::69:dead
security perimeter outside the data-center and
2a01:4f8:140:50c5::69:deae
2a01:4f8:140:50c5::69:deaf
protect from increasing frequency, scale and
2
→ SYN 2a01:4f8:140:50c5::69:dead
0 ← A 88.198.69.81
sophistication of web attacks.
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
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
Avoid data theft and downtime by extending the
IPv4
IPv6
security perimeter outside the data-center and
0 → DNS A? www.rd.td.h.labs.apnic.net
0
→ DNS AAAA? www.rd.td.h.labs.apnic.net
protect from increasing frequency, scale and
299 ← A 88.198.69.81
1
← AAAA 2a01:4f8:140:50c5::69:72
sophistication of web attacks.
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 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
Avoid data theft and downtime by extending the
298
← AAAA
2a01:4f8:140:50c5::69:dead
security perimeter outside the data-center and
0 ← A 88.198.69.81
11
→ SYN 2a01:4f8:140:50c5::69:dead (a)
protect
0
→ SYN 2a01:4f8:140:50c5::69:dead (b) from increasing frequency, scale and
250
→ SYN 2a01:4f8:140:50c5::69:dead (c)
sophistication of web attacks.
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
Dual stack on Mac + Chrome, broken IPv6

OS: Mac OS X 10.8.4
Browser: Chrome 27

Time Activity
IPv4
IPv6
Avoid data theft and downtime by extending the
0 → DNS A? www.rd.td.h.labs.apnic.net
security
0
→ DNS AAAA? www.rd.td.h.labs.apnic.netperimeter outside the data-center and
299 ← A 88.198.69.81
protect from increasing frequency, scale and
1
← AAAA 2a01:4f8:140:50c5::69:72
1 → SYN 88.198.69.81 (port a)
sophistication of web attacks.
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

Windows
Mac OS
(as of Lion)
iOS

DNS
Serial
parallel

DNS Timeout

parallel

Preference
IPv6
Fastest*

45-60 sec

21*

TCP Timeout
21
75

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
2 in parallel

# of
Connections
Preference
IPv6
Dual stack –
No
happy eyeballs Serial: wait for
timeout
Remember
yes
failed IPs

Chrome
2 in parallel + 1
slightly after
IPv6
start with IPv6,
+300ms IPv4

Firefox
2 in parallel

yes

yes

©2013 AKAMAI | FASTER FORWARDTM

IPv6
In parallel

Safari
Single
connection
Fastest (Mac)
Start with first,
+calc time add
second, etc.
yes
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

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

A

IN

CNAME

www-

a152.dscb.akamai.net.
A
173.223.232.168
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
What happens when
things break?

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

©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
©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
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

©2013
http://www.flickr.com/photos/shortleafiscute/5831167984/ AKAMAI | FASTER FORWARD

TM
Setting TTLs
Alexa top 1000, TTLs of A records:
<1m

193

<2.5m <5m

152

34

<10m

229

<1h

169

<5h

<1d

154

80% < 1 hour
They actually change quite frequently!

©2013 AKAMAI | FASTER FORWARDTM

39

<2d

13

<5d

>5d

4

1
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.
star.c10r.facebook.com.

3600 IN
60 IN

CNAME
A

300
300
300
300
300

A
A
A
A
A

star.c10r.facebook.com.
173.252.112.23

Google
www.google.com.
www.google.com.
www.google.com.
www.google.com.
www.google.com.

IN
IN
IN
IN
IN

74.125.239.51
74.125.239.50
74.125.239.49
74.125.239.52
74.125.239.48

©2013 AKAMAI | FASTER FORWARDTM
Anycast
London

IX

Hong-Kong

NYC
T1N

ISP

ISP
ISP

©2013 AKAMAI | FASTER FORWARDTM
Anycast
London
10.0.2.X

IX

Hong-Kong
10.0.3.X

example.com IN NS
10.0.1.1
10.0.2.1
10.0.3.1

NYC

10.0.1.X

T1N

67% chance of getting
a far resolver!
ISP

ISP
ISP

©2013 AKAMAI | FASTER FORWARDTM
Anycast
London
10.0.2.X
10.0.10.X

IX

Hong-Kong
10.0.3.X
10.0.10.X

NYC

10.0.1.X
10.0.10.X

T1N

ISP

ISP
ISP

©2013 AKAMAI | FASTER FORWARDTM

example.com IN NS
10.0.10.1
10.0.10.2
CDNs and Distributed Service
London
10.0.2.X

IX

Hong-Kong
10.0.3.X

NYC

10.0.1.X

T1N

ISP

ISP
ISP

©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:
Total

Total hits
Total IPv6 hits
Total DNSSEC hits
Total DNSSEC TCP
Non DNSSEC TCP

•
•
•
•

Percentage of DNS hits

4,487,728
204,477
3,552,809
5,344
2,406

Records are cacheable
Need to validate only once
Some resolvers will not validate…
Consider DNSSEC today!
©2013 AKAMAI | FASTER FORWARDTM

100.00%
4.56%
79.17%
0.12%
0.05%
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.

©2013 AKAMAI | FASTER FORWARDTM
Thank you!

Ido Safruti,
ido@akamai.com

Más contenido relacionado

La actualidad más candente

Edge 2014: Increasing Control with Property Manager with eBay
Edge 2014: Increasing Control with Property Manager with eBayEdge 2014: Increasing Control with Property Manager with eBay
Edge 2014: Increasing Control with Property Manager with eBayAkamai Technologies
 
Akamai: From Theory to Practice
Akamai: From Theory to PracticeAkamai: From Theory to Practice
Akamai: From Theory to PracticeLiz Bradley
 
Responsive Web Demo with Akamai
Responsive Web Demo with AkamaiResponsive Web Demo with Akamai
Responsive Web Demo with AkamaiFran Albaladejo
 
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...IDATE DigiWorld
 
40 - IDNOG03 - Bob Lau (Akamai) - BGP and Traffic Engineering
40 - IDNOG03  - Bob Lau (Akamai) - BGP and Traffic Engineering40 - IDNOG03  - Bob Lau (Akamai) - BGP and Traffic Engineering
40 - IDNOG03 - Bob Lau (Akamai) - BGP and Traffic EngineeringIndonesia Network Operators Group
 
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamaielenae00
 
Step by Step Mobile Optimization
Step by Step Mobile OptimizationStep by Step Mobile Optimization
Step by Step Mobile OptimizationGuy Podjarny
 
Adobe Managed Services: Complicated Cloud Deployments
Adobe Managed Services: Complicated Cloud DeploymentsAdobe Managed Services: Complicated Cloud Deployments
Adobe Managed Services: Complicated Cloud DeploymentsAdam Pazik
 
Performance Implications of Mobile Design (Perf Audience Edition)
Performance Implications of Mobile Design (Perf Audience Edition)Performance Implications of Mobile Design (Perf Audience Edition)
Performance Implications of Mobile Design (Perf Audience Edition)Guy Podjarny
 
2015 Velocity SC: Convince your CFO that #perfmatters
2015 Velocity SC: Convince your CFO that #perfmatters2015 Velocity SC: Convince your CFO that #perfmatters
2015 Velocity SC: Convince your CFO that #perfmattersColin Bendell
 
Agoda open stack in a large scale deployment
Agoda open stack in a large scale deploymentAgoda open stack in a large scale deployment
Agoda open stack in a large scale deploymentSharkrit JOBBO
 
Akamai connector for varnish
Akamai connector for varnishAkamai connector for varnish
Akamai connector for varnishVarnish Software
 
Content Growth by Kams Yueng
Content Growth by Kams YuengContent Growth by Kams Yueng
Content Growth by Kams YuengMyNOG
 
AWS Webinar - Intro to Amazon Cloudfront 13-09-17
AWS Webinar -  Intro to Amazon Cloudfront 13-09-17AWS Webinar -  Intro to Amazon Cloudfront 13-09-17
AWS Webinar - Intro to Amazon Cloudfront 13-09-17Amazon Web Services
 
Next Generation Availability on Cloud
Next Generation Availability on CloudNext Generation Availability on Cloud
Next Generation Availability on CloudAmazon Web Services
 
Best practices for content delivery using amazon cloud front
Best practices for content delivery using amazon cloud frontBest practices for content delivery using amazon cloud front
Best practices for content delivery using amazon cloud frontAmazon Web Services
 
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...Tom Laszewski
 
AEM Communities 6.1 - MongoSV '15
AEM Communities 6.1 - MongoSV '15AEM Communities 6.1 - MongoSV '15
AEM Communities 6.1 - MongoSV '15Kevin Nennig
 
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...devang-dsshah
 
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...Amazon Web Services
 

La actualidad más candente (20)

Edge 2014: Increasing Control with Property Manager with eBay
Edge 2014: Increasing Control with Property Manager with eBayEdge 2014: Increasing Control with Property Manager with eBay
Edge 2014: Increasing Control with Property Manager with eBay
 
Akamai: From Theory to Practice
Akamai: From Theory to PracticeAkamai: From Theory to Practice
Akamai: From Theory to Practice
 
Responsive Web Demo with Akamai
Responsive Web Demo with AkamaiResponsive Web Demo with Akamai
Responsive Web Demo with Akamai
 
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...
Future of CDN - Next 10 Years - Ahmet Ozalp, Akamai Technologies - DigiWorld ...
 
40 - IDNOG03 - Bob Lau (Akamai) - BGP and Traffic Engineering
40 - IDNOG03  - Bob Lau (Akamai) - BGP and Traffic Engineering40 - IDNOG03  - Bob Lau (Akamai) - BGP and Traffic Engineering
40 - IDNOG03 - Bob Lau (Akamai) - BGP and Traffic Engineering
 
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
 
Step by Step Mobile Optimization
Step by Step Mobile OptimizationStep by Step Mobile Optimization
Step by Step Mobile Optimization
 
Adobe Managed Services: Complicated Cloud Deployments
Adobe Managed Services: Complicated Cloud DeploymentsAdobe Managed Services: Complicated Cloud Deployments
Adobe Managed Services: Complicated Cloud Deployments
 
Performance Implications of Mobile Design (Perf Audience Edition)
Performance Implications of Mobile Design (Perf Audience Edition)Performance Implications of Mobile Design (Perf Audience Edition)
Performance Implications of Mobile Design (Perf Audience Edition)
 
2015 Velocity SC: Convince your CFO that #perfmatters
2015 Velocity SC: Convince your CFO that #perfmatters2015 Velocity SC: Convince your CFO that #perfmatters
2015 Velocity SC: Convince your CFO that #perfmatters
 
Agoda open stack in a large scale deployment
Agoda open stack in a large scale deploymentAgoda open stack in a large scale deployment
Agoda open stack in a large scale deployment
 
Akamai connector for varnish
Akamai connector for varnishAkamai connector for varnish
Akamai connector for varnish
 
Content Growth by Kams Yueng
Content Growth by Kams YuengContent Growth by Kams Yueng
Content Growth by Kams Yueng
 
AWS Webinar - Intro to Amazon Cloudfront 13-09-17
AWS Webinar -  Intro to Amazon Cloudfront 13-09-17AWS Webinar -  Intro to Amazon Cloudfront 13-09-17
AWS Webinar - Intro to Amazon Cloudfront 13-09-17
 
Next Generation Availability on Cloud
Next Generation Availability on CloudNext Generation Availability on Cloud
Next Generation Availability on Cloud
 
Best practices for content delivery using amazon cloud front
Best practices for content delivery using amazon cloud frontBest practices for content delivery using amazon cloud front
Best practices for content delivery using amazon cloud front
 
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...
Speeding up delivery of web content using Amazon Route 53, Elastic Load Balan...
 
AEM Communities 6.1 - MongoSV '15
AEM Communities 6.1 - MongoSV '15AEM Communities 6.1 - MongoSV '15
AEM Communities 6.1 - MongoSV '15
 
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...
Implementing Large Scale Digital Asset Repositories with Adobe Experience Man...
 
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...
7 Use Cases in 7 Minutes Each : The Power of Workflows and Automation (SVC101...
 

Similar a Velocity 2013: Resolution For A Faster Site

Resolution for a Faster Site
Resolution for a Faster SiteResolution for a Faster Site
Resolution for a Faster SiteIdo Safruti
 
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]APNIC
 
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark Python
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark PythonFrom Raw Data to an Interactive Data App in an Hour: Powered by Snowpark Python
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark PythonHostedbyConfluent
 
Redis Reliability, Performance & Innovation
Redis Reliability, Performance & InnovationRedis Reliability, Performance & Innovation
Redis Reliability, Performance & InnovationRedis Labs
 
Решение Cisco Collaboration Edge
Решение Cisco Collaboration EdgeРешение Cisco Collaboration Edge
Решение Cisco Collaboration EdgeCisco Russia
 
PLNOG 9: Adam Obszyński - DNS Caching
PLNOG 9: Adam Obszyński - DNS Caching PLNOG 9: Adam Obszyński - DNS Caching
PLNOG 9: Adam Obszyński - DNS Caching PROIDEA
 
EDNS0 Client-Subnet for DNS based CDNs by Matt Jansen
EDNS0 Client-Subnet for DNS based CDNs by Matt JansenEDNS0 Client-Subnet for DNS based CDNs by Matt Jansen
EDNS0 Client-Subnet for DNS based CDNs by Matt JansenMyNOG
 
Champion Fas Deduplication
Champion Fas DeduplicationChampion Fas Deduplication
Champion Fas DeduplicationMichael Hudak
 
Webinar: Untethering Compute from Storage
Webinar: Untethering Compute from StorageWebinar: Untethering Compute from Storage
Webinar: Untethering Compute from StorageAvere Systems
 
Akamai Korea - Tech Day (2015/03/11) DNS
Akamai Korea - Tech Day (2015/03/11) DNSAkamai Korea - Tech Day (2015/03/11) DNS
Akamai Korea - Tech Day (2015/03/11) DNSSangJin Kang
 
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamaielenae00
 
Living on the edge
Living on the edgeLiving on the edge
Living on the edgeAdrian Cole
 
Mobile web performance - MoDev East
Mobile web performance - MoDev EastMobile web performance - MoDev East
Mobile web performance - MoDev EastPatrick Meenan
 

Similar a Velocity 2013: Resolution For A Faster Site (20)

Resolution for a Faster Site
Resolution for a Faster SiteResolution for a Faster Site
Resolution for a Faster Site
 
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
DNSSEC Tutorial, by Champika Wijayatunga [APNIC 38]
 
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark Python
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark PythonFrom Raw Data to an Interactive Data App in an Hour: Powered by Snowpark Python
From Raw Data to an Interactive Data App in an Hour: Powered by Snowpark Python
 
Redis Reliability, Performance & Innovation
Redis Reliability, Performance & InnovationRedis Reliability, Performance & Innovation
Redis Reliability, Performance & Innovation
 
Решение Cisco Collaboration Edge
Решение Cisco Collaboration EdgeРешение Cisco Collaboration Edge
Решение Cisco Collaboration Edge
 
PLNOG 9: Adam Obszyński - DNS Caching
PLNOG 9: Adam Obszyński - DNS Caching PLNOG 9: Adam Obszyński - DNS Caching
PLNOG 9: Adam Obszyński - DNS Caching
 
EDNS0 Client-Subnet for DNS Based CDNs
EDNS0 Client-Subnet for DNS Based CDNs EDNS0 Client-Subnet for DNS Based CDNs
EDNS0 Client-Subnet for DNS Based CDNs
 
EDNS0 Client-Subnet for DNS based CDNs by Matt Jansen
EDNS0 Client-Subnet for DNS based CDNs by Matt JansenEDNS0 Client-Subnet for DNS based CDNs by Matt Jansen
EDNS0 Client-Subnet for DNS based CDNs by Matt Jansen
 
NFS and Oracle
NFS and OracleNFS and Oracle
NFS and Oracle
 
Champion Fas Deduplication
Champion Fas DeduplicationChampion Fas Deduplication
Champion Fas Deduplication
 
Dyna trace
Dyna traceDyna trace
Dyna trace
 
Webinar: Untethering Compute from Storage
Webinar: Untethering Compute from StorageWebinar: Untethering Compute from Storage
Webinar: Untethering Compute from Storage
 
DNS: EdgeCast Route - Technical DNS Service Overview
DNS: EdgeCast Route - Technical DNS Service Overview DNS: EdgeCast Route - Technical DNS Service Overview
DNS: EdgeCast Route - Technical DNS Service Overview
 
16 (IDNOG01) EDNS0 / How CDNS works by Matt Jansen
16 (IDNOG01) EDNS0 / How CDNS works by Matt Jansen16 (IDNOG01) EDNS0 / How CDNS works by Matt Jansen
16 (IDNOG01) EDNS0 / How CDNS works by Matt Jansen
 
Profilling client performance
Profilling client performanceProfilling client performance
Profilling client performance
 
Cdn cs6740
Cdn cs6740Cdn cs6740
Cdn cs6740
 
Akamai Korea - Tech Day (2015/03/11) DNS
Akamai Korea - Tech Day (2015/03/11) DNSAkamai Korea - Tech Day (2015/03/11) DNS
Akamai Korea - Tech Day (2015/03/11) DNS
 
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
 
Living on the edge
Living on the edgeLiving on the edge
Living on the edge
 
Mobile web performance - MoDev East
Mobile web performance - MoDev EastMobile web performance - MoDev East
Mobile web performance - MoDev East
 

Más de Akamai Technologies

Akamai Intelligent Edge Security
Akamai Intelligent Edge SecurityAkamai Intelligent Edge Security
Akamai Intelligent Edge SecurityAkamai Technologies
 
Replacing recovery with resilience
Replacing recovery with resilienceReplacing recovery with resilience
Replacing recovery with resilienceAkamai Technologies
 
Competitive EDGE - Data Driven Differentiation
Competitive EDGE - Data Driven DifferentiationCompetitive EDGE - Data Driven Differentiation
Competitive EDGE - Data Driven DifferentiationAkamai Technologies
 
3 Reasons You Need Proactive Protection Against Malware
3 Reasons You Need Proactive Protection Against Malware3 Reasons You Need Proactive Protection Against Malware
3 Reasons You Need Proactive Protection Against MalwareAkamai Technologies
 
3 Reasons It's Time for a New Remote Access Model
3 Reasons It's Time for a New Remote Access Model3 Reasons It's Time for a New Remote Access Model
3 Reasons It's Time for a New Remote Access ModelAkamai Technologies
 
새로운 원격 접속 모델이 필요한 3가지 이유
새로운 원격 접속 모델이 필요한 3가지 이유새로운 원격 접속 모델이 필요한 3가지 이유
새로운 원격 접속 모델이 필요한 3가지 이유Akamai Technologies
 
更新遠端存取模式的 3 大理由
更新遠端存取模式的 3 大理由更新遠端存取模式的 3 大理由
更新遠端存取模式的 3 大理由Akamai Technologies
 
应该采用全新远程访问模式的 3 大原因
应该采用全新远程访问模式的 3 大原因应该采用全新远程访问模式的 3 大原因
应该采用全新远程访问模式的 3 大原因Akamai Technologies
 
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと きAkamai Technologies
 
3 razões chegou a hora de um novo modelo de acesso remoto
3 razões chegou a hora de um novo modelo de acesso remoto3 razões chegou a hora de um novo modelo de acesso remoto
3 razões chegou a hora de um novo modelo de acesso remotoAkamai Technologies
 
3 motivi per cui è necessario un nuovo modello di accesso remoto
3 motivi per cui è necessario un nuovo modello di accesso remoto3 motivi per cui è necessario un nuovo modello di accesso remoto
3 motivi per cui è necessario un nuovo modello di accesso remotoAkamai Technologies
 
3 raisons de changer votre modèle d'accès à distance
3 raisons de changer votre modèle d'accès à distance3 raisons de changer votre modèle d'accès à distance
3 raisons de changer votre modèle d'accès à distanceAkamai Technologies
 
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...Akamai Technologies
 
3 Gründe für eine neue Art des Remotezugriffs
3 Gründe für eine neue Art des Remotezugriffs3 Gründe für eine neue Art des Remotezugriffs
3 Gründe für eine neue Art des RemotezugriffsAkamai Technologies
 
Customer Technology Day Chicago 2015
Customer Technology Day Chicago 2015Customer Technology Day Chicago 2015
Customer Technology Day Chicago 2015Akamai Technologies
 
Edge 2014: MPEG DASH – Tomorrow's Format Today
Edge 2014: MPEG DASH – Tomorrow's Format TodayEdge 2014: MPEG DASH – Tomorrow's Format Today
Edge 2014: MPEG DASH – Tomorrow's Format TodayAkamai Technologies
 
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...Site Shield Product Brief - Origin defense by cloaking web infrastructure and...
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...Akamai Technologies
 
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...Prolexic Routed Product Brief - DDoS defense for protecting network and data ...
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...Akamai Technologies
 
Web Application Accelerator Product Brief - Application delivery for global w...
Web Application Accelerator Product Brief - Application delivery for global w...Web Application Accelerator Product Brief - Application delivery for global w...
Web Application Accelerator Product Brief - Application delivery for global w...Akamai Technologies
 
Alta Product Brief - Cloud-based application delivery platform for web applic...
Alta Product Brief - Cloud-based application delivery platform for web applic...Alta Product Brief - Cloud-based application delivery platform for web applic...
Alta Product Brief - Cloud-based application delivery platform for web applic...Akamai Technologies
 

Más de Akamai Technologies (20)

Akamai Intelligent Edge Security
Akamai Intelligent Edge SecurityAkamai Intelligent Edge Security
Akamai Intelligent Edge Security
 
Replacing recovery with resilience
Replacing recovery with resilienceReplacing recovery with resilience
Replacing recovery with resilience
 
Competitive EDGE - Data Driven Differentiation
Competitive EDGE - Data Driven DifferentiationCompetitive EDGE - Data Driven Differentiation
Competitive EDGE - Data Driven Differentiation
 
3 Reasons You Need Proactive Protection Against Malware
3 Reasons You Need Proactive Protection Against Malware3 Reasons You Need Proactive Protection Against Malware
3 Reasons You Need Proactive Protection Against Malware
 
3 Reasons It's Time for a New Remote Access Model
3 Reasons It's Time for a New Remote Access Model3 Reasons It's Time for a New Remote Access Model
3 Reasons It's Time for a New Remote Access Model
 
새로운 원격 접속 모델이 필요한 3가지 이유
새로운 원격 접속 모델이 필요한 3가지 이유새로운 원격 접속 모델이 필요한 3가지 이유
새로운 원격 접속 모델이 필요한 3가지 이유
 
更新遠端存取模式的 3 大理由
更新遠端存取模式的 3 大理由更新遠端存取模式的 3 大理由
更新遠端存取模式的 3 大理由
 
应该采用全新远程访问模式的 3 大原因
应该采用全新远程访问模式的 3 大原因应该采用全新远程访问模式的 3 大原因
应该采用全新远程访问模式的 3 大原因
 
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き
3 つの理由 今こそ新しいリモート・アク セス・モデルを採用すべきと き
 
3 razões chegou a hora de um novo modelo de acesso remoto
3 razões chegou a hora de um novo modelo de acesso remoto3 razões chegou a hora de um novo modelo de acesso remoto
3 razões chegou a hora de um novo modelo de acesso remoto
 
3 motivi per cui è necessario un nuovo modello di accesso remoto
3 motivi per cui è necessario un nuovo modello di accesso remoto3 motivi per cui è necessario un nuovo modello di accesso remoto
3 motivi per cui è necessario un nuovo modello di accesso remoto
 
3 raisons de changer votre modèle d'accès à distance
3 raisons de changer votre modèle d'accès à distance3 raisons de changer votre modèle d'accès à distance
3 raisons de changer votre modèle d'accès à distance
 
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...
3 motivos por los que ahora es el momento perfecto para adoptar un nuevo mode...
 
3 Gründe für eine neue Art des Remotezugriffs
3 Gründe für eine neue Art des Remotezugriffs3 Gründe für eine neue Art des Remotezugriffs
3 Gründe für eine neue Art des Remotezugriffs
 
Customer Technology Day Chicago 2015
Customer Technology Day Chicago 2015Customer Technology Day Chicago 2015
Customer Technology Day Chicago 2015
 
Edge 2014: MPEG DASH – Tomorrow's Format Today
Edge 2014: MPEG DASH – Tomorrow's Format TodayEdge 2014: MPEG DASH – Tomorrow's Format Today
Edge 2014: MPEG DASH – Tomorrow's Format Today
 
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...Site Shield Product Brief - Origin defense by cloaking web infrastructure and...
Site Shield Product Brief - Origin defense by cloaking web infrastructure and...
 
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...Prolexic Routed Product Brief - DDoS defense for protecting network and data ...
Prolexic Routed Product Brief - DDoS defense for protecting network and data ...
 
Web Application Accelerator Product Brief - Application delivery for global w...
Web Application Accelerator Product Brief - Application delivery for global w...Web Application Accelerator Product Brief - Application delivery for global w...
Web Application Accelerator Product Brief - Application delivery for global w...
 
Alta Product Brief - Cloud-based application delivery platform for web applic...
Alta Product Brief - Cloud-based application delivery platform for web applic...Alta Product Brief - Cloud-based application delivery platform for web applic...
Alta Product Brief - Cloud-based application delivery platform for web applic...
 

Último

UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 

Último (20)

UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 

Velocity 2013: Resolution For A Faster Site

  • 1. Resolution for a Faster Site How DNS Affects Page Load Time Ido Safruti ido@akamai.com Web Performance Products, Akamai
  • 2. 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
  • 3. I’ll also won’t be talking about Daddy’s Nasty Sons ©2013 AKAMAI | FASTER FORWARDTM
  • 4. Why is DNS important? ©2013 AKAMAI | FASTER FORWARDTM
  • 5. The phonebook of the Internet ©2013 AKAMAI | FASTER FORWARDTM
  • 6. We just assume it always works ©2013 AKAMAI | FASTER FORWARDTM
  • 7. ©2013 AKAMAI | FASTER FORWARDTM
  • 8. ©2013 AKAMAI | FASTER FORWARDTM
  • 9. ©2013 AKAMAI | FASTER FORWARDTM
  • 10. ©2013 AKAMAI | FASTER FORWARDTM
  • 11. ©2013 AKAMAI | FASTER FORWARDTM
  • 12. Location of DNS root servers, including anycast nodes, identified by their one-letter names. (2008) ©2013 AKAMAI | FASTER FORWARDTM
  • 13. 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 ©2013 AKAMAI | FASTER FORWARD http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records TM
  • 14. Let’s see some Data ©2013 AKAMAI | FASTER FORWARDTM
  • 15. Getaddrinfo() times, Chrome OS Windows Mac Linux Mean 644 230 293 10% <=1 0 2 25% 12 5 12 50% 43 28 37 75% 119 67 89 90% 372 279 279 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). Source: Will Chan, http://goo.gl/ByZmX Mar 15, 2012 ©2013 AKAMAI | FASTER FORWARDTM
  • 16. DNS failure - Mac Device: Mac OSX 10.8.4 (mountain lion), Safari 6.0.5 Connection: 3 name servers, all not responding Time ---0 1 3 1 3 1 3 9 ---21 Activity ---------> DNS1 -> DNS1 (retransmit) -> DNS2 -> DNS2 (retransmit) -> DNS3 -> DNS3 (retransmit) -> DNS1 -> DNS1 (retransmit) ©2013 AKAMAI | FASTER FORWARDTM
  • 17. DNS failure - Windows Device: Windows 7 (IE9) Connection: 3 name servers, all not responding Time ---0 1 1 2 4 4 1 1 2 4 ---24 Activity ---------> DNS1 -> DNS2 -> DNS3 -> DNS1, DNS2, DNS3 -> DNS1, DNS2, DNS3 -> DNS1 -> DNS3 -> DNS2 -> DNS1, DNS2, DNS3 -> DNS1, DNS2, DNS3 ©2013 AKAMAI | FASTER FORWARDTM
  • 18. Nav Timing data ©2013 AKAMAI | FASTER FORWARDTM
  • 19. DNS time vs page load time 14000 12000 20.0% 10000 15.0% 8000 6000 10.0% 4000 5.0% 2000 0.0% 0 0 - 10 10 - 25 25 - 50 50 - 75 msec msec msec msec 75 100 msec 100 200 msec 200 300 msec 300 400 msec 400 500 msec 500 600 msec Source: Akamai RUM data ©2013 AKAMAI | FASTER FORWARDTM 600 700 msec 700 800 msec 800 900 msec 900 - > 1000 1000 msec msec Page Load Time DNS Time Distribution 25.0%
  • 20. DNS time by browser type Only hits with a base page download time <= 169ms 700 600 500 Chrome 400 Firefox Internet Explorer Android Webkit 300 Chrome Mobile IEMobile 200 100 0 p25_dns median_dns p75_dns Source: Akamai RUM data ©2013 AKAMAI | FASTER FORWARDTM p90_dns
  • 22. Distance of users from resolvers – method 1 EU: 0.9% >2000 miles AS:6.25% NA: 1.9% SA: 5.0% July 2012, Akamai ©2013 AKAMAI | FASTER FORWARDTM AF:6.9% OC:6.5%
  • 23. Distance of users from resolvers – method 2 EU: 1.4% >2000 miles AS: 5.4% NA: 1.7% SA: 4.7% July 2012, Akamai ©2013 AKAMAI | FASTER FORWARDTM AF: 7.3% OC: 6.8%
  • 24. DNS usage Alexa Top 10,000 DNS Marketshare - May 6, 2013 Websites (out of 10,000) Marketshar Marketshare e Change Provider +6 / +1.382% AWS Route 53 2 381 3.81% 14 / 3.815% 3 361 3.61% -2 / -0.551% DNSPod 4 336 3.36% 5 / 1.511% CloudFlare 5 314 3.14% 23 / 7.904% 6 287 2.87% -10 / -3.367% 7 246 2.46% 0 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 Source: Cloud Harmony 4.40% Akamai Amazon.com 440 DNS Made Easy Hint: they have a DNS service 1 GoDaddy DNS The only one that doesn’t? DynECT UltraDNS 9 of top 10 run their own DNS. Rank 26 2 0.02% 0 CDNetworks DNS 27 2 0.02% 1 / 100% 3392 33.92% Total ©2013 AKAMAI | FASTER FORWARDTM
  • 25. Alexa Top 1,000 DNS Marketshare - May 6, 2013 Provider DynECT UltraDNS Akamai AWS Route 53 DNSPod DNS Made Easy GoDaddy DNS Cotendo Advanced DNS Verisign DNS easyDNS CloudFlare Rackspace Cloud DNS Namecheap Softlayer DNS Enom DNS Internap Savvis Nettica ClouDNS ZoneEdit DTDNS EuroDNS No-IP Worldwide DNS Total Rank 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Websites (out of Marketsha Marketshare 1,000) re Change 79 7.90% 0 63 6.30% 1 / 1.613% 48 4.80% 0 34 3.40% -1 / -2.857% 32 3.20% 0 21 2.10% 0 14 1.40% 0 11 1.10% -1 / -8.333% 10 1% 0 10 1% 0 8 0.80% 1 / 14.286% 7 0.70% 0 6 0.60% 0 5 0.50% 0 5 0.50% 0 3 0.30% 0 3 0.30% 0 2 0.20% 0 2 0.20% 0 2 0.20% 0 1 0.10% 0 1 0.10% 0 1 0.10% 0 1 0.10% 369 36.90% Fortune 500 DNS Marketshare - May 6, 2013 Provider UltraDNS Verisign DNS Akamai DynECT DNS Made Easy Savvis GoDaddy DNS Internap Rackspace Cloud DNS AWS Route 53 easyDNS No-IP Enom DNS ZoneEdit Rank 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Websites (out of Marketsh Marketshare 500) are Change 36 7.20% 1 / 2.857% 24 4.80% 0 13 2.60% 0 8 1.60% 0 6 1.20% 0 4 0.80% 0 4 0.80% 0 4 0.80% 0 2 0.40% 0 2 0.40% 0 1 0.20% 0 1 0.20% 0 1 0.20% 0 1 0.20% 0 Total 0 Source: Cloud Harmony ©2013 AKAMAI | FASTER FORWARDTM 107 21.40%
  • 26. Asia stats influenced by China Source: Catchpoint DNS direct agents, testing the [ab].ns.facebook.com name servers ©2013 AKAMAI | FASTER FORWARDTM
  • 27. ©2013 AKAMAI | FASTER FORWARDTM
  • 28. IPv6 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. ©2013 http://www.flickr.com/photos/yukop/7350636534/AKAMAI | FASTER FORWARD TM
  • 29. 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 TTL Apps/Browser – receives host/IP, but no TTL. ©2013 AKAMAI | FASTER FORWARDTM
  • 30. Dual stack DNS behavior - basics OS: Windows XP 5.1.2600 Service Pack 3 Connection: tcpopen foo.rd.td.h.labs.apnic.net Avoid data theft and downtime by extending the Time (ms) Packet Activity security perimeter outside the data-center and 0 → DNS Query for AAAA record foo.rd.td.h.labs.apnic.net protect from increasing frequency, scale and 581 ← AAAA response 2a01:4f8:140:50c5::69:72 sophistication 4 → DNS Query for A record for foo.rd.td.h.labs.apnic.net of web attacks. 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
  • 31. Dual stack DNS behavior - basics OS: Mac OSX 10.8.4 (mountain lion) Connection: tcpopen foo.rd.td.h.labs.apnic.net Avoid data theft and downtime by extending the Time (ms) Packet Activity security perimeter outside the data-center and 0 → DNS Query for A record for foo.rd.td.h.labs.apnic.net increasing frequency, scale and protect from 0 → DNS Query for AAAA record foo.rd.td.h.labs.apnic.net sophistication of web attacks. 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
  • 32. DNS failure – Mac – IPv4 + IPv6 - Chrome Device: Mac OSX 10.8.4 (mountain lion), Chrome 27 Connection: 3 name servers, all not responding Time ---0 0 1 0 3 0 1 0 3 0 1 0 3 0 9 0 ---21 Activity ---------> DNS1 A -> DNS1 AAAA -> DNS1 A (retransmit) -> DNS1 AAAA (retransmit) -> DNS2 A -> DNS2 AAAA -> DNS2 A (retransmit) -> DNS2 AAAA (retransmit) -> DNS3 A -> DNS3 AAAA -> DNS3 A (retransmit) -> DNS3 AAAA (retransmit) -> DNS1 A -> DNS1 AAAA -> DNS1 A (retransmit) -> DNS1 AAAA (retransmit) not available because DNS lookup failed ©2013 AKAMAI | FASTER FORWARDTM
  • 33. DNS failure – Mac – IPv4 + IPv6 - Firefox Device: Mac OSX 10.8.4 (mountain lion), Firefox 22 Connection: 3 name servers, all not responding Time ---0 0 1 0 3 0 1 0 3 0 1 0 3 0 9 0 ---21 Activity ---------> DNS1 A -> DNS1 AAAA -> DNS1 A (retransmit) -> DNS1 AAAA (retransmit) -> DNS2 A -> DNS2 AAAA -> DNS2 A (retransmit) -> DNS2 AAAA (retransmit) -> DNS3 A -> DNS3 AAAA -> DNS3 A (retransmit) -> DNS3 AAAA (retransmit) -> DNS1 A -> DNS1 AAAA -> DNS1 A (retransmit) -> DNS1 AAAA (retransmit) “Server not found” ©2013 AKAMAI | FASTER FORWARDTM
  • 34. DNS failure – Mac – IPv4 + IPv6 - Firefox (DNS on IPv6) Device: Mac OSX 10.8.4 (mountain lion), Firefox 22 Connection: 3 name servers, all not responding Time ---0 1 3 1 3 1 3 9 9 1 3 1 3 1 ---39 Activity ---------> DNS1 A, AAAA -> DNS1 (retransmit) -> DNS2 -> DNS2 (retransmit) -> DNS3 -> DNS3 (retransmit) -> DNS1 -> DNS1 (retransmit) -> DNS2 -> DNS2 (retransmit) -> DNS3 -> DNS3 (retransmit) -> DNS1 -> DNS1 (retransmit) “Server not found” ©2013 AKAMAI | FASTER FORWARDTM
  • 35. DNS failure – Mac – IPv4 + IPv6 - Safari Device: Mac OSX 10.8.4 (mountain lion), Safari 6.0.5 Connection: 3 name servers, all not responding Time ---0 1 3 1 3 1 3 9 27 81 243 ... Activity ---------> DNS1 A, AAAA -> DNS1 A, AAAA (retransmit) -> DNS2 A, AAAA -> DNS2 A, AAAA (retransmit) -> DNS3 -> DNS3 (retransmit) -> DNS1 -> DNS1 (retransmit) -> DNS2 -> DNS2 (retransmit) -> DNS3 ©2013 AKAMAI | FASTER FORWARDTM
  • 36. Protocol failure – OS “native” behavior OS: Windows XP 5.1.2600 Service Pack 3 Connection: tcpopen foo.rx.td.h.labs.apnic.net Time 0 581 4 299 3 3000 6000 12000 298 0 -------22185 Activity Avoid data theft and downtime by extending the → DNS AAAA? foo.rx.td.h.labs.apnic.net security perimeter outside the data-center and ← AAAA 2a01:4f8:140:50c5::69:72 → DNS A? foo.rx.td.h.labs.apnic.net protect from increasing frequency, scale and ← A 88.198.69.81 sophistication of web attacks. → SYN 2a01:4f8:140:50c5::69:dead → SYN 2a01:4f8:140:50c5::69:dead → SYN 2a01:4f8:140:50c5::69:dead → SYN 88.198.69.81 ← SYN+ACK 88.198.69.81 → ACK 88.198.69.81 Source: Geoff Huston ©2013 AKAMAI | FASTER FORWARDTM
  • 37. Protocol failure – OS “native” behavior OS: Mac OS X 10.7.2 Connection: tcpopen foo.rxxx.td.h.labs.apnic.net Time 0 4 230 20 3 980 1013 1002 1008 1103 2013 4038 8062 16091 32203 8031 75124 75213 297 0 -------- Activity → DNS AAAA? foo.rxxx.td.h.labs.apnic.net → DNS A? foo.rxxx.td.h.labs.apnic.net ← DNS AAAA 2a01:4f8:140:50c5::69:dead 2a01:4f8:140:50c5::69:deae 2a01:4f8:140:50c5::69:deaf ← A response 88.198.69.81 → SYN 2a01:4f8:140:50c5::69:dead (1) → SYN 2a01:4f8:140:50c5::69:dead (2) → SYN 2a01:4f8:140:50c5::69:dead (3) → SYN 2a01:4f8:140:50c5::69:dead (4) → SYN 2a01:4f8:140:50c5::69:dead (5) → SYN 2a01:4f8:140:50c5::69:dead (6) → SYN 2a01:4f8:140:50c5::69:dead (7) → SYN 2a01:4f8:140:50c5::69:dead (8) → SYN 2a01:4f8:140:50c5::69:dead (9) → SYN 2a01:4f8:140:50c5::69:dead (10) → SYN 2a01:4f8:140:50c5::69:dead (11) → SYN 2a01:4f8:140:50c5::69:deae (repeat sequence of 11 SYNs) → SYN 2a01:4f8:140:50c5::69:deaf (repeat sequence of 11 SYNs) → SYN 88.198.69.81 ← SYN+ACK 88.198.69.81 → ACK 88.198.69.81 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. 226435 Source: Geoff Huston ©2013 AKAMAI | FASTER FORWARDTM
  • 38. 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 Avoid data theft and downtime by extending the IPv4 IPv6 0 → DNS A? www.rd.td.h.labs.apnic.net security perimeter outside the data-center and 1 → DNS AAAA? www.rd.td.h.labs.apnic.net 333 ← AAAA 2a01:4f8:140:50c5::69:72 from increasing frequency, scale and protect 5 ← A 88.198.69.81 sophistication of web attacks. 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
  • 39. 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 theft and downtime by extending the Avoid data 299 ← AAAA 2a01:4f8:140:50c5::69:dead security perimeter outside the data-center and 2a01:4f8:140:50c5::69:deae 2a01:4f8:140:50c5::69:deaf protect from increasing frequency, scale and 2 → SYN 2a01:4f8:140:50c5::69:dead 0 ← A 88.198.69.81 sophistication of web attacks. 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
  • 40. 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 Avoid data theft and downtime by extending the IPv4 IPv6 security perimeter outside the data-center and 0 → DNS A? www.rd.td.h.labs.apnic.net 0 → DNS AAAA? www.rd.td.h.labs.apnic.net protect from increasing frequency, scale and 299 ← A 88.198.69.81 1 ← AAAA 2a01:4f8:140:50c5::69:72 sophistication of web attacks. 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
  • 41. 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 Avoid data theft and downtime by extending the 298 ← AAAA 2a01:4f8:140:50c5::69:dead security perimeter outside the data-center and 0 ← A 88.198.69.81 11 → SYN 2a01:4f8:140:50c5::69:dead (a) protect 0 → SYN 2a01:4f8:140:50c5::69:dead (b) from increasing frequency, scale and 250 → SYN 2a01:4f8:140:50c5::69:dead (c) sophistication of web attacks. 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
  • 42. Dual stack on Mac + Chrome, broken IPv6 OS: Mac OS X 10.8.4 Browser: Chrome 27 Time Activity IPv4 IPv6 Avoid data theft and downtime by extending the 0 → DNS A? www.rd.td.h.labs.apnic.net security 0 → DNS AAAA? www.rd.td.h.labs.apnic.netperimeter outside the data-center and 299 ← A 88.198.69.81 protect from increasing frequency, scale and 1 ← AAAA 2a01:4f8:140:50c5::69:72 1 → SYN 88.198.69.81 (port a) sophistication of web attacks. 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
  • 43. Dual Stack: OS behavior Windows Mac OS (as of Lion) iOS DNS Serial parallel DNS Timeout parallel Preference IPv6 Fastest* 45-60 sec 21* TCP Timeout 21 75 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
  • 44. Dual Stack: Browser IE 9 2 in parallel # of Connections Preference IPv6 Dual stack – No happy eyeballs Serial: wait for timeout Remember yes failed IPs Chrome 2 in parallel + 1 slightly after IPv6 start with IPv6, +300ms IPv4 Firefox 2 in parallel yes yes ©2013 AKAMAI | FASTER FORWARDTM IPv6 In parallel Safari Single connection Fastest (Mac) Start with first, +calc time add second, etc. yes
  • 46. 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 ;; ANSWER SECTION: www.akamai.com. 900 main.akamai.com.edgesuite.net. www-main.akamai.com.edgesuite.net. 900 IN CNAME a152.dscb.akamai.net. 20 IN a152.dscb.akamai.net. 20 IN A IN CNAME www- a152.dscb.akamai.net. A 173.223.232.168 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
  • 47. 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
  • 48. 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
  • 49. What happens when things break? http://www.flickr.com/photos/coast_guard/3220493384/ ©2013 AKAMAI | FASTER FORWARDTM
  • 50. 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
  • 51. ©2013 AKAMAI | FASTER FORWARDTM
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 59. 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
  • 60. 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
  • 61. 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
  • 63. Setting TTLs Alexa top 1000, TTLs of A records: <1m 193 <2.5m <5m 152 34 <10m 229 <1h 169 <5h <1d 154 80% < 1 hour They actually change quite frequently! ©2013 AKAMAI | FASTER FORWARDTM 39 <2d 13 <5d >5d 4 1
  • 64. Setting TTLs • Short enough to accommodate failover • Depends on your DNS performance – too short means more DNS activity • Mobile ©2013 AKAMAI | FASTER FORWARDTM
  • 67. Anycast London 10.0.2.X IX Hong-Kong 10.0.3.X example.com IN NS 10.0.1.1 10.0.2.1 10.0.3.1 NYC 10.0.1.X T1N 67% chance of getting a far resolver! ISP ISP ISP ©2013 AKAMAI | FASTER FORWARDTM
  • 69. CDNs and Distributed Service London 10.0.2.X IX Hong-Kong 10.0.3.X NYC 10.0.1.X T1N ISP ISP ISP ©2013 AKAMAI | FASTER FORWARDTM
  • 70. 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
  • 71. 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
  • 72. 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
  • 73. 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
  • 74. DNSSEC Sample data from a day of DNS traffic of a US based customer: Total Total hits Total IPv6 hits Total DNSSEC hits Total DNSSEC TCP Non DNSSEC TCP • • • • Percentage of DNS hits 4,487,728 204,477 3,552,809 5,344 2,406 Records are cacheable Need to validate only once Some resolvers will not validate… Consider DNSSEC today! ©2013 AKAMAI | FASTER FORWARDTM 100.00% 4.56% 79.17% 0.12% 0.05%
  • 76. 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
  • 77. 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. ©2013 AKAMAI | FASTER FORWARDTM

Notas del editor

  1. http://www.speedawarenessmonth.com/caffeinated-dns-monitoring-and-the-att-dns-outage/http://blog.netdna.com/maxcdn/dns-outage-post-mortem/http://blog.dnsimple.com/incident-report-dns-outage-due-to-ddos-attack/http://www.networkcomputing.com/security/godaddy-outage-a-harsh-reminder-that-ent/240007312
  2. http://www.caida.org/funding/dns-itr/proposal/Image: http://www.caida.org/funding/dns-itr/proposal/Figures/dns_map_2.png
  3. http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records
  4. http://www.flickr.com/photos/dia-a-dia/7046151669/
  5. https://plus.google.com/103382935642834907366/posts/FKot8mghkok
  6. http://blog.cloudharmony.com/2013/05/dns-marketshare-alexa-10000-fortune-500.html
  7. http://www.flickr.com/photos/yukop/7350636534/
  8. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  9. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  10. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  11. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  12. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  13. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  14. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  15. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  16. http://www.potaroo.net/ispcol/2011-12/esotropia.html
  17. Dual stack analysis: http://www.potaroo.net/ispcol/2011-12/esotropia.htmlApple note: http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html
  18. Chrome: https://plus.google.com/103382935642834907366/posts/FKot8mghkokDual stack analysis: http://www.potaroo.net/ispcol/2011-12/esotropia.html
  19. The important part is with the resolvers, not
  20. http://www.flickr.com/photos/keithburtis/2614418536/