none
DNS timestamp replication (again), and Scavenge vs Enable Automatic scavenging

    Question

  • i've read all the posts on "dns record timestamp replication" i can find on this forum, and i'm still concerned about enabling scavenging on a multi-server dns infrastructure, after it's been off forever.

    if i have 3 dns servers, and different clients update their dns on different dns servers, the "last refresh" timestamp can be different depending on which dns server i look at. i would think that verifying timestamp replication would be at the top of any pre-enabling-scavenging to-do list.

    but it can't be, because *timestamps don't replicate unless scavenging is already turned on.*

    so i assumed the solution would be to turn on scavenging on only one dns server, which would enable other dns servers to replicate their current timestamps *to* it, but i don't see the timestamps changing on server2 where i enabled scavenging. i know dns is replicating OK because if i create a new record on server1 it appears on server2. but existing timestamps on server2 are not updating to the newer timestamps of server1, even after i enabled scavenging on server2.

    if those timestamps don't change on server2, they are going to get scavenged, and then deleted from server1 even if the timestamp on server1 is 5 minutes before the scavenging starts. right?

    second issue:

    in the 2008 r2 dns console, i right click the server name, "set aging/scavenging for all zones," check the box that says "scavenge stale resource records."

    and/or

    in the 2008 r2 dns console, i right click the server name, choose properties, advanced tab, and check the box that says "enable automatic scavenging of stale records."

    what is the difference between these two?
    do i need both boxes checked before anything will actually get scavenged?
    how do they work together?
    what does only checking the first one do?
    what does only checking the second one do?


    • Edited by John_Curtiss Saturday, March 10, 2012 3:49 PM typo in title
    Saturday, March 10, 2012 12:48 AM

All replies

  • Hi,

    please check below link this will be helpful.

    http://social.technet.microsoft.com/Forums/eu/winserverDS/thread/b5bf16da-a205-42a2-99b3-6de8c7499e4b

    http://tst.social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/66e9e96e-3134-451c-855b-29a8f1ca497e

     http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Hope this helps


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

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

    Saturday, March 10, 2012 12:55 AM
  • John,

    To summarize, yes, with using AD integrated zones, you just enable scavenging on one server, then the time stamp will replicate through the normal AD replication process.

    To force timestamps on existing records, you can run dnscmd /ageallrecords, however, the only caveat is that it will also timestamp any static entries, making them eligible for scavenging. If you want to run this command and you have many static records, assuming you already have an inventory of all static records, run that command, then go into each record and change something on it, such as the last number of the IP, then change it back so it remains. Now if you have many records, then I would suggest to use dnscmd to reset the records.

    .

    As far as not seeing the time stamps getting enabled, you honestly need to be patient. That's the whole thing with this. I attempted to create some screenshots for you in response to this, but I can't get it to show the timestamp on the record until after the scavenging period passes. For example, if I selected 7 days No Refresh, and 7 Days Refresh, the zone will available to scavenge 15 days from now (1 day after the No Refresh and Refresh). So this is something you just have to wait for!

    .

    If you set it at the server to set again/scavenging for all zones, it will do all zones for you. If you want it on a specific zone, you don't do it at the server level, rather on the individual zone. You don't need to set it both. You can set it at the server level, but everyone I talk to, even me, set it everywhere because... you ready for this... I'm not patient! :-)

    .

    Read more on this in my blog, as well as the other two, which gets into specifics with static entries at the AD attribute level - dnsTombstoned - so you can see how this works with AD replication.

    .

    DHCP Service Configuration, Dynamic DNS Updates, Scavenging, Static Entries, Timestamps, DnsUpdateProxy Group, DHCP Credentials, prevent duplicate DNS records, DHCP has a "pen" icon, and more...
    http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx  

    .

    Good article explaining how AD handles scavenging with records in an AD integrated zone, as well as what happens if say a machine who's record is marked as dnsTombstoned, but the machine is reinstalled, which now has a new SID, and how it can't update the original record -  the original host record is not removed immediately:
    DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones, by Guy Teverovsky, 23 Sep 2010
    http://blogs.technet.com/b/isrpfeplat/archive/2010/09/23/dns-scavenging-internals-or-what-is-the-dnstombstoned-attribute-for-ad-integrated-zones-dstombstoneinterval-dnstombstoned.aspx

    .

    Don't be afraid of DNS Scavenging. Just be patient.
    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    .

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Saturday, March 10, 2012 6:20 AM
  • in the 2008 r2 dns console, i right click the server name, "set aging/scavenging for all zones," check the box that says "scavenge stale resource records."

    and/or

    You can have multiple zone in the DNS apart from the one for your domain like if you have multiple domain or configured name resolution for the partner domain, then if you select this option aging/scavenging will be applied to all the zones present in the DNS.

    in the 2008 r2 dns console, i right click the server name, choose properties, advanced tab, and check the box that says "enable automatic scavenging of stale records."

    This option can be configured when you want to enable aging/scavenging at the particular zone not on all the zones.

    what is the difference between these two?
    do i need both boxes checked before anything will actually get scavenged?
    how do they work together?
    what does only checking the first one do?
    what does only checking the second one do?

    I guess below reference will help you to understand in depth as it contains good explanation and relevant details and links.

    http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx

    http://awinish.wordpress.com/2011/02/08/dns-scavenging-auditing-concepts/

    Yes, instead of enabling scavenging at multiple server, it should be enabled on the one server.


    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Saturday, March 10, 2012 8:24 AM
    Moderator
  • thanks for the feedback, guys. i had already read most of those articles before i posted. but i still feel like i'm not getting my exact questions answered.

    ace, i don't really want to "force timestamp on all existing records." what i want is for the timestamp for recordX on dnsserver1, which is 3/9/2012, to replicate to dnsserver2, which has a timestamp for recordX from 2007. where do i need to enable scavenging to make this happen?

    Awnish, i'm not asking for the difference between "set scavenging" at the server level and "set scavenging" at the zone level. i think i understand that one. i'm asking for the difference between two separate *server level* settings in two separate locations.

     if i right-click the *Server object*, the context menu has a "set aging/scavenging for all zones," option and a "properties" option.

    Click here to view full size

    when i choose "set aging/scavenging" from that screenshot, i get another popup with a checkbox that says "scavenge stale resource records."

    Click here to view full size

    when i choose "properties," from the first screenshot above, the Advanced tab has a checkbox for "enable automatic scavenging of stale records."

    Click here to view full size

    what is the difference between the highlighted checkboxes in the last two screenshots?
    do i need to check both before anything will get scavenged?
    what does only checking the first one do?
    what does only checking the second one do?

    Saturday, March 10, 2012 3:46 PM
  • what is the difference between the highlighted checkboxes in the last two screenshots?
    do i need to check both before anything will get scavenged?
    what does only checking the first one do?
    what does only checking the second one do?

    Hi,

    Scavenging is set in three places on a Windows Server:

    • On the individual resource record to be scavenged.
    • On a zone to be scavenged.
    • At one or more servers performing scavenging.

    Hence first screenshot for Scavenging Settings at the Zone and second for Scavenging settings on the Server.

    For more detail, read the below article:
    Don't be afraid of DNS Scavenging. Just be patient: http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx


    Best Regards,

    Abhijit Waikar.
    MCSA 2003 | MCSA:Messaging | MCTS | MCITP:Server Administrator | Microsoft Community Contributor | My Blog

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

    Saturday, March 10, 2012 4:07 PM
  • ok. for one thing, i was confused by the fact that when i checked the "scavenge stale resource records" box in the "Set aging/scavenging for all zones" at the server level, the samne "scavenge stale resource records" box on each zone remained unchecked. **until i refreshed the view.** so i was interpreting this as a server level setting when it's actually just a zone level setting applied across all zones.

    so i now have "scavenge stale resource records" checked on all my zones on a single dns server. should timestamps from my other dns servers be replicating to this server? they aren't.

    do i have to actually check the "enable automatic scavenging" box on the server advanced properties to get timestamp replication to occur? ok, done. when i force an ad replication from this server, should i see the timestamps updating? i don't.


    Saturday, March 10, 2012 4:51 PM
  • You mean this?

    .

    .

    As Awinish said, you really have to read that article by Josh Jones [MSFT] - "Don't be afraid of DNS Scavenging," where he explains it.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Saturday, March 10, 2012 4:52 PM
  • ok. for one thing, i was confused by the fact that when i checked the "scavenge stale resource records" box in the "Set aging/scavenging for all zones" at the server level, the samne "scavenge stale resource records" box on each zone remained unchecked. **until i refreshed the view.** so i was interpreting this as a server level setting when it's actually just a zone level setting applied across all zones.

    - Yes, the DNS console is not that smart. Sometimes a close and re-open does the trick.

    .

    so i now have "scavenge stale resource records" checked on all my zones on a single dns server. should timestamps from my other dns servers be replicating to this server? they aren't.

    .

    - It takes time. You have to first allow it to stamp it, which will take your NoRefrseh + Refresh + 1 day. So if you set it for 4 days, that will be 9 days before you see it. Then it will take 9 more days for it to actually remove it. I have specifics in my blog on that with a chart showing the timeline. It applies to this, too.

    .

    do i have to actually check the "enable automatic scavenging" box on the server advanced properties to get timestamp replication to occur? when i force an ad replication from this server, should i see the timestamps updating?

    - Yes, I would. In my opinion, that basically "turns it on" on the server, or kicks it off, so to speak.

    .



    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Saturday, March 10, 2012 4:57 PM
  • "- It takes time. You have to first allow it to stamp it, which will take your NoRefrseh + Refresh + 1 day. So if you set it for 4 days, that will be 9 days before you see it. Then it will take 9 more days for it to actually remove it. I have specifics in my blog on that with a chart showing the timeline. It applies to this, too.- "

    so i think what i'm hearing is that, at the moment i enable scavenging on server2, if server1 has a timestamp for clientX of 3 days ago and server2 has a timestamp for clientX of 3 years ago, the timestamp on server1 will not get replicated to server2. the next time clientX refreshes its timestamp on server1, it will get replicated to server2. right?

    i'm not patient either:)

    so clientx reports only to server1, not to server2. i deleted clientX's record on server1, ipconfig /registerdns on clientX, server1 gets a new timestamp for clientX of right now.

    "scavenge stale resource records" is enabled on that zone on server2, and "enable automatic scavenging" is enabled on server2, and the new timestamp of clientX on server1 is still not getting replicated to server2.

    are saying i still have to wait the "refresh interval" before the timestamp will get replicated to server2? the verbiage of "refresh interval" sounds like the record gets scavenged after the refresh interval.

    so no-refresh interval is 7 days, it means no matter how many times clientx tries to update itself in those 7 days, server1 won't let it update until the interval expires.

    the wording of "refresh interval":

    the time between the earliest moment when a record timestamp can be refreshed
    (which i interpret to mean the end of the no-refresh period)

    and the earliest moment when the record can be scavenged
    (which i interpret to mean when the record becomes eligible for deletion during the next scavenging operation)

    so if refresh interval is 7 days, then 7 days after the no-refresh interval ends, clientx's record will be deleted by the next scavenge on server2. is that not correct? either way, i don't see the word "replication" in either interval's description, so i'm still confused how either interval affects replication of timestamps from server1 to server2. 

    Saturday, March 10, 2012 5:34 PM
  • Yes to all the above! Re-read my blog. I just updated it with some of this stuff about the refresh, how long it takes, etc.

    I have to head out for a podcast spot I was invited to. No, not about technical stuff, rather a 'what's up with the NFL and a Philly Eagles chat" with a local podcast. :-) I'll check back later.

    .

    And - BE PATIENT!!!!!!!


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Saturday, March 10, 2012 5:39 PM
  • Hi John,

    Thanks for posting here.

    Not sure if we have aware of this part which is quoted form blog post “Don't be afraid of DNS Scavenging. Just be patient”:

    “Once a timestamp is set on a record it will replicate around to all servers that host the zone.  There is one caveat to this.  If scavenging is not enabled on the zone that hosts the record then it will never scavenge so the timestamp is essentially irrelevant.  The timestamp may get updated on the server where the client dynamically registers but it will not replicate around to the other servers in the zone.”

    And I believe this is also the reason that we suggest to enable “DNS Scavenging” on one DNS server but not all .

    Don't be afraid of DNS Scavenging. Just be patient:
    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    Regards,

    Tiger Li

    TechNet Subscriber Support in forum
    If you have any feedback on our support, please contact  tnmff@microsoft.com.


    Tiger Li

    TechNet Community Support

    Monday, March 12, 2012 3:27 AM
  • ace, still confused as to how refresh/norefresh intervals affect *replication." and how a 7 day refresh and a 7 day no refresh is preventing a 3-year-old timestamp on server2 (where scavenging is enabled) from being updated by a 1-hour-old timestamp from server1 (where scavenging is not enabled).

    Tiger, as stated several times above, i have scavenging enabled on one server, and that server is still not getting updated timestamps replicated to it.

    Monday, March 12, 2012 3:39 AM
  • ace, still confused as to how refresh/norefresh intervals affect *replication." and how a 7 day refresh and a 7 day no refresh is preventing a 3-year-old timestamp on server2 (where scavenging is enabled) from being updated by a 1-hour-old timestamp from server1 (where scavenging is not enabled).

    Tiger, as stated several times above, i have scavenging enabled on one server, and that server is still not getting updated timestamps replicated to it.

    If there is an older record in the zone, then DHCP, assuming we're talking about a DHCP Dynamic Update, may not be able to update it due to ownership on the record. If DHCP is not the owner, it won't be able to update or replicate the changes to the record, since whatever created the record, owns the record, and it may be a different owner.

    One way around this is to simply delete the record, and either run an ipconfig /registerdns, or release/renew the IP on a DHCP client.

    You can also force all records to age by running the dnscmd /AgeAllRecords command. If you're seeing different ownership on each DNS server for records, then I would run this on that server, too.

    I've found it easier to simply delete the record. Since it's been there for 3 years, then it's something we can just consider a little housekeeping to "clean" it up and move forward with your newly configured, scavenged set, zones.

    I hope that makes sense and helped out.

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Monday, March 12, 2012 4:00 PM
  •  clientX is a server with a static IP address. but its dns entry is not static. its tcp/ip settings say "register this connection's addresses in dns." if i delete clientx's record from its primary dns server, server1, and do an ipconfig /registerdns on clientx, the record on server1 gets a timestamp of right now, all as expected. but clientx does not have dnsserver2 in its tcp/ip settings, so it will never register itself with dnsserver2 to update its timestamp. the only way dnsserver2 is ever going to get an updated timestamp for clientx is if it gets replicated from dnsserver1.

    so when should i expect to see this new timestamp on dnsserver1 replicated to dnsserver2, if dnssesrver2 currently has a 3-year-old timestamp for clientx, and has scavenging enabled?

    i don't want to age all records because i have plenty of static records i want to keep static. i also don't want to go delete all the old records by hand, replicate once, and forget about it, since so far i haven't seen anything to convince me that replication from dnsserver1 can/will overwrite an old timestamp on dnsserver2. i already know replication from dnsserver1 can create a "new" record on dnsserver2 if i delete it from dnsserver2

    in other words, i know if i delete clientx's 3-year-old record from dnsserver2 today, replicate from dnsserver1 to create a new timestamp on dnsserver2, everything will look just like we want: with a current timestamp for clientx on dnsserver2. but i still dont' trust that in 4 weeks, or 6 weeks or whenever, dnsserver2 won't still have clientx's timestamp from today, think it's old, and scavenge it.


    Monday, March 12, 2012 10:47 PM
  • If I understand what you're saying, that 3 year old record is still there. If you haven't run the /AgeAllRecords command, then let's manually delete that 3 year old record. Now test it.

    I know it will not overwrite it due to ownership, but it will eventually (should) get scavanged.

    Otherwise, if you need to get this cleaned up now, then sorry, you would have to either run that command, or delete them manually. I don't believe there is another way around it.

    You can probably use dnscmd to export your static records, run the command, and re-import them, but I haven't tested that yet, since I just delete them manually, and recreate any static records. For larger customers, I'll provide instructions for one of their junior admins to do this part. :-)

    What you're seeing is just one of the drawbacks of never setting this up in the beginning. It happens all the time.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBookTwitterLinkedIn


    Tuesday, March 13, 2012 12:25 AM
  • "scavenged" doesn't mean "deleted?" when it gets "deleted" on dnsserver2, won't that get replicated around and delete it from the other servers as well?

    in fact i'm also confused about how manually deleting a record from dnsserver2 won't simply replicate the deletion to dnsserver1 before dnsserver1 replicates its newer timestamp back to dnsserver2... again, the client is NOT registering with dnsserver2, only dnsserver1.

    as an example, i just deleted 2 fairly unimportant old records from dnsserver2 which had very recent timestamps on dnsserver1. after a few minutes, rather than updating the timestamps on dnsserver2, the records disappeared from dnsserver1. this is not good a good thing. am i supposed to wait for the client's OS to re-register with dnsserver1 sometime in the next 24 hours and replicate that timestamp to dnsserver2? or do i need to ipconfig /registerdns on every server whose ip i want to have replicated around....that doesn't scale very well in production....

    Tuesday, March 13, 2012 12:57 AM
  • If you delete a record in a specfic zone on one server, it will replicate the change (note - it's the "Change" that's replicated) in the zone to all DC that host a copy of that zone based in it's replication scope.

    Yes, scavenged means deleted.

    If you are seeing that you create a record, say as a test, and look at another DC, you should see it replicated over. You should also see the SOA change to the DC that you created the record on (note - this is default behavior - the SOA changes all day long). THen if you go to either one of those DCs, and you delete the record, then it will replicate to other DCs.

    That process is all based on AD replication and not DNS. Of cousre there are attributes that define DNS objects, but it's all based on AD.

    If a record gets scavenged (deleted) on one server in a specific zone, then that change will get replicated.

    If in your manual  testing you're not seeing this default behavior, then something is wrong with replication. And if this is the case, the troubleshooting side of it turns into AD troubleshooting and not DNS troubleshooting.

    I hope that makes sense so far?

    .

    As for that one specific record, if there is any corruption on the actual record object, that may stop it from replicating any changes. I've seen this happen with records that have been there for years. What causes it? No idea. Sometimes you can't even delete it in the GUI, and you have to use ADSI Edit to delete it.

    .

    Also, another caveat or something to look out for, is if there are duplicate AD integrated zones in the AD database, that will surely result in numerous problems because there will be multiple (duplicate) copies of the zone that different servers arelooking at and "thinking" that that is the real zone and the others are not. This is not a desired condition.

    .

    To see if there are dupes, you follow the procedure below. Matter of fact, if you don't mind, let's take a peek at the databases to see if there are any dupes just to rule this out as any possible concern.

    Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
    http://msmvps.com/blogs/acefekay/archive/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones.aspx 

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    • Proposed as answer by Tiger Li Tuesday, March 13, 2012 2:13 AM
    Tuesday, March 13, 2012 1:47 AM
  • if i add or remove a record from any of my dns servers, that change is replicated to my other dns servers.

    i have been testing this in a really small dmz AD. for grins, last night i changed the no-refresh period on the zone to six hours to see if i could speed up the replication process (we're impatient, yes?), and the refresh period to 14 days to be overly cautious on the scavenging side (as if i wasn't going to check it first thing today...). this morning *most* of the timestamps on all three of my dns servers had today's date. and i did an ipconfig /registerdns on the ones that were still old (about a month old) on two of my dns servers (they were only a couple of days old on the dns servers the clients actually registered with), and the updated timestamp did replicate around to the other machines. those two clients must have just not tried to re-register last night.

    this is without "enable automatic scavenging of stale records" enabled on any of my servers.

    relief.

    so the moral of the story here is one or both of these:

    a. no matter how ancient a timestamp might be on a dns server, i have to wait for one no-refresh period to expire from the moment i enable scavenging on the zone before an updated timestamp will get replicated from another dns server.

    b. any timestamp created prior to the moment i enable scavenging on the zone will not get replicated to other dns servers, even if was created only 5 minutes prior to that moment and the other servers have timestamps from the Clinton administration. the next time the client updates its timestamp, it will get replicated to all the dns servers.

    (off-topic: it's been a fun touch that when i sort the timestamp column it's not really sorting by date, just by the leftmost digits of the date. you weren't kidding when you said "the dns console is not that smart.")

    Tuesday, March 13, 2012 4:45 PM
  • The moral of the story, is be patient. To add, you may need to do a little housekeeping on the older records. :-)

    And don't you just love the DNS console? :-)

    Cheers!

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

    FaceBook Twitter LinkedIn

    Wednesday, March 14, 2012 2:33 AM