Golden Rules for Windows 2000-Test

Logon Process

 

When a Directory Serv ice s-aware client logs onto the network, the following process is performed:

1.     The client will activate its IP address, either from a static assigned address or from a DHCP server.

2.     The client will query the DNS server for SRV resource records for its domain. The DNS query will be formulated based on existing information. If the client knows which site it is currently in, it will query for a domain controller in its site.

3.     The client will then send UDP requests to each domain controller returned by the DNS server. The first domain controller in the client’s site that responds will be used by the client for authentication of the user’s credentials. If a domain controller in the client’s site cannot be found, the client will use a domain controller outside of the site until a domain controller in the same site is available.

4.     The client will use the NetLogon process to authenticate both the user and the computer account (if running Window NT or Windows 2000).

5.     The domain controller will look up the user object in Active Directory to determine the SID of the user and the SID of all group memberships.

6.     If the domain is in Native mode, the authenticating domain controller will query a global catalog server to determine if the user is a member of any universal groups.

 

Note

The global catalog server is also queried by the authenticating domain controller if the user logon name provided is in the form of a User Principal Name (UPN) to determine which domain and account the UPN is associated with.

 

7.     The user’s access token is populated with all group information (including universal groups returned from the global catalog server) and passed to the client.

 

When planning for logon traffic affected by an upgrade, the following points should be considered:

Ensure that sites and subnets have been implemented to ensure that domain controllers exist at every site where Active Directory-aware clients will be deployed.

Ensure that a domain controller is located at each site where Active Directory-aware clients will be deployed to ensure that local authentication takes place.

Ensure that a global catalog server is deployed at remote sites. This is especially important if the domain is in Native mode. If the authenticating domain controller cannot contact a global catalog server to determine universal group membership, the client can only be logged on using cached credentials.

 

Note

If the Active Directory deployment is a single domain, the global catalog server will not be required in Native mode to determine universal group membership since all membership will be stored in the Active Directory domain. The authenticating domain controller will determine that there is only a single domain in the environment by inspecting the Configuration Naming Context.

 

Windows 2000 domain controllers will be able to authenticate downlevel client authentication requests.

For clients not using the DS Client software, WINS servers will still be required to allow authentication by domain controllers at remote subnets provided there is not a local domain controller. Alternatively, the LMHOSTS configuration file can be populated with domain controller information. [6] Module 4

 

Groups & the 5000 User Limit

 

·         Several sources quote that we have tested and will support up to 5000 users in an AD group.

·         [John Gray (MS LTD)]  5000 users is not an absolute limit.  It is just the amount of users that can be guaranteed to work.  Remember that any given DC (DSA) must be able to create the group including its entire membership in a single transaction (when the DC initially replicates the data).  The DSA in Windows 2000 has been optimised to guarantee that creation of a group with up to 5000 members is possible, but if you create groups with more members than this, it is not guaranteed to work, although it may. 

·         How do we reconcile that with very large domains, such as the multi-million object directory created by Compaq.

·         [John Gray (MS LTD)]  Use Group Nesting, or take your chances.  I would use the former :::::)

·         The Domain Users group for this very large domain would have much more than 5000 members.

·         [John Gray (MS LTD)]  Domain Users (along with authenicated users)is an exception, as its membership is built dynamically. [4]

 

 

 

Domain Roles

 

·         New Password Change and Conflict Resolution Functionality - ID: Q225511

 

Mixed Mode Domain – adding BDCs

The only way to add NT 4 BDC's to a Windows 2000 mixed mode domain is to precreate the BDC'c computer account with the netdom tool.

 

The syntax is netdom add bdcname /domain:domainname /dc

 

The reason for this requirement is that when a NT4 BDC attempts to join the domain, it creates a computer acount of class "user". To prevent problems later on if the BDC was to be upgraded to Windows 2000, the core DS prevents the BDC from creating the computer account.

 

Using netdom, correctly creates the computer account as class computer.

 

Schema Management Snap-in

 

·         You install the schema management snap-in from the Admin pack (adminpak.msi). It registers the snap-in (schmmgmt.dll), copies the saved console (schmmgmt.msc) and creates the Start Menu shortcuts. Alternatively you can just manually register the snap-in using the command line regsvr32 schmmgmt.dll [4]

 

RID Master

 

Cross-domain Move

