Knowledge Base

Updated Version of Dns.exe Fixes Several Problems

Article ID: 159310

Article Last Modified on 11/1/2006


APPLIES TO


This article was previously published under Q159310

SYMPTOMS

An updated version of Dns.exe is available to fix the following problems:
  • A lookup for a non-existent A record takes about 30 seconds to time out: When the internal DNS server is queried, it goes to the root server. If the root server returns an RCODE of 0, the Microsoft DNS server does not respond to its client immediately. Some versions of BIND may return an RCODE of 0. This can cause a 30 second delay at the querying client.
  • Problem resolving some MX records: If a DNS client does a recursive query to the Microsoft DNS server for an MX record and the authoritative DNS server for that MX record returns an SOA record instead (because the MX record doesn't exist), the Microsoft DNS server does not return that SOA record to the client. A BIND DNS server does return the SOA record to the DNS client even though it requested an MX record. Microsoft has modified its DNS service to be compatible with BIND.


  • BIND incompatibility: When the Microsoft DNS service receives a query for a name that requires an authoritative lookup, and the DNS server handling the lookup is a BIND server, it may respond with a CNAME record, causing the name server (NS) record for the BIND server to be overwritten in cache. The NS record is used to specify the authoritative name server for a domain.


  • When using the new WriteAuthorityNs reg key that was added in Windows NT 4.0 SP3 DNS, DNS queries will always return authority records=0 and additional=0 instead the actual count for this.


  • If you delegate a zone (such as mydepartment.mycompany.com) to a DNS server that is not in the zone (such as yourserver.yourdepartment.company.com), when a client does a lookup on a host in the delegated zone, it will not succeed. If you ping the server that the zone was delegated to (yourserver.yourdepartment.company.com) once so that it is cached, lookups will start to succeed. The problem was caused by a problem following the glue record that was associated with the delegation, and it has been fixed.


  • Access Violation in Dns.exe: Dr Watson may report an access violation on a secondary DNS server when it is receiving invalid records from the primary, and the data changes on the primary from the initial zone transfer.

Other updates and optimizations:
  • Reduced traffic to root servers: This version eliminates the automatic root query on startup and in the timeout thread; instead, it queries the root only when it receives a query that needs to be sent to the root servers, and limits retrying the root servers to once every ten minutes.
  • Better recursion response: This version supports direct forwarding of a response from the remote DNS, where possible.
  • Eliminates a deadlock condition hit by a few customers. At least one person posting on the MS-DNS newsgroup reported hitting a deadlock. The symptom of this is that the server stops responding to all requests.
  • Better use of SOA in authority section: This version still has an optimization to avoid this on local queries, but overall should be a more "friendly" partner for remote DNS servers when sending a NAME_ERROR or no-records response.
  • Local network prioritization of queries: If there are multiple A records, this version of the server puts the one that "fits best" first; if none fits best, a straight round robin scheme is followed. This is off by default but can be turned on with the new LocalNetPriority registry flag:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Paramete

    Value Name: LocalNetPriority
    Data Type : REG_DWORD
    Data : 0 or 1 (0 is disabled)

    NOTE: This key does not exist by default.


For more information see the following article in the Microsoft Knowledge base:

ARTICLE-ID: 177883
TITLE : DNS Server Stops Using Round Robin for Host Name Resolution

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

152734 How to Obtain the Latest Windows NT 4.0 Service Pack


STATUS

Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.

MORE INFORMATION

The hotfix mentioned above, may experience some problems as specified below:

Additional query words: 4.00

Keywords: kbhotfixserver kbqfe kbbug kbnetwork kbqfe KB159310