dynamic DNS

bighornsheep

I'm playing around with DDNS in my lab. I configure DDNS options in DHCP, and configured secure DDNS in DNS MMC. (Both services run on a win2k3 DC)

I'm testing this feature with a win2k pro (SP4) client, so I've added the DC to be a DNSupdateproxy, and configured the creditial. It seems to be "working properly" as in I can change the IP on the client, and the changes is updated on the win2k3 DNS server, however I can't locate this record in the DNS snap in. I have a single domain forest, so there's really only one place it should be at. I've checked the HOSTS file, and it's not there....did I set something wrong?

bighornsheep

bump...

any ideas? the subnet has the updated ip with nslookup...but where is the record kept?

sprkymrk

bighornsheep wrote:

It seems to be "working properly" as in I can change the IP on the client, and the changes is updated on the win2k3 DNS server, however I can't locate this record in the DNS snap in.

I'm actually a lttle confused bighornsheep, if you can "see" that the IP is updated on the DNS server, what do you mean by not being able to locate it? Can you rephrase your question?

bighornsheep

I can see that the IP is updated because ping resolves the host's FQDN after a DNS flush, however, the A record can not be found in DNS snap in. The IP is definitely updated on DNS server because clients in the subnet that uses the DNS service reponds the same to ping.

sprkymrk

I've never seen that. Actually, never thought to look for it. Are we talking a long time to update, never update, or what?

Have you checked out this:
http://support.microsoft.com/kb/816592

bighornsheep

I didnt use that page, but I just took a look at it, and it's what I had done following my 291 books. Except for this:

You can use the DHCP server to register and update the PTR and A resource records on behalf of the server's DHCP-enabled clients. When you do this, you must use an additional DHCP option, the Client FQDN option (option 81). This option lets the client send its FQDN to the DHCP server in the DHCPREQUEST packet. This enables the client to notify the DHCP server as to the service level it requires.

I understood the rest and I had done 'em. The A record was never created as far as I know.

bighornsheep

bighornsheep wrote:

The A record was never created as far as I know.

n/m....I just double checked my WINS server on a second win2k3 member server, it seems it's updated there...that's why the record fail to exist, but name resolution still works....sigh...

I'll re-try my procedures for DDNS with the technet page....I must have done something incorrectly.

can WINS and DDNS co-exist? and could you please explain the option 81?

sprkymrk

bighornsheep wrote:

and could you please explain the option 81?

microsoft wrote:

This option lets the client send its FQDN to the DHCP server in the DHCPREQUEST packet. This enables the client to notify the DHCP server as to the service level it requires.

Also:
http://www.iana.org/assignments/bootp-dhcp-extensions/

royal

Yes, they can co-exist. The dns client on a client machine will try dns first always. If that fails, the dns client service hands over control to netbios. When you join a domain, you get a primary dns suffix by default (domain.com). When you do a ping computername, it actually uses the primary dns suffix and then your dns suffix search list afterwards if nothing was found.

Basically, let me draw it out how query lookups work when both machines are on the same domain and both machines have the primary dns lookup as domain.com

ping server1
Automatically appends domain.com to the end. It then tries to ping server1.domain.com.
If that fails, it will try the dns suffix search list. If that fails, if dns has a wins forward lookup record, dns will contact wins and search (helpful for non-windows clients that can only use dns and can't use wins).
If you don't have a wins forward lookup, your clients dns service will hand off control to netbios. Netbios will then do its thing depending on its configuration (0x1, 0x2, 0x4, or 0x. If you're using hybrid, it will look at wins first and if no record is found in wins, your client will then try to do a netbios broadcast to try to find the machine.
If that doesn't work, then failure.

Hope this helps!