DNS Reference Information

Applies To: Windows Server 2008

RFCs for the DNS Server service

Request for Comments (RFCs) are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents. DNS specifications are based on approved RFCs published by the Internet Engineering Task Force (IETF) and other working groups.

The following RFCs can be found in the IETF RFC Database. These documents contain specifications used to design and implement the DNS Server service and DNS Client service.

• RFC 1034: Domain Names — Concepts and Facilities

• RFC 1035: Domain Names — Implementation and Specification

• RFC 1123: Requirements for Internet Hosts — Application and Support

• RFC 1886: DNS Extensions to Support IP Version 6

• RFC 1995: Incremental Zone Transfer in DNS

• RFC 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

• RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)

• RFC 2181: Clarifications to the DNS Specification

• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)

• RFC 2535: Domain Name System Security Extensions (DNSSEC)

• RFC 2671: Extension Mechanisms for DNS (EDNS0)

• RFC 2782: A DNS RR for specifying the location of services (DNS SRV)

Note

RFCs 1034 and 1035 define the original DNS standard protocol to support domain name services in a TCP/IP environment. These RFCs describe the protocols in a detailed manner, emphasizing the underlying ideas and techniques used in all DNS implementations.

Internet drafts for DNS

Internet drafts are not assigned an RFC number, but are specifications currently in the proposal stage and generally published by one of the IETF working groups, of which several groups focus on discussion of DNS-related topics. The following Internet drafts contain specifications used to design and implement the DNS Server service and DNS Client service:

• Draft-skwan-utf8-dns-02.txt: Using the UTF-8 Character Set in the Domain Name System

• Draft-ietf-dhc-dhcp-dns-08.txt: Interaction between DHCP and DNS

• Draft-ietf-dnsind-tsig-11.txt: Secret Key Transaction Signatures for DNS (TSIG)

• Draft-ietf-dnsind-tkey-00.txt: Secret Key Establishment for DNS (TKEY RR)

• Draft-skwan-gss-tsig-04.txt: GSS Algorithm for TSIG (GSS-TSIG)

Other specifications for DNS

The af-saa-0069.000.doc: ATM Name System Specification version 1.0 specification is used to design and implement the DNS Server service and DNS Client service. This specification is published by the ATM Forum. You can download this specification from the ATM Forum FTP site.

Obtaining DNS RFCs and other Internet draft specifications

You can obtain RFCs and other Internet drafts from the RFC Editor Web site.

DNS resource records reference

A DNS database consists of one or more zone files used by the DNS server. Each zone holds a collection of structured resource records, the following of which are supported by the DNS Server service.

All resource records have a defined format that uses the same top-level fields, as described in the following table.

Format of DNS resource records

Field	Description
Owner	A field that indicates the DNS domain name that owns a resource record. This name is the same as that of the console tree node where a resource record is located.
Time to Live (TTL)	For most resource records, an optional field that indicates a length of time used by other DNS servers to determine how long to cache information for a record before expiring and discarding it. For example, most resource records created by the DNS Server service inherit the minimum (default) TTL of 1 hour from the Start of Authority (SOA) resource record, which prevents overlong caching by other DNS servers. For an individual resource record, you can specify a record-specific TTL that overrides the minimum (default) TTL inherited from the SOA RR. TTL values of zero are not recommended as they increase DNS server utilization unnecessarily. In the following resource record examples, the TTL field is omitted wherever it is optional. The TTL field is included in the syntax for each record to indicate where it can be added.
Class	A required field that contains standard mnemonic text indicating the class of the resource record. For example, a setting of “IN” indicates that the resource record belongs to the Internet class, which is the only class supported by Windows Server 2008 DNS.
Type	A required field that contains standard mnemonic text indicating the type of resource record. For example, a mnemonic of “A” indicates that the resource record stores host address information.
Record-specific data	A required, variable-length field that contains information describing the resource. The format of this information varies according to the type and class of the resource record.

DNS resource records (alphabetical list)

