LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 01-13-2003, 10:47 PM   #1
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Rep: Reputation: 30
Question Internal DNS Resolution Problem


I am having a weird problem with my internal network's name resolution. I have a name server set up to specifically deal with resolving all of our internal clients, printers, servers, etc... (I am using RedHat 7.2 and Win 98 for the majority of these machines by the way)

Let just say that on a given machine if there isn't an entry in the host file that corresponds to machineX and I ping machineX, I get this as output back from ping.

# ping machineX
PING machineX.mydomain.com (192.168.2.246) from 192.168.2.90 : 56(84) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from 192.168.2.246: icmp_seq=0 ttl=128 time=429 usec
64 bytes from 192.168.2.246: icmp_seq=1 ttl=128 time=9.034 sec
64 bytes from 192.168.2.246: icmp_seq=2 ttl=128 time=18.060 sec
64 bytes from 192.168.2.246: icmp_seq=3 ttl=128 time=27.083 sec
64 bytes from 192.168.2.246: icmp_seq=4 ttl=128 time=36.108 sec
64 bytes from 192.168.2.246: icmp_seq=5 ttl=128 time=45.132 sec
64 bytes from 192.168.2.246: icmp_seq=6 ttl=128 time=54.157 sec
64 bytes from 192.168.2.246: icmp_seq=7 ttl=128 time=63.181 sec

(notice the pattern?)

Now when I have an entry that corresponds to machineX in my host file I receive this output:

# ping machineX
PING machineX (192.168.2.246) from 192.168.2.90 : 56(84) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from machineX (192.168.2.246): icmp_seq=0 ttl=128 time=474 usec
64 bytes from machineX (192.168.2.246): icmp_seq=1 ttl=128 time=247 usec
64 bytes from machineX (192.168.2.246): icmp_seq=2 ttl=128 time=250 usec
64 bytes from machineX (192.168.2.246): icmp_seq=3 ttl=128 time=237 usec
64 bytes from machineX (192.168.2.246): icmp_seq=4 ttl=128 time=245 usec
64 bytes from machineX (192.168.2.246): icmp_seq=5 ttl=128 time=245 usec
64 bytes from machineX (192.168.2.246): icmp_seq=6 ttl=128 time=253 usec

(notice the beautiful pings?)

My resolv.conf file looks like this:

search mydomain.com
nameserver 192.168.2.254

The weird thing is, is that the first line of output from the ping statement (when the given machine is w/o the machineX host file entry):

PING machineX.mydomain.com (192.168.2.246) from 192.168.2.90 : 56(84) bytes of data.

comes back very fast...

Also, when I do something like try to ssh FROM machineX TO this given machine (and I don't have an entry for machineX in this machines host file), it takes forever with respect the time it takes when this given machine has an entry for machineX in it's host file.

I am not certain what to make of this and would love your help in resolving this problem...

Thanks in advance!
 
Old 01-13-2003, 11:57 PM   #2
mcleodnine
Senior Member
 
Registered: May 2001
Location: Left Coast - Canada
Distribution: s l a c k w a r e
Posts: 2,731

Rep: Reputation: 45
I've never seen the time of day warning bfore so I just had to do a google search. Found a lot of Re Hat refences to kernel 2.4.9. This [bug] error can even trigger if there is a difference of microseconds. A workaround is to use ping with the -U switch. A better solution is to update the kernel.

As for your named...
Are you running more than one name server?
How many zones are you hosting?
Running on more than one subnet?
Try 'dig targethost' or 'dig @your.name.servers.name targethost' and see if the replies are the same.
 
Old 01-14-2003, 12:04 AM   #3
DavidPhillips
Guru
 
Registered: Jun 2001
Location: South Alabama
Distribution: Fedora / RedHat / SuSE
Posts: 7,154

Rep: Reputation: 56
that is very strange

try this see what comes back


ping -b -i 5 192.168.2.255
 
Old 01-14-2003, 12:09 AM   #4
DavidPhillips
Guru
 
Registered: Jun 2001
Location: South Alabama
Distribution: Fedora / RedHat / SuSE
Posts: 7,154

Rep: Reputation: 56
It might also be worth adding -R to see the routing
 
Old 01-14-2003, 08:27 AM   #5
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
Quote:
Originally posted by mcleodnine

As for your named...
Are you running more than one name server?
How many zones are you hosting?
Running on more than one subnet?
Try 'dig targethost' or 'dig @your.name.servers.name targethost' and see if the replies are the same.
One name server for internal resolution and one for our externally hosted sites...

Should only be one (besides the root hints and localhost) zone on the internal nameserver but at the moment there are 12. The same zone files that are on our external nameserver are on our internal nameserver plus a zone file for the internal zone (and it's reverse lookup). I am to remove the extra zone files and am to make the internal name server a Non-Authoritative Caching nameserver but am not exactly sure how to do this. I know that basically I only need to have a root hints and localhost zone records to do this. I also need to include my internal zone and it's respective reverse lookup zone as well.

Are there any special directives/keywords that I need to include in my named.conf file to create a Non-Authoritative Caching nameserver?

We have only one subnet at the moment.

And yeah, performing a dig gives my valid/correct info.

Quote:
that is very strange

try this see what comes back


ping -b -i 5 192.168.2.255
ok... all of the output found below is when my host did not have any host file entries...

# ping -b -i 5 192.168.2.255
WARNING: pinging broadcast address
PING 192.168.2.255 (192.168.2.255) from 192.168.2.125 : 56(84) bytes of data.
64 bytes from 192.168.2.101: icmp_seq=0 ttl=255 time=215 usec
64 bytes from 192.168.2.104: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.38: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.254: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.198: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.105: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.27: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.108: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.93: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.116: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.111: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.29: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.152: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.50: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.64: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.103: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.118: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.125: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.247: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.55: icmp_seq=0 ttl=64 time=215 usec (DUP!)
64 bytes from 192.168.2.106: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.100: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.112: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.122: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.63: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.66: icmp_seq=0 ttl=255 time=215 usec (DUP!)
Warning: time of day goes back, taking countermeasures.
64 bytes from 192.168.2.125: icmp_seq=1 ttl=255 time=298 usec
64 bytes from 192.168.2.254: icmp_seq=1 ttl=255 time=406 usec (DUP!)
64 bytes from 192.168.2.247: icmp_seq=1 ttl=64 time=587 usec (DUP!)
64 bytes from 192.168.2.198: icmp_seq=1 ttl=64 time=681 usec (DUP!)
64 bytes from 192.168.2.106: icmp_seq=1 ttl=255 time=774 usec (DUP!)
64 bytes from 192.168.2.55: icmp_seq=1 ttl=64 time=873 usec (DUP!)
64 bytes from 192.168.2.105: icmp_seq=1 ttl=255 time=968 usec (DUP!)
64 bytes from 192.168.2.101: icmp_seq=1 ttl=255 time=1.112 msec (DUP!)
64 bytes from 192.168.2.152: icmp_seq=1 ttl=255 time=1.214 msec (DUP!)
64 bytes from 192.168.2.118: icmp_seq=1 ttl=255 time=1.354 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=1 ttl=255 time=1.451 msec (DUP!)
64 bytes from 192.168.2.116: icmp_seq=1 ttl=255 time=1.590 msec (DUP!)
64 bytes from 192.168.2.64: icmp_seq=1 ttl=64 time=1.689 msec (DUP!)
64 bytes from 192.168.2.104: icmp_seq=1 ttl=255 time=1.786 msec (DUP!)
64 bytes from 192.168.2.29: icmp_seq=1 ttl=64 time=1.885 msec (DUP!)
64 bytes from 192.168.2.93: icmp_seq=1 ttl=255 time=2.036 msec (DUP!)
64 bytes from 192.168.2.100: icmp_seq=1 ttl=255 time=2.175 msec (DUP!)
64 bytes from 192.168.2.27: icmp_seq=1 ttl=255 time=2.279 msec (DUP!)
64 bytes from 192.168.2.50: icmp_seq=1 ttl=64 time=2.376 msec (DUP!)
64 bytes from 192.168.2.38: icmp_seq=1 ttl=255 time=2.517 msec (DUP!)
64 bytes from 192.168.2.108: icmp_seq=1 ttl=64 time=2.617 msec (DUP!)
64 bytes from 192.168.2.111: icmp_seq=1 ttl=255 time=2.715 msec (DUP!)
64 bytes from 192.168.2.103: icmp_seq=1 ttl=255 time=2.812 msec (DUP!)
64 bytes from 192.168.2.112: icmp_seq=1 ttl=255 time=2.944 msec (DUP!)
64 bytes from 192.168.2.122: icmp_seq=1 ttl=255 time=3.048 msec (DUP!)
64 bytes from 192.168.2.63: icmp_seq=1 ttl=255 time=3.149 msec (DUP!)
64 bytes from 192.168.2.66: icmp_seq=1 ttl=255 time=3.247 msec (DUP!)
64 bytes from 192.168.2.125: icmp_seq=2 ttl=255 time=138 usec
64 bytes from 192.168.2.247: icmp_seq=2 ttl=64 time=358 usec (DUP!)
64 bytes from 192.168.2.254: icmp_seq=2 ttl=255 time=512 usec (DUP!)
64 bytes from 192.168.2.105: icmp_seq=2 ttl=255 time=609 usec (DUP!)
64 bytes from 192.168.2.198: icmp_seq=2 ttl=64 time=706 usec (DUP!)
64 bytes from 192.168.2.118: icmp_seq=2 ttl=255 time=802 usec (DUP!)
64 bytes from 192.168.2.55: icmp_seq=2 ttl=64 time=898 usec (DUP!)
64 bytes from 192.168.2.106: icmp_seq=2 ttl=255 time=997 usec (DUP!)
64 bytes from 192.168.2.101: icmp_seq=2 ttl=255 time=1.114 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=2 ttl=255 time=1.214 msec (DUP!)
64 bytes from 192.168.2.64: icmp_seq=2 ttl=64 time=1.314 msec (DUP!)
64 bytes from 192.168.2.116: icmp_seq=2 ttl=255 time=1.411 msec (DUP!)
64 bytes from 192.168.2.29: icmp_seq=2 ttl=64 time=1.511 msec (DUP!)
64 bytes from 192.168.2.93: icmp_seq=2 ttl=255 time=1.629 msec (DUP!)
64 bytes from 192.168.2.111: icmp_seq=2 ttl=255 time=1.727 msec (DUP!)
64 bytes from 192.168.2.38: icmp_seq=2 ttl=255 time=1.827 msec (DUP!)
64 bytes from 192.168.2.100: icmp_seq=2 ttl=255 time=1.924 msec (DUP!)
64 bytes from 192.168.2.50: icmp_seq=2 ttl=64 time=2.029 msec (DUP!)
64 bytes from 192.168.2.152: icmp_seq=2 ttl=255 time=2.149 msec (DUP!)
64 bytes from 192.168.2.104: icmp_seq=2 ttl=255 time=2.247 msec (DUP!)
64 bytes from 192.168.2.27: icmp_seq=2 ttl=255 time=2.347 msec (DUP!)
64 bytes from 192.168.2.112: icmp_seq=2 ttl=255 time=2.441 msec (DUP!)
64 bytes from 192.168.2.103: icmp_seq=2 ttl=255 time=2.558 msec (DUP!)
64 bytes from 192.168.2.63: icmp_seq=2 ttl=255 time=2.657 msec (DUP!)
64 bytes from 192.168.2.108: icmp_seq=2 ttl=64 time=2.756 msec (DUP!)
64 bytes from 192.168.2.122: icmp_seq=2 ttl=255 time=2.853 msec (DUP!)
64 bytes from 192.168.2.66: icmp_seq=2 ttl=255 time=2.950 msec (DUP!)
64 bytes from 192.168.2.125: icmp_seq=3 ttl=255 time=133 usec
64 bytes from 192.168.2.247: icmp_seq=3 ttl=64 time=332 usec (DUP!)
64 bytes from 192.168.2.118: icmp_seq=3 ttl=255 time=476 usec (DUP!)
64 bytes from 192.168.2.105: icmp_seq=3 ttl=255 time=578 usec (DUP!)
64 bytes from 192.168.2.254: icmp_seq=3 ttl=255 time=676 usec (DUP!)
64 bytes from 192.168.2.93: icmp_seq=3 ttl=255 time=771 usec (DUP!)
64 bytes from 192.168.2.198: icmp_seq=3 ttl=64 time=866 usec (DUP!)
64 bytes from 192.168.2.100: icmp_seq=3 ttl=255 time=966 usec (DUP!)
64 bytes from 192.168.2.111: icmp_seq=3 ttl=255 time=1.062 msec (DUP!)
64 bytes from 192.168.2.104: icmp_seq=3 ttl=255 time=1.166 msec (DUP!)
64 bytes from 192.168.2.38: icmp_seq=3 ttl=255 time=1.286 msec (DUP!)
64 bytes from 192.168.2.55: icmp_seq=3 ttl=64 time=1.386 msec (DUP!)
64 bytes from 192.168.2.106: icmp_seq=3 ttl=255 time=1.485 msec (DUP!)
64 bytes from 192.168.2.108: icmp_seq=3 ttl=64 time=1.580 msec (DUP!)
64 bytes from 192.168.2.101: icmp_seq=3 ttl=255 time=1.677 msec (DUP!)
64 bytes from 192.168.2.152: icmp_seq=3 ttl=255 time=1.795 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=3 ttl=255 time=1.893 msec (DUP!)
64 bytes from 192.168.2.116: icmp_seq=3 ttl=255 time=1.993 msec (DUP!)
64 bytes from 192.168.2.112: icmp_seq=3 ttl=255 time=2.091 msec (DUP!)
64 bytes from 192.168.2.64: icmp_seq=3 ttl=64 time=2.192 msec (DUP!)
64 bytes from 192.168.2.122: icmp_seq=3 ttl=255 time=2.310 msec (DUP!)
64 bytes from 192.168.2.29: icmp_seq=3 ttl=64 time=2.411 msec (DUP!)
64 bytes from 192.168.2.103: icmp_seq=3 ttl=255 time=2.508 msec (DUP!)
64 bytes from 192.168.2.50: icmp_seq=3 ttl=64 time=2.606 msec (DUP!)
64 bytes from 192.168.2.63: icmp_seq=3 ttl=255 time=2.723 msec (DUP!)
64 bytes from 192.168.2.27: icmp_seq=3 ttl=255 time=2.822 msec (DUP!)
64 bytes from 192.168.2.66: icmp_seq=3 ttl=255 time=2.923 msec (DUP!)
64 bytes from 192.168.2.125: icmp_seq=4 ttl=255 time=134 usec
64 bytes from 192.168.2.247: icmp_seq=4 ttl=64 time=257 usec (DUP!)
64 bytes from 192.168.2.105: icmp_seq=4 ttl=255 time=356 usec (DUP!)
64 bytes from 192.168.2.254: icmp_seq=4 ttl=255 time=531 usec (DUP!)
64 bytes from 192.168.2.198: icmp_seq=4 ttl=64 time=637 usec (DUP!)
64 bytes from 192.168.2.118: icmp_seq=4 ttl=255 time=737 usec (DUP!)
64 bytes from 192.168.2.50: icmp_seq=4 ttl=64 time=837 usec (DUP!)
64 bytes from 192.168.2.106: icmp_seq=4 ttl=255 time=934 usec (DUP!)
64 bytes from 192.168.2.27: icmp_seq=4 ttl=255 time=1.029 msec (DUP!)
64 bytes from 192.168.2.55: icmp_seq=4 ttl=64 time=1.145 msec (DUP!)
64 bytes from 192.168.2.112: icmp_seq=4 ttl=255 time=1.245 msec (DUP!)
64 bytes from 192.168.2.108: icmp_seq=4 ttl=64 time=1.342 msec (DUP!)
64 bytes from 192.168.2.104: icmp_seq=4 ttl=255 time=1.444 msec (DUP!)
64 bytes from 192.168.2.101: icmp_seq=4 ttl=255 time=1.564 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=4 ttl=255 time=1.666 msec (DUP!)
64 bytes from 192.168.2.29: icmp_seq=4 ttl=64 time=1.763 msec (DUP!)
64 bytes from 192.168.2.122: icmp_seq=4 ttl=255 time=1.857 msec (DUP!)
64 bytes from 192.168.2.152: icmp_seq=4 ttl=255 time=1.977 msec (DUP!)
64 bytes from 192.168.2.63: icmp_seq=4 ttl=255 time=2.074 msec (DUP!)
64 bytes from 192.168.2.64: icmp_seq=4 ttl=64 time=2.172 msec (DUP!)
64 bytes from 192.168.2.38: icmp_seq=4 ttl=255 time=2.272 msec (DUP!)
64 bytes from 192.168.2.93: icmp_seq=4 ttl=255 time=2.369 msec (DUP!)
64 bytes from 192.168.2.100: icmp_seq=4 ttl=255 time=2.486 msec (DUP!)
64 bytes from 192.168.2.116: icmp_seq=4 ttl=255 time=2.585 msec (DUP!)
64 bytes from 192.168.2.111: icmp_seq=4 ttl=255 time=2.684 msec (DUP!)
64 bytes from 192.168.2.103: icmp_seq=4 ttl=255 time=2.781 msec (DUP!)
64 bytes from 192.168.2.66: icmp_seq=4 ttl=255 time=2.879 msec (DUP!)

--- 192.168.2.255 ping statistics ---
5 packets transmitted, 5 packets received, +130 duplicates, 0% packet loss
round-trip min/avg/max/mdev = 0.133/1.352/3.247/0.939 ms



Now if I was to execute a single ping to host 192.168.2.90 I get this:

# ping penguin2
PING penguin2.castlebranch.com (192.168.2.90) from 192.168.2.125 : 56(84) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from 192.168.2.90: icmp_seq=0 ttl=255 time=357 usec
64 bytes from 192.168.2.90: icmp_seq=1 ttl=255 time=27.000 sec
64 bytes from 192.168.2.90: icmp_seq=2 ttl=255 time=54.070 sec
64 bytes from 192.168.2.90: icmp_seq=3 ttl=255 time=81.130 sec

--- penguin2.castlebranch.com ping statistics ---
114 packets transmitted, 5 packets received, 95% packet loss
round-trip min/avg/max/mdev = 0.357/54080.306/108200.195/38258.648 ms


This is so weird...

When compared to the output for this host on the broadcast ping

64 bytes from 192.168.2.90: icmp_seq=0 ttl=255 time=215 usec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=1 ttl=255 time=1.451 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=4 ttl=255 time=1.666 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=3 ttl=255 time=1.893 msec (DUP!)
64 bytes from 192.168.2.90: icmp_seq=2 ttl=255 time=1.214 msec (DUP!)

/me scratches head some more

Thanks for your help! Keep it coming!
 
Old 01-14-2003, 08:37 AM   #6
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
Quote:
Originally posted by DavidPhillips
that is very strange

try this see what comes back


ping -b -i 5 192.168.2.255
# ping -R penguin2
PING penguin2.castlebranch.com (192.168.2.90) from 192.168.2.125 : 56(124) bytes of data.
Warning: time of day goes back, taking countermeasures.
64 bytes from 192.168.2.90: icmp_seq=0 ttl=255 time=420 usec
RR: web5 (192.168.2.125)
192.168.2.90
192.168.2.90
web5 (192.168.2.125)

64 bytes from 192.168.2.90: icmp_seq=1 ttl=255 time=83.200 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=2 ttl=255 time=105.260 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=3 ttl=255 time=132.320 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=4 ttl=255 time=156.380 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=5 ttl=255 time=177.440 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=6 ttl=255 time=198.500 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=7 ttl=255 time=219.560 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=8 ttl=255 time=240.620 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=9 ttl=255 time=261.680 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=10 ttl=255 time=279.500 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=11 ttl=255 time=300.560 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=12 ttl=255 time=321.620 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=13 ttl=255 time=342.680 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=14 ttl=255 time=363.740 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=15 ttl=255 time=381.560 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=16 ttl=255 time=402.620 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=17 ttl=255 time=423.680 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=18 ttl=255 time=444.740 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=19 ttl=255 time=462.560 sec (same route)
64 bytes from 192.168.2.90: icmp_seq=20 ttl=255 time=483.620 sec (same route)

 
Old 01-14-2003, 08:44 AM   #7
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
ok... dig (no pun intended!) this...

# dig penguin2.mydomain.com

; <<>> DiG 9.1.3 <<>> penguin2.mydomain.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13630
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;penguin2.mydomain.com. IN A

;; ANSWER SECTION:
penguin2.mydomain. 518400 IN A 192.168.2.90

;; AUTHORITY SECTION:
mydomain. 518400 IN NS localhost.

;; Query time: 3 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Tue Jan 14 09:41:29 2003
;; MSG SIZE rcvd: 82


now this:

# dig -x 192.168.2.90
;; connection timed out; no servers could be reached

seems like it may be a reverse lookup problem... eh?
 
Old 01-14-2003, 01:32 PM   #8
DavidPhillips
Guru
 
Registered: Jun 2001
Location: South Alabama
Distribution: Fedora / RedHat / SuSE
Posts: 7,154

Rep: Reputation: 56

dig -x 192.168.2.90


try this


dig @dnsserverip -x 192.168.2.90



I think your right, it's something in the dns setup

Last edited by DavidPhillips; 01-14-2003 at 01:33 PM.
 
Old 01-14-2003, 01:37 PM   #9
DavidPhillips
Guru
 
Registered: Jun 2001
Location: South Alabama
Distribution: Fedora / RedHat / SuSE
Posts: 7,154

Rep: Reputation: 56
here's one

Code:
$TTL    86400
@       IN      SOA     ns0.mydomain.com. hostmaster.mydomain.com.  (
                                      12190205   ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
                 NS      ns0.mydomain.com.
1                PTR     ns0.mydomain.com.
10               PTR     www.mydomain.com.
25               PTR     slacker.mydomain.com.
22               PTR     firedragon.mydomain.com.
20               PTR     winxp.mydomain.com.

Last edited by DavidPhillips; 01-14-2003 at 01:39 PM.
 
Old 01-14-2003, 04:34 PM   #10
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
thanks for your help man... things blew up here at work (email) and I have not had a chance to get back to it... you'll see me post tomorrow bout all of this when I get back to it...
 
Old 01-16-2003, 09:57 AM   #11
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
ok... this problem was indeed caused by a problem with reverse zone info...

The person who configured the named.conf file before me had this in the file:

zone "0.2.168.192.in-addr.arpa" {
type master;
file "192.168.2.0.rev";
notify no;
};

This is incorrect! It should read like such:
zone "2.168.192.in-addr.arpa" {
type master;
file "192.168.2.0.rev";
notify no;
};

notice the 0 left off of the zone statement?

Thanks for your help everyone!
 
Old 01-16-2003, 05:16 PM   #12
DavidPhillips
Guru
 
Registered: Jun 2001
Location: South Alabama
Distribution: Fedora / RedHat / SuSE
Posts: 7,154

Rep: Reputation: 56
Good work!
 
Old 01-17-2003, 01:12 PM   #13
WeNdeL
Member
 
Registered: Oct 2002
Location: At my desk...
Distribution: RedHat, Fedora, Ubuntu
Posts: 344

Original Poster
Rep: Reputation: 30
thanks man... whew... what a week...

funny thing is, I still have dns issues to resolve... whoever set my companies dns up didn't do too good a job...

I'll hit that affero button here before too long...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
dhcp internal dns problem snoyl Linux - Networking 0 12-02-2005 05:17 AM
wacky DNS resolution problem Rotwang Linux - Networking 3 04-04-2005 06:04 PM
problem with portage dns resolution jalsk Linux - Software 0 02-07-2005 11:50 PM
Strange DNS Resolution Problem pmconway Fedora 1 11-10-2004 07:37 AM
Linux Internal DNS Problem Help!!!! Sabeer Linux - Networking 6 04-02-2003 01:37 PM


All times are GMT -5. The time now is 02:12 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration