Re: queer dns access problem
- From: "Bill Tangren" <bjt@xxxxxxxxxxxxx>
- Date: Mon, 17 Dec 2007 18:15:31 -0500 (EST)
It sounds like it is a networking issue. If it didn't have the correct
gateway it makes sense that you would be able to access everything locally
on your subnet, but when it comes time to get out of your subnet it
wouldn't know the route to get there. Other possibilities are your
firewall/router just doesn't allow your IP outbound or there is a NAT
mis-configuration. Does your server require a static 1-to-1 NAT or should
it fall into a pool?
The following is why I don't think its a firewall issue.
server a.com is broken.
server b.com is not.
If I change the name and IP address of a.com to match b.com, remove b.com
from the network, and reboot a.com (as b.com), it still has the same DNS
problem. If the firewall was looking to reject a.com traffic, why won't it
work when it is set up like b.com?
Is it possible that this is some bizarre SELinux problem? Perhaps the
resolv.conf or nsswitch.conf file has the wrong context, or something?
I've seen nothing in the logs that would inicate that, but who knows. I'm
not at work right now, so I can't check it until tomorrow. This is the
most bizarre problem I've ever encountered.
----- "Bill Tangren" <bjt@xxxxxxxxxxxxx> wrote:
Earlier you said you could ssh out of the broken box. Can you sshto the
same segment or to a remote network? Can you log in to the boxtwice and
start a packet capture while you attempt a dns lookup? This mightshow us
if it is related to firewalling or routing.
If by the same segment, you mean within the same 10.1.5.x domain, I
can
ssh if I use the IP number to the same segment (there are errors, but
it
ultimately succeeds), but I cannot ssh out of the segment, with or
without
IP number. Also, I can ssh into the broken box from within the
segment.
so
Ian
----- "Bill Tangren" <bjt@xxxxxxxxxxxxx> wrote:
On Dec 13, 2007 8:02 AM, Bill Tangren <bjt@xxxxxxxxxxxxx> wrote:10.1.1.46/8 are
OK. Is the /8 netmask a cut and paste error too?
No, it is correct.
Your trouble could be a routing issue: 10.1.5.58/8 and
on the same subnet as far as the network layer is concerned
athere
is
no reason to go to the default route. Thats why I asked for
stillwork.traceroute too -- or mtr if you have it installed and it will
# mtr -rnc 10 DNS.SERVER.IP.ADDRESS
What netmask is the firewall using for the interface?
When the network guy comes in this afternoon, I'll ask. This
bothdoesn't
explain why it works for one machine, but not the other, when
itare
set
the same.
I am assuming you've done the usual stuff
double checked /etc/resolv.conf
checked /etc/nsswitch.conf
Did these two.
Pinged the default gateway.
Ping is shut off on the gateway. I'll ask the firewall guy to turn
on
long enough to test this.
Checked the network cabling back to the switch.
Yes, other computers work just fine with this cabling.
Checked the patch cable.
Patch cable? What is that?
ifconfig to make sure the interface is actually up.
yep.
ethtool to check that speed and duplex are as expected.
Didn't think to do this. Will try it on Monday.
Can't think of anything else offhand.
Thanks for the help.
--
Stephen Carville
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
- Follow-Ups:
- Re: queer dns access problem
- From: Ian Lists
- Re: queer dns access problem
- References:
- Re: queer dns access problem
- From: Ian Lists
- Re: queer dns access problem
- Prev by Date: Re: queer dns access problem
- Next by Date: Re: queer dns access problem
- Previous by thread: Re: queer dns access problem
- Next by thread: Re: queer dns access problem
- Index(es):
Relevant Pages
|