A cross-domain Move originates at a master replica of the object to be moved. Move first does a special remote Create of an object with the same GUID as the original. (If the object is a security principal its SID is appended to the SID-History of the object in the new domain.) After that succeeds, Move converts the original object into a local surrogate pointing to the remote object just created.  (Surrogates are an implementation technique, internal to DBLayer, for cross-NC object references.)

A cross-domain Move can only originate at a replica that holds the RID Master FSMO role for its domain.  Otherwise Move might send an object O from domain D1 to domain D2, while concurrently at another replica of D1 Move sends O to domain D2.  This conflict would be very difficult to resolve after the fact, so it must be prohibited using a FSMO.

Suppose Move sends an object O from domain D1 to domain D2.  Concurrently, at another replica of D1, Modify modifies O, or Delete deletes O. After resolution, at all replicas of D1, O is a surrogate pointing to the object in the new domain, and the object in the new domain has not been affected by the Modify or Delete.

Move does not conflict with itself. Suppose Move sends an object O from domain D1 to domain D2. Then Move sends O from D2 back to D1. The latter Move can only succeed at a replica of D1 that holds O as a surrogate, or not at all. Replication can be designed to ensure that the conversion of O to a surrogate arrives at all replicas before the re-creation of object O.  This avoids the possibility of conflict between the old and new generations of O in domain D1. [7]

Infrastucture Master

 

So, to put the below threads into some guiding principles.....

 

·         A domain does not have to have a GC - No, every domain must have a GC, In most cases logon will fail if one is not available,in a multi-domain forest a GC is required during logon to ascertain a users universal group membership, if one is not available then users will be able to access resources that have been denied to them as members of universal groups. A GC is required even if you only have one domain in your forest, any searches done against "Entire Directory" result in a query directed to a GC on port 3268,  DC's do not listen on this port and won't pick up the query.

 

·         No, every SITE should have a GC, but which domain it belongs to is not crucial. DNS will use site knowledge to point the user to a local GC if one exists.  Otherwise it would locate one over the WAN.

 

·         If a domain has a GC, active management of Infrastructure Master role is irrelevant when each DC is a GC. (Correct)

 

·         If a domain has a GC, active management of IM role is relevant when you have fewer number of GCs than DCs. (Correct)

 

·         If you have more than 1 domain in a forest, IM must be on a DC that isn't a GC.(Correct, unless you plan all DC's to be GC's as in point 2) Your domains GC server  will always have up to date data on all objects in all domains in the forest through replication, your other DC's will not and so over time they will contain references to objects on other domains that no longer exist, have been renamed etc, the infrastructure master acts as a go between for your GC and your DC's, it contains the same data as your DC's and periodically checks it against the data on the GC, if it finds it is out of date it request's the up to date data and will then replicate it to all other DC's in your Domain. If all your DC's are all GC servers  then they will never have out of date on objects in other domains and so the infrastructure master role becomes defunct and it won't matter what DC holds it.

 

·         If you only have one GC and multiple DC's in your domain the GC shouldn't hold the IM role as it is needed to keep all Data on your DC's up to Date, if the GC holds the IM role then no replication to other DC's will occur as the IM role holder's data (The GC) will always be up to date. [4]

 

·         Why must the infrastructure master not be a Global Catalog server?

When an object on one domain controller references an object that is not on that domain controller, it represents that reference as a record containing the GUID, the SID (for references to security principals), and the distinguished name of the object being referenced. If the referenced object moves, its GUID does not change, its SID changes if the move is cross-domain, and its distinguished name always changes.

The infrastructure master for a domain periodically examines the references, within its replica of the directory data, to objects not held on that domain controller. It queries a Global Catalog server for current information about the distinguished name and SID of each referenced object. If this information has changed, the infrastructure master makes the change in its local replica and also replicates the new values to other domain controllers within the domain.

If the infrastructure master runs on a Global Catalog server it will never update anything, because it does not contain any references to objects that it does not hold. That is because a Global Catalog server holds a partial replica of every object in the forest. [8]

• Why must the domain naming master also be a Global Catalog server?

When the domain naming master creates an object representing a new domain, it must make sure that no other object — domain object or otherwise — has the same name. The domain naming master achieves this by running on a Global Catalog server, which contains a partial replica of every object in the forest. [8]

 

NOTE: The infrastructure role should be held by a DC that is not a global

catalog (GC). If this role is hosted on a GC server, cross-domain object

