The state of resolv.conf

[Les Mikesell]

Simo Sorce wrote:
> 
>>>> So the answer seems to be that glibc will not change it's simple
>>>> internal resolver (which has more limitations than just noticing
>>>> resolv.conf changes), but the recommendation is that lwresd or a local
>>>> caching nameserver be used for more complex DNS setups.
>>> A caching nameserver that can be instructed what to do when conditions
>>> change is what we really need.
>> Isn't it a little late to redesign the internet so names and addressing 
>> aren't delegated hierarchically?
> 
> What would this mean ?

What it would mean is that could have duplication of names and addresses 
and different nameservers give different results on purpose.  This 
happens with private lans with private addresses and non-registered 
domains and you can sort-of deal with it as long as the private space 
you see is all coordinated and has no overlap with the public.

> But let me ask a question in your own style: do you understand the
> difference between a normal DNS server and a local cache ?

I'm not sure what you mean by the question.  It is very normal for any 
DNS server to also be a local cache.  The issue here is about 'when 
conditions change', which in the context of public DNS is basically 
never - that is, any resolver anywhere will give the same result unless 
you go out of your way to localize it.  I think what we were talking 
about are situations where you have one or more private LAN segments 
with their own private name servers (that can probably also resolve 
public DNS) and your machine is a roaming laptop or you arbitrarily make 
and break VPN connections among the private segments.  In the simple 
roaming case you would let DHCP give you DNS servers that are primary or 
secondary for their private space as well as public resolvers.  In the 
more complicated setup, you can configure named to use different 
forwarders for different private zones.  You won't be able to resolve 
names if your VPN to a forwarder is down, but you wouldn't be able to 
connect there anyway so it's not a big loss.

-- 
   Les Mikesell
     lesmikesell at gmail.com