Bizarre Name Resolution/Routing Problem

[Matthew Carpenter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Apparently your nameservers have a lot of "noused" in your reverse
domains:
matt at legolas:~> nslookup 66.207.129.180
<snip>
Non-authoritative answer:
180.129.207.66.in-addr.arpa     name = noused.timesys.com.

Authoritative answers can be found from:
129.207.66.in-addr.arpa nameserver = ns2.aspstation.net.
129.207.66.in-addr.arpa nameserver = ns1.aspstation.net.
ns1.aspstation.net      internet address = 66.207.128.2
ns2.aspstation.net      internet address = 66.207.128.3

matt at legolas:~> host -l 129.207.66.in-addr.arpa ns2.aspstation.net >
129.207.66.in-addr.arpa
matt at legolas:~> grep noused 129.207.66.in-addr.arpa
160.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
162.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
163.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
164.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
174.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
175.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
176.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
178.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
180.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
179.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
182.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
183.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
184.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
185.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
186.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
187.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
188.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.
189.129.207.66.IN-ADDR.ARPA domain name pointer noused.timesys.com.

Your reverse zones indeed are handing out that address.  It doesn't
matter what the forward lookups are.  Are the listed DNS servers under
your control?
If they are an ISP's slaving off your master, perhaps they are not
slaving the reverse zones correctly?

Kurt Wall wrote:

|On Tue, Dec 07, 2004 at 09:02:06PM -0500, David A. Bandel took 94
lines to write:
|
|>Regurgitating the prose of Kurt Wall Kurt Wall <kwall at kurtwerks.com> on
|>Tue, 7 Dec 2004 20:28:19 -0500:
|>
|>|Okay, boys and girls, this one beat all. At work, we're having the
|>|strangest name resolution or routing problem I've yet to encounter.
|>|For the record, the architecture and configuration is legacy stuff
|>|that I/we have to nurse along until we get something better put up.
|>|
|>|We have a Web site, www.timesys.com, a CNAME for timesys.com, which
|>|resolves to 66.207.129.180:
|>|
|>|$ host www.timesys.com
|>|www.timesys.com is an alias for timesys.com.
|>|timesys.com has address 66.207.129.180
|>|
|>|Between the Web server (Apache 1.3.mumble running on Red Hat 3.mumble)
|>|and the Internet sits a firewall device, one of those Watchguard
|>|Firebox gadgets (to which I don't have access). If I traceroute from my
|>|house to the Web site, I get:
|>|
|>|[kwall]$ traceroute www.timesys.com
|>|traceroute to timesys.com (66.207.129.180), 30 hops max, 38 byte
|>|packets
|>| 1  marta (192.168.0.1)  0.496 ms  0.142 ms  0.128 ms
|>|[...]
|>|13  noused.timesys.com (66.207.129.180)  32.169 ms  32.362 ms  29.906
|>|ms
|>|
|>|Note the name: noused.timesys.com. That name doesn't appear anywhere
|>|that I've seen in our DNS files.
|>
|>Where are your DNS files?  If, like your web server, your DNS is behind
|>your firewall, is your hardware firewall capable of doing DNS?
|
|
|Behind the firewall, I believe, or perhaps in the DMZ.
|
|>traceroute gets DNS info the way everyone else in the UNIX world does --
|>via the resolver library and (depending on how /etc/nsswitch.conf is
|>configured) finally from your DNS server.  My guess is that if your DNS
|>server for timesys.com is behind your firewall, and your firewall can't
|>get your DNS servers to answer, it (your firewall) is providing an
|>answer.
|
|
|The wrong answer, evidently.
|
|>I'd run tcpdump port 53 when you web server goes "down" to the world to
|>see if your DNS server is getting/answering external queries (you can
|>also see if those queries are correct).  I'd also do the same from a
|>system outside the firewall to try to trap this noused.timesys.com
|>response and trace it back to the DNS server providing that answer (and
|>likely the wrong A record for your web server).
|
|
|Good idea. That's what I was looking for. Thanks.
|
|>pings (icmp echo requests) are often dropped by firewalls -- the
|>administrators feel "safe" somehow if systems don't respond to pings.
|>try httping (works from here).
|
|
|Yup. I think dropping ICMP echo packets is silly, but I'm just in
charge of
|the Web site, not security policy. I use a wget script with --spider to
|check the site's status.
|
|>|I'm starting to suspect a hardware problem on the firewall, but I
|>|honestly don't know. Anyone have some ideas?
|>
|>sounds more like the firewall "winging it" if it can't get to a nat'd
|>box.  noused.timesys.com is a really bizarre (and syntactically
|>incorrect, should be notused, response).
|>
|>Can you see the traffic/load on the firewall in any way?  Or is this a
|>"black box" literally?
|
|
|To me, it's a black box. I'm sharing admin duties with the real admin;
|I just own the Web site, he installs new things, reconfigures old things,
|keeps every things ( ;-) ) running.
|
|Thanks again,
|
|Kurt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBuS1Eso9lqh4MragRApc+AJ0Re+UYvVxtPNqY+2Xadvfrvn2MSgCaAwGT
ANrLODQ6SB5rH+KA85UMh2A=
=uL3a
-----END PGP SIGNATURE-----