doing horrible things to dns in the name of science - sf performance meetup

Doing Horrible Things

to DNS(in the name of science)

@sh1mmer SF Perf MeetupThursday, September 23, 2010

The basics of DNS

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

San Francisco - Mission BranchThursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

San Francisco - Main LibraryThursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

New York City - 5th & 42nd BranchThursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

New York City - 5th & 42nd BranchThursday, September 23, 2010

Thursday, September 23, 2010

San Francisco - Main LibraryThursday, September 23, 2010

San Francisco - Main LibraryThursday, September 23, 2010

Thursday, September 23, 2010

San Francisco - Mission BranchThursday, September 23, 2010

San Francisco - Mission BranchThursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

Thursday, September 23, 2010

DNS for performance

Thursday, September 23, 2010

Page Load Time vs. BandwidthThursday, September 23, 2010

Page Load Time vs. Round Trip TimeThursday, September 23, 2010

Trend Curves for Bandwidth vs. RTTThursday, September 23, 2010

Serial HTTP loadingThursday, September 23, 2010

Parallel HTTP loadingThursday, September 23, 2010

Why not just use a bunch of domains?

Thursday, September 23, 2010

DNS QueryingThursday, September 23, 2010

Ideal? 1 domain many threads

Thursday, September 23, 2010

Option 1: SPDY

Thursday, September 23, 2010

Good: Multi-thread TCP connections Bad: Only works on Chrome

Thursday, September 23, 2010

Option 2: Do horrible things to DNS

Thursday, September 23, 2010

Good: Works nowBad: Might have to violate RFCs

Thursday, September 23, 2010

Option 2a - Mucking about with C names

Thursday, September 23, 2010

CNAMES are hosts which are aliases of other hosts

Thursday, September 23, 2010

ajax1.hackerhouse.org. 1800 IN CNAME ajax2.hackerhouse.ajax2.hackerhouse.org. 1800 IN CNAME ajax3.hackerhouse.ajax3.hackerhouse.org. 1800 IN CNAME ajax4.hackerhouse.ajax4.hackerhouse.org. 1800 IN CNAME ajax5.hackerhouse.ajax5.hackerhouse.org. 1800 IN CNAME ajax.hackerhouse.ajax.hackerhouse.org. 1800 IN A 127.0.0.1

Thursday, September 23, 2010

We now have 6 hostnames

Thursday, September 23, 2010

Good: 6 hostnamesBad: Inflexible

Thursday, September 23, 2010

Option 2b - Doing weird things with RRs

Thursday, September 23, 2010

RR is the section of a DNS response which contains the HOST records

Thursday, September 23, 2010

;; QUESTION SECTION:;ajax.hackerhouse.org. IN A

;; ANSWER SECTION:ajax.hackerhouse.org. 60 IN A 184.106.231.91

Thursday, September 23, 2010

;; QUESTION SECTION:;ajax.hackerhouse.org. IN A;ajax1.hackerhouse.org. IN A;ajax2.hackerhouse.org. IN A

;; ANSWER SECTION:ajax.hackerhouse.org. 60 IN A 184.106.231.91ajax1.hackerhouse.org. 60 IN A 184.106.231.90ajax2.hackerhouse.org. 60 IN A 184.106.231.89

Thursday, September 23, 2010

;; QUESTION SECTION:;ajax.hackerhouse.org. IN A

;; ANSWER SECTION:ajax.hackerhouse.org. 60 IN A 184.106.231.91

;; ADDITIONAL SECTION:ajax1.hackerhouse.org. 60 IN A 184.106.231.90ajax2.hackerhouse.org. 60 IN A 184.106.231.89

Thursday, September 23, 2010

Good: FlexibleBad: Caching /Violating RFCs

Thursday, September 23, 2010