A

Description: Host address (A) resource record. Maps a DNS domain name to an Internet Protocol version 4 (IPv4) 32-bit address. For more information, see RFC 1035.

Syntax:: owner class ttl A IP_v4_address

Example: host1.example.microsoft.com.     IN A 127.0.0.1

AAAA

Description: IPv6 host address (AAAA) resource record. Maps a DNS domain name to an IPv6 128-bit address. For more information, see RFC 1886.

Syntax: owner class ttl AAAA IP_v6_address

Example: ipv6_host1.example.microsoft.com.     IN AAAA 4321:0:1:2:3:4:567:89ab

AFSDB

Description: Andrew File System Database (AFSDB) resource record. Maps a DNS domain name in the server_host_name field to the host name for a server computer of a server subtype. The subtype field can have either of the following recognized and supported values: A value of 1 to indicate that the server is an AFS version 3.0 volume location server for the named AFS cell. A value of 2 to indicate that the server is an authenticated name server holding the cell-root directory node for the server that uses either Open Software Foundation’s (OSF) DCE authenticated cell-naming system or Network Computing Architects, Inc. (NCA) architecture. For more information, see RFC 1183.

Syntax: owner ttl class AFSDB subtype server_host_name

Example: example.microsoft.com.   AFSDB   1 afs-server1.example.microsoft.com.

ATMA

Description: Asynchronous Transfer Mode address (ATMA) resource record. Maps a DNS domain name in the owner field to an ATM address referenced in the atm_address field. For more information, see “ATM Name System Specification Version 1.0” at the ATM Forum FTP site. At the ATM Forum FTP site, download af-saa-0069.000.doc or af-saa-0069.000.rtf.

Syntax: owner ttl class ATMA atm_address

Example: atm-host   ATMA   47.0079.00010200000000000000.00a03e000002.00

CNAME

Description: Canonical name (CNAME) resource record. Maps an aliased or alternate DNS domain name in the owner field to a canonical or primary DNS domain name specified in the canonical_name field. The canonical or primary DNS domain name used in the data is required and must resolve to a valid DNS domain name in the namespace.

Syntax: owner ttl class CNAME canonical_name

Example: aliasname.example.microsoft.com.   CNAME   truename.example.microsoft.com.

HINFO

Description: Host information (HINFO) resource record. Specifies the type of CPU and operating system in the cpu_type and os_type fields, respectively, for the host DNS domain name in the owner field. Well-known CPU and operating system types that are most often used are noted in RFC 1700. This information can be used by application protocols such as FTP, which use special procedures when communicating with computers of a known CPU and operating system type.

Syntax: owner ttl class HINFO cpu_type os_type

Example: my-computer-name.example.microsoft.com.    HINFO   INTEL-386 WIN32

ISDN

Description: Integrated Services Digital Network (ISDN) resource record. Maps a DNS domain name to an ISDN telephone number. Telephone numbers used with this record should follow ITU-T E.163/E.164 international telephone numbering standards, which are compatible with current international phone numbering plans already in use. For more information, see RFC 1183.

Syntax: owner ttl class ISDN isdn_address sub_address

Example: my-isdn-host.example.microsoft.com.    ISDN   141555555539699 002

KEY

Description: Public key (KEY) resource record. Contains a public key that is associated with a zone. In a full DNS Security (DNSSEC) implementation, resolvers and servers use KEY resource records to authenticate SIG resource records received from a signed zones. KEY resource records are signed by the parent zone, allowing a server that knows a parent zone’s public key to discover and verify the child zone’s key. Name servers or resolvers receiving resource records from a signed zone obtain the corresponding SIG record and then retrieve the zone’s KEY record. For more information, see RFC 2535.

Syntax: owner class KEY protocol digital_signature_algorithm (DSA) public_key

Example: widgets.microsoft.com IN KEY 0x0000 3 0

MINFO

Description: Mailbox mail list information (MINFO) resource record. Specifies (in responsible_mailbox) a domain mailbox name for a responsible person who maintains a mailing list or mailbox specified in the owner field. The error_mailbox field can also be used to specify a domain mailbox that receives error messages related to this mailing list or mailbox. Mailboxes specified for responsible contacts and error forwarding must be the same as valid mailbox (MB) records that already exist in the current zone. For more information, see RFC 1035.

Syntax: owner ttl class MINFO responsible_mailbox error_mailbox

Example: administrator.example.microsoft.com.    MINFO resp-mbox.example.microsoft.com err-mbox.example.microsoft.com

MX

Description: Mail exchanger (MX) resource record. Provides message routing to a mail exchanger host, as specified in mail_exchanger_host, for mail sent to the domain name specified in the owner field. A 2-digit preference value indicates preferred ordering if multiple exchanger hosts are specified. Each exchanger host must have a corresponding host (A) address resource record in a valid zone. For more information, see RFC 1035.

Syntax: owner ttl class MX preference mail_exchanger_host

Example: example.microsoft.com. MX 10 mailserver1.example.microsoft.com

NS

Description: Name server (NS) resource record. Used to map a DNS domain name as specified in owner to the name of hosts operating DNS servers specified in the name_server_domain_name field.

Syntax: owner ttl IN NS name_server_domain_name

Example: example.microsoft.com.    IN NS nameserver1.example.microsoft.com

NXT

Description: Next (NXT) resource record. Indicates the nonexistence of a name in a zone by creating a chain of all of the literal owner names in that zone. They also indicate which resource record types are present for an existing name. For more information, see RFC 2535.

Syntax: owner class NXT next_domain_name last_record_type NXT

Example: east.widgets.microsoft.com. IN NXT ftp.widgets.microsoft.com. A NXT

OPT

Description: Option (OPT) resource record. One OPT resource record can be added to the additional data section of either a DNS request or response. An OPT resource record belongs to a particular transport level message, such as UDP, and not to actual DNS data. Only one OPT resource record is allowed, but not required, per message. For more information, see RFC 2671.

Syntax: Name OPT class ttl rdlen rdata

Example: null OPT IN 1280 0 0

PTR

Description: Pointer (PTR) resource record. Points from the name in owner to another location in the DNS namespace, as specified by targeted_domain_name. Often used in special domains, such as the in-addr.arpa domain tree, to provide reverse lookups of address-to-name mappings. In most cases, each record provides information that points to another DNS domain name location, such as a corresponding host (A) address resource record in a forward lookup zone. For more information, see RFC 1035.

Syntax: owner ttl class PTR targeted_domain_name

Example: 1.0.0.10.in-addr.arpa.    PTR host.example.microsoft.com.

RP

Description: Responsible Person (RP) resource record. Specifies the domain mailbox name for a responsible person in mailbox_name. This name is then mapped to a domain name in text_record_name for which (TXT) resource records exist in the same zone. When RP records are used in DNS queries, subsequent queries are used to retrieve associated text (TXT) resource record information. For more information, see RFC 1183.

Syntax: owner ttl class RP mailbox_name text_record_name

Example: example.microsoft.com. RP admin.example.microsoft.com. admin-info.example.microsoft.com. admin-info.example.microsoft.com. TXT “Joe Administrator, (555) 555-0110”

SIG

Description: Signature (SIG) resource record. Encrypts an RRset to a signer’s (RRset’s zone owner) domain name and a validity interval. For more information, see RFC 2535.

Syntax: owner class SIG ttl signature_expiration signature_inception key_identifier signer_name{digital_signature}

Example: widgets.microsoft.com IN SIG 86400 19700101000000 19700101000000 49292 widgets.microsoft.com.{ AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHF ElxbvKoWmvjDTCmfiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= }

SOA

