[cifs-protocol] [EXTERNAL] [MS-DNSP] sticky static dns updates - TrackingID#2106070040005009

[Douglas Bagnall]

hi Jeff,

The client side is Samba. If you are able to compile and run Samba 
testcases, I can prepare a git branch or patch that contains this test.

Attached is a network capture, though the ldap is all encrypted.

I have not tried with a Windows client.

Douglas


On 8/06/21 5:46 am, Jeff McCashland wrote:
> I see you said at the top the server is WS 2012 R2. What tool and steps are you using to repro the issue?
> 
> Best regards,
> Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
> 
> -----Original Message-----
> From: Jeff McCashland
> Sent: Monday, June 7, 2021 9:55 AM
> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>; cifs-protocol <cifs-protocol at lists.samba.org>
> Cc: jeffm at microsoftsupport.com
> Subject: RE: [EXTERNAL] [MS-DNSP] sticky static dns updates - TrackingID#2106070040005009
> 
> [Tom to BCC, support alias on CC]
> 
> Hi Douglas,
> 
> Are you able to provide a network trace showing the behavior in question? What are the Server and Client OS versions? Does this repro in a Windows-to-Windows scenario?
> 
> Best regards,
> Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 We value your feedback.  My manager is Natesha Morrison (namorri), +1 (704) 430-4292
> 
> -----Original Message-----
> From: Tom Jebo <tomjebo at microsoft.com>
> Sent: Monday, June 7, 2021 8:43 AM
> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>; cifs-protocol <cifs-protocol at lists.samba.org>
> Subject: RE: [EXTERNAL] [MS-DNSP] sticky static dns updates - TrackingID#2106070040005009
> 
> [dochelp to bcc]
> 
> Hi Douglas,
> 
> 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.
> 
> Best regards,
> Tom Jebo
> Sr Escalation Engineer
> Microsoft Open Specifications
> 
> -----Original Message-----
> 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
> 
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sticky-dns-updates-filtered.pcapng
Type: application/x-pcapng
Size: 19764 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20210608/10542d91/sticky-dns-updates-filtered.bin>