[NTLUG:Discuss] browser can't resolve some domain names, including google.com
Larry D'Agostino
larrydag at sbcglobal.net
Mon Nov 6 21:33:41 CST 2006
Well here goes. Thanks for the feedback Robert. I'm still a bit baffled.
I have tried adding the nameservers to my resolv.conf file but it seems that
doesn't help either. I'm not sure why. I can ping the nameservers no
problem.
Here is an nslookup of google.com against nameserver. it seems to work OK.
Server: 68.94.156.1
Address: 68.94.156.1#53
Non-authoritative answer:
Name: google.com
Address: 64.233.167.99
Name: google.com
Address: 64.233.187.99
Name: google.com
Address: 72.14.207.99
Yet putting google in my browser doesn't resolve.
Here is my resolv.conf file. Notice it shows my netgear IP 192.168.0.1 which
is correct.
### BEGIN INFO
#
# Modified_by: dhcpcd
# Backup: /etc/resolv.conf.saved.by.dhcpcd.eth0
# Process: dhcpcd
# Process_id: 4353
# Script: /sbin/modify_resolvconf
# Saveto:
# Info: This is a temporary resolv.conf created by service dhcpcd.
# The previous file has been saved and will be restored later.
#
# If you don't like your resolv.conf to be changed, you
# can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This
# variables are placed in /etc/sysconfig/network/config.
#
# You can also configure service dhcpcd not to modify it.
#
# If you don't like dhcpcd to change your nameserver
# settings
# then either set DHCLIENT_MODIFY_RESOLV_CONF=no
# in /etc/sysconfig/network/dhcp, or
# set MODIFY_RESOLV_CONF_DYNAMICALLY=no in
# /etc/sysconfig/network/config or (manually) use dhcpcd
# with -R. If you only want to keep your searchlist, set
# DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp or
# (manually) use the -K option.
#
### END INFO
search site site site
nameserver 192.168.0.1
The dmesg output. As you can see I'm hosting a web server
8139too Fast Ethernet driver 0.9.27
eth0: RealTek RTL8139 at 0xf8ec4000, 00:e0:4c:8f:bd:e1, IRQ 5
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53530 PROTO=TCP SPT=80
DPT=54899 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53676 PROTO=TCP SPT=80
DPT=54899 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53687 PROTO=TCP SPT=80
DPT=54905 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53689 PROTO=TCP SPT=80
DPT=54905 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53691 PROTO=TCP SPT=80
DPT=54905 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=53693 PROTO=TCP SPT=80
DPT=54905 WINDOW=8190 RES=0x00 ACK SYN URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=17364 PROTO=TCP SPT=80
DPT=54899 WINDOW=0 RES=0x00 RST URGP=0
IN=eth0 OUT= MAC=00:e0:4c:8f:bd:e1:00:09:5b:c9:da:a4:08:00 SRC=72.14.203.104
DST=192.168.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=4356 PROTO=TCP SPT=80
DPT=54905 WINDOW=0 RES=0x00 RST URGP=0
ifconfig output. I think this looks good.
eth0 Link encap:Ethernet HWaddr 00:E0:4C:8F:BD:E1
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:375 errors:0 dropped:0 overruns:0 frame:0
TX packets:407 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:195887 (191.2 Kb) TX bytes:52729 (51.4 Kb)
Interrupt:5 Base address:0x4000
ping output of my Netgear router. this looks good too.
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.49 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.19 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.19 ms
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 1.197/1.298/1.499/0.144 ms
ping output of the nameservers 1 and 2
PING 68.94.156.1 (68.94.156.1) 56(84) bytes of data.
64 bytes from 68.94.156.1: icmp_seq=1 ttl=250 time=17.5 ms
64 bytes from 68.94.156.1: icmp_seq=2 ttl=250 time=4.63 ms
64 bytes from 68.94.156.1: icmp_seq=3 ttl=250 time=4.11 ms
--- 68.94.156.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 4.117/8.757/17.515/6.196 ms
PING 68.94.157.1 (68.94.157.1) 56(84) bytes of data.
64 bytes from 68.94.157.1: icmp_seq=1 ttl=250 time=4.68 ms
64 bytes from 68.94.157.1: icmp_seq=2 ttl=250 time=4.21 ms
64 bytes from 68.94.157.1: icmp_seq=3 ttl=250 time=5.10 ms
64 bytes from 68.94.157.1: icmp_seq=4 ttl=250 time=3.89 ms
--- 68.94.157.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3019ms
rtt min/avg/max/mdev = 3.892/4.474/5.106/0.466 ms
netstat -r output
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
On Monday 06 November 2006 08:14 pm, Robert Pearson wrote:
> On 11/6/06, Larry D'Agostino <larrydag at sbcglobal.net> wrote:
> > Answers to your questions below.
> >
> > On Sunday 05 November 2006 11:38 pm, Robert Pearson wrote:
> > > On 11/5/06, Larry D'Agostino <larrydag at sbcglobal.net> wrote:
> > > > resolv.conf shows the nameserver of my router (192.168....). I also
> > > > added the nameservers of my ISP but that didn't help.
> > >
> > > Did you reboot or restart the process that resolves the IP nameservers
> > > after you added them?
> >
> > Yes, pretty sure I have rebooted several times.
> >
> > > You can do this in YaST or direct.
> > > I can't always recall off the top of my head what the process name is,
> > > like now, so I just reboot. Check the /etc/resolv.conf after the
> > > reboot to make sure it didn't get wiped out again.
> > >
> > > Be advised this will happen with SUSE and once you get it working
> > > again make a local copy of the working /etc/resolv.conf. Call it
> > > /etc/resolv.conf-org-DSL or something like that. I always make a copy
> > > of the working /etc/resolv.conf to /etc/resolv.conf-org as a backup.
> > > Use copy (cp) to restore it so you don't lose your backup.
> > >
> > > Do you have static IP's for your machine(s)?
> >
> > No, dynamic
> >
> > > Or do you run DHCP from your Netgear box?
> >
> > Yes
> >
> > > Actually that won't make any difference at all. You get the same
> > > effect if the Netgear is down as the DSL being down. The SUSE OS
> > > writes a new /etc/resolv.conf with no nameservers in it.
> > >
> > > The SUSE OS or the ISP will change your /etc/resolv.conf at will.
> > > If the DSL line is down when you login SUSE will create a new
> > > /etc/resolv.conf file with no nameservers in it because it couldn't
> > > get a network connection to find any.
> > > If you run DHCP there is an option to prevent DHCP from altering the
> > > /etc/resolv.conf file at boot. Be advised it doesn't always work which
> > > is why
> > > on my SUSE machines I keep a backup copy of the /etc/resolv.conf file
> > > after I know it is working.
> > > I am constantly switching between DSL and Cable Modem depending on who
> > > has the best price. I have one of each /etc/resolv.conf saved for each
> > > ISP provider.
>
> Well, since you didn't put anything at the end about it was working I
> will assume it is still broken. It looks like time for DHCPman.
> In my case, once I copied the good, working /etc/resolv.conf file in
> place and rebooted all was well.
>
> You do need to check after the reboot and see if the /etc/resolv.conf
> file is still the same?
>
> Basic stuff:
> Does your network interface get configured properly?
> My DMESG output:
> # /bin/dmesg | grep -i eth
> forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
> eth0 renamed to eth1
> eth0: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0
> eth1: no IPv6 routers present
> martian destination 0.0.0.0 from 192.168.1.1, dev eth1
> martian destination 0.0.0.0 from 192.168.1.1, dev eth1
> martian destination 0.0.0.0 from 192.168.1.1, dev eth1
> martian destination 0.0.0.0 from 192.168.1.1, dev eth1
>
> # /sbin/ifconfig eth1
> eth1 Link encap:Ethernet HWaddr 00:26:54:10:F1:CC
> inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::226:54ff:fe10:f1cc/64 Scope:Link
> UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:12260 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7804 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:16198516 (15.4 Mb) TX bytes:1111903 (1.0 Mb)
> Interrupt:185 Base address:0xc000
>
> 1) Since you have all the IPs, can you ping your Netgear router?
> Mine looks like this:
> # /bin/ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=150 time=0.588 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=150 time=0.588 ms
> ...snip...
>
> 2) Can you ping the nameservers manually?
> Nameserver 1 looks like this:
> #/bin/ping 24.93.41.125
> PING 24.93.41.125 (24.93.41.125) 56(84) bytes of data.
> 64 bytes from 24.93.41.125: icmp_seq=1 ttl=245 time=23.2 ms
> 64 bytes from 24.93.41.125: icmp_seq=2 ttl=245 time=20.5 ms
> ...snip...
>
> Nameserver 2 looks like this:
> #/bin/ping 24.93.41.126
> PING 24.93.41.126 (24.93.41.126) 56(84) bytes of data.
> 64 bytes from 24.93.41.126: icmp_seq=1 ttl=245 time=24.7 ms
> 64 bytes from 24.93.41.126: icmp_seq=2 ttl=245 time=24.7 ms
> ...snip...
>
> 4) What does the output of /bin/netstat -r look like?
> Mine looks like this
> # /bin/netstat -r
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface 192.168.1.0 * 255.255.255.0 U 0 0
> 0 eth1 link-local * 255.255.0.0 U 0 0
> 0 eth1 loopback * 255.0.0.0 U 0 0
> 0 lo default 192.168.1.1 0.0.0.0 UG 0 0
> 0 eth1
>
> Try going into YaST and looking at "Network Services" like "Routing"?
> Then "Security and Users", "Firewall".
>
> Advanced stuff:
> Does your /etc/resolv.conf ever look right after a reboot?
> Mine looks like this:
> ### BEGIN INFO
> #
> # Modified_by: dhcpcd
> # Backup: /etc/resolv.conf.saved.by.dhcpcd.eth1
> # Process: dhcpcd
> # Process_id: 3198
> # Script: /sbin/modify_resolvconf
> # Saveto:
> # Info: This is a temporary resolv.conf created by service dhcpcd.
> # The previous file has been saved and will be restored
> later. #
> # If you don't like your resolv.conf to be changed, you
> # can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no.
> # This variables are placed in /etc/sysconfig/network/config.
> #
> # You can also configure service dhcpcd not to modify it.
> #
> # If you don't like dhcpcd to change your nameserver
> # settings
> # then either set DHCLIENT_MODIFY_RESOLV_CONF=no
> # in /etc/sysconfig/network/dhcp, or
> # set MODIFY_RESOLV_CONF_DYNAMICALLY=no in
> # /etc/sysconfig/network/config or (manually) use dhcpcd
> # with -R. If you only want to keep your searchlist, set
> # DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp
> or # (manually) use the -K option.
> #
> ### END INFO
> search tx.rr.com
> nameserver 24.93.41.125
> nameserver 24.93.41.126
>
>
> Is DHCPCD running on your machine?
> Mine looks like:
> # /bin/ps -ef | grep -i dhcp
> root 3302 1 0 18:47 ? 00:00:00 /sbin/dhcpcd -C -D -K
> -N -t 999999 -h black-magic -c
> /etc/sysconfig/network/scripts/dhcpcd-hook eth1
>
> I am not running true DHCP because I don't have the DHCP client
> running on each machine. So I get dynamic IPs from my Linksys and
> static hostnames. Just one of those projects I got to a level of
> working I could live with and never got back to finalize.
>
> What I am looking for now is a pattern I recognize. If I don't see one
> I will be of no further help. Solving problems remotely works best
> when a pattern can be found or a troubleshooting process exists to
> eliminate possible causes until the "source of the problem" pattern
> emerges.
>
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss
--
= = = = = = = =
Discover more about Linux!
Linuxblogger by larrydag
http://www.linuxblogger.net
= = = = = = = =
More information about the Discuss
mailing list