Link to home
Start Free TrialLog in
Avatar of steveriley1310
steveriley1310Flag for United States of America

asked on

losing dns after service network restart

I am on Linux CentOS 5.1. I am not able to resolve domain names after doing "service network restart" even though I have not changed any settings. No errors are reported. I see in /var/log/messages "updated /etc/resolv.conf" and yet resolv.conf before and after restarting the network is the same:

   nameserver 192.168.0.1
   search localdomain

(I don't know why "search localdomain" is there or what it means.)

I'm still able to ping the local interface and the local router. I'm able to ping external IP addresses. So everything is working except dns and dns works before restarting network services.

I have another machine using the same dhcp server. I am able to restart networking on it with no problems. It restarts much faster, if that is any clue, and does not have "search localdomain" in its resolv.conf

Any help is appreciated.

Avatar of omarfarid
omarfarid
Flag of United Arab Emirates image

What about iptables, is it blocking your dns queries? Check for port 53 tcp/udp
Avatar of steveriley1310

ASKER

Thanks for the reply.

No, that is not it. Firewall is off.
You may put the following line in /etc/resolv.conf

domain yourdomain.tld (e.g. mycompanydomain.com)
That did not work. My domain is localdomain.

Do I need to restart networking after each change to /etc/resolv.conf? (I don't think so.)

When I restart networking, I am getting confirming messages to the shell, but it is not writing any lines to /var/log/messages.

The nameserver 192.168.0.1 is my router. I assume it is passing queries to a nameserver at my ISP (Verizon). I don't think anything is wrong with the router since it's working for other machines, but for testing purposes, is there a public DNS server IP address that I can put in resolv.conf?









You don't have to restart network when you update /etc/resolv.conf

Why don't you put the ISP DNS server IP in the /etc/resolv.conf?
ASKER CERTIFIED SOLUTION
Avatar of Arty K
Arty K
Flag of Kazakhstan image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Just to make sure that you dhcp server is providing you with the right DNS try

dhclient ethx //where x is your ethernet card number

You might have a VMserver on one of your PCs that is broadcasting wrong leases
Thanks for the replies.

dhclient eth0 did not work

------------------------

root@localhost:/etc# nslookup google.com 192.168.0.1
;; connection timed out; no servers could be reached

(But I can ping 192.168.0.1)

-------------------------------------------

root@localhost:~# tcpdump -n -vv udp port 53
tcpdump: listening on eth0, link-type EN10MB
(Ethernet), capture size 96 bytes
12:09:45.237736 IP (tos 0x0, ttl  64, id 0, offset 0,
flags [DF], proto: UDP (17), length: 56)
192.168.0.250.32785 > 192.168.0.1.domain: [bad udp
cksum a883!]  58160+ A? google.com. (28)
12:09:50.239336 IP (tos 0x0, ttl  64, id 0, offset 0,
flags [DF], proto: UDP (17), length: 56)
192.168.0.250.32785 > 192.168.0.1.domain: [bad udp
cksum a883!]  58160+ A? google.com. (28)
12:09:55.240434 IP (tos 0x0, ttl  64, id 0, offset 0,
flags [DF], proto: UDP (17), length: 56)
192.168.0.250.32785 > 192.168.0.1.domain: [bad udp
cksum a883!]  58160+ A? google.com. (28)

3 packets captured
6 packets received by filter
0 packets dropped by kernel

--------------------------------------------

After rebooting, it does work:

root@localhost:~# tcpdump -n -vv udp port 53
tcpdump: listening on eth0, link-type EN10MB
(Ethernet), capture size 96 bytes
12:18:35.873026 IP (tos 0x0, ttl  64, id 0, offset 0,
flags [DF], proto: UDP (17), length: 56)
192.168.0.250.filenet-pa > 192.168.0.1.domain: [bad
udp cksum a1fa!]  27716+ A? google.com. (28)
12:18:35.876491 IP (tos 0x0, ttl 248, id 34549, offset
0, flags [DF], proto: UDP (17), length: 104)
192.168.0.1.domain > 192.168.0.250.filenet-pa:  27716
q: A? google.com. 3/0/0 google.com. A 64.233.167.99,
google.com.[|domain]

2 packets captured
4 packets received by filter
0 packets dropped by kernel
> but for testing purposes, is there a public DNS server IP address that I can put in resolv.conf?

I see the problem is in your router, that is not responding by whatever reason. Most likely you should put your Verizon's DNS IP address in /etc/resolv.conf now and test it.

You may ask your ISP what is your DNS IP, if you don't know.
Thanks Guru Nopius. I learned a few things. Will close this down.
Thank you for points, steveriley1310.

But the problem still unresolved or unclear to me.
The difference between 'reboot' and 'network restart' in a number of startup scripts, your Linux is performing. So most probably there are some additional steps on 'reboot' that are not performed in 'network restart' (may be some kind of registration on your router, you may find it by listening network on the router side during reboot and during net restart, then compare what is different).