DNS Tombstoning dstombstoneinterval

Hi,

After investigating why a name kept re-registering in the incorrect case
(SAP App)... I discovered this feature...

I now know my DNS uses the default period of 7 days (604800 seconds) via
using dnscmd...

However I am wondering why Microsoft documentation states you can only set
this to a different value via dnscmd but only between 1-30 seconds???!!

"UselessUser" <> wrote in message
newsC717A18-32DA-4C1D-9F87-...
> Hi,
>
> After investigating why a name kept re-registering in the incorrect case
> (SAP App)... I discovered this feature...
>
> I now know my DNS uses the default period of 7 days (604800 seconds) via
> using dnscmd...
>
> However I am wondering why Microsoft documentation states you can only set
> this to a different value via dnscmd but only between 1-30 seconds???!!


You can change the values in whole days in the GUI. But why would you want
to finite it down to seconds?

Can you post a link to the documentation you're quoting, please?

Thank you.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum to benefit from collaboration
among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

http://twitter.com/acefekay

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

I believe it refers to this:

http://technet.microsoft.com/en-us/l...16(WS.10).aspx

I have no idea at all why it says [1-30] there. The command takes input
in seconds and doesn't seem to have a problem with you entering a value
outside of that range.

For instance, it will let you set a value matching the default with:

dnscmd /config /dstombstoneinterval 604800

All that does is add a registry value to this key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\DNS\Parameters

A REG_DWORD with the same name as the parameter.

Note that the [1-30] doesn't refer to days either. It will let you put a
value of 31 days (in seconds that's 2678400) without complaint.

Chris


Ace Fekay [MCT] wrote:
> "UselessUser" <> wrote in message
> newsC717A18-32DA-4C1D-9F87-...
>> Hi,
>>
>> After investigating why a name kept re-registering in the incorrect case
>> (SAP App)... I discovered this feature...
>>
>> I now know my DNS uses the default period of 7 days (604800 seconds) via
>> using dnscmd...
>>
>> However I am wondering why Microsoft documentation states you can only
>> set
>> this to a different value via dnscmd but only between 1-30 seconds???!!
>
>
> You can change the values in whole days in the GUI. But why would you
> want to finite it down to seconds?
>
> Can you post a link to the documentation you're quoting, please?
>
> Thank you.
>

Hi,

yes that is the link I am referring to...

Ace you mention that these settings are exposed in the GUI?? Where are they?

"Chris Dent" wrote:

>
> I believe it refers to this:
>
> http://technet.microsoft.com/en-us/l...16(WS.10).aspx
>
> I have no idea at all why it says [1-30] there. The command takes input
> in seconds and doesn't seem to have a problem with you entering a value
> outside of that range.
>
> For instance, it will let you set a value matching the default with:
>
> dnscmd /config /dstombstoneinterval 604800
>
> All that does is add a registry value to this key:
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\DNS\Parameters
>
> A REG_DWORD with the same name as the parameter.
>
> Note that the [1-30] doesn't refer to days either. It will let you put a
> value of 31 days (in seconds that's 2678400) without complaint.
>
> Chris
>
>
> Ace Fekay [MCT] wrote:
> > "UselessUser" <> wrote in message
> > newsC717A18-32DA-4C1D-9F87-...
> >> Hi,
> >>
> >> After investigating why a name kept re-registering in the incorrect case
> >> (SAP App)... I discovered this feature...
> >>
> >> I now know my DNS uses the default period of 7 days (604800 seconds) via
> >> using dnscmd...
> >>
> >> However I am wondering why Microsoft documentation states you can only
> >> set
> >> this to a different value via dnscmd but only between 1-30 seconds???!!
> >
> >
> > You can change the values in whole days in the GUI. But why would you
> > want to finite it down to seconds?
> >
> > Can you post a link to the documentation you're quoting, please?
> >
> > Thank you.
> >
>

"UselessUser" <> wrote in message
news:20562EC7-99C5-4AAA-A054-...
> Hi,
>
> yes that is the link I am referring to...
>
> Ace you mention that these settings are exposed in the GUI?? Where are
> they?

Sorry, I meant the Scavenging time, not the dstombstoneinterval. My
apologies.

Ace

"Chris Dent" <> wrote in message
news:%...
>
> I believe it refers to this:
>
> http://technet.microsoft.com/en-us/l...16(WS.10).aspx
>
> I have no idea at all why it says [1-30] there. The command takes input in
> seconds and doesn't seem to have a problem with you entering a value
> outside of that range.
>
> For instance, it will let you set a value matching the default with:
>
> dnscmd /config /dstombstoneinterval 604800
>
> All that does is add a registry value to this key:
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\DNS\Parameters
>
> A REG_DWORD with the same name as the parameter.
>
> Note that the [1-30] doesn't refer to days either. It will let you put a
> value of 31 days (in seconds that's 2678400) without complaint.
>
> Chris

And that's interesting it lets you do it down to the second, but the
tombstone time, if I recall a thread a few weeks ago regarding the tombstone
time, is only in whole days.

Ace

Perhaps tombstone cleanup only happens once a day? It would make
anything but whole days moot (with rounding applied for everything but).

Now I'm going to have to try and find the documentation (if there is
any) on that process

Chris

It looks like the once a day theory is correct, although I can find
little official documentation on that, just a snippet that suggests such
a (unnamed) process runs at a non-configurable 2am every day (presumably
UTC).

So the value could be set to 9 days, 6 hours and 23 seconds, but it will
still only cleanup the next time the process runes, at 10 days.

Chris

"Chris Dent" <> wrote in message
news:...
>
> It looks like the once a day theory is correct, although I can find little
> official documentation on that, just a snippet that suggests such a
> (unnamed) process runs at a non-configurable 2am every day (presumably
> UTC).
>
> So the value could be set to 9 days, 6 hours and 23 seconds, but it will
> still only cleanup the next time the process runes, at 10 days.
>
> Chris


I believe it has something to do with the way AD stores the data, because if
the zone's AD integrated, it is in the AD database. Here's an excerpt of a
private email I was working with Meinolf to help someone else that had a
question about the way timestamps work in AD.

===
I found the following article talking about DNS timestamps
(http://blogs.techrepublic.com.com/networking/?p=618), but it shows the same
thing with a Windows 2008 DNS console. I think it rounds up to the next
hour.

I found the following link, too, that explains it only displays it in hours.
It kind of confirms my hunch that’s it’s done to save memory or processing
additional data that is not needed. It shows that it only displays it in
even hours. But it doesn’t exactly explain why. I found other links that
indicate this timestamp value in even hours is also used by BIND/Unix. I
believe from reading some links, it’s used to save memory. The article below
also states the time stamp is stored as “Little Endian,” (also known as
“Little End In”) which means it uses the least significant portion of the
byte field, to save memory, so the additional info concerning minutes and
seconds are not stored. However based on Bruce’s post, AD does store the
data, as he found using ADSI Edit. So I’m assuming using the Little Endian
method, it is only pulling the hour bits or portion of the byte, and not the
whole byte that the time is stored in.

Mapping the DNSRecord attribute
http://www.highorbit.co.uk/?p=1097

Here’s a better explanation of Little and Big Endian:
http://searchnetworking.techtarget.c...11659,00.html#
===

And more on Little Endian and Big Endian:
===
Little/Big Endian has nothing to do with precision, accuracy or data size,
but rather the ordering of binary values in memory. IBM mainframes (and
some other architectures) store the most significant byte of a binary value
in the memory byte with the lowest address. Other architectures (notably
the Intel one used in x86 computers) store the least significant byte in the
lowest memory address.

All Internet related protocols specify the byte ordering of binary values
the same way – big endian – otherwise interoperability between different
computer architectures would be impossible. Computers that natively use
little endian binary values have to re-order the bytes for transmission over
the network using IP protocols.

http://en.wikipedia.org/wiki/Byte_order has a good explanation of this along
with some history.
===

Ace

Hmm lost my first version of this. If it turns up there will be a bit of
duplication here.

"Mapping the DNSRecord Attribute" is my article, that would be my blog
Eventually I'll finish mapping dnsProperty and post that one too.

This stands aside from the operation of DsTombstoneInterval. When a DNS
record is tombstoned the majority of data in the dnsRecord attribute is
stripped. The TimeStamp field is set to 0, the record class portion is
removed, etc.

Therefore the tombstone process must key off something else (hopefully
something that will become apparent as I continue to dig into the DNS
service). That unknown process has to be resident in the DNS service
otherwise the DsTombstoneInterval is misplaced and illogical.

The structure of DNSRecord, as far as I could determine, is in that
article. It includes a note of the 4 byte little endian field for TimeStamp.

The TimeStamp value is represented as the number of hours since
01/01/1601 00:00:00 (the beginning of the MS Epoch).

For example, you might take the 4 byte field from the dnsRecord
attribute and write them in Decimal form like this:

15 166 54 0

The field is a little endian, so if we're converting the value we must
treat it as if it were this:

0 54 166 15

The simplest way to convert that value up is (probably) this:

(0 * 256^3) + (54 * 256^2) + (166 * 256^1) + (15 * 256^0)

As you can see, the first byte, 0, is irrelevant. It's included to make
the conversion complete with the assumption it's there just in case we
ever get that far into the future. The last byte is 15 because 256^0 is
1, law of exponents and all that.

That gives you a value of 3581455.

Finally add that number of hours to the MS epoch giving that date 28
July 2009 07:00:00, the TimeStamp of the dnsRecord for one of my Domain
Controllers (UTC, not adjusted for a time zone).

As for why that's hours, we can theorise that it's to save space. If
they'd used an accurate date in Integer8 format 8 bytes would have been
needed instead of 4 (see attributes like lastLogon). That change
wouldn't give much to the DNS service really.

It's conjecture though, all we can really say is that it's whole hours
because MS made it that way.

Chris