The state of resolv.conf

[Les Mikesell]

Nils Philippsen wrote:
> On Tue, 2008-09-16 at 11:23 -0500, Les Mikesell wrote:
>> For private ranges/domain views, you'd normally either have a local DNS 
>>   server configured as primary or secondary for those zones that can 
>> also resolve public addresses, or for roaming vpn users you'd use a 
>> similar central private server that can resolve everything, public or 
>> private while you are connected.  You'll quickly go insane if you try to 
>> mix unrelated private connections (for example, if there really are 
>> different parts of your 10.x.x.x range that don't know about each 
>> other).   If there isn't some 'other' part of your 10.x range, you can 
>> point the whole /8 to a server that knows about the part you use.
> 
> I have a private network which has its own non-public name server. I
> connect to a VPN with "similar" addresses (10.x.y.z) that doesn't know a
> thing about my home network (and neither should it). From my POV, that
> bind still doesn't allow to properly separate responsibilities here is
> an oversight that needs fixing.

As long as someone coordinates addresses on the private ranges you can 
survive, but the internet wasn't designed to permit duplicate addressing 
so you can't expect this to work in general.   In your scenario I'd have 
a local name server set up with the forward and reverse zones for the 
private local zones, with forwarders set for the private zones on the 
VPN pointed to a DNS server there (or, depending on your relationship, 
configure as secondary for those zones).   Likewise, depending on your 
relationship and whether the VPN is up all the time, you can let the DNS 
server on the VPN forward everything thing including public addresses to 
simplify the config, or you can use your ISP's servers, or just go to 
the public yourself.

Named can be configured to do what you want, it just is not graceful 
about dynamic changes.  You might have a complaint if you regularly 
switch your vpn connections among different private networks and had to 
switch the forwarders.

-- 
   Les Mikesell
    lesmikesell at gmail.com