[nycbug-talk] Split Horizon DNS

[Miles Nordin]

>>>>> "mj" == Matt Juszczak <matt at atopia.net> writes:

    mj> -two servers configured to forward onto ISP nameservers

I used to do this but don't now.  It's a nice idea, but for me causes
more problems than it solves.  DNS turns out not to be among the big
problems with making things web scale, so the elaborate tree of
caching resolvers early advocates envisioned probably isn't
necessary---one cache per user, or one cache per handful of users,
should be fine.  no cache is of course not fine at all.  It's slow and
it's being a bad neighbor.  In fact I think it'd be good if bind wrote
its cache to disk across restarts, but I don't know of any resolver
that does this.  But if you are using ISP forwarders instead of
unleashing your recursive resolvers onto the internet directly to be
neighborly, I think your etiquette is somewhat obsolete.

If your ISP is nationwide and has a cluster of nameservers at
``national headquarters'' instead of spreading recursive resolvers
over all their POP's, then you are much better running your own
recursive resolver and not using forwarding because (a) you get lower
latency on the queries themselves and (b) many CDN's will end up
serving you better because they'll know where you are.

    mj> "domain name".int

use a TLD that is not already in use on the internet.  .int is in use
so that's a very bad choice.  also do not use .local

just say 'dig int. ns' and you can see that it's in use already.

    mj> timeout of 1 set in /etc/resolv.conf

that's a nice idea, and not necessarily a bad one.

However please do understand the timeout isn't for your internal
servers---it's for the whole process of resolution.  There's no way
for the resolver to tell the difference between a recursive resolver
that's down and a name that honestly takes a long time to resolve.
so, if you are behind a slow pipe with a big FIFO buffer (DSL, T1), or
if the other guy's authoritative servers are really slow, or if one of
the authoritative servers is down and BIND's recursive resolver
timeout is taking longer than 1 second (yes I think it is) to move on
to the next redundant nameserver, then you won't be able to resolve
those slow domains at all.  at least not the first time.  If the data
is cacheable maybe you can press ``reload'' and try again after the
query finishes behind the scenes.  But there seems to be some caching
inside Firefox itself too which could fuck you. :(

If you had the slave use the master as a forwarder, then your timeout
for the overall external process becomes 2 seconds, but I think this
is a loss overall.  First it's not much longer.  Second if done
stupidly it destroys the redundancy you wanted---may as well just list
the master.  Even if done smartly so the slave can be made to forward
first, then try to resolve on its own, it's still a loss: What you
want to avoid most with resolver-side DNS redundancy is a situation
where every lookup takes 4 - 30 seconds.  (ex. what facebook was
causing by blackholing AAAA queries instead of returning NXDOMAIN. but
they fixed it.)  This is what really pisses people off.  really you
need a failover stratagy that's stateful lower down in the resovler
tree---right now we only have state in the caches, which is too far
up, beyond the point where you put your redundancy.  IMHO with most
OS's you may as well just mention one nameserver because if it ever
has to move onto the second, it would be better to fail outright and
get attention than silently work in this severely broken/slow way.
the type of resolver redundancy that would work is anycast or CARP or
something like that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20090514/72f37371/attachment.bin>