:: Re: [DNG] Time sync at startup (was…
Página Inicial
Delete this message
Reply to this message
Autor: Simon Hobson
Data:  
Para: dng@lists.dyne.org
Assunto: Re: [DNG] Time sync at startup (was: vdev)
Steve Litt <slitt@???> wrote:

>> Unless you have just one device on your network, then you should not
>> be running a recursive resolver on each of them - that's just being
>> antisocial to the internet.
>
> What would happen in djbdns' dnscache if you put your LAN's resolver at
> the head of the list of root DNS servers? Is there any way of telling
> dnscache "use this root server if at all possible?"


No experience with either of those.

> My idea, if it's possible, would be a way to have the office-wide
> caching and world resource conservation of a LAN level resolver, but
> still have a complete and capable host resolver.


I suspect the problem with any of the software options is getting something to do "if the resolver exists then use it, otherwise do your own resolving" which is necessary for a nomadic machine - unless you do some scripting to munge the setup each time you move networks.

With Bind, a simple (from memory) "forwarder blah" will tell it that anything it can't resolve locally should be sent to blah. If blah is offline then you'll get no resolving of anything but locally defined zones, and if blah is online then you'll get stuff resolved - but there'll be two levels of caching (local and on blah*).

* assuming, as would be sensible, that blah does caching on anything it resolves.

I do know some Windows people use an "implementation specific undocumented feature" whereby Windows will consult the resolvers you specify in order. This sort of works for split horizon stuff in that they can list an internal (non-recursive) server first, and external ones after that. AIUI it works fine as long as the internal server(s) is never offline - because if it's ever not available, clients move it internally to the bottom of the list and the system breaks :-)

My approach is that, with a small number of special case exceptions, a network should provide a reliable caching resolver for use by devices on that network - and devices on that network should use it. Most of the arguments for a local resolver boil down to "provided service isn't reliable" to which the correct answer is "well then, fix it !"


Oh yes, and another reason for ISPs to provide resolvers for their customer's to use - that provides caching across many many customers - potentially hundreds of thousands of customers, with potentially millions of devices. That's a lot of round trips removed from the system.