references in that domain are not updated, and a warning to that effect is

entered in that DC's event log.  It's OK to have the IM on a GC in a single domain infrastructure because there's no cross-domain object reconciliation that the IM has to worry about. [4]

 

·          

 

 

Migration

·         The SID History feature can not be implemented unless the target domain is Windows 2000 in Native mode.  Accounts can be migrated to Windows 2000 in mixed mode, but the SID History option can not be enabled. [4]

 

Organizational Units

 

OUs should reflect organisational hierarchy [1]

The OU hierarchy inside one domain is independent of the OU structure of other domains. [1]

 

Domains vs. Organizational Units

When considering whether to split a particular part of your network into separate domains or separate OUs, consider the following[1]:

·    Split into separate domains if you have a decentralized organization, where different users and resources are managed by completely different sets of administrative personnel.

·    Split into separate domains when two parts of your network are separated by a link so slow that you never want complete replication traffic to cross it. (For slow links that can still handle replication traffic on less-frequent schedule, you can configure a single domain with multiple physical sites).

·    Split into OUs to reflect the details of your company’s structure and organization.

·    Split into OUs to delegate administrative control over smaller groups of users, groups and resources. The administrative control you grant can be complete (creating users and changing passwords) or limited (as minor as merely maintaining print queues).

·       Split into OUs if this particular organizational structure in your company is likely to change later. When possible, organize domains so that they will not have to be moved or split often in the future.

 

DNS

 

·         When designing a new DNS namespace, the easiest approach is to place a host in a dynamic DNS zone which corresponds to each Windows NT domain. [1]

Not every DC needs to be a DNS Server, but it is recommended that you have at least one DNS server at every site containing a DC. [1]

 

DNS query for authoritative DNS servers of a DNS domain is sent via UDP.  Therefore, the amount of servers that can be returned is limited to how many of the authoritative DNS server names can fit within a single UDP packet.  Also, every decent size site will want it owns DNS server for redundancy purposes.When a DNS UDP response contains more data than will fit in a UDP response. the client is notified that more data exists and then uses a TCP connection to request the data.[5]

 

The value in the registry which seem to hold down the DNS domain name associated with the server at:

HKLM/System/CurrentControlSet/Serv ice s/Tcpip/Parameters/Domain

 

·         How to stop registering server names: How to Prevent Domain Controllers from Registering DNS Names  [ntrelease] ID: Q198767 [4]

 

·         How can the Windows 2000 DNS be secured against unauthorized updates from non-Microsoft DNS servers?

Don’t make them secondary servers to bind. Root AD in a different namespace and set up root hints or forwarders to bind for name resolution. Make the bind servers authoritative for the PTR record and have the DHCP servers update them or open up the reverse lookup zones to DDNS on the bind servers.

·         Can Windows 2000 DNS support split subnets, where half the net is administered by a BIND dns server, and the other half administered by a Windows 2000 DNS server?  If so, how are reverse lookups handled?  How would the two reverse lookup zones be named?

If there is a different namespace for Windows 2000 than what is in use now splitting subnets is no big deal. As said above let bind handle the reverse lookup.

·         If we turn on the Windows 2000 DNS “WINS” option, will that cause problems with down level BIND servers?

As far as I know it won’t.

·         If we decide to manually update non-ddns BIND servers with SRV records, does Microsoft offer any tools to support that?  Is this at all practical. i.e. what are the risks and maintenance costs?

No tools not practical not recommended. We have tried this in a lab and it is a nightmare. [4]

 

·         can't configure a forwarder within my DNS MMC because all the options are greyed out stating that I am working on a ROOT server. If there is a forward lookup zone file called “.” Delete it and the tab will be usable. The “.” Zone file tells the DNS Server it is a root server.

 

·         Current DNS namespace is limited to 64 chars. What happened?

In build 2167, DCPROMO was changed to limit Active Directory domain names to be no longer than 64 UTF-8 bytes.

1 ASCII character == 1 UTF-8 byte.  Non-ASCII characters are encoded in multiple UTF-8 bytes.  This limits Active Directory domain names to <=64 characters, where the exact number of characters allowed depends on the characters used.

This limit does not apply to computer names.  It only applies to the fully-qualified DNS name of an Active Directory domain (i.e. redmond.corp.microsoft.com).

 

Why was the change necessary?

Win32 file APIs allow file paths (including UNC paths) to be up to 260 characters (MAX_PATH) in length.  The DNS protocol allows DNS names to be up to 255 bytes long.  As you can see, it is easy to create a UNC path including a DNS name that exceeds the 260 character MAX_PATH limit.

 

Group policy references files in the SYSVOL using UNC paths.  A typical UNC path used by group policy looks like this:

 

//<domain-name>/sysvol/<domain-name>/Policies/<GUID>/<Machine|User>/<GroupPolicy-Extension-Specific-Path>

 

(The second instance of <domain-name> is necessary in order to be able to host more than one domain on a domain controller, in the future.)  If the length of a policy UNC path exceeds MAX_PATH, the policy cannot be read and is not applied to clients.  Given the longest <Policy-Extension-Specific-Path> found in the policy extensions that ship in the product, it was determined that the maximum allowed length of <domain-name> is 64 characters.  This close to RTM, the only fix with acceptable risk was to limit fully-qualified DNS names of Active Directory domains to 64 UTF-8 bytes.

 

This issue has existed since group policy was introduced into the product.  Test variations have been added to prevent this issue and similar issues from occuring in the future.

 

Previously, DCPROMO limited Active Directory domain names to 155 UTF-8 bytes.  This was due to the fact that the maximum length of a DNS name is 255 UTF-8 bytes, but the locator attaches varies prefixes (domain GUIDs, site names, etc) to the records entered in DNS and the longest possible prefix is 100 UTF-8 bytes long.

 

What's next?

The development team is exploring ways to allow longer Active Directory domain names in future versions of Windows 2000. Questions/comments should be directed to SKwan.[4]

 

·         Windows 2000 supports secure dynamic updates from clients when the DNS zone is integrated into Active Directory.  It does not support RFC 22137 or secured transfer of zone files to/from another DNS server. [4]

 

·         On port 445/TCP and 445/UDP there is a serv ice called "microsoft-ds."

This is a new protocol used in Windows 2000 called "Direct-hosting".  From the TCP/IP White Paper:

 

NetBIOS Over TCP/IP

NetBIOS defines a software interface and a naming convention, not a protocol. Early versions of Microsoft networking products provided only the NetBEUI local-area networking protocol with a NetBIOS application-programming interface. NetBEUI is a small, fast protocol with no networking layer; thus, it is not routable and is often not suitable for WAN implementations. NetBEUI relies on broadcasts for name resolution and location of serv ice s. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the WAN, and providing interoperability with various other operating systems.

The Windows NT Workstation serv ice , Server serv ice , Browser, Messenger, and NetLogon serv ice s are all (direct) NetBT clients. They use TDI (described earlier in this paper) to communicate with NetBT. Windows NT and Windows 2000 also include a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS applications and translates them to equivalent TDI primitives.

Windows 2000 still uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Windows 95. However, the Windows 2000 redirector and server components now also support direct hosting to communicate with other computers running Windows 2000. Direct hosting uses the DNS for name resolution. No NetBIOS name resolution (WINS or broadcast) is used, and the protocol is simpler. Direct Host TCP uses port 445, instead of the NetBIOS TCP port 139. [4]

 

·         The client will have the same domain name for the Linux Box and the Windows2000 domain.   The Linux box will sit in a DMZ and is supposed to only transmit a few entries to the ISP and also resolve for the internet.   DDNS for Windows 2000 will be used for the workstations serv ice location. My question is:  Can we have both DNS boxes using the same domain name and if we can not resolve an address in the Windows2000 DDNS database use a forwarder to the Linux box

This is possible as long as the Win2k DDNS server is authoritative for the domain name space, and yes you can use forwarders to point to external DNS servers. However, when you first install the DNS for the root, it creates a zone for the ".", and you will have to delete this for configuring forwarding address on the Win2k DNS server, else, the forwarding part of the UI will be greyed out. [4]

 

From David Cross’ Web site on DNS:

FAQ/TIPS

1.  How do I set the DNS zone mode via the command line?

no update

dnscmd <ServerName> /ResetRegistry <ZoneName> /AllowUpdate 0

dynamic update

dnscmd <ServerName> /ResetRegistry <ZoneName> /AllowUpdate 1

secure dynamic update

dnscmd <ServerName> /ResetRegistry <ZoneName> /AllowUpdate 2

 

How to add a reverse lookup zone:

To add a reverse lookup zone of 11.1.2.x use dnscmd and identify zone type using the in-addr.arpa as the zone name.

Eg: “dnscmd /zoneadd 2.1.11.in-addr.arpa /dsprimary [JRP]

 

2.  I need to interoperate with Unix DNS, what version of BIND should I use?

The requirements for the DNS server to support AD are:

support SRV records (as per Internet-Draft "A DNS RR for specifying the location of serv ice s (DNS SRV)" http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt) BIND 4.9.6 and up

support dynamic updates (RFC 2136) BIND 8.1.2 and up

Not ice that the support for dynamic update is not required but VERY, VERY recommended. If admin still prefers to use a DNS server that doesn't support dynamic updates then he/she will need to update the DNS zones manually by monitoring netlogon.dns file (on each DC) that contains a list of DNS resource records to be published in DNS.

BIND 8.1.2 has been tested to support AD. No problems were detected.

We didn't try to use BIND 8.2 to support AD, but there is no reason to believe that it wouldn't work, since it supports dynamic updates and SRV records (and we tested these two features).

BIND 4.9.7 has a lot of bug and security fixes.  8.x series also supports items such as SRV RR records. 

BIND 4.9.3 servers cannot be secondary for zones that contain locator RRs (SRV RRs).

 

3.  What version of Unix BIND supports underscore "_" characters in the zone files?

BIND 8.1.2 can accept underscores when using the "check-names ignore" config directive.

 

4.  Why is mutual authentication required?

All scenarios need mutual authentication. Customers expect that they connect to the machine they asked for, and it is in general impossible to know what the consequences of them connecting to a server that pretends to be the one they wanted. Suppose an attacker's server could pretend to be your online banking server, for example. It could transfser money to a different account than you wanted. If an attacker's file server can pretend to be the NETLOGON share, it can feed you logon scripts that cause you to do anything.

As a result, the only safe thing to do is to always get mutual authentication.

 

5.  To what extent will Active Directory integrate with BIND 8.2, taking into consideration that these are RFC 2052, RFC 2136, and 2137 compliant?

In the lab, we test the Active Directory with BIND 8.1.2 and 8.2, and it works fine. We are fully interoperable with RFC 2136.

 

6.  How will Windows 2000 integrate with the DNS SEC RFC2137 standard implemented with RSA in BIND 8.2?

BIND 8.2 does not support RFC 2137 (secure dynamic update via DNSSEC). BIND 8.2 has only limited support for RFC 2065/2535 (DNSSEC) - it will dole out signed records that are generated out of band, but it does no cryptography itself. That said, we are testing our client and server to make sure it fails gracefully when presented with DNSSEC-ized responses. The MS DNS client and server do not support DNSSEC in Win2K. We are evaluating DNSSEC for a future release.

 

7.  Is there a way to forward requests to a Bind DNS server if the request can't be handled by my AD DNS?

Yes, there is a way to configure a BIND (or any other) DNS as a forwarder to your DNS server.

Go to DNS manager, open the Properties of your DNS server (the one you call AD DNS), go to the Forwarders page and check the checkbox to enable forwarding and specify the IP address of the BIND server. At the same time you should realize that all unresolved by your (AD) DNS server queries (even those that BIND is not authoritative for) will be forwarded to the BIND server. BIND will recursively resolve the queries and return the response to your (AD) DNS server. Not ice that it may significantly increase the load on the BIND server.

 

8.  Regarding the DNS client resolver cache, is there a maximum cache size (in which case what is the size of an entry) or is there a maximum number of entries that can be cached ? 

The cached entries are stored in the hash table. The size of the table is limited by 211 rows by default. To change the default value you need to change the CacheHashTableSize value in the HKLM/System/CurrentControlSet/Serv ice s/dnscache/parameters registry key. Every row in the hash table may contain by default up to 10 entries (meaning up to 10 names). To change the default change the CacheHashTableBucketSize in the same reg key. Thus by default cache may contain entries for up to 2110 different names.

 

9.  Is the Primary DNS server the only server that can actively register clients?

The primary DNS server is where changes are made unless you use AD integration.

 

10.  A machine can override another machines DNS entry, at least in Bind. If there is an entry for a machine in DNS and another machine comes up with the same name the DNS entry is overwritten. Is this the same in MS DNS? And if so is there a way to avoid this?  

To prevent it, you need to configure zone to accept only Secure Dynamic Updates (you can do it through the General page under Properties of the zone). Not ice that this feature is available only for the DS-integrated zones. According to default behavior (you may modify the ACLs controlling access if necessary) any authenticated client can create a new name in the zone. But if the name already exists in the zone, then a client must have necessary credentials, written in the ACL, in order to update/modify/delete/add a resource records to that name. By default, the client that created a name has a full control of it. Enterprise , Domain and DNS admins also have a full control over all zones and names.

 

11.  Should a company maintain a separate internal namespace form external DNS namespace?

from Jerry Condon (Entirenet):

The decision of whether to maintain separate internal and external DNS namespace is based on conventional logic, but the implications are expanded under a Windows 2000 environment. The namespace used for an internal directory affects the end-users since it is part of their login name. For example: Using separate namespace, Joe User must be educated on the distinction between his login name, juser@smarket.org, and his internet e-mail address, juser@streetmarket.com. Using a single namespace, Joe User simply needs to learn and use a single address space: juser@streetmarket.com.

Separate namespace publish Internet dev ice s on a completely different domain name from internal dev ice s. In this configuration, only those internal serv ice s that are specifically required are published to the Internet. The setup for this type of arrangement is easy since management and the dev ice s themselves are maintained separately.

A single published namespace serv ice s both Internet and internal requests. There are a few popular methods of configuring this setup so that internal dev ice names are not compromised:

1. Since both Internet and intranet domain names should be registered with Internic, the SOA entries for both zones must be accessible to the Internet. As such, the first step will be to create two primary zones on the Internet DNS server: one for the Internet domain system and the other for the intranet.

2. Security issues dictate that internal serv ice s not be published to the Internet. To meet this requirement, the intranet DNS system also must host the intranet DNS zone as a primary. At this point, the two DNS systems have no knowledge of each other and will respond to requests for the intranet domain name.

3. Two additional points of configuration are necessary to ensure that the intranet zone receives all appropriate requests and is also protected from exposure to the Internet. On the Internet DNS system, delegate control of the intranet zone to the internal DNS server by establishing an NS type record pointing to the internal server.

4. Further, establish the Internet DNS server as the forwarder for the intranet DNS system. The intranet DNS server will not attempt to resolve external queries directly to the Internet, but will instead pass requests through the Internet DNS servers.

 

 

The implementation of a single DNS domain would serv ice both internal and Internet communications. In this case, a single zone will span both Internet and intranet DNS systems resulting in a single namespace for the organization.

The requirement to secure internal records still exists however, so a method of separating the resources must be used.

1) In this case, the primary zone for the domain name will be created on both Internet and intranet DNS servers. In this state neither DNS server is aware of the other, which meets the desired criteria.

2) Records in this case will be managed as if the zones existed for two separate domains. Internet records are published on the Internet system, and internal records are published on the intranet system. Never the twain shall meet.

3) Again, the intranet DNS system should utilize the Internet system as a forwarding agent to avoid exposure to the Internet.

The main point to the single namespace arrangement is that users see one view of both the Internet and intranet. It is up to the administrator to make a backend distinction between the two networks.

Administration and management are a little more difficult in this scenario because while the systems are technically distinct, specification must be made as to what resources exist on which primary zone. This may lead to security issues resulting from internal resources being inadvertently posted to the Internet DNS system.

As such I think it comes down to a few bullet points...

Advantages

· A consistent namespace exists across an entire organization.

· Users do not have to consider multiple namespace addresses.

Disadvantages

· DNS is a more difficult configuration due to the issues and considerations in implementing and managing the namespace.

· Security risks are greater as the same namespace exists both internally and externally.

12.  What is the default behavior for a Windows 2000 client when WINS address is also provided?

The default behavior for WINS clients running on Windows 2000 is to:

Attempt name resolution through DNS for all names longer than 15 characters or for names that make use of periods (‘dots’).

Attempt name resolution through WINS for names that are shorter than 15 characters and do not use periods.

Attempt DNS name resolution after a WINS query fails if the client is configured to use a DNS server.

 

 

 

Performance:

from Levon Esibov:

The DNS development and testing team compiled some statistics as a profile of DNS server performance during preliminary testing of Windows 2000 Server. In testing, two different DNS server hardware configurations were used and overall DNS query and dynamic update activity was measured, along with processor utilization.

The results of each of these tests are listed in the table below.

Server configuration	Queries/sec	Dynamic updates/sec	Processor utilization
Alpha 533 MHz dual-processor	1600	200	25%
Intel P-II 400 MHz dual-processor	900	100	30%

During the collection of these measurements, the monitored DNS server was processing both queries and dynamic updates at the same time. The numbers above reflect these concurrent processes.

For dynamic updates, standard primary type zones were used, not Active Directory-integrated zones. Where directory integration is used for zones, the rate of the dynamic updates that can be processed decreases, since the DNS server must write to and rely upon the Active Directory database as well.

In addition, if a zone is configured to accept only secure dynamic updates, the update rate can decrease as well. Network performance might also be a factor in these cases since the directory database might require network activity to process updates.

Important

The previous measurements are not meant in any way to indicate maximum performance or server limitations for Windows 2000 DNS servers. The objective of the tests was merely to sample typical DNS server performance and obtain a working benchmark based on standard available hardware as a basis to begin server capacity planning.

 

below I provide the data under the assumption that the specified entity is configured to perform dynamic DNS registration. Obviously that if it is not configured so - then no DNS registration will take place. Below are specified default values. Admin may adjust these values (all, except the DHCP server)

 

• every W2K professional reregisters the A and PTR records every 24 hours (prereq only dynamic update if record was not changed)
• every W2K server/advanced server/DTC reregisters the A and PTR records every hour (prereq only dynamic update if record was not changed)
• every DC reregisters 14 DC locator specific records every hour
• every GC reregisters 19 DC locator specific records every hour
• W2K DHCP server performing registration of the DNS records registers record at every lease renewal.

 

 [4]

 

 

·         Disable reverse lookup but keep dynamic registration of DDNS:

 

 

·         Construct all DNS to have the same "Reverse Lookup Zone"(because network devides into some segments and want all DNS to have whole network "Reverse Lookup Zone".)

And, want to use DDNS's Dynamic update. So, I want to use Dynamic-Update, not to register "Reverse Lookup Zone" with Dynamic-Update, Dynamic-Update only works for "Forward Lookup Zone".

You can disable the PTR registration with the following reg value:

 HKLM/System/CCS/Serv ice s/TcpIp/DisableReverseAddressRegistrations REG_DWORD 0x1.

 

Note that PTR dynamic registrations will still be done if you have a DHCP server configured to do this on behalf of the clients.

 

·         If a DNS srv have 2 forwarders, can I specify a delay between query to the first and second one. eg: query first forwarder, waiting 10 s, query second forwarder ?

 

Is there a solution to stop forwarding to top level DNS (if I delete servers A-.. on tab, they come back)

 

      If you don't want the DNS server for sub.mydomain.com to forward a query to the DNS server for mydom.com

      you can disable recursion in the advanced tab of sub.mydom.com's DNS server.

      You could also make both DNS servers root servers by creating a root (.) forward lookup zone on your second DNS server,

      root hints and forwarders are then disabled.

 

 

·         Arch.

         1 parent domain (1 DC HQ) mydom.com

         + 1 child domain (1 DC  HQ + 1 server per physical site) sub.mydom.com

 

every servers is dns svr for dns zone corresponding to domain (AD integrated).

every physical sites corresponding to an AD site

         Sometimes branch-off ice srv make dns query for _ldap.tcp.SiteName._sites.dc._msdcs.ServerName and never have response. Do you know xhat is this name, why this query ....?

 

       ldap.tcp.<sitename>._sites..dc._msdcs.<domainname>  records  allow clients to find the DC of <domainname>, queries for a Domain controller of your domain

       will be answered with this record e.g.. during a client logon. All of your DC's must register this record,

       you'll find it in the GUI by browsing through  -your domains lookup zone

                                                                - the _MSDCS folder

                                                           - the DC folder

                                                                - the _SITES folder

                                                                - the _TCP folder

 

 

·         Same question about record for all DCs (of all domains) in _msdcs.mydom.com. eg: a09d20da-0589-4713-9ffe-41edf4361ddf._msdcs.mydom.com --> mysrv.sub.mydom.com

 

           records such as a09d20da-0589-4713-9ffe-41edf4361ddf._msdcs_mydom.com are used to answer normal A address record lookups which a client may use if it knows the

           GUID of the MSFT-DSA object for the DC and the name of the forest the DC is in. This record is used to ease the ability to rename a DC (DNS Whitepaper) [4]