IMPORTANT: This article contains information about editing the registry.Before you edit the registry, make sure you understand how to restore it ifa problem occurs. For information about how to do this, view the "Restoringthe Registry" Help topic in Regedit.exe or the "Restoring a Registry Key"Help topic in Regedt32.exe.
WARNING: Using Registry Editor incorrectly can cause serious problems thatmay require you to reinstall your operating system. Microsoft cannotguarantee that problems resulting from the incorrect use of Registry Editorcan be solved. Use Registry Editor at your own risk.
For information about how to edit the registry, view the "Changing KeysAnd Values" Help topic in Registry Editor (Regedit.exe) or the "Add andDelete Information in the Registry" and "Edit Registry Data" Help topicsin Regedt32.exe. Note that you should back up the registry before you editit.
To change these parameters, use the following procedure:
- Start Registry Editor (Regedt32.exe).
- From the HKEY_LOCAL_MACHINE subtree, go to the following key:
- From the Edit menu, click Add Value and add a value to the key described in the appropriate entry below. Type in the value, and use the "Data Type" check box to set the value type.
- Click OK.
- Quit Registry Editor.
- Restart the DNS Server for the above changes to take affect.
Several registry parameters determine behavior of the entire server. Each of these is a registry value under
: These registry keys are read only at startup. Some may be reset and, in some cases, the server behavior dynamically changed, through the DNS Administrator. But if manually reset, the DNS server must be restarted to pick up the new value.
All of the DNS parameters are registry values located under subkeys of:
Value: SecureResponses Added: SP4 (April 1998) Type: DWORD (Boolean) Default: NoKey = OFF (Non-secure data is kept) Function: Determines whether server attempts to clean up responses to avoid cache pollution.
With the Service Pack 4 (April, 1998) release, the SecureResponses flag is off. Create the SecureResponses value and set it to 1 to enable it. Responses from other DNS servers may contain records whose validity are open to question.
Examples: DNS server makes MX query for domain.samples.microsoft.com tosamples.microsoft.com's DNS server. The samples.microsoft.com DNS server responds but includes A record for A.ROOT-SERVERS.NET giving its own address. The rogue DNS server has then gotten itself set up as a root server in your DNS server's cache. Less malicious, but more common, are referral responses (or direct responses from BIND, see WriteAuthorityNs for discussion) that contain records for the DNS of an ISP:Authority section:
new.samples.microsoft.com NS ns.new.samples.microsoft.com.
new.samples.microsoft.com NS ns.isp.samples.microsoft.com.
ns.new.samples.microsoft.com. A 126.96.36.199NOTE
ns.isp.samples.microsoft.com. A 188.8.131.52
: The address record for the ISP happens to be old\stale.If SecureResponses is on, records that are not in a subtree of the zone queried are eliminated. For example, in the example above, the samples.microsoft.com. DNS server was queried, so the all the samples.microsoft.com records are secure, but the ns.isp.microsoft.com. A record is not in the sample .microsoft.com. subtree, and is not cached or returned by the DNS server.
Value: RecursionRetry Added: Windows NT 4.0 Type: DWORD Default: NoKey (Retry is three seconds) Function: Set the interval before retrying a recursive lookup.
To resolve recursive client queries, the DNS server queries remote DNSservers. When no response comes back, the server must retry (to the sameand/or other DNS servers). This key allows override of default retrytimeout. If the RecursionRetry key does not exist or is zero, retries aremade after three seconds. If the RecursionRetry key is nonzero, its value(in seconds) sets the retry interval. Users should not alter this key.
Value: RecursionTimeout Added: Windows NT 4.0 Type: DWORD Default: NoKey (Timeout is 15 seconds) Function: Set the timeout before DNS server gives up recursive query.
To resolve recursive client queries, the DNS server queries remote DNSservers. When no response comes back, the server from any of the remoteservers contacted, the DNS server must eventually give up on the query andreport to the client that it was unable to answer it (response code isSERVER_FAILURE). This key allows override of default retry timeout. If theRecursionTimeout key does not exist or is zero, the DNS gives up after 15seconds. If the RecursionTimeout key is nonzero, its value (in seconds)sets the retry timeout. In general the 15-second timeout allows anyoutstanding response from anywhere to get back to the DNS server. Users arediscouraged from altering this key.
Value: RoundRobin Added: SP4 Type: DWORD (Boolean) Default: NoKey (Round robin A records) Function: Determine whether server round robins multiple A records.
By default, the Microsoft DNS server round robins A records when multiple Arecords exists for a name. This is a primitive load balancing mechanism.
If the RoundRobin key does not exist or is nonzero, the DNS server roundrobins A records. If the RoundRobin key is zero, the DNS server returns Arecords in a fixed (file load) order.
Value: LocalNetPriority Added: SP4 Type: DWORD (Boolean) Default: NoKey (Give local net records priority) Function: Determine the priority of multiple A records given in response.
By default, the Microsoft DNS server gives priority to the "closest" Arecord to the client's IP address when there are multiple A records for aname. This is designed so that the client application will attempt toconnect to the closest (and fastest) IP available.
Example: www.samples.microsoft.com has three A records: 184.108.40.206,220.127.116.11, and 18.104.22.168. Client at 22.214.171.124 queries DNS server forwww.samples.microsoft.com. Instead of returning in database order or roundrobin, the DNS server notices that the client's 131.21 address matches thenetwork (class B) portion of the 126.96.36.199 address. The DNS server thenreorders the addresses in the response:
188.8.131.52 184.108.40.206 220.127.116.11
If the client query comes from 18.104.22.168, then none of addressesmatches in the network portion of the address and NO local net priorityreordering is done.
If more than one address matches in the network portion, then the matchingaddresses are ordered with the closest match first so that the result ismost likely to be correct regardless of any subnetting.
Example: www.samples.microsoft.com has four A records: 22.214.171.124,126.96.36.199, 188.8.131.52, and 184.108.40.206. Client at 220.127.116.11 queriesDNS server for www.samples.microsoft.com. Now both 131.21 addresses arereturned at the top, but the 131.21.196 address is first because it matchesthe client's IP address down through the 131.21.192 subnet (that is, itwould match even if subnetting down to a 255.255.248 mask). So the responseis ordered:
18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52
NOTE: Having LocalNetPriority supersedes round robining. However, ifRoundRobin is on, the records continue to be round-robined, and arereturned in the current round-robin order when no LocalNetPriority matchcan be made.
Value: AddressAnswerLimit Added: SP3 Type: DWORD Default: NoKey (No limit) Function: Limits number of A records put in answer to query.
The AddressAnswerLimit registry key puts a limit on the number of A recordsthat are actually written to the answer section in a response to an Arecord query. This has two benefits:
- Allows Windows 95 clients to operate correctly, even when a DNS name is configured with more than 28 A records.
- Keeps remote DNS servers resolving a name from retrying with TCP when they receive a truncated response. (In general, client resolvers will not retry with TCP, whether the truncation bit is set or not.)
If the AddressAnswerLimit registry key is nonzero, it specifies a limit onthe number of A records written into an answer for a name. The limit itselfis bounded 5 < x < 28. So an AddressAnswerLimit value greater than 28, willresult in a limit of 28, and a value 0 < x < 5, will result in a limit offive. (The bottom limit of 5 is there so that, if multiple addresses are available, at least enough is given back so that one computer is likely to be found.) Inaddition, when AddressAnswerLimit is set, the truncation bit is not set ona response, even if the packet space is exhausted before the limit forwriting A records is reached (see benefit 2 above).
NOTE: These restrictions are only for simple A record queries to the name.They do not affect other query types.
If the AddressAnswerLimit registry key does not exist or is zero, A recordresponses are not limited. All A records for a name are written to thepacket. If all the records do not fit in a UDP DNS packet, the truncationbit it set.
Value: LooseWildcarding Added: SP4 Type: DWORD (Boolean) Default: NoKey (prior to SP4 loose; after SP4 RFC wildcarding) Function: Set server to do wildcarding loosely.
Zone file fragment:
*.sample.microsoft.com. MX 10 mailserver1.sample.microsoft.com. sample.microsoft.com. MX 10 mailserver2.sample.microsoft.com. host.sample.microsoft.com. A 184.108.40.206
Host.sample.microsoft.com, type MX
According to RFC, the host.samples.microsoft.com.com query is looked up andno MX record is found at host.samples.microsoft.com, but an A record doesexist. Hence, no wildcard matching is done. The query responds with anauthoritative empty response (no error and no records). Smart mail programswould then requery for an A record for host.samples.microsoft.com and usethe A record to send mail directly to host.samples.microsoft.com.
Before Service Pack 4 (SP4), the Microsoft DNS server finds no MX record athost.samples.microsoft.com, notes that MX is a wildcard type, and notesthat samples.microsoft.com is the parent of a wildcard name. It checks thatwildcard name *.samples.microsoft.com for MX records, finds a match andreturns it. The mail program would then send mail tomailserver1.samples.microsoft.com.
The advantages of each approach should be apparent. The RFC approach iseasier if your hosts are capable of receiving mail directly. However, ifyou advertise hosts that are not mail servers, you also need to explicitlyadd MX records at each host. The Microsoft DNS approach allows you to setup just two MX records and cover queries to the entire zone. However, ifyou have individual hosts that should receive there own mail, you need toput MX records at each of these hosts.
If the LooseWildcarding key does not exist or is zero, the server (afterSP4) will follow the RFC specified wildcarding behavior. The administratoris advised to put MX records in for all hosts that are not capable ofreceiving mail.
If the LooseWildcarding key is nonzero, the server aggressively seek outthe closest wildcard node (equivalent to shipped Windows NT 4.0 behavior).The administrator should put MX records at both the zone root and in awildcard node (*) directly below the zone root. The administrator shouldalso put self-referent MX records on hosts that are to receive their ownmail.
Value: BindSecondaries Added: Windows NT 4.0 Type: DWORD (Boolean) Default: NoKey (Send uncompressed transfers to non-MS secondaries) In Admin: No. Function: Determine AXFR message format when sending to non-MS DNS secondary.
BIND did not implement the RFC specified zone transfer protocol.Specifically, BIND sends one zone record in every DNS message. This addsthe unnecessary overhead of a message header with every record; it alsoeliminates any possibility of name compression. BIND servers prior to 4.9.4will refuse zone transfer messages that properly buffer multiple records ineach DNS message, and some implementations may fault. More recent BINDversions (4.9.4 and later) will both accept and send the faster compressedformat, but may be configured with a list of servers that must receive theold format.
The Microsoft DNS server can send (and receive) messages in either format.To allow Microsoft to Microsoft transfers to use the faster format, aMicrosoft DNS secondary appends two characters (MS) to its AXFR requestpacket. When a Microsoft master receives a request with this signal, itthen sends the transfer using the fast compressed format. If the requestdoes not contain this signal, the transfer is sent using the slower onerecord per message format, to avoid causing problems if the secondary is anold BIND implementation.
If the BindSecondaries registry key does not exist or is nonzero, theserver uses the paradigm described above and will always send transfers tonon-Microsoft DNS secondaries in the uncompressed BIND compatible format.If the BindSecondaries registry key is zero, the server will send alltransfers in the fast format. Note that the default behavior is adequate totransfer to any DNS server. The only reason to use the BindSecondaries keyis when you have NEW BIND servers (or non-BIND, non-Microsoft servers) thatare secondaries to an Microsoft DNS server and you want to get the fastestpossible transfer performance.
As the fixed BIND servers replace older versions, the defaults to this keymay be altered so that the efficient transfer is the default even to non-Microsoft servers.
Value: WriteAuthorityNs Added: SP3 Type: DWORD (Boolean) Default: NoKey (Do not write unnecessary NS records) Function: Write NS records to authority section on successful response.
By default, Microsoft DNS server uses the authority section only asoutlined by RFC1034:
- For NS records when making a referral.
- For an SOA record to allow caching of a NAME_ERROR response. (In compliance with dnsind clarify draft.)
If the WriteAuthorityNs registry key is nonzero, the server will write NSrecords for the zone into the Authority section when making a successfulauthoritative response. If the WriteAuthorityNs registry key does not existor is zero, the server use the default RFC compliant behavior and onlywrite to the Authority section in the two cases noted above.
NOTE: This key exists only for those who need Authority data for someprogrammatic reason.
Value: WriteAuthoritySoa Added: SP3 Removed: SP4 Type: DWORD (Boolean) Default: NoKey (Do not write unnecessary SOA record) Function: Write NS records to authority section on successful response.
The use of this key is deprecated. Use WriteAuthorityNs (see above) ifmimicking of BIND authority section behavior is desired.
Value: ListenAddresses Added: Windows NT 4.0 Type: BINARY Default: NoKey (Use all IP interfaces) Function: Determines IP addresses bound to DNS server.
Some DNS resolvers (including Windows 95) require that the IP sourceaddress of a DNS response be the same as the IP address they sent the queryto, or they reject the response. Accommodating these resolvers means thatthe DNS server must explictly bind sockets to IP addresses on the computer.
The ListenAddresses key is a list of IP addresses for the DNS server tolisten on. The list is not dotted IP strings, but a counted array of rawaddresses in net byte order. It should be configured through the ServerProperties, Interfaces dialog box in the Administrator tool. Editing theregistry key is discouraged. If the ListenAddresses key does not exist, theDNS server attempts to bind to every IP address on the computer. This is,in general, desirable behavior.
However, there are a few reason why using the listen address key may bedesirable:
- For administrative reasons, you do not want to use some interfaces.
- Computer contains lots of IP interfaces, binding to all of them is expensive.
- If greater than 35 IP interfaces, the DNS server will not detect and bind to all IP interfaces properly. Because of limitations in Winsock's GetAddressByName(), only the first 35 interfaces are returned to the DNS server. If your DNS should be bound to any addresses beyond the first 35, whether all the addresses on the computer or some subset, ListenAddresses is required to get the correct binding.