[PLUG] DNS resolver cache, and poisoned nameservers
Keith Lofstrom
keithl at kl-ic.com
Mon Mar 12 23:04:14 UTC 2007
PLUGgers:
I forwarded a similar question about borked DNS resolution to
the Scientific Linux mailing group, and got a great response,
forwarded below. My solution might not be available to most
people. However, there might be DNS servers out there on
alternate ports to UDP 53, and a expedient IP tables fix might
work for others, too.
Keith
----- Forwarded message from Keith Lofstrom <keithl at kl-ic.com> -----
> On 3/12/07, Keith Lofstrom <keithl at kl-ic.com> 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 keithl at keithl.com Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
More information about the PLUG
mailing list