Need help with MS DNS Caching of stub zone records

[wchull]

I'm wondering if it advisible to use use a stub zone in this situation and could use some advice. Today we have a secondary DNS zone defined on our production DNS DC that is contains host/alias record for a very active test DNS domain. Currently when we add/delete/change a record in the test zone we apply the change and though a VBScript we initiate a forced zone transfer to occur immediately so the secondary zones contain the update. All is currently working well but we thought that instead of a secondary zone we would try using a stub zone so we setup a bogus test zone to confirm that things were working like we wanted and found an issue that I need advice on.

I should have explained that this the DC only contains internal (non-public) zones however we DO forward external queries from this server to the internet and we DO have the server setup to cache the entries that it resolves from zones that the DC does not host.

In testing the change from a secondary zone to a stub zone we noted that if a name resolution took place involving the stub zone, that entry was placed in the servers cache. The problem arises when you need to change the IP address and now the record in the primary zone is different than the record in the cache on the production DC. Since the server goes to the cache before querying the stub zone, a subsequent query always results in the wrong resolution unless you flush the record out of the cache.

What I'm looking for is some options or solutions to this cache problem. What I was looking for was a way to set the TTL for all records in the zone down to a short TTL but I have not been able to find a way to do that except on a record-by-record basis. I have tried to find some means of deleting a single record from the cache through a script or command line program and so far I've come up short. Any help would be appreciated.

 

[ITPangaeaArchitect]

The problem arises when you need to change the IP address and now the record in the primary zone is different than the record in the cache on the production DC.
Q: When you say "when you need to change the IP address", are you speaking of changing the name server IP that the stub zone targets, or a resource system IP (such as web server)?
All that should be in the stub zone is the SOA, NS, and A records for the DNS servers hosting the real zone.

What I'm looking for is some options or solutions to this cache problem.
Somwhat a smarta** answer here, but, you could always clear the dns server cache via dns management console

exactly what records are you wanting to lower the TTL on? All records, or just the NS and A records for the stub zone?

-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+
Manager - Global AD Operations
ACS, Inc.

 

[wchull]

In regard to your questions.....

I was referring to a simple IP address change for the device such as ServerA switching from 10.172.182.6 to 10.172.181.35 in a VLAN environment.

What we have found so far is that we can set the TTL down on the zone itself for new records but for existing records would also have to be changed or re-created.

Yes, you are correct that I can manually, thru the MMC, remove a single record from Cache or simply flush out all of the Cache but flushing out all the cache removes thousands of cached, external entries as this DC is set to forward externally if DNS does not manage the zone. Seems to us that flushing the cache all the time defeates the purpose of the Cache so we we were looking for some means of deleting individual cached records through a command line or VB Code. So far we've come up empty handed.

Sadly another problem that we discovered is that an AD integrated zone can and will use the entries from any DC that provides an answer not necessarily the one that is closest. In my test I shorten up the TTL so the record would disappear from cache within a minute but when I pinged the device again it re-cached the old IP address because replcation had not yet occurred on a DC in Minnesota even though the zone where the change was made exists in Illinos and that is where the query was initiated from. Basically, what we've been told by others on other forums is not to use Stub zones except on rare circumstances.

 

[ITPangaeaArchitect]

Stub zones should be viewed as fancy forwarders. Thats why they contain the same basic info...who is the name server, and no other records. Stub zones can be useful for trusts with fast connections and things like that.
I'm not against them, but forwarders are much easier

As far as the caching goes...remember its kind of two fold...if the DNS client service on the workstation still has the last valid response cached, it will use that, and the DNS server cache won't matter.


Sadly another problem that we discovered is that an AD integrated zone can and will use the entries from any DC that provides an answer not necessarily the one that is closest.
A: This was someones brilliant idea in house at MS back in the day to make the DNS lookup algorithm a random alphabetical algorithm (I know right...). Any DC who answers is authoritative for the zone, so requests will not go beyond that DC.


In my test I shorten up the TTL so the record would disappear from cache within a minute but when I pinged the device again it re-cached the old IP address because replcation had not yet occurred on a DC in Minnesota even though the zone where the change was made exists in Illinos and that is where the query was initiated from.
A: Where did you ping from? The same system? After the DNS server cache cleared, and before re-pinging again, did you do an ipconfig /flushdns & ipconfig /registerdns (or cycle the dns client service) on the system where you were pinging from? If no, what you saw may be expected since the local dns client service still has the last response cached, depending on factors like node type, etc.


-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+
Manager - Global AD Operations
ACS, Inc.