[TriLUG] DNS providers: why bother? was Re: Email Problems
Aaron Joyner
aaron at joyner.ws
Thu Feb 14 23:51:42 EST 2013
I too have run bind at home since I did it on dialup. In addition to
learning a few things about bind along the way, I was able to parlay
those skills into a comfortable existence for myself and my family.
Thus, I can't say enough good things about the value of running bind
at home. :)
That said... there is a valid answer to the Alexey's question:
-----8< snip 8<-----
Am I the only one here that runs their own recursive resolver? ... Why
use some third party service that does who-knows-what sort of
shenanigans?
-----8< snip 8<-----
The answer is basically the same today as it was when us crotchety
old-timers were on dialup. You run a caching DNS server to reduce
latency. You use someone else's nameserver (directly, or as a
forwarder) to further reduce latency, by leveraging a larger cache and
fatter pipes than your own.
Consider the following lookup:
-----8< snip 8<-----
asjoyner at bob:~$ dig +trace www.slashdot.org
; <<>> DiG 9.7.3 <<>> +trace www.slashdot.org
;; global options: +cmd
. 356389 IN NS m.root-servers.net.
. 356389 IN NS d.root-servers.net.
. 356389 IN NS a.root-servers.net.
. 356389 IN NS j.root-servers.net.
. 356389 IN NS f.root-servers.net.
. 356389 IN NS l.root-servers.net.
. 356389 IN NS g.root-servers.net.
. 356389 IN NS k.root-servers.net.
. 356389 IN NS c.root-servers.net.
. 356389 IN NS b.root-servers.net.
. 356389 IN NS i.root-servers.net.
. 356389 IN NS e.root-servers.net.
. 356389 IN NS h.root-servers.net.
;; Received 436 bytes from 10.0.5.1#53(10.0.5.1) in 1 ms
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
;; Received 436 bytes from 192.228.79.201#53(b.root-servers.net) in 80 ms
slashdot.org. 86400 IN NS ns4.p03.dynect.net.
slashdot.org. 86400 IN NS ns2.p03.dynect.net.
slashdot.org. 86400 IN NS ns3.p03.dynect.net.
slashdot.org. 86400 IN NS ns1.p03.dynect.net.
;; Received 120 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 37 ms
www.slashdot.org. 300 IN A 216.34.181.48
slashdot.org. 86400 IN NS ns1.p03.dynect.net.
slashdot.org. 86400 IN NS ns2.p03.dynect.net.
slashdot.org. 86400 IN NS ns4.p03.dynect.net.
slashdot.org. 86400 IN NS ns3.p03.dynect.net.
;; Received 136 bytes from 204.13.250.3#53(ns2.p03.dynect.net) in 31 ms
asjoyner at bob:~$ dig +noall +stats www.slashdot.org @8.8.8.8
;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 22:47:27 2013
;; MSG SIZE rcvd: 50
asjoyner at bob:~$
-----8< snip 8<-----
Note that the initial query done by +trace to the root is basically
free (1 millisecond), your caching DNS server has the addresses of the
roots hard coded. Consequentially, their TTL is meaningless*. The
TTL of the .org TLD, as received from the root nameservers, is pretty
high (2 days). ns/.*/.dynect.net is uncommon enough that you're
probably only resolving it every time you hit slashdot, and it has a
similar TTL (1 day). The www A record has a very low TTL (5 minutes),
which roughly means you'll pay that penalty basically every browsing
session, but only once per session.
Lets say you visit slashdot 3 times per day, morning, at lunch, and
evening. The net effect gained by running a caching nameserver is
that the first time you visit slashdot for each of those sessions, the
DNS query for your initial page load will take ~31ms. That query will
update the TTL of the NS records for dynect.net, saving you from
refreshing that as long as you visit the site once per day. If you
*don't* visit slashdot over the weekend, your first page load on
Monday will cost you an extra ~117ms.
Lets compare-and-contrast that with just using 8.8.8.8. Over the
course of the week, the caching resolver has cost you 357ms (133ms +
(16ms * 14)) versus using 8.8.8.8 directly. That might not seem like
a lot, but as latency from you to where ever you're visting increases,
that can rapidly balloon from tens to hundreds of milliseconds for
every first page load, which starts to become a nuisance.
By the way, the tables can turn if the caching DNS server you choose
is slow. A quick sampling of my ISP (Charter) indicated a very
sporadic 50-90ms query time for www.slashdot.org. In my quick sample,
Google's Public DNS (8.8.8.8) was always 16ms, give or take 2ms. A
coworker (and good friend) of mine, Thomas Stromberg, actually wrote a
simple tool to compare myriad DNS providers as fairly as possible to
help you choose the best choice: http://code.google.com/p/namebench/
So... what if you want to run a nameserver, but don't want to loose
that extra 357ms per week waiting on Slashdot to load? BIND to the
rescue, again! You can setup a 'forwarders' entry in your options
stanza, and for any domain not otherwise configured (eg. not locally
defined), BIND will forward the query to the forwarder, rather than
attempt to do the recursive resolution itself. It will cache whatever
answer it's given by the forwarder indefinitely.
But, but, but... that exposes you to the provider doing *evil* things
in the responses! Well, my first answer would be "don't use an evil
provider, use 8.8.8.8". :) There are some work-arounds you can put
in place to prevent those shenanigans, but nothing quite as fool-proof
as just running your own recursive resolver. There's a very valid
point here that the first time you mistype a URL and land on a
DNS-hijacked page, any seconds it takes you to gracefully recover, and
minutes it takes you to strip or change the forwarders{} entry, would
vastly out weigh any milliseconds you might save on the typical page
load.
Ya' know... I really did originally intend to just make the fun
comment at the top about also having used BIND since the days of
dialup... I'm going to sleep now.
Good night, and good luck.
Aaron S. Joyner
* - A surprise awaits any diligent reader who can explain where the
dig +trace command above gets it's list of the root nameserver
addresses from. :)
More information about the TriLUG
mailing list