Contents
Recently, we saw what happened with the botnet attack on Dyn, but instead, let’s talk about a fine day on a happy Beatrix Potter-like Internet, shall we? We start on your local network: your DSL modem (or cable box) is your residential gateway. There’s a little hedgehog inside, helping the hamster in your computer fetch those silly cat photos from the Internet. The problem: your ISP ships you a pretty sad hedgehog inside that residential gateway.
So my modem makes the Internet slow?
When you turn on your home computer, the hamster inside gets a zap, and starts spinning the CPU wheel really fast, providing energy to your network interface. To get a network address, the hamster blows a horn on your network card, requesting an address. This is a DHCP request.
Hearing this DHCP Discovery announcement, the hedgehog in your residential gateway puts on its glasses, straightens his bow-tie, and consults the network address leases ledger. This ledger associates your hamster’s MAC address (like 00:04:3a:af:32:0a ) with an IP address (like 192.168.0.2) He writes the DHCP offer on a slip of oiled paper with india ink and quietly passes the note to the hamster. Inevitably, the ink smears off the note and the hamster will have to blast the horn again. But before the ink smears, the hamster has enough info to fetch a silly cat picture.
What does DHCP have to do with DNS?
Your Linux computer is running dhclient (DHCP client) to ask for an IP address, and your residential gateway is running dhcpd (DHCP daemon). When your computer gets a DHCP Offer, it contains the IP of your network gateway, the IPs of other network gateways, and the IP of a DNS server. This determines where you ask for DNS answers. An offer might contain:
Your Address: 192.168.0.10
Gateway: 192.168.0.1
Options {
1 (Netmask): 255.255.255.0
3 (Router): 192.168.0.1
6 (DNS): 205.171.2.25
51 (Lease time): 86400 seconds
}
And the DNS part?
So when your hamster asks for www.bing.com, it zaps a DNS query to 205.171.2.25. So how do we know that number? Our dhclient daemon rewrites /etc/resolv.conf with that DNS server ip.
$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.0.1 nameserver 205.171.2.25
If you ping 205.171.2.25, you’ll be lucky to get a time as good as 35 milliseconds (ms).
$ ping 205.171.2.25 64 bytes from 205.171.2.25: icmp_seq=1 ttl=60 time=24.1 ms 64 bytes from 205.171.2.25: icmp_seq=2 ttl=60 time=279 ms 64 bytes from 205.171.2.25: icmp_seq=3 ttl=60 time=302 ms 64 bytes from 205.171.2.25: icmp_seq=4 ttl=60 time=325 ms 64 bytes from 205.171.2.25: icmp_seq=5 ttl=60 time=41.1 ms ^C
Compare Google’s DNS:
$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=25.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=129 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=556 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=176 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=200 ms ^C
Compare my residential gateway:
$ ping 192.168.0.1 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=6.12 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=5.46 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=5.32 ms ^C
Compare two hosts on a gigabit Ethernet switch:
$ ping 192.168.100.1 64 bytes from 192.168.100.24: icmp_seq=1 ttl=64 time=0.238 ms 64 bytes from 192.168.100.24: icmp_seq=2 ttl=64 time=0.269 ms 64 bytes from 192.168.100.24: icmp_seq=3 ttl=64 time=0.188 ms
(Looks like the modem I’m at, or the ISP I’m using, probably enforces a rate limit on ICMP. Looks like the first response was at full speed. The further responses were significantly delayed.)
Gone are the days where network times were measured in only milliseconds. A typical time to ping your network gateway on an Ethernet network is about 250 microseconds. So if205.171.2.25 returns an answer immediately, it takes 300.25 ms.
If you try that on a wireless, a ping to your gateway is more likely going to be 6ms, and a DNS result will be 306.25ms. Now repeat that for ten host names referenced in a web page, then you might spend as little as 3 seconds just asking for IPs to start making connections. What you have there is a rather dumb hedgehog.
You can use dig to query for DNS host name lookup times.
$ dig www.bing.com @8.8.8.8 2>&1 | grep -i 'query time' ;; Query time: 249 msec $ dig www.bing.com @205.171.2.25 2>&1 | grep -i 'query time' ;; Query time: 208 msec
Looks like Google and CenturyLink are not so far off, mostly transit time. Let’s compare against our residential gateway:
$ dig www.bing.com @192.168.0.1 2>&1 | grep -i 'query time' ;; Query time: 26 msec $ dig www.bing.com @192.168.0.1 2>&1 | grep -i 'query time' ;; Query time: 152 msec $ dig www.bing.com @192.168.0.1 2>&1 | grep -i 'query time' ;; Query time: 25 msec
Wow, was that inconsistent or what? Now, let’s not be too hasty…that was conducted over a WiFi network. Anytime you do that you can get a series of radio retransmissions…but still. Now I’ll compare it to an Intel Atom powered firewall running dnsmasq:
$ dig www.bing.com @192.168.100.1 2>&1 | grep -i 'query time' ;; Query time: 20 msec $ dig www.bing.com @192.168.100.1 2>&1 | grep -i 'query time' ;; Query time: 0 msec
OH SNAP as my local hedgehogs say, a zero milliseconds query time! Actually, it’s a 236 microsecond response, because that’s our average ping time on that network. This is value of a caching forwarder! Compare the craptastic performance of my ISPs residential gateway: 25 ms is four times longer than a cached response that should look identical to our 6ms ping time.
Upgrading your Hedgehog
DNSmasq is both a DHCPD server and a caching DNS forwarder. It makes your hedgehog smarter. If you set up another computer on your network to serve DHCP and DNS, remember turn off DHCP on your residential gateway. If you get it right, you can get prompt speedup, but if you leave both running, you have dueling hedgehogs confusing your hamster until it passes out! Your computer will get conflicting responses from both DHCP servers and the faster hardware doesn’t always answer first.
Lets setup a Rasberry Pi with a fixed IP of 192.168.0.3 and configure dnsmasq on it. Your new dnsmasq DHCP offer would look like this:
Your Address: 192.168.0.10
Gateway: 192.168.0.1
Options {
1 (Netmask): 255.255.255.0
3 (Router): 192.168.0.1
6 (DNS): 192.168.0.3
51 (Lease time): 86400 seconds
}
Your Rasberry Pi will answer DNS queries by asking 205.171.2.25 if the answer isn’t cached. So the first DNS response is always going to be slowest. But if it takes a snappy hedgehog 1 microsecond to return the cached IP of www.bing.com, your web page with ten host names in it could take 0.21ms (210us) to start downloading.
This performance gain is one reason I prefer move my DNS service away off my residential gateway. I’ll discuss more on using dnsmasq and ideas on splitting up your network devices in further posts.
Related Posts:
The nice tool to benchmark DNS servers
https://github.com/google/namebench