[cifs-protocol] [EXTERNAL] [MS-DNSP] sticky static dns updates - TrackingID#2106070040005009
tomjebo at microsoft.com
Mon Jun 7 15:42:45 UTC 2021
[dochelp to bcc]
Thanks for the question. I have created case number 2106070040005009 to track this issue and placed the number in the subject of this email. Please refer to it and leave it in the subject when communicating about this issue with our team. One of the Open Specifications team members will get back to you shortly.
Sr Escalation Engineer
Microsoft Open Specifications
From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
Sent: Sunday, June 6, 2021 11:55 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol <cifs-protocol at lists.samba.org>
Subject: [EXTERNAL] [MS-DNSP] sticky static dns updates
Another question around DNS nodes and records, based on tests against 2012r2.
In the following series of steps, where I mention a TXT record (A, B, C, or D) it refers to a record with that string (e.g. "A") as data (which should not be relevant, other than that they are all distinct).
1. Create a new zone.
2. Create a dnsNode in the zone.
3. Add TXT record A via a DNS update (RFC1035). This record will have the current timestamp, as expected.
4. Add another text record B using LDAP, setting the dwTimeStamp to 0, making B a static record.
5. Perform a DNS update on B (this step appears to alert the server to B's static status).
6. Add record C using DNS update. This record is created as static, with timestamp 0.
7. Remove records B and C using LDAP.
8. A new record D is added using DNS update. This record also gets a zero timestamp, although there is nothing in the LDAP node object to tell it that. Record A still has its original timestamp.
(Steps 3 and 6 are illustrative and can be skipped. Record A can also be removed in step 7, and/or step 8 can update the existing record A instead of creating the new D. It doesn't matter whether aging is turned on or not.)
My questions relate to the behaviour in step 8.
As far as I can see, there is no method in the documented protocols to determine that a node has the "static bit" set (short of creating a record). It is not recorded in the ldap objects, and not revealed over RPC. Is this correct?
Therefore it follows that this stickiness will not replicate to other servers? That is, if another server joins after step 7, and step 8 is performed there, the update would lead to D having a current timestamp because that server knows only what replication/ldap knows, right?
Have I just missed something? Or have the docs missed something?
More information about the cifs-protocol