Quoting richard lucassen (mailinglists@???):

> 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.

You are correct. tinydns along with other pure authoritative-only
nameservers do not cache. Thus, tinydns (as packaged in either djbdns,
zinq-djbdns, Debian djbdns/dbndns, N-DJBDNS, or LolDNS), dnsjava, gdnsd,
Knot DNS, ldapdns, NSD, rbdldnsd, and YADIFA do not themselves cache
data.

Or at least I'm pretty sure none of them do -- as it would be abnormal
for a pure authoritate-only nameserver to do so. If you know of any
exceptions, please let me know and I'll amend its entry on
http://linuxmafia.com/faq/Network_Other/dns-servers.html, accordingly.

That aside, I'm entirely unsure what your point is. This seems
extremely non-responsive to either the upthread discussion about
timesync at startup _or_ my assertion to you that modern networked *ix
machines really ought to have local recursive resolvers in the general
case. So, what's the relevance, please?


> I do not agree.

You're entitled to your wrong opinion. ;->

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?

If you think merely running a recursive nameserver meaningfully burdens
the root nameservers, let alone causes a net increase in network
traffic, then you really need to learn some DNS.


> If you do a lot of repetitive queries

No, resolvconf or openresolv (and a local recursive resolver) are simply
beneficial to networked *ix servers in the general case. Perhaps you
should try it before expressing such opinions.

OTOH, if you would rather not try it, that's your privilege, too.


> 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.

Excuse me, but the example you gave was of wrong entries in resolv.conf.
That seemed extremely contrived, but my answer was: Don't take a chance
on distant recusive servers being incorrectly specified; put 127.0.0.1
as your first entry in resolv.conf and run a small recursive nameserver
(such as Unbound), and then you _cannot_ have that problem.

Now, you're moving the goalposts to 'your network settings were wrong
during boot' more broadly, and saying 'Ah, but Unbound would be
foiled if it were unable to use network access, so you're mistaken.'
Really, Richard? If you're breaking your system that badly, I believe
you already have a lot bigger problems than Unbound being unable to use
network access.

Unbound would _also_ be unable to reach the root nameservers if you
dropped the running server into a full bathtub of soapy water, as it
turns out. So, maybe, as the old technical support joke phrases it,
'Don't do that, then.' ;->


> 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.

I'm sorry, but choice of nomenclature matters, and calling a piece of
software 'caching DNS' is saying basically nothing, because that's far
too vague to actually mean anything. That's what I was saying. If you
mean recursive, say recursive. If you mean forwarder, say forwarder.
If you mean iterative, say iterative. If you mean authoritative, say
authoritative. Any of those could be 'caching', or not, but saying
'caching' doesn't identify what they actually do.

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

Is there a reason why you were unable to read any of the several links I
provided where I already explained all of this?


> BTW: I don't use bind.

I don't like BIND9 either. Not that that's relevant.

> I like the way Dan Berstein seperates the recursive and the iterative
> resolver.

I like the way the combination of Unbound and NSD separates the
recursive and authoritative servers. (Iterative service sucks.)

Dan doesn't like me, by the way. ;->
http://linuxmafia.com/~rick/faq/dan-brandishing-legal-threats