Re: [gentoo-user] Best caching dns server?

[Alan McKinnon]

On Sun, 20 May 2012 06:15:42 +0530
Nilesh Govindrajan <contact@××××××××.com> wrote:

> On Sat, May 19, 2012 at 10:06 PM, Alan McKinnon
> <alan.mckinnon@×××××.com> wrote:
> > On Sat, 19 May 2012 07:45:56 +0530
> > Nilesh Govindrajan <contact@××××××××.com> wrote:
> >
> >> Hi,
> >>
> >> Which is the best caching dns server? I'm presently using
> >> pdns-recursor, which is quite good, but doesn't have option to set
> >> minimum ttl (doesn't make sense, but some sites like twitter have
> >> ridiculously low ttl of 30s). Also, it isn't able to save cached
> >> entries to file so that it can be restored on next boot. Any
> >> option?
> >
> > You can use almost any cache you want...
> >
> > ... except bind
> >
> > We use unbound. Does the job, does it well, developer very
> > responsive.
> >
> > But do not fiddle with TTLs, that breaks stuff in spectacular ways.
> > Essentially, with the TTL the auth server is saying "We guarantee
> > that you can treat this RR as valid for X amount of time and suffer
> > no ill effects if you do"
> >
> > What you want to do is break that agreement, which is really not s
> > good idea.
> >
> >>
> >> I am keeping my box 24x7 on because it serves as dns on my small
> >> home wifi, not acceptable to me, because network is almost off at
> >> night (only phone) and I have my router as secondary dns.
> >
> > Just use Google's caches or OpenDNS. They do the job so much better
> > than you ever could. Why reinvent the wheel?
> >
> >
>
> Slow connection. See my previous reply to the list. I'm using pdnsd,
> which can persist records and has every damn feature I wanted.
>

Fair enough, but consider this:

If your connection is slow, the only thing you speeded up is the DNS
lookups. Thereafter, everything else is still as slow as it ever was.
And if you feel the need to speed up DNS lookups then the odds are very
good that "everything else" is too slow i.e. not exactly usable.

We get this a lot from our customers too, and the advise we give them
is to look closely at their traffic throttling. In almost every case
all UDP traffic has had the living crap throttled out of it somewhere
by folk that don't really think things through, severely affecting
dns and ntp as well as AV streaming.

Throttled DNS rapidly gets out of hand, IIRC the last time we did some
measurements it only takes around 5% of dns lookups to go wonky for the
situation to rapidly spiral out of control - when dns fails the cache
will try a TCP lookup and that's like wading through molasses.

Our advice to customers is to first unthrottle dns and ntp completely,
give it the highest possible priority (these are extremely light
protocols and seldom show up on the radar when you do this), and see
how that goes.

It just seems to me that you *might* be trying a very unusual solution
for a problem that is better handled one layer lower down.

-- 
Alan McKinnnon
alan.mckinnon@×××××.com