[cifs-protocol] [MS-DNSP] sticky static dns updates

[Douglas Bagnall]

hi Dochelp,

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?

thanks,
Douglas