Hi, Tridge,
I just want to check to see if you have any more questions about this
request. If not, I will close this case after the new year since you may be on
vocation.
Thanks!
Hongwei
-----Original Message-----
From: Hongwei Sun
Sent: Wednesday, December 22, 2010 6:21 PM
To: 'tri...@samba.org'
Cc: cifs-proto...@samba.org; abart...@samba.org
Subject: RE: [cifs-protocol] authority section return for unknown replies
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-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On
Behalf Of tri...@samba.org
Sent: Monday, December 20, 2010 6:07 PM
To: Interoperability Documentation Help
Cc: cifs-proto...@samba.org; abart...@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:
tri...@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@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
