Setting up DNS Scavenging - date showing 01/01/1601 00:00:00 ? any ideas?

[ronnoco]

Hello,

 

I am following a Microsoft blog for setting up DNS scavenging as we have far too many old and in some cases multiple entries in our DNS records.

 

One of the first steps is to set the aging properties. This should show a date of 7 days ahead but ours shows 01/01/1601. Have tried applying anyway to see if it changes but it doesn't and with this date wrong, I can't see how we can configure.

 

Does anyone have any ideas or advice on scavenging and keeping DNS tidy?

 

Thanks very much in advance.

[timzim]

Thou must be using Ye Windowes 0.1. Verily, 'tis fulle of bugges!!

[Admiral208]

I think you have to set it at both server and zone levels.

[PiqueABoo]

That's what zero is in one of the date formats. IIRC that's what you get on all DNS records when you first turn on scavenging i.e. the exisiting records don't automatically have "created" timestamps in them on the off-chance you will use scavenging one day. As above you DO have to turn this on both at the server level and for each DNS zone, after which I'm pretty sure this does sort itself out (I'm a bit shaky on this because MS scavenging annoyed me so I rolled my own to factor in DHCP etc.).

[m25man]

Windows DNS normally looks after itself pretty well with the minimum of intervention as AD integrated clients can keep their own records in check through DHCP renewals.

 

Lots of Ghosting/WDS/Renaming can mess things up pretty quickly and once you start to get duplicate entries in your Forward/Reverse zones then all sorts of things start to fail.

 

Most dynamically created Hosts A records can be deleted manually just avoid deleting other records such as servers and external hosts (such as your website)

Delete any/all of the reverse zone records as these will be automatically recreated as the forward zone repopulates.

 

Set the server to scavenge automatically every 7 days and check it once a month (more often if you are doing a lot of new machine imaging).

[PiqueABoo]

Generally agree with that assuming it's secure updates, but the scavenging introduces a new problem, or at least it did (has been a while so perhaps this is smarter now?). It's with Laptops that flit from wired to wireless and thus end with say this DNS A RR:

 

LAP01 -> ;

 

AIUI because of the scavenging no-refresh interval the order those IPs are returned can get stuck for a while, so if you ping LAP01 you always get the Wireless IP back. This can be a right pain in practice for a variety of apps other than ping.

 

Without scavenging the IP you get back is whatever was last registered or refreshed e.g. plug in a cable and it's now the Wired IP which is generally much, much better. You can still get issues here if you're creative enough, but I rarely hit them.

 

What I did was knock up an app which runs overnight and basically clears from DNS anything in DHCP scope IP range that: a) Doesn't exist in DHCP, or b) Has the wrong (security) ownership, but in both case records are only zapped if the associated IP isn't responding right now. I reckon this is more complex than necessary, but I wanted to get my head around coding for the various technical corners - a simpler strategy might be to simply delete all DNS records referring to the DHCP scope IP range where the associated IP isn't responding.