[cifs-protocol] authority section return for unknown replies

[Hongwei Sun]

Tridge,

   I duplicated the exactly same behavior between the windows client using nslookup and the Windows server.  After tracing through the logic, it looks like that Windows DNS server will send a zone SOA record if it is a authoritative response and  DNS_RECORD_NAME_ERROR will be returned.  This explains the behavior we observed.   Since there is  no WSPP document for Microsoft extension to general DNS operations (MS-DNSP is for the DNS management RPC interface), Microsoft's implementation should follow the RFCs in this regard, so I started to review the related RFCs and certain informative MSDN content.   

   It looks like that the SOA record added to the response with no name error is for the negative response caching, which is an option feature defined in section 4.3.4 of RFC 1034.   In this feature, a name server may add an SOA RR to the additional section of a response when that response is authoritative.  It allows name servers to distribute and resolve to cache , negative results with TTL. For example, a name server can distribute a TTL along with a name error indication, and a resolver receiving such information is allowed to assume that the name does not exist during the TTL period without consulting authoritative data.   The section 2.2.1 of RFC2308 also specifically called out a name server to include a SOA record to allow negative answer caching.  
     
   As of the dynamic update, the DHCP client machine  will start with an explicit SOA type query using the DNS domain name of the computer to find the primary DNS server (http://technet.microsoft.com/en-us/library/dd197552(WS.10).aspx).  This is shown in some dynamic updates in network traces we have seen before. 
 
   Please let me know if this makes sense.  If you have further question, We can continue after Christmas break.  
  
Merry Christmas !!!

Hongwei



-----Original Message-----
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of tridge at samba.org
Sent: Monday, December 20, 2010 6:07 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org; abartlet at samba.org
Subject: [cifs-protocol] authority section return for unknown replies

Windows DNS servers return an AUTHORITY section pointing at the
authoritative DNS server when looking up a name that doesn't
exist. We'd like to know if this is important for correct operation
with Windows clients.

For example, if I lookup unknown.v2.tridgell.net:

tridge at blu:~/$ dig @10.0.0.4 -t A unknown.v2.tridgell.net.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29547
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;unknown.v2.tridgell.net.       IN      A

;; AUTHORITY SECTION:
v2.tridgell.net.        3600    IN      SOA     w2k8.v2.tridgell.net. hostmaster.v2.tridgell.net. 689 900 600 25200 3600


In the above, w2k8.v2.tridgell.net is a w2k8r2 DNS server and DC. 

A bind9 server, which we are using for DNS in Samba, doesn't do this,
and we would like to know if this will cause any problems.

We suspect this relates to how Windows clients find the DNS server to
do dynamic updates to. A windows client will first look for its own
name in the above manner, and seems to use the authority reply to
determine where to send the update. When we don't give the authority
reply, windows clients seem to fall back on a different mechanism, but
we would like to know that the alternative mechanism is reliable.

We suspect this is related to the way that Windows servers virtualise
the SOA record, so that each DC returns a SOA record pointing at
itself, even when the underlying LDAP record points at a different
server.

Is this SOA behaviour and AUTHORITY behaviour documented in WSPP
anywhere? We couldn't find it.

Cheers, Tridge
_______________________________________________
cifs-protocol mailing list
cifs-protocol at cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol