DNS Tombstoning dstombstoneinterval

Discussion in 'DNS Server' started by UselessUser, Jul 26, 2009.

  1. UselessUser

    UselessUser Guest

    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, Jul 26, 2009
    #1
    1. Advertisements


  2. 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.
     
    Ace Fekay [MCT], Jul 26, 2009
    #2
    1. Advertisements

  3. UselessUser

    Chris Dent Guest

    I believe it refers to this:

    http://technet.microsoft.com/en-us/library/cc756116(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\Services\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
     
    Chris Dent, Jul 27, 2009
    #3
  4. UselessUser

    UselessUser Guest

    Hi,

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

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

     
    UselessUser, Jul 27, 2009
    #4
  5. Sorry, I meant the Scavenging time, not the dstombstoneinterval. My
    apologies.

    Ace
     
    Ace Fekay [MCT], Jul 27, 2009
    #5
  6. 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
     
    Ace Fekay [MCT], Jul 27, 2009
    #6
  7. UselessUser

    Chris Dent Guest

    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
     
    Chris Dent, Jul 27, 2009
    #7
  8. UselessUser

    Chris Dent Guest

    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, Jul 27, 2009
    #8

  9. 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.com/sDefinition/0,,sid7_gci211659,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
     
    Ace Fekay [MCT], Jul 28, 2009
    #9
  10. UselessUser

    Chris Dent Guest

    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
     
    Chris Dent, Jul 28, 2009
    #10

  11. Chris,

    Ididn't realize that was you who've wrote that article. Nice article.

    I agree that it must be to save space, hence using Little Endian for the
    timestamp value. I would assume and imagine that Big Endian would be used if
    it were finited down to the second, but I think from reading your blog, and
    the other links, that it's ignored or they don't really care to go down to
    that much detail for such an attribute, nothing like the lastLogon, which is
    more important to keep track of.

    Looking forward to your update!

    Ace
     
    Ace Fekay [MCT], Jul 28, 2009
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.