Summary (Dynamic) Domain Name System (DNS)

DNS is the name service of Windows 2000. Windows 2000 clients use DNS for name resolution and service location, including locating domain controllers for logon.

Any DNS Server implementation supporting service location resource records (SRV RRs, as described in an Internet Draft "A DNS RR for specifying the location of services", RFC 2052 (DNS SRV) and dynamic update, (RFC 2136) is sufficient to provide the name service for Windows 2000–based computers. Theses services are provided by DNS servers compatible with BIND 8.1.2 or later.

The Domain Name System is a hierarchical distributed database and an associated set of protocols that define:

The names in a DNS database form a hierarchical tree structure called the domain name space. Domain names consist of individual labels separated by dots. For example: mydomain.microsoft.com.

A Fully Qualified Domain Name (FQDN) uniquely identifies the host’s position within the DNS hierarchical tree by specifying a list of names separated by dots on the path from the referenced host to the root. 

Before you can install DNS, the server must have a static ip address and the host and domain name must be specified. You can install DNS via the following ways :

DNS resource records

A DNS database consists of resource records (RRs). Each RR identifies a particular resource within the database. There are various types of RRs in DNS.

The following table provides detailed information on structure of common RRs (Note: this is not an exhaustive list of RRs):

In a zone file, the "@" symbol represents the root domain of the zone (microsoft.com in the following examples). The "IN" in the following records is the class of data. It stands for Internet. Other classes exist, but none of them are currently in widespread use.

The first record in any database file is the SOA Record.

@ IN SOA <source host> <contact e-mail> <ser. no.> <refresh time> <retry time> <expiration time> <TTL>

Example:

@ IN SOA nameserver1.microsoft.com. glennwo.microsoft.com. (

1 ; serial number
10800 ; refresh [3 hours]
3600 ; retry [1hour]
604800 ; expire [7 days]
86400 ) ; time to live [1 day]

Setting the servers refresh interval is a balance between data consistency (accuracy of your data) and your networks load.

Lists the name servers for this domain allowing other name servers to lookup names in your domain. It also refers to delegated domains. In this case the DNS server of the delegated domain needs a NS and an A record.

<domain> NS <nameserver host >

Example:

@ NS nameserver2.microsoft.com.
@ NS nameserver3.microsoft.com.
delnameserver A 10.10.0.33
deldomain NS delnameserver.microsoft.com

The mail exchange record (MX)

This record tells which host processes mail for this domain. If multiple mail exchange records exist, the resolver will attempt to contact the mail servers in order of preference from lowest value (highest priority) to highest value (lowest priority). By using the example records that follow, mail addressed to scottsu@microsoft.com is delivered to scottsu@mailserver0.microsoft.com first. If the mailserver0 is unavailable the mail is send to scottsu@mailserver1.microsoft.com. 

<domain> MX <preference> <mailserver host >

Example:

@ MX 1 mailserver0
@ MX 2 mailserver1

A host record is used to statically associate hosts names to IP addresses within a zone. It should contain entries for all hosts which require static mappings including workstations, name servers, mail servers, etc. These are the records which make up most of the database file when static records are used.

<host name> A <ip address of host>

Example:

rhino A 157.55.200.143
nameserver2 A 157.55.200.2
mailserver1 A 157.55.200.51

If more than one record exists for the same server, the DNS server will create load-balancing if the Round-Robin function is active. The setting is activated by default.

The host record (IPv6)

IP version 6 uses the AAAA recource record to store the host's ip address.

<hostname> AAAA IPV6 ip address

The local host record (A)

A local host record allows lookups for "localhost.microsoft.com." to return 127.0.0.1.

The cname record (CNAME)

These records are sometimes called ‘aliases’ but are technically referred to as ‘Canonical Name’ (CNAME) entries. These records allow you to use more than one name to point to a single host.

Using canonical names makes it easy to do such things as host both an FTP server and a Web server on the same machine.

<host alias name> CNAME <host name>

Example:

Assume that www.microsoft.com and ftp.microsoft.com are on the same machine. If this is the case then you might have the following entries in your zone file:

FileServer1 A 157.55.200.41
ftp CNAME FileServer1
www CNAME FileServer1

If you ever intend on moving the FTP server service away from the Web service, then all you have to do is change the CNAME in the DNS server for FTP and add an address record for the new server. For example:

FileServer2 A 157.55.200.42
FTP CNAME FileServer2

Wins records can be used to check a WINS server if the query cannot be solved via DNS. Only queries to direct children of the rootzone of the DNS-server host will be resolved. You can add the following options to a WINS record :

@ IN WINS [ttl] <local> <LookupTimeout> <CacheTimeout> <ip address of WINS server>

TTL sets the time a WINS record can be cached, Local specifies whether the record must be included in a zone replication, LookupTimeout sets the number of seconds the DNS server waits for a response from the WINS server (default 2 seconds) and CacheTimeout sets the amount of seconds the DNS server can cache the DNS entry (default 15 minutes). By specifying the ‘local’ option, WINS-records will not be replicated. This can be used the specify different WINS servers for different DNS servers of the same domain.

The WINS-R resource record is used for reverse lookups by using a NetBIOS adapter node status query. It has the same parameters as the WINS record execpt that the NameResultDomain is specified instead of the ip address of the WINS server. The NameResultDomain specifies the domain that is append to the NetBIOS name.

Examples :

@ IN WINS 5 3600 192.5.29.2 192.5.29.3
@ IN WINS LOCAL 5 3600 192.5.29.5 192.5.29.6
@ IN WINS-R LOCAL 5 3600 microsoft.com

PTR (pointer) records are used for reverse lookups. They are only in subdomains of the in-addr.arpa domain. An example of a PTR record for a client with ip address 150.10.20.1 in the 150.10.0.0 network is :

1.20 IN PTR client.domain.com.

This record is stored in the 10.150.in-addr.arpa domain.

SRV (service locator records) are used to locate hosts providing specific services. The format is :

<service>.<protocol>.<name> <ttl> <class> SRV <priority> <weight> <port> <target>

For example :

_ldap._tcp_dc._msdc 300 IN SRV 0 100 389 kona.kapoho.com

Before the type of record, (A, SRV, CNAME etc.) you can fill in a TTL and a Class. The TTL describes the time in seconds a resolver may cache the record. The class should always be IN.

A DNS database can be partitioned into multiple zones. A zone is a portion of the DNS database that contains the resource records with the owner names that belong to the contiguous portion of the DNS namespace. Zone files are maintained on DNS servers. A single DNS server can be configured to host zero, one or multiple zones.

Each zone is anchored at a specific domain name referred to as the zone’s root domain. A zone contains information about all names that end with the zone’s root domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name. The first record in any zone file is a Start of Authority (SOA) RR. The SOA RR identifies a primary DNS name server for the zone as the best source of information for the data within that zone and as an entity processing the updates for the zone.

Names within a zone can also be delegated to other zone(s). Delegation is a process of assigning responsibility for a portion of a DNS namespace to a separate entity. This separate entity could be another organization, department or workgroup within your company. In technical terms, delegating means assigning authority over portions of your DNS namespace to other zones. Such delegation is represented by the NS record that specifies the delegated zone and the DNS name of the server authoritative for that zone. Delegating across multiple zones was part of the original design goal of DNS. The main reasons for the delegation of a DNS namespace are :

There could be multiple zones representing the same portion of the namespace. Among these zones there are two types:

As mentioned above, a name server can host multiple zones. A server can therefore be primary for one zone (it has the master copy of the zone file) and secondary for another zone (it gets a read-only copy of the zone file).

The process of replicating a zone file to multiple name servers is called a zone transfer. A zone transfer is achieved by copying the zone file information from the master server to the secondary server.

The source of zone information for a secondary name server in a DNS hierarchy is referred to as a master name server. A master name server can be either a primary or secondary name server for the requested zone.

The zone transfer is initiated in one of the following ways:

There are two types of zone file replication. The first, full zone transfer (AXFR), replicates the entire zone file. The second, incremental zone transfer (IXFR), replicates only the changed records of the zone.

There are two types of the AXFR: One requires single record per packet, the other allows multiple records per packet (fast zone transfer). The Windows 2000 DNS server supports both, but by default uses multiple records per packet, unless is configured differently. You can disable fast zone transfers via the option ‘Bind secondaries’ on the Advanced tab of the DNS server.

Incremental zone transfers are initiated by a master server sending a NOTIFY-packet. After receiving this packet, a slave server capable of IXFR, will send an NOTIFY-packet containing the SOA-serial number of it’s copy of the zone-file. After receiving this packet the master-server will start the incremental transfer. A full transfer (AXFR) will be made if :

The changes of the DNS database that should be transferred via an incremantal zone replication are stored in the domainname.dns.log.file.

If the zones are directory-integrated, the Active Directory replication mechanism is used. The main benefits are :

DNS queries can be sent from a client (resolver) to a DNS server (a name server), or between two name servers.

A query is merely a request for records of a specified type with a specified name. For example, a query can request all host RRs with a particular name.

There are two types of queries that can be made to a DNS server:

A recursive query forces a DNS server to respond to a request with either a failure or a successful response. Resolvers typically make recursive queries. With a recursive query, the DNS server must contact any other DNS servers it needs to resolve the request. When it receives a successful response from the other DNS server(s), it then sends a response to the client. The recursive query is typical for a resolver querying a name server and for a name server querying its forwarder (another name server configured to handle requests forwarded to it).

When a DNS server processes a recursive query and a query can not be resolved from local zone files, the query must be escalated to a root DNS server. Each standard-based implementation of DNS includes a cache file (or root server hints) that contains entries for root servers of the Internet domains.

An iterative query is one in which the name server is expected to provide the best information (also known as referral if the server is not authoritative for the name) based on what the server knows from local zone files or from caching. If a name server doesn’t have any information to answer the query, it simply sends a negative response. A non-forwarding DNS server makes this type of query as it tries to find names outside its local domain(s). It may have to query a number of outside DNS Servers in an attempt to resolve the name.

The following figure shows an example of both types of queries.

When a DNS name server receives a DNS request, it attempts to locate the requested information within its own zone files. If this fails because the server is not authoritative for the domain requested, it must communicate with other DNS name servers to resolve the request. Since, on a globally connected network, a DNS resolution request outside a local zone typically requires interaction with DNS name servers outside of the company on the public internet, you may want to selectively enable specific DNS name servers in your company to do this wide-area communication.

To address this issue, DNS allows for the concept of forwarders. Specific DNS name servers are selected to be forwarders, and only forwarders are allowed to carry out the wide-area communications across the Internet. All other DNS name servers within the company are configured to use forwarders and are configured with the IP addresses of the DNS name servers designated as forwarders. This configuration is done on a per server basis, not a per zone basis, on the Forwarders-tab of the properties of a DNS server. Also select the Disable recursion on the Advanced tab to prevent the DNS server from using other servers.

When a server which is configured to use forwarders receives a DNS request that it is unable to resolve (through its own zone files), it passes the request to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the request and returns the results to the requesting server, which, in turn, returns the results to the original requester. If the forwarder is unable to resolve the query, the DNS server attempts to resolve the query on its own as normal.

Slaves are DNS servers that have been configured to use forwarders and have also been configured to return a failure message if the forwarder is unable to resolve the request. Slaves make no attempt to contact other name servers if the forwarder is unable to satisfy the request.

Although all DNS name servers cache queries that they have resolved, Caching-only servers are DNS name servers whose only job is to perform queries, cache the answers, and return the results. In other words, they are not authoritative for any domains and only contain information which they have cached while resolving queries.

To be able to convert an ip-address to a domain name, a special domain "in-addr.arpa." in the DNS name space was created. But since IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in-addr.arpa tree. To find a host name for the IP address 157.55.200.2, the resolver would query the DNS server for a pointer record for 2.200.55.157.in-addr.arpa. If this IP address was outside the local domain, the DNS server would start at the root and sequentially resolve the domain nodes until he reached 200.55.157.in-addr.arpa which should contain the resource PTR record for 2 (that is 157.55.200.2).

The active directory can be used for storing and replication DNS entries. The benefits are :

Only DNS servers on a domain controller can load DS integrated zones.

The multi-master replication model can cause problems if two changes to the same object are made on different DNS servers. When replication, only the last modified/created item will remain. Until this time different answers will be givens by the two servers. This is why the Active Directory database is called loosely consistent.

DS integrated DNS servers do provide secure dynamic DNS updates. Every DS-integrated zone, or object within this zone, has a ACL which allows users of groups to create, modify or delete the object.

The Windows 2000 DNS service supports Dynamic DNS (DDNS) as covered in RFC 2136. Via an UPDATE-message, resource-records can be added and deleted for a specific zone. Updates will be made on the primary server. On a non-ds-integrated DNS environment, update-messages will be forwarded to the primary server. In a ds-integrated DNS environment, update-messages can be send to any DNS server on a domain controller whose directory service contains the zone.

During a zone-transfer the zone is locked but to be able to provide dynamic updates, these updates will be queued and handled after the zone-transfer.

Updates are made via the following algorithm :

If the client uses DHCP, the DHCP-server is used to negotiate the DDNS-registration. The following situation can appear :

A client will re-register it’s DNS entries via ‘ipconfig /registerdns’. If you want a DC to re-register all entries from netlogon.dns, restart the netlogon service.

At the expiration of the lease, the dynamic DNS entries must be removed from the zone. This should be done by the computer who created the resource-records. (the DHCP-client or DHCP-server). By default, the DHCP-server will only remove the records it did register (standard only the PTR-record). When the option ‘Discard forward (name-to-address) lookups when lease expire’ is activated, also A-records will be removed by the DHCP-server.

DNS entries are reregistered by the DHCP-server when a lease is renewed. A DHCP-client renews the entry every 24 hours or at the following events :

You can change the interval of 24 hours are the registry entry hkey_local_macine\System\CurrentControlSet\Services\TCPIP\Parameters\DefaultRegistrationRefreshInterval. After creating the entry you should restart the machine.

The default TTL for a resource record entered by a client is 20 minutes. This can be changed via the registry entry hkey_local_machine\system\CurrentControlSet\Services\TCPIP\Parameters\DefaultRegistrationTTL (seconds). After creating the entry you should restart the machine.

If a client dynamically registers an address that is already in DNS, by default the existing entry is overwritten in a non-secure environment. This can be changed via the registry setting Hkey_local_macine\System\CurrentControlSet\Services\TCPIP\Parameters\DisableReplaceAddressesInConflict. By default the value is 0 which means that existing entries will be overwritten. When changed to 1, the client will not overwrite existing names.

You can disable dynamic updates for the whole client on the registry key hkey_local_machine\CurrentControlSet\Services\TCP\Parameters\DisableDynamicUpdate or per interface on hkey_local_machine\CurrentControlSet\Services\TCPIP\Parameters\Interfaces\<interface>\DisableDynamicUpdate.

If you only want to disable the registration of reverse lookups you can change the DisableReverseAddressRegistrations registry entry. You can only disable PTR registration per machine and not per adapter.

1. The client queries the local name server to discover which server is autorative for the name it tries to update.
2. The client queries the autorative server to verify that it is autorative.
3. The client attempts to make a non-secure update. (if this works, the process stops)
4. The client and the server begin security context negotiation by using the TKEY-resource record. First a security mechanism is negotiated, by default this is Kerbores. Next, Kerbores is used to identify the identities. After the security context is established, it will be used to create and verify transaction signatures.
5. The client sends signed dynamic update requests by using the TSIG-resource record.
6. The server tries to update the Active Directory. The result is based on the permission of the client and if the preqequisites are met.
7. The server informs the client about the result with a message signed with the TSIG-key.

A client can use three policies for secure DDNS-updates :

In some cases DDNS-records are not automatically deleted. This causes stale records in the database that use extra resources and can give wrong answers. To clean up the database aging and scavenging can be used by specifying the following :

By default scavenging is disabled. When activated, records created before enablement will not be scavenged. The only way to scavenge these old records is to use the AgeAllRecords option in dnscmd.exe.

Aging and scavenging parameters per zone :

Aging and scavenging parameters per server :

A server can start scavenging a zone when :

Active directory zone-files with scavenging enabled cannot be copied to non-Windows 2000 DNS servers as the format has been changed. Zone-transfers do work.

Time-stamps of records that are created by any other method than a dynamic update are set to zero. A zero value indicates that the timestamp must not be refreshed and that the records should not be scavenged.

Windows 2000 DNS does support UTF-8 characters to easy the migration from NetBIOS names. Keep in mind that when using non-Windows 2000 DNS servers zone-transfers can give problems for UTF-8 names. Also do not use these names in computers that should be visible globally.

UTF-8 character encoding is a superset of ASCII and a translation of UCS-2 (UniCode). It contains characters of most of the world’s written languages. (RFC 2044)

You can set per DNS server if you allow the usage of UTF-8 character on the Advanced tab of the server’s properties. You can set on of the following options for Name checking :

The maximum length of a fully qualified domain name is 255 bytes, the maximum of a label is 63 bytes. A domain controller is limited to 155 bytes for a fully qualified domain name.

The domain locator is part of the Netlogon-service and enables a client to locate a domain controller. The domain controller location algorithm contains the following steps :

Steps within the ip/dsn locator :

When a locator searches for a domain controller, it attempts to find one in the same site where the client is unless specified otherwise. If at the beginning of the search the locator is not aware of the client’s site, it will query a DNS server for the records of the domain controllers in the specified domain. Then it contacts discovered domain controllers and finds the site to which the client belongs. If the discovered domain controller is not in the same site the locator will repeat DNS query specifying the client’s site.

A domain controller should be registered within DNS. To receive the domain controllers, the client sends a DNS query to the DNS server to lookup the domain controller(s) for the specific domain. After the query is resolved the client sends LDAP UDP lookup’s to check the availability of the domain controllers. Finally the netlogon service caches the found domain controllers.

A domain controller adds the following SRV items to a DNS server :

When a resolver receives multiple A records for a host, it first uses the ip address of the host on the same subnet as the resolver. This is called subnet prioritization. Subnet priorization disables Round-robin in which the servers changes the order of offering multiple ip addresses for the same host. It is an easy way to provide load balancing. Round-robin is described in RFC 1794.

You can disable subnet priorization by setting the value of the Hkey_local_machine\System\CurrentControlSet\Services\DNSCache\Parameters\PrioritizeRecordData to 0.

On the DNS server you can enable Round-robin on the Advanced tab. You can also enable subnet priorization on the server via the registry parameter LocalNetPriority. By default this option is set to 0 (disabled). This leads to the following combinations :

The registry information of DNS is stored in Hkey_local_machine/System/CurrentControlSet/Services/DNS. The DNS folder (systemroot\system32\Dns) contains the following files :

Only in case of a server failure or a non-response, the client will ask the next DNS server in the list the same question. If a server not responds, the priority of the DNS-server-list will automatically be reordered.

The name-resolution-process can be summarized :

A single name without a dot is called a unqualified simple label name, e.g. ntserver. This name has to made full qualified by adding a suffix. Two types of suffix’s are possible. If a suffix search order is predefined, then it is used. If it is not defined then the Primary (normally the Active Directory domain name) and per-adapter domain names are used. The steps of resolving a unqualified simple name are :

Before Nslookup will work, a PTR record of the name-server must exist in the DNS. Nslookup provide a console with the following options :

You can use the following commands of ipconfig for troubleshooting :

You can also flush the DNS resolver cache by stopping and starting the dns client service.

On the Logging tab of the DNS server you can set the DNS server to maintain a log file. It can log the following types of events :

The file is stored in RTF format in the %systemroot%\system32\dns\dns.log. The folder and filename can be changed in hkey_local_machine\CurrentControlSet\Services\DNS\parameters\LogFilePath.

The default size is 4 mb. This can be changed via the LogFileMaxSize entry in the registry. (minimun size 64 kb)