Re: re Laptop Does Not See eth0 [RESOLVED] [?]

On Sun, Mar 18, 2012 at 10:33:17PM -0700, Bradley D. Thornton wrote:
> On 03/18/2012 05:15 PM, Bengt Richter wrote:
> > On 03/18/2012 11:13 AM Rich Shepard wrote:
> > [...]
> >>
> >> All that's left to do is write a shell script she can run that 
> >> copies /etc/resolv.conf.home to /etc/resolv.conf for use on the 
> >> LAN. Each time the laptop is used at some wifi hot spot it 
> >> overwrites /etc/resolv.conf so I need to restore it for use here 
> >> where we run static IP addresses for the few hosts on the LAN. A 
> >> shell script that runs with /etc/sudoers will do the trick.
> >>
> > Couldn't you just use /etc/hosts ?
> 
> It appears that Rich wants to use DNS, since presumably, he is 
> operating a nameserver with Split Zones, which means it simply 
> reports one set of AUTH data to the general public, and another 
> 'augmented' set of AUTH zone data to a limited amount of clients 
> that includes private or other IPs not intended for the public.
> 
> The problem he's experiencing is due to the DHCP server[s] handing 
> out nameservers that don't have the zone data he desires.
> 
> There's an easy way to address this situation, and that's by 
> incorporating /etc/resolv.conf.head and /etc/resolv.conf.tail 
> files.

Is that a dhcpcd(8) feature? How does this work if the first 
nameserver returns NXDOMAIN for name.internal.example? As best as I 
can tell from resolv.conf(5), that NXDOMAIN would be taken as the 
answer. This probably will not work as intended.

> No messy scripts for non-priv users ;)

I agree there, and would also suggest that this wheel has been 
invented quite a few times. The Debian folk have something called 
"resolvconf", probably kludgy. I'm not familiar with it except as 
much as I have seen them on lists and IRC stumbling around to solve 
this problem.

The clean and DNS-aware solution to this problem is to configure 
dnsmasq(8) to refer queries for internal.example to the proper NS 
host for those names. If that host is reachable, it answers; 
otherwise the queries time out. (That's fine; if the name doesn't 
resolve, you probably can't reach it anyway.)

Your dnsmasq can use external forwarders, the list of which can be 
maintained by dhcpcd, which in turn can use a hook to send a signal 
when that list changes.

Another choice is to run named(8) on the same machine and alternate 
port, to be the upstream resolver for dnsmasq. Then you are never 
stuck having to rely on someone else's questionable nameservers and 
caches.

> I hope that helps!
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: