:: Re: [DNG] Time sync at startup (was…
Top Page
Delete this message
Reply to this message
Author: richard lucassen
Date:  
To: dng
Subject: Re: [DNG] Time sync at startup (was: vdev)
On Mon, 15 Aug 2016 04:21:45 -0700
Rick Moen <rick@???> wrote:

> Quoting richard lucassen (mailinglists@???):
>
> > On my workstations I have no caching DNS.
>
> The term 'caching DNS' doesn't actually mean anything.[1] All DNS
> software _caches_; even the stub resolver in glibc caches. I spoke
> of something different and quite specific: a local recursive
> resolver.


Unbound is a (local) caching resolver. Or a (local) recursive resolver.
But tinydns, which I use for internal resolving is an iterative
resolver. Tinydns does NOT cache at all. And as I use split horizon for
my internal network I have 1 caching resolver and one tinydns:

$ host ssl1.xaq.nl
ssl1.xaq.nl has address 192.168.64.24

$ host ssl1.xaq.nl 8.8.8.8
ssl1.xaq.nl has address 194.109.75.188
ssl1.xaq.nl has IPv6 address 2001:984:c40c:64::24

> And what I was saying is: You should run one on modern networked *ix
> machine generally. Because it's 2016.


I do not agree. If the local machine generates quite a bunch of queries
than you're right. So, if you have (in 2016) let's say forty servers
running in a network, they are all going to query the root servers? I
think it's better to have one resolver that does the job for such a
network. But you're right to install a caching DNS on a server that
makes a lot of queries. I'd use that caching DNS as a forwarder to the
central DNS and not one that is going to bother the root-servers.

> > There is one in the network that's the one that is in dhcpd.conf.
>
> Even DHCP-client hosts can have local recursive resolvers. This is
> useful:
>
> http://qref.sourceforge.net/Debian/reference/ch-gateway.en.html#s-dns-resolvconf
> or
> http://roy.marples.name/projects/openresolv/index


If you do a lot of repetitive queries

> > And even though you have an caching resolver, if your network
> > settings are wrong during boot, there is nothing to be gained with
> > a local resolver ;-)
>
> If you cannot reach _127.0.0.1_ because 'your network settings were
> wrong during boot', you have somehow managed to achieve such an epic
> degree of TCP/IP failure that I'm not sure you should be running *ix
> machines. ;->


Wrong ;-) If your local caching resolver is trying to query the root
servers and it is not able to find its way out, than you will have a
timeout problem.

> Fortunately, I don't think that's even possible.
>
> [1] Here is an article that may help you with terminology, one I wrote
> after one too many person insisted on using the meaningless term
> 'caching nameserver': http://linuxmafia.com/~rick/lan.html


Let me put it this way, it all in how we call things: a caching or a
recursive resolver has, when it starts, an empty cache and NO database.
An iterative resolver has NO cache but just a database.

dnscache is a caching only resolver
tinydns is a simple iterative resolver

BTW: I don't use bind. I like the way Dan Berstein seperates the
recursive and the iterative resolver.

R.

R.

--
richard lucassen
http://contact.xaq.nl/