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

Jeff McCashland jeffm at microsoft.com
Tue Jun 15 18:42:16 UTC 2021

Hi Douglas,

In my email this morning for the StartScavenging case, I mentioned the article:
How DNS Aging and Scavenging Works

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

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: 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: 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?


More information about the cifs-protocol mailing list