Article ID: 186820 - View products that this article applies to.
This article was previously published under Q186820
With WINS lookup enabled, a Microsoft DNS server returns RCODE=3 when a name exists but the requested type of resource record (RR) is not available.
The Microsoft DNS server is returning RCODE=3, which, according to RFC 1035, means:
Name Error - Meaningful only for responses from an authoritative nameThis only occurs when WINS lookup is enabled and the Microsoft DNS server has received a response from WINS that states Name Not Found. This is passed back in error to the original requester as rcode-3 (nxdomain).
server, this code signifies that the domain name referenced in the query
does not exist.
BIND 4.9.x and 8.1.x name servers cache the fact that the name does not exist so subsequent queries for other record types that do exist (such as, QTYPE="MX") fail.
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:
(https://support.microsoft.com/kb/152734/EN-US/ )How to Obtain the Latest Windows NT 4.0 Service Pack
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.
Section 4.1, Domain Implementation and Specification, of RFC 1035 statesThe last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section contains RRs that point toward an authoritative name server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question.
RFC 1034 indicatesWhen the resolver performs the indicated function, it usually has one of the following results to pass back to the client:
RFC 1035 includes the followingRCODE Response code - this 4 bit field is set as part of responses. The values have the following interpretation:
0 No error conditionThe algorithm for operation of a name server specified in RFC 1034, is as follows:
1 Format error - The name server was unable to interpret the query.
2 Server failure - The name server was unable to process this query due to a problem with the name server.
3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.
4 Not Implemented - The name server does not support the requested kind of query.
5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (for example, zoneMockapetris [Page 27] transfer) for particular data.
6-15 Reserved for future use.
3. Start matching down, label by label, in the zone. The matching process can terminate several ways:According to the specified algorithm, the only time an authoritative name error is allowed to be specified is in step 3c. In the case that we have, however, the QNAME did match, so you should copy all the RRs into the answer section whose TYPE matches QTYPE (in this case zero RRs), and jump to step 6 which has NO way of setting NXDOMAIN.
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6.
Article ID: 186820 - Last Review: November 1, 2006 - Revision: 2.2