[cifs-protocol] [REG:110122101544609]authority section return for unknown replies

[Bryan Burgin]

[dochelp to bcc]
[Adding case # to title; adding case mail]

Hi, Tridge,

I created SR 110122101544609 for this issue.  An engineer from the protocols team will contact you soon.

Bryan


-----Original Message-----
From: tridge at samba.org [mailto:tridge at samba.org] 
Sent: Monday, December 20, 2010 4:07 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org; abartlet at samba.org
Subject: 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