Dynamic Update Best Practice?

[Brent]

First off, sorry for the long explanation. Just wondering
what the best practice is considering our experiences
below.

We are upgrading from a nt4 domain to a 2003 AD domain. We
use Netware clustered DHCP and BIND running on EnGarde
Secure Linux. Our DNS admin has allowed dynamic updates in
the "_" zones and in "dyn".xyz.org. The dyn zone was
created for workstations to dynamically register in. We
have a mixture of windows clients. The root domain xyz.org
does not allow dynamic updates. A and PTR records are
created for servers manually in this zone.

We have a couple issues. When workstation primary dns
suffix is set to xyz.org (AD domain name) and connection
specific suffix is set to dyn.xyz.org (through DHCP),
there is a large amount of traffic consisting of errors
trying to update in xyz.org. Workstation registers just
fine in dyn.xyz.org. KB article 240943 explains that this
is the intended action.

Second issue. Workstation primary dns suffix is set to
dyn.xyz.org. AD domain remains xyz.org. DNS suffix search
list was set to xyz.org,dyn.xyz.org. GPO was modified to
push primary dns suffix to workstations. Workstations then
record event id's 5788 and 5789 from netlogon. KB article
258503 explains that these can be corrected. Also, domain
controller's still try to register their "A" records which
are manually created in xyz.org. This can also be
corrected edit the netlogon parameters in the registry.
All of the above actions seem klunky in order just to have
workstation dynamically register in dns.

Do people live with the above or are we just missing
something? For various reasons DNS will stay with BIND and
we do not want to create a "win" (win.xyz.org) child zone
to delegate to a set of Microsoft dns servers for
Microsoft products.

TIA,
Brent

 

[J.C. Hornbeck [MSFT]]

Hi Brent,
Members of domain xyz.org will always try and register in xyz.org by
default. That's just how AD works. You can technically make a member
register in a domain to which it does not belong but that won't really help
resolve your problem. If you're going to disable dynamic updates in the
zone to which the members belong then the only way to stop the warnings and
errors from being logged is to disable dynamic updates entirely on each
computer in the domain.

To disable dynamic updates on a server (assuming it's not also a RAS
client), there are three services which are responsible for dynamic DNS
registrations. If you wish to disable dynamic updates then the properties
of all services that register records will have to modified via the
registry. For example, here are the services involved in different
scenarios:

Stand alone server:
DHCP client service

Domain controller (DC):
DHCP client service
Netlogon service

Domain Controller (DC) running DNS:
DHCP client service
Netlogon service
DNS server service

In the case where we have a DC or a DC running DNS, there is no single
setting or registry entry that will disable all dynamic DNS registrations.
Each service will have to be individually modified to prevent these
registrations from occurring. Here are the registry values involved and
what can be controlled:

The DHCP client service:
------------------------
- All adapters - forward (hostname A) and reverse (PTR) records -
DisableDynamicUpdate.
- All adapters - reverse (PTR) records - DisableReverseAddressRegistrations.
- Per adapter - forward (hostname A) and reverse (PTR) records - advanced
TCP/IP properties on the DNS tab.
- Per adapter - forward and reverse (hostname A and PTR) records -
DisableDynamicUpdate.

The Netlogon service:
---------------------
- All adapters - all records - UseDynamicDns.
- All adapters - forward (hostname A) records - RegisterDnsARecords.

The DNS server service:
-----------------------
- Per adapter - forward (hostname A) records - PublishAddresses.
- Per adapter - forward (hostname A) records - DNS server listening
addresses (found in properties)


What the above also implies is that it is not possible to disable all
registrations on a DC for a particular adapter on a multihomed system. The
only recourse is to disable all registrations after making sure the proper
records exist within DNS.

For more information on these registry values and other details on dynamic
registrations see these knowledge base articles:

1. 178148 (http://support.microsoft.com/?id=178148). This describes how to
disable registrations done by the DHCP client service for all interfaces.

2. 816592 (http://support.microsoft.com/?id=816592). This describes dynamic
registrations for Windows Server 2003 and how to disable DHCP client service
registrations on a per adapter basis.

3. 246804 (http://support.microsoft.com/?id=246804). This describes the
services that register records and the registry keys that effect their
respective behavior.

--
J.C. Hornbeck, MCSE
Microsoft Product Support

NOTE: Please reply to the newsgroup and not directly to me. This allows
others to add to and benefit from these threads and also helps to ensure a
more timely response. Thank you!

This posting is provided "AS IS" without warranty either expressed or
implied, including, but not limited to, the implied warranties of
merchantability or fitness for a particular purpose.

 

[Kevin D. Goodknecht [MVP]]

In

First off, sorry for the long explanation. Just wondering
what the best practice is considering our experiences
below.

We are upgrading from a nt4 domain to a 2003 AD domain. We
use Netware clustered DHCP and BIND running on EnGarde
Secure Linux. Our DNS admin has allowed dynamic updates in
the "_" zones and in "dyn".xyz.org. The dyn zone was
created for workstations to dynamically register in. We
have a mixture of windows clients. The root domain xyz.org
does not allow dynamic updates. A and PTR records are
created for servers manually in this zone.

We have a couple issues. When workstation primary dns
suffix is set to xyz.org (AD domain name) and connection
specific suffix is set to dyn.xyz.org (through DHCP),
there is a large amount of traffic consisting of errors
trying to update in xyz.org. Workstation registers just
fine in dyn.xyz.org. KB article 240943 explains that this
is the intended action.

Second issue. Workstation primary dns suffix is set to
dyn.xyz.org. AD domain remains xyz.org. DNS suffix search
list was set to xyz.org,dyn.xyz.org. GPO was modified to
push primary dns suffix to workstations. Workstations then
record event id's 5788 and 5789 from netlogon. KB article
258503 explains that these can be corrected. Also, domain
controller's still try to register their "A" records which
are manually created in xyz.org. This can also be
corrected edit the netlogon parameters in the registry.
All of the above actions seem klunky in order just to have
workstation dynamically register in dns.

Do people live with the above or are we just missing
something? For various reasons DNS will stay with BIND and
we do not want to create a "win" (win.xyz.org) child zone
to delegate to a set of Microsoft dns servers for
Microsoft products.

TIA,
Brent

A better solution is to use the MS DNS for the DC and delegate the AD
subzones to the MS DNS.
Active Directory DNS is much more secure than BIND anyway.
It is not necessary for clients to register in DNS, but your solution of
creating a separate DDNS zone will work, I would still keep the dynamic DNS
on the Win2k3, you can't beat the security.

If you can't live with MSDNS, you'll be better to post this in a BIND group
to get a viewpoint from BIND users. I cannot recommend you use BIND for
Dynamic DNS due to opening up security issues.