Velocity 2013: Resolution For A Faster Site

2,172 views
2,019 views

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,172
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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
  • http://www.caida.org/funding/dns-itr/proposal/Image: http://www.caida.org/funding/dns-itr/proposal/Figures/dns_map_2.png
  • http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records
  • http://www.flickr.com/photos/dia-a-dia/7046151669/
  • https://plus.google.com/103382935642834907366/posts/FKot8mghkok
  • http://blog.cloudharmony.com/2013/05/dns-marketshare-alexa-10000-fortune-500.html
  • http://www.flickr.com/photos/yukop/7350636534/
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • Dual stack analysis: http://www.potaroo.net/ispcol/2011-12/esotropia.htmlApple note: http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00009.html
  • Chrome: https://plus.google.com/103382935642834907366/posts/FKot8mghkokDual stack analysis: http://www.potaroo.net/ispcol/2011-12/esotropia.html
  • The important part is with the resolvers, not
  • http://www.flickr.com/photos/keithburtis/2614418536/
  • Velocity 2013: Resolution For A Faster Site

    1. 1. Resolution for a Faster Site How DNS Affects Page Load Time Ido Safruti ido@akamai.com Web Performance Products, Akamai
    2. 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. 3. I’ll also won’t be talking about Daddy’s Nasty Sons ©2013 AKAMAI | FASTER FORWARDTM
    4. 4. Why is DNS important? ©2013 AKAMAI | FASTER FORWARDTM
    5. 5. The phonebook of the Internet ©2013 AKAMAI | FASTER FORWARDTM
    6. 6. We just assume it always works ©2013 AKAMAI | FASTER FORWARDTM
    7. 7. ©2013 AKAMAI | FASTER FORWARDTM
    8. 8. ©2013 AKAMAI | FASTER FORWARDTM
    9. 9. ©2013 AKAMAI | FASTER FORWARDTM
    10. 10. ©2013 AKAMAI | FASTER FORWARDTM
    11. 11. ©2013 AKAMAI | FASTER FORWARDTM
    12. 12. Location of DNS root servers, including anycast nodes, identified by their one-letter names. (2008) ©2013 AKAMAI | FASTER FORWARDTM
    13. 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. 14. Let’s see some Data ©2013 AKAMAI | FASTER FORWARDTM
    15. 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. 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. 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. 18. Nav Timing data ©2013 AKAMAI | FASTER FORWARDTM
    19. 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. 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
    21. 21. 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%
    22. 22. 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%
    23. 23. 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
    24. 24. 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%
    25. 25. Asia stats influenced by China Source: Catchpoint DNS direct agents, testing the [ab].ns.facebook.com name servers ©2013 AKAMAI | FASTER FORWARDTM
    26. 26. ©2013 AKAMAI | FASTER FORWARDTM
    27. 27. 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
    28. 28. 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
    29. 29. 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
    30. 30. 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
    31. 31. 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
    32. 32. 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
    33. 33. 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
    34. 34. 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
    35. 35. 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
    36. 36. 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
    37. 37. 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
    38. 38. 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
    39. 39. 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
    40. 40. 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
    41. 41. 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
    42. 42. 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
    43. 43. 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
    44. 44. http://www.flickr.com/photos/natwilson/4260384198/ ©2013 AKAMAI | FASTER FORWARDTM
    45. 45. 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
    46. 46. 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
    47. 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! Good for high availability? ©2013 AKAMAI | FASTER FORWARDTM
    48. 48. What happens when things break? http://www.flickr.com/photos/coast_guard/3220493384/ ©2013 AKAMAI | FASTER FORWARDTM
    49. 49. 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
    50. 50. ©2013 AKAMAI | FASTER FORWARDTM
    51. 51. 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
    52. 52. 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
    53. 53. 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
    54. 54. 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
    55. 55. 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
    56. 56. 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
    57. 57. http://www.flickr.com/photos/fairfaxcounty/7456122122/ ©2013 AKAMAI | FASTER FORWARDTM
    58. 58. 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
    59. 59. 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
    60. 60. 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
    61. 61. Setting TTLS ©2013 http://www.flickr.com/photos/shortleafiscute/5831167984/ AKAMAI | FASTER FORWARD TM
    62. 62. 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
    63. 63. Setting TTLs • Short enough to accommodate failover • Depends on your DNS performance – too short means more DNS activity • Mobile ©2013 AKAMAI | FASTER FORWARDTM
    64. 64. 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
    65. 65. Anycast London IX Hong-Kong NYC T1N ISP ISP ISP ©2013 AKAMAI | FASTER FORWARDTM
    66. 66. 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
    67. 67. 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
    68. 68. 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
    69. 69. 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
    70. 70. 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
    71. 71. 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
    72. 72. 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
    73. 73. 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%
    74. 74. http://www.flickr.com/photos/keithburtis/2614418536/ ©2013 AKAMAI | FASTER FORWARDTM
    75. 75. 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
    76. 76. 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
    77. 77. Thank you! Ido Safruti, ido@akamai.com

    ×