Bizarre Name Resolution/Routing Problem

[Kurt Wall]

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
-- 
X-rated movies are all alike ... the only thing they leave to the
imagination is the plot.