queer dns access problem

[Stephen Carville]

Bill Tangren wrote:
>> Bill Tangren wrote:
>>>>> -----Original Message-----
>>>> Some ideas:
>>>>
>>>> Turn off firewalling if possible.
>>>>
>>>> Check default route
>>>> # ip route list
>>>> 10.212.166.0/24 dev eth0  proto kernel  scope link  src 10.212.166.26
>>>> 169.254.0.0/16 dev eth0  scope link
>>>> default via 10.212.166.1 dev eth0 <----!!!!
>>>>
>>>> correct if necessary.
>>>>
>>>> Check for UDP connectivity
>>>>
>>>> # nmap -PU -p53 DNS.SERVER.IP.ADDRESS
>>>>
>>>> # traceroute -U DNS.SERVER.IP.ADDRESS
>>>
>>> OK, this is what is produced on the server that works:
>>>
>>> *****
>>> [root at mach2 X11]# ip route list
>>> 169.254.0.0/16 dev eth0  scope link
>>> 10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.1.5.58
>>> default via 10.1.1.2 dev eth0
>> So mach2:eth0 has an IP of 10.1.5.58, right?
> 
> 
> Correct.
> 
> 
>>> [root at mach2 ~]# nmap -PU -p53 10.1.1.6
>>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12
> 15:33
>>> EST
>>> Note: Host seems down. If it is really up, but blocking our ping
> probes,
>>> try -P0
>>> Nmap run completed -- 1 IP address (0 hosts up) scanned in 2.054
> seconds
>>> [root at mach2 ~]# nmap -PU -p53 10.1.1.46
>>> Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2007-12-12
> 15:33
>>> EST
>>> Interesting ports on aurora.timenet.usno.navy.mil (10.1.1.46):
>>> PORT   STATE SERVICE
>>> 53/tcp open  domain
>>> MAC Address: 00:18:8B:38:28:97 (Unknown)
>>>
>>> Nmap run completed -- 1 IP address (1 host up) scanned in 0.295 seconds
>>>
>>> [root at mach2 ~]#
>>> *****
>>>
>>> The server that doesn't looks like this:
>>>
>>> *****
>>> [root at aa-cvs ~]# ip route list
>>> 169.254.0.0/16 dev eth0  scope link
>>> 10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.1.5.58
>>> default via 10.1.1.2 dev eth0
>> and aa-cvs:eth0 also has an IP address of 10.1.5.58, right?
>>
>> See the problem yet?  Same IP address on two nodes?
> 
> 
> Sorry. That's a cut and paste error. It is actually 10.1.5.94. I just
> rechecked.

OK. Is the /8 netmask a cut and paste error too?

Your trouble could be a routing issue: 10.1.5.58/8 and 10.1.1.46/8 are 
on the same subnet as far as the network layer is concerned so there is 
no reason to go to the default route.  Thats why I asked for a 
traceroute too -- or mtr if you have it installed and it will work.

# mtr -rnc 10 DNS.SERVER.IP.ADDRESS

What netmask is the firewall using for the interface?

-- 
Stephen Carville <scarville at landam.com>
Systems Engineer
Land America
1.626.667.1450 X1326
#####################################################################
Ad eundum quo nemo ante iit.