DNS reverse lookup Server 2003

[william-swc]

Hi,

 

We are having issues with reverse lookup on DNS. The scenario is this:

 

When I run nslookup command in the format "nslookup computername" eg nslookup ot11-wks01, it will contact the primary DNS server and return the correct IP address for that computer, in this example I will use 10.50.23.20 as the returned ip address.

 

If I then run nslookup on the IP address eg nslookup 10.50.23.20 it will return the FQDN of a completely different computer.

 

I believe this to be a reverse lookup problem. It may not seem important but we use 8e6 iR3000 as our web filter and review the websites students are viewing regularly. the r3000 returns IP addresses used to access websites and we need to be able to resolve the ip address to a computer name in order to locate the offending user in the college. We had an occasion recently where a student was falsely accused of accessing a computer in a staff area because nslookup returned the wrong computer name

 

My DNS settings on reverse lookup zones are:

Scavenging time 7 Days (actually another technician has just changed this to 1 hour for testing)

refresh interval 15 mins

expires after 1 day

Minimum Time to Live 1 hour

 

Under DHCP settings the DNS tab is

Enable DNS Dynamic updates (tick)

Always Dynamically update DNS A and PTR records (tick)

Discard A and PTR records when lease is deleted (tick)

Everything else unticked

 

There's alot of information there so thanks for anyone who took the time to read it and I hope someone can help.

[srochford]

I hate DNS for things like this - I don't think I ever really understood it so I just followed the instructions and it did all work in the end.

 

The MS docs are here -http://technet.microsoft.com/en-us/library/cc757041(WS.10).aspx and should help if you follow them through.

 

Plan B is to add something to the user logon script which logs their IP address somewhere. You've then got a much simpler link to who did what (you link IP to user rather than IP to machine and machine to user)

[william-swc]

Hey, thanks for replying. Yea I hate DNS too! Unfortuneatly we can't use Plan B to use a script to link usernames to ip address as we have ercently got a suite of iMacs and have had issues connecting them to our AD structure. According to Apple they are very sensitive to DNS so we need to get this issue resolved to rule out that being an issue there too!

[ind1ekid]

I had a similar issue to this a while ago when I set Squid up for webfiltering. I needed to create various acls in squid based on netbios/fqdn names of clients which meant reverse dns records needed to be accurate.

 

Your heading in the right direction I'd say though. Scavenging more frequently will help. If you have enough addresses to do so in DHCP, maybe increase the lease time? would mean IP addresses werent changing as much, and lesson the problem further.

 

[william-swc]

Ok, I've set scavenging automatically for all zones to 2 hours to see if it clears it up, I will increase this value if and when this is proven to work. I could probably increase DHCP lease if necessary as well, we have loads of IP addressess available.

[william-swc]

Well, I arrived in at work this morning and tried nslookup on the IP address, still returning a different computer. Any ideas?

[HodgeHi]

Reserved Ip addresses and manually entered DNS entries?

 

This is what i used a year ago and everything seemed to work relatively well. This year i have not done it and my DNS is also in a terrible state. I may be going back to doing a manual reserved IP range for the macs at least.

 

You can use the netsh command to create the DHCP scope and add the reserved Ip addresses and associated mac addresses. It can also be scripted. You can also do the same for the DNS entries too.

 

I have the commands somewhere if you're interested.

 

Oh and if you have ARD obtaining a list of the Mac addresses for the macs is a relatively painless task. Just run a report for the network section of the system. This should give you the info you are after along with the name of the machine.

Edited February 25, 2010 by HodgeHi
ARD note

[william-swc]

Hey Hodge, thanks for your suggestion. We tend to move our computers about quite a bit and that means they get assigned different computer names according to their location. It's also the reason why we don't want to go down the static DNS route.

 

I've just notived something interesting..which maybe implies that there is something completely wrong with my DNS settings. I set a computer with a static PTR record in the reverse lookup zone yesterday. I've just performed NSlookup on it's ip address and it has returned a completely different computer......and that's a static record!

 

What could be causing this?

[Jamo]

Can you use wireshark and intercept the DNS request from the PC and see where it is going and who replies? Do you have a rogue DNS server somewhere on the network?!

[william-swc]

Good suggestion! will try that thanks. I'll look for rogue DNS servers, we do have about 6 different DNS servers across 4 geographical sites which replicate frequently over Fibre Optic lines. I'm pretty sure the client is sending the DNS request to the correct server ip address as configured by DHCP but will still follow your suggestion as I'm fast running out of ideas!

[HodgeHi]

What i think happens is that Windows automatically updates the DNS entries when it gets a new IP address from the DHCP Server. Windows clients are allowed to do this as they are part of the Active Directory and therefore as secure updates is usually the default option when setting up AD and DNS, XP can update the records.

 

OS X does not do this. If OS X takes a new DHCP IP then the DNS records do not get updated causing DNS records to become incorrect.

 

If you dual boot your macs you have the same machine with the same mac address with 2 operating systems that behave differently when it comes to IP leasing and DNS updating. I believe this to be the cause of my and maybe your issues. although i may be completely wrong.

 

Take this example:

 

Server1.example.com has an IP address 192.168.1.1

 

DNS entry for this machine is currently 192.168.1.1

 

you run OS X. Th machine obtains a new IP 192.168.1.2. The DNS records do not get updated.

 

You then run XP. In turn Xp gets the new Ip 192.168.1.2 and updates the records accordingly.

 

DNS now reads 192.168.1.2.

 

IIRC if you manually create the reverse lookup records they stay and a new one gets created. So now you have 2 reverse lookup records that point to different IP addresses.

 

I can't remember which way round it is and i always get confused when thinking about this. I haven't looked at my own DNS yet. When i do i will update on my findings.

[william-swc]

I understand what you're saying. We have very few Mac's on the network, in fact there's none on my campus at all. We have recently setup a suite of about 20 iMacs on another campus and none of the iMacs are dual boot. The DNS problem was there before we got the macs, we just didn't have the time to look at it, it's only now when we are trying to perform more frequent audits on internet use and since we got the macs that it has become important to resolve the issue.

 

We had specialists come in to setup the Macs but they didn't know how to update the Active Directory Schema so had to perform work arounds on the Macs which are seperate issues. I knew how to update the schema but as this was taking place on a different site I was never made aware of the issue until the Mac guys had left. If I can get the DNS working perfect on the Windows computers then we can start to look at the problems on the iMacs.

 

Cheers

[ind1ekid]

Does it not return the correct FQDN for anything?

Have you tried deleting the PTR records from the reverse zone then waiting for DHCP to add them back in there .. correctly I'd hope?

[william-swc]

Doen't seem to, any computers I've tried at least. It is an option just to delete all PTR records in reverse lookup but it still doesn't really fix our problem as when we move computers or change names it still won't update dynamically. I haven't had time just yet but am going to investigate the possibility of a rogue DNS server first.

[ind1ekid]

If deleting the current PTR's (im not suggesting do all of them at once ) and waiting for the DHCP leases to renew and add the PTR's, and you still end up with incorrect records then I'd be at a loss

[william-swc]

Well, we don't have a rogue DNS server. I used Wireshark and found that it was requesting DNS lookup from our Domain Controller which is also our DNS server. We are really down to the final option of deleting PTR records.....

[william-swc]

Ok what I have done now is test on my own PC. I looked up DNS and found 2 DNS PTR records for my pc name and also the PTR record associated with my ip address...3 PTR records in total!!!! I deleted them and did ipconfig /release /renew. DNS automatically updated with the correct details!!

 

At last we are getting somewhere! I think the only option we have now is to delete the DNS PTR records gradually throughout the site.

[waldronm2000]

I think this may be related to secure dynamic updates. If I recall correctly, the ACLs that get created for records in AD-integrated zones only allow the owner of the record to update it. This isn't a problem for forward lookups, as the A record belongs to the PC with that name. However, for reverse lookups, the PTR record is tied to the IP address, and this moves as DHCP reallocates the address to different hosts. This may cause problems if the new owner of the IP tries to update the PTR record originally created by a different host. If this is the problem, the solution is to ensure that only the DHCP server updates the PTR records, not the clients. Then delete all the PTR records to ensure that when DHCP leases are renewed the PTR records are created correctly, and owned by the DHCP server.

[ind1ekid]

Ok what I have done now is test on my own PC. I looked up DNS and found 2 DNS PTR records for my pc name and also the PTR record associated with my ip address...3 PTR records in total!!!! I deleted them and did ipconfig /release /renew. DNS automatically updated with the correct details!!

 

At last we are getting somewhere! I think the only option we have now is to delete the DNS PTR records gradually throughout the site.

 

Glad to hear it

[william-swc]

are there any repercussions of just deleting the reverse lookup zone PTR records in one go? surely for accessing network shares the computers use forward lookup?

 

My plan would be to delete them all this afternoon, then when everyone logs in again on Monday DHCP will update the PTR records

[waldronm2000]

Shouldn't cause any major problems to delete your PTR records, as they're mostly an optional extra with DNS anyway, unless you happen to be using them as a basis for web filtering etc. If you're concerned about getting them back up quickly you could create a CMD file that just says IPCONFIG /RENEW, stick it in a share everyone has read-only access to, and use the AT command (or Scheduled Tasks) to run it on each PC in turn. The DHCP renewal should prompt the DHCP server to recreate the PTR records (I think), and as there's no /RELEASE connectivity should not be affected.

 

Incidentally, don't delete the PTR records for any statically configured hosts, or if you do then run IPCONFIG /REGISTERDNS on those to recreate the PTR records.

[william-swc]

I think this may be related to secure dynamic updates. If I recall correctly, the ACLs that get created for records in AD-integrated zones only allow the owner of the record to update it. This isn't a problem for forward lookups, as the A record belongs to the PC with that name. However, for reverse lookups, the PTR record is tied to the IP address, and this moves as DHCP reallocates the address to different hosts. This may cause problems if the new owner of the IP tries to update the PTR record originally created by a different host. If this is the problem, the solution is to ensure that only the DHCP server updates the PTR records, not the clients. Then delete all the PTR records to ensure that when DHCP leases are renewed the PTR records are created correctly, and owned by the DHCP server.

 

Thanks for you contribution, DNS is set to dynamically update from secure sources only and the DHCP server is set to update PTR records not the client. Deleting the PTR records is all there's left to do.

[william-swc]

Incidentally, don't delete the PTR records for any statically configured hosts, or if you do then run IPCONFIG /REGISTERDNS on those to recreate the PTR records.

 

Thanks, yea I know not to delete them. Considering that DHCP is set to update the PTR records, not the client, will the registerdns command still work when run from the client?

[waldronm2000]

Considering that DHCP is set to update the PTR records, not the client, will the registerdns command still work when run from the client?

 

Probably not; that's why you would only use /REGISTERDNS on the statically configured IP hosts (in case you need to recreate the PTRs for those too). The /RENEW from the clients should trigger the DHCP server to recreate the PTR records for the DHCP hosts.

[william-swc]

Doh! Schoolboy error right there! lol Note to self.... static ip's don't use DHCP!!!