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

Thu Jun 17 22:26:00 UTC 2021

Hi Douglas,

I've been reviewing the documentation and source code where we perform operations on the dnsNode. I realize now that scavenging/aging is specific to the resource records, while Tombstoning happens to the dnsNode when connected to AD server. From our source code, it appears the only way we track if a record is static is with the 0 timestamp. I've yet to find any static tracking on the dnsNode itself.

Can you tell me more about what you're working on and the context of this question? How are you applying the information, and what is the bigger problem you're trying to solve? 

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: Douglas Bagnall <douglas.bagnall at catalyst.net.nz> 
Sent: Tuesday, June 15, 2021 2:22 PM
To: Jeff McCashland <jeffm at microsoft.com>; Andrew Bartlett <abartlet at samba.org>; cifs-protocol <cifs-protocol at lists.samba.org>
Cc: Jeff McCashland <jeffm at microsoftsupport.com>
Subject: Re: [cifs-protocol] [EXTERNAL] [MS-DNSP] sticky static dns updates - TrackingID#2106070040005009

hi Jeff,

>> I want to make sure I understand the question you're asking. I gather that once a DNS Server 'notices' a static record has been added to a DnsNode, new records added to that node (by DNS Update) will automatically be static, even if all of the static records have been removed from the DnsNode. So the question is, how is that property of the DnsNode indicated, and is it replicated?
>> 
>> Have I got this correct?

Yes, that is the question.

Douglas

On 16/06/21 6:42 am, Jeff McCashland wrote:
> Hi Douglas,
> 
> In my email this morning for the StartScavenging case, I mentioned the article:
> How DNS Aging and Scavenging Works
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoci
> al.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F21724.how-dns-
> aging-and-scavenging-works.aspx&data=04%7C01%7Cjeffm%40microsoft.c
> om%7C304bea71a23e4296d41708d93043a32e%7C72f988bf86f141af91ab2d7cd011db
> 47%7C1%7C0%7C637593889343557255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> Lp48h1x1eNu%2Bii5s3ShCQjJDZnvXLk2grL2DqUfF2PM%3D&reserved=0
> 
> This article has a link to a related article:
> How to Convert a Dynamic Resource Record to a Static One Without 
> Re-Creating it in DNS
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoci
> al.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F21726.how-to-c
> onvert-a-dynamic-resource-record-to-a-static-one-without-re-creating-i
> t-in-dns.aspx&data=04%7C01%7Cjeffm%40microsoft.com%7C304bea71a23e4
> 296d41708d93043a32e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63759
> 3889343557255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N8jbs8oXjGYRvCAmZR
> rIyU1iF958%2FJ6D94RP%2BwHBEZI%3D&reserved=0
> 
> Which mentions:
> "In AD-integrated zones, the change will be replicated to other DC / DNS servers and the resource record will be excluded from aging and scavenging mechanism."
> 
> This suggests the stickiness of static records is replicated to other DNS servers.
> 
> I want to make sure I understand the question you're asking. I gather that once a DNS Server 'notices' a static record has been added to a DnsNode, new records added to that node (by DNS Update) will automatically be static, even if all of the static records have been removed from the DnsNode. So the question is, how is that property of the DnsNode indicated, and is it replicated?
> 
> Have I got this correct?
> 
> 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: 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&data=04%7C01%7Cjeffm%40microsoft.
> com%7C304bea71a23e4296d41708d93043a32e%7C72f988bf86f141af91ab2d7cd011d
> b47%7C1%7C0%7C637593889343567227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata
> =y3XaKEoUE%2BYTiS9yLaykm7UNECMc1bJLpZ5ihuuiuCY%3D&reserved=0 | 
> Extension 1138300 We value your feedback.  My manager is Natesha 
> Morrison (namorri), +1 (704) 430-4292
> 
> -----Original Message-----
> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> Sent: Thursday, June 10, 2021 3:18 PM
> To: Jeff McCashland <jeffm at microsoft.com>; Andrew Bartlett 
> <abartlet at samba.org>; cifs-protocol <cifs-protocol at lists.samba.org>
> Cc: Jeff McCashland <jeffm at microsoftsupport.com>
> Subject: Re: [cifs-protocol] [EXTERNAL] [MS-DNSP] sticky static dns 
> updates - TrackingID#2106070040005009
> 
> On 11/06/21 6:08 am, Jeff McCashland wrote:
>> Hi Douglas,
>>
>> I added the Keytab file on the Wireshark Preferences page under Protocols -> KRB5, and checked 'Try to decrypt Kerberos blobs', then reloaded the trace.
>>
>> The LDAP frames still aren't decrypted. Did I miss a step?
> 
> Maybe or maybe not.
> 
> For me, using '✅ Try to decrypt Kerberos blobs' and
> 
>    wireshark -K windows.keytab sticky-dns-updates-filtered.pcapng
> 
> there is a little tab at the bottom of the screen called "Decrypted data (NNN bytes)", and when I click on that tab I see data that is definitely decrypted, but also definitely not parsed, like this:
> 
>> 0000   30 81 be 02 01 08 63 81 b8 04 5d 44 43 3d 74 65   0.....c...]DC=te
>> 0010   73 74 5f 75 70 64 61 74 65 5f 73 74 61 74 69 63   st_update_static
>> 0020   5f 73 74 69 63 6b 69 6e 65 73 73 2c 43 4e 3d 4d   _stickiness,CN=M
>> 0030   69 63 72 6f 73 6f 66 74 44 4e 53 2c 44 43 3d 44   icrosoftDNS,DC=D
>> 0040   6f 6d 61 69 6e 44 4e 53 5a 6f 6e 65 73 2c 44 43   omainDNSZones,DC
>> 0050   3d 73 61 6d 62 61 2c 44 43 3d 65 78 61 6d 70 6c   =samba,DC=exampl
> 
> So I think it is the right keytab and Wireshark is using it correctly, but is refusing to do anything useful thereafter. Which is quite annoying.
> 
> Maybe someone else on the cifs-protocol list knows how to get past this point?
> 
> Douglas
> 