Description: Start of Authority (SOA) resource record. Indicates the name of origin for the zone and contains the name of the server that is the primary source for information about the zone. It also indicates other basic properties of the zone. The SOA resource record is always first in any standard zone. It indicates the DNS server that either originally created it or is now the primary server for the zone. It is also used to store other properties, such as version information and timings that affect zone renewal or expiration. These properties affect how often transfers of the zone are performed between servers authoritative for the zone. In the following example, the owner (primary DNS server) is specified as “@” because the domain name is the same as the origin of all data in the zone (example.microsoft.com.). This is a standard notation convention for resource records and is most often seen in the SOA record.

Syntax: owner class SOA name_server responsible_person (serial_number refresh_interval retry_interval expiration minimum_time_to_live)

Example: @   IN SOA     nameserver.example.microsoft.com. postmaster.example.microsoft.com. ( 1            ; serial number 3600         ; refresh   [1h] 600          ; retry     [10m] 86400        ; expire    [1d] 3600 )       ; min TTL   [1h]

SRV

Description: Service locator (SRV) resource record. Allows multiple servers providing a similar TCP/IP-based service to be located using a single DNS query operation. This record enables you to maintain a list of servers for a well-known server port and transport protocol type ordered by preference for a DNS domain name. For example, in Windows Server 2008 DNS, it provides the means to locate domain controllers that use Lightweight Directory Access Protocol (LDAP) service over TCP port 389. The purposes of each of the specialized fields used in an SRV resource record are as follows: service A symbolic name for the desired service. For well-known services, a reserved universal symbolic name such as “_telnet” or “_smtp” is defined in RFC 1700. If a well-known service name is not defined in RFC 1700, a local or user-preferred name can be used instead. Some widely used TCP/IP services, notably the Post Office Protocol (POP), do not have a single universal symbolic name. If RFC 1700 assigns a name for a service indicated in this field, the RFC-defined name is the only name you can use. Only locally defined services can be named locally. protocol Indicates the transport protocol type. Typically, this is either TCP or UDP, although any transport protocol named in RFC 1700 can be used. name The DNS domain name referred to by this resource record. The SRV resource record is unique among other DNS record types in that it is not used to perform the search or query. priority Sets the preference for a host specified in the target field. DNS clients that query for SRV resource records attempt to contact the first reachable host of the lowest numbered preference listed here. Although target hosts have the same stated preference value, they can be tried in random order. The range of preference values is 0 to 65535. weight Can be used in addition to preference to provide a load-balancing mechanism where multiple servers are specified in the target field and are all set to the same level of preference. When selecting a target server host among those of equal preference, this value can be used to set an added level of preference that can be used to determine the exact order or balancing of selection for the target hosts used in an answered SRV query. When a non-zero value is used, servers of equal preference are tried in proportion to the weight of this value. The range of values is 1 to 65535. If load balancing is not needed, use a value of 0 in this field to make the record easier to read. port The server port on the target host that provides the service indicated in the service field. The range of port numbers is 0 to 65535, although the number is often a well-known assigned service port number, as specified in RFC 1700. Unassigned ports can be used as needed. target Specifies the DNS domain name of the host that provides the type of service being requested. For each host name used, a corresponding host address (A) resource record in the DNS namespace is required. A single period (.) can be used in this field to indicate authoritatively that the requested service specified in this SRV resource record is not available at this DNS domain name. For more information, see the Internet draft “A DNS RR for specifying the location of services (DNS SRV).”

Syntax: service.protocol.name ttl class SRV preference weight port target

Example: _ldap._tcp._msdcs    SRV 0 0   389 dc1.example.microsoft.com SRV 10 0   389 dc2.example.microsoft.com

TXT

Description: Text (TXT) resource record. Maps a DNS domain name specified in the owner field to a string of characters in text_string serving as descriptive text. For more information, see RFC 1035.

Syntax: owner ttl class TXT text_string

Example: example.microsoft.com.    TXT “This is an example of additional domain name information.”

WKS

Description: Well-known service (WKS) resource record. Describes the well-known TCP/IP services supported by a particular protocol on a specific IP address. WKS records provide TCP and UDP availability information for TCP/IP servers. If a server either supports both TCP and UDP for a well-known service or has multiple IP addresses that support a service, then multiple WKS records are used. For more information, see RFC 1035.

Syntax: owner ttl class WKS address protocol service_list

Example: example.microsoft.com.    WKS 10.0.0.1 TCP ( telnet smtp ftp )

X25

Description: X.25 (X25) resource record. Maps a DNS domain name in the owner field to a Public Switched Data Network (PSDN) address number specified in psdn_number. PSDN numbers used with this record should follow the X.121 international numbering plan. For more information, see RFC 1183.

Syntax: owner ttl class X25 psdn_number

Example: example.microsoft.com.    X25 52204455506

DNS server log reference

The following is a partial list of events recorded in the DNS server log. Event messages logged by the DNS Client service are logged in System log, and can also be viewed using Event Viewer at the applicable client computer. If you need to troubleshoot persistent problems, you can also enable advanced debugging options at the DNS server for obtaining a more detailed log of server activity. You can view this log by using the DNS console after the DNS Server service is installed on the server computer.

Some events recorded in the DNS server log

Event ID	Description
2	The DNS server has started. This event appears at startup when either the server computer is started or the DNS Server service is started manually.
3	The DNS server has shut down. This event appears when either the server computer is shut down or the DNS Server service is stopped manually.
408	This event indicates the DNS server could not open a socket for address IPaddress. Verify that this is a valid IP address for the server computer. If this is a valid IP address for the server computer, verify that no other application that would attempt to use the same DNS server port (such as another DNS server application) is running. By default, DNS uses TCP port 53.
413	This event indicates the DNS server will send requests to other DNS servers on a port other than its default port (TCP port 53). This DNS server is multihomed and has been configured to restrict DNS Server service to only some of its configured IP addresses. For this reason, there is no assurance that DNS queries made by this server to other remote DNS servers will be sent using one of the IP addresses enabled for the DNS server. This might prevent query answer responses returned by these servers from being received on the DNS port that the server is currently configured to use. To avoid this problem, the DNS server sends queries to other DNS servers using an arbitrary non-DNS port, and the response is received regardless of the IP address used. Typically, the response to this event is to limit the DNS server to using only its configured DNS port for sending queries to other DNS servers. Use the Interfaces tab of server properties in the DNS console as follows: To enable the DNS server to listen on all configured server IP addresses, select All IP addresses. Or, if you continue to select and use Only the following IP addresses, limit the IP address list to a single server IP address.
414	This event indicates the server computer currently has no primary DNS suffix configured. Its DNS name is currently a single label host name. For example, its currently configured name is “host” rather than “host.example.microsoft”.com or another fully qualified name. While the DNS server has only a single label name, default resource records created for its configured zones use only this single label name when mapping the host name for this DNS server. This can lead to incorrect and failed referrals when clients and other DNS servers use these records to locate this server by name. In general, the DNS server should be reconfigured with a full DNS computer name appropriate for its domain or workgroup use on your network.
708	This event indicates the DNS server did not detect any zones of either primary or secondary type. It will run as a caching-only server but will not be authoritative for any zones.
3150	This event should only appear if the DNS server is configured to operate as a root server. The DNS server wrote a new version of zone zonename to file filename. You can view the new version number in the Serial Number field of the DNS Manager Zone Properties dialog box.
6527	This event might appear when the DNS server is configured to host a secondary copy of the zone from another DNS server acting as its source or master server. It is always a good practice to verify that this server has network connectivity to its configured master server. Zone zonename expired before it could obtain a successful zone transfer or update from a master server acting as its source for the zone. The zone has been shut down. If the problem continues, one or more of the following options is available: Delete the zone and re-create it, specifying either a different master server, or an updated and corrected IP address for the same master server. If zone expiration continues, consider adjusting the expire interval.

For more information about all other messages not described in this topic, refer directly to the message text itself as it appears in the DNS server event log.