> On 3/12/07, Keith Lofstrom <[log in to unmask]> wrote:
> >This weekend at a motel with free wifi, the nameserver was broken
> >and spewing some incorrect IP addresses ( wikipedia = 1.0.0.0
> >for example ).  Traffic to numeric IP addresses flowed normally.
> >
> >I attempted a workaround by putting known-good nameservers in
> >/etc/resolv.conf .  Unfortunately, I still saw a lot of borked
> >DNS resolution, and surfing and pinging sites that I had attempted
> >before the fix resulted in the same errors.  The errors persisted
> >over a reboot.
 
On Mon, Mar 12, 2007 at 04:18:28PM -0600, Stephen John Smoogen wrote:
> A lot of hotels use DNS proxies and/or network trafficing to make sure
> all/most DNS goes to their ISP's DNS server. I found this at the last
> couple of Motels I have been at.. where putting in any DNS servers or
> using the Caching-nameserver to use the root servers directly..
> didn't. At some hotels, all traffic was lost.. at some I would see it
> in the case of 4 out of 10 or so calls would get routed silently to
> their servers.
> 
> >I recently converted from RH9 2.4.22 to SL4.4 2.6.9 , and I don't
> >know how the new system does DNS resolution (it appears to be in
> >the kernel instead of a separate program like named) and how SELINUX
> 
> Linux usually uses the following system:
> 
> Program calls glibc which calls some subset of named instructions.
> These then use the ips listed in /etc/resolv.conf to grab DNS anmes.
> 
> However in most hotels cases, this doesnt work because while your
> packet thinks its going to say 129.24.8.1.. all UDP for port 53 goes
> to 10.0.0.1 and gets rewritten back to you so it looks like it came
> from 129.24.8.1

So there wasn't really a cache on my machine at all.  Interesting.

This suggests a fix.  I usually set up a VPN back to my server when
I am remote (and it worked this time, too, because I use numeric IP
addresses to get there).  If I use iptables rules to forward all UDP
port 53 traffic to my own server, through the VPN, I can bypass a
balky DNS server.  A little slower, but more reliable.

Thanks for the very helpful response!

Keith

-- 
Keith Lofstrom          [log in to unmask]         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs