> On 3/12/07, Keith Lofstrom <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
