Quoting richard lucassen (mailingli...@lucassen.org): > 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng