Solved

nslookup not working ?

Posted on 2013-06-06
4
472 Views
Last Modified: 2013-06-13
Can someone explain why the ping resolves but
when doing nslookup, it does not do a reverse
dns to search for the hostname of the given IP ?

Refer to below:

D:\>ping nnxxxhp1vir03.ggg.local

Pinging nnxxxhp1vir03.ggg.local [10.41.169.204] with 32 bytes of data:
Reply from 10.41.169.204: bytes=32 time<1ms TTL=128
Reply from 10.41.169.204: bytes=32 time<1ms TTL=128

Ping statistics for 10.41.169.204:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C
D:\>nslookup 10.41.169.204
Server:  nnnputl30-pppp.ggg.local
Address:  10.50.139.18

*** nnputl30-pppp.ggg.local can't find 10.41.169.204: Non-existent domain

D:\>
0
Comment
Question by:sunhux
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
4 Comments
 
LVL 9

Assisted Solution

by:EMJSR
EMJSR earned 120 total points
ID: 39226602
You can also try and use "ping -a <ip address>". That also does a reverse lookup on an IP.

Not all hosts are configured to allow for reverse lookup. So if you do not get a response, it's an issue with the host, not nslookup.

You can test this by doing a ping on "google.com" and then try "ping -a" and "nslookup". It works just fine.
0
 
LVL 4

Assisted Solution

by:apreed
apreed earned 130 total points
ID: 39227042
Your DNS server for ggg.local needs to have a Reverse DNS record (PTR) that is named with the IP address in reverse order... something like 204.169.41.10.in-addr.arpa
This record will contain the hostname

Have a look in your DNS server. If this record isn't there, you'll not get a name back from the IP.

Reverse lookup isn't set up by default on AD: Technet Article
0
 
LVL 40

Accepted Solution

by:
footech earned 130 total points
ID: 39228302
Why does the ping resolve?  Because it is using the A record to resolve the hostname to an IP and then showing that information.  In your nslookup you're trying to resolve an IP to a hostname.  If you ran nslookup nnxxxhp1vir03.ggg.local then you would get the same IP info back as your ping command.
As EMJSR mentioned, you can use ping -a <IP> to resolve an IP to a hostname.  In your case, if you used ping -a 10.41.169.204, the ping would still work, but it wouldn't display any info about the hostname, same as your nslookup command because there isn't a PTR record for that IP.

I can tell from your nslookup output that you have at least one Reverse Lookup Zone (probably for 10.50.139.x).  Once a zone is set up with a range that matches the IP of a server/workstation, in most cases the records will be created automatically in that zone either by DHCP or the server/workstation itself (if configured statically).  So if you created a new zone for 10.41.169.x, after a while you should see a PTR record created automatically for 10.41.169.204, unless it was some device like a printer, etc. that is configured statically and doesn't register its own records.
0
 
LVL 9

Assisted Solution

by:Zenvenky
Zenvenky earned 110 total points
ID: 39228772
Ping contacts Host and LMHost files and DNS cache to resolve any IP to name or Name to IP. Where as NSLookup directly contacts DNS Server to get the information. In this case 10.41.169.204 does not have any records in DNS server.
0

Featured Post

Major Incident Management Communications

Major incidents and IT service outages cost companies millions. Often the solution to minimizing damage is automated communication. Find out more in our Major Incident Management Communications infographic.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Did you know that more than 4 billion data records have been recorded as lost or stolen since 2013? It was a staggering number brought to our attention during last week’s ManageEngine webinar, where attendees received a comprehensive look at the ma…
Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

737 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question