DHCP & RDNS

  • Thread starter Thread starter MPaquette
  • Start date Start date
M

MPaquette

Hello all. I am using Windows 2000 Server AD. Why can't I do an nslookup on
an internal IP address and have it resolve to the computer name? Does DHCP
not allow RDNS since it is dynamic therefore possibly always changing?
Thanks.
 
MPaquette said:
Hello all. I am using Windows 2000 Server AD. Why can't I do an nslookup on
an internal IP address and have it resolve to the computer name? Does DHCP
not allow RDNS since it is dynamic therefore possibly always changing?
Thanks.


Not sure what you mean by not being able to use nslookup for internal or external names, forward names or reverse names. TCan you give us an example of what you mean?

Does a reverse zone exist? If so, does a PTR for the client or whatever you are trying to resolve with nslookup, exist?

Also, please provide an unedited ipconfig /all from the DC. This will give us a better idea of the DC's config in relation to the client resolver and what DNS servers are indicated in its config, which will greatly help in diagnosing this issue.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(e-mail address removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay
 
MPaquette said:
Hello all. I am using Windows 2000 Server AD. Why can't I do an nslookup on
an internal IP address and have it resolve to the computer name? Does DHCP
not allow RDNS since it is dynamic therefore possibly always changing?
Thanks.


Not sure what you mean by not being able to use nslookup for internal or external names, forward names or reverse names. TCan you give us an example of what you mean?

Does a reverse zone exist? If so, does a PTR for the client or whatever you are trying to resolve with nslookup, exist?

Also, please provide an unedited ipconfig /all from the DC. This will give us a better idea of the DC's config in relation to the client resolver and what DNS servers are indicated in its config, which will greatly help in diagnosing this issue.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(e-mail address removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay
 
I am only talking about internal lookups. If I go to a command prompt and
type "nslookup 10.1.5.42" (which is my PC) I get the error "can't find
10.1.5.42: Non-existent domain". There is no entry for 10.1.5.42 in the
reverse zone for 10.1.5.0. DHCP is not creating records in the reverse zone
which leads me to my original question. Can DHCP be setup to create revese
zone entries?
 
I am only talking about internal lookups. If I go to a command prompt and
type "nslookup 10.1.5.42" (which is my PC) I get the error "can't find
10.1.5.42: Non-existent domain". There is no entry for 10.1.5.42 in the
reverse zone for 10.1.5.0. DHCP is not creating records in the reverse zone
which leads me to my original question. Can DHCP be setup to create revese
zone entries?
 
MPaquette said:
I am only talking about internal lookups. If I go to a command prompt and
type "nslookup 10.1.5.42" (which is my PC) I get the error "can't find
10.1.5.42: Non-existent domain". There is no entry for 10.1.5.42 in the
reverse zone for 10.1.5.0. DHCP is not creating records in the reverse zone
which leads me to my original question. Can DHCP be setup to create revese
zone entries?

Oh, I see. When nslookup initializes, it will use the first DNS entry in its IP configuration. It will then attempt to resolve the IP to a name. Since the message (not an error) states "can't find 10.1.5.42: Non-existent domain," simply means there is no DNS entry.

By default, yes, if the client requests to register its resource records with DNS, the client is responsible for generating the dynamic UPDATE request per Request for Comments (RFC) 2136. Then, the DHCP server registers its PTR (pointer) record, that is if:

1. A reverse zone exists that matches the client's IP subnet range.
2. Updates are allowed into the zone (Secured Only for AD clients, or unsecured for any machine - AD or non-AD clients).
3. The ONLY DNS server in IP properties is the DNS server that you want to update into, which assuming this is in an AD environment, must be only the internal DC/DNS server(s) that hosts the AD zone. If not an AD environment, same thing applies - it must be the only server(s) that host the zones you need to resolve/register into. This pretty much means you cannot use your router as a DNS address, nor your ISP as a DNS address. That was why I asked for an ipconfig /all to verify your configuration.
4. (Related to #3), if a DHCP client, DHCP Option 006 must only be the DNS server(s) that host the zone.

So you are saying it is not registering into the reverse zone. That is interesting, because it should out-of-the box, so to speak. If the three conditions I pointed out are not met, then I can understand why it is not registering.

Make sure the above works first before going on to the next step in configuring DHCP to update everything for all clients (Windows and non-Windows), because by default, as I stated, DHCP will register the PTR. So please check the conditions and ensure it works. Once you've straightened out any issues, you can force registration at the client by running: ipconfig /registerdns.

To *force* DHCP to update the PTR records, the three conditions must still be met to make sure it is working. Once verified, then:

Open the DHCP properties for the server.
Click the DNS tab, click Properties, and then click to select the Dynamically update DNS A and PTR records only if requested by the DHCP clients check box.
or
Update for all machines, whether they can register or not.

For more specifics and background on how the whole process works, please read the following link:

How to configure DNS dynamic updates in Windows Server 2003 (good for Windows 2000, 2003 and 2008 DNS/DHCP):
http://support.microsoft.com/kb/816592

I hope it helps.

Ace
 
MPaquette said:
I am only talking about internal lookups. If I go to a command prompt and
type "nslookup 10.1.5.42" (which is my PC) I get the error "can't find
10.1.5.42: Non-existent domain". There is no entry for 10.1.5.42 in the
reverse zone for 10.1.5.0. DHCP is not creating records in the reverse zone
which leads me to my original question. Can DHCP be setup to create revese
zone entries?

Oh, I see. When nslookup initializes, it will use the first DNS entry in its IP configuration. It will then attempt to resolve the IP to a name. Since the message (not an error) states "can't find 10.1.5.42: Non-existent domain," simply means there is no DNS entry.

By default, yes, if the client requests to register its resource records with DNS, the client is responsible for generating the dynamic UPDATE request per Request for Comments (RFC) 2136. Then, the DHCP server registers its PTR (pointer) record, that is if:

1. A reverse zone exists that matches the client's IP subnet range.
2. Updates are allowed into the zone (Secured Only for AD clients, or unsecured for any machine - AD or non-AD clients).
3. The ONLY DNS server in IP properties is the DNS server that you want to update into, which assuming this is in an AD environment, must be only the internal DC/DNS server(s) that hosts the AD zone. If not an AD environment, same thing applies - it must be the only server(s) that host the zones you need to resolve/register into. This pretty much means you cannot use your router as a DNS address, nor your ISP as a DNS address. That was why I asked for an ipconfig /all to verify your configuration.
4. (Related to #3), if a DHCP client, DHCP Option 006 must only be the DNS server(s) that host the zone.

So you are saying it is not registering into the reverse zone. That is interesting, because it should out-of-the box, so to speak. If the three conditions I pointed out are not met, then I can understand why it is not registering.

Make sure the above works first before going on to the next step in configuring DHCP to update everything for all clients (Windows and non-Windows), because by default, as I stated, DHCP will register the PTR. So please check the conditions and ensure it works. Once you've straightened out any issues, you can force registration at the client by running: ipconfig /registerdns.

To *force* DHCP to update the PTR records, the three conditions must still be met to make sure it is working. Once verified, then:

Open the DHCP properties for the server.
Click the DNS tab, click Properties, and then click to select the Dynamically update DNS A and PTR records only if requested by the DHCP clients check box.
or
Update for all machines, whether they can register or not.

For more specifics and background on how the whole process works, please read the following link:

How to configure DNS dynamic updates in Windows Server 2003 (good for Windows 2000, 2003 and 2008 DNS/DHCP):
http://support.microsoft.com/kb/816592

I hope it helps.

Ace
 
Thanks for the detailed reply. Allow dynamic updates was set to no on all
reverse zones. Setting it to only secure updates has fixed the problem.
 
Thanks for the detailed reply. Allow dynamic updates was set to no on all
reverse zones. Setting it to only secure updates has fixed the problem.
 
MPaquette said:
Thanks for the detailed reply. Allow dynamic updates was set to no on all
reverse zones. Setting it to only secure updates has fixed the problem.

Good to hear!

Ace
 
MPaquette said:
Thanks for the detailed reply. Allow dynamic updates was set to no on all
reverse zones. Setting it to only secure updates has fixed the problem.

Good to hear!

Ace
 
Back
Top