DNS TTL and XP DNS cache questions

[Chris]

I'm confused with DNS TTL and the DNS cache on XP.

1. a A record SVR1 is set with TTL 4 hours. When XP resolved SVR1 it will
have it cached locally for 24 hours (by default)? What will happen if the 4
hours DNS TTL expired? Does the cached DNS record will be removed?

2. In the case mentioned above the real local cache will depend on TTL and
XP max cache TTL, whcihever the shortest one? Right?

3. If I chahged the DNS TTL from 4 hours to 20 min before it expires the XP
won't get updated TTL till next time it tried to resolve the name, right?
Then it will get the new TTL value.

4. Does DNS have its own cache? How to set the interval for its update? If
I set TTL short than the cache update interval does the cache keep the record
or remove it?

5. How to force DNS update manually?

I'm using Windows 2003 AD intergrated DNS.

Thanks.

[Herb Martin]

"Chris" <Chris@discussions.microsoft.com> wrote in message
news:FFCB384C-0F97-4976-83E3-EF0DE6FF7B83@microsoft.com...
> I'm confused with DNS TTL and the DNS cache on XP.
>
> 1. a A record SVR1 is set with TTL 4 hours. When XP resolved SVR1 it will
> have it cached locally for 24 hours (by default)? What will happen if the
> 4
> hours DNS TTL expired? Does the cached DNS record will be removed?

That is not correct. The TTL will be a MAXIMUM of 24 hours (by default)
OR the Actual TTL of the DNS Server resource record whichever is SMALLER.

If the TTL (on the record) is 2 days, then the TTL of the client will still
be
one day.

If the TTL (on the record) is 4 hours then this will be used.

> 2. In the case mentioned above the real local cache will depend on TTL and
> XP max cache TTL, whcihever the shortest one? Right?

This is correct. Whichever is shorter.

> 3. If I chahged the DNS TTL from 4 hours to 20 min before it expires the
> XP
> won't get updated TTL till next time it tried to resolve the name, right?
> Then it will get the new TTL value.

Correct again.

> 4. Does DNS have its own cache? How to set the interval for its update?
> If

Yes, if it is an "intermediate" DNS it will cache the record for (up to) the
TTL
time provided by the owner (master) of the zone/record where the record
originates.

> I set TTL short than the cache update interval does the cache keep the
> record
> or remove it?

The cache on THIS server has NOTHING to do with the records/zones on
THIS Server.

The cache on THIS server is only used for caching OTHER Servers' records.

> 5. How to force DNS update manually?

What does that mean? And if you wish to flush the caches you might well
explain "Why" you wish to do something that is practically never required.

> I'm using Windows 2003 AD intergrated DNS.

Clients (modern ones at least) cache records they get from DNS Servers.

DNS Servers cache records they get from OTHER DNS Servers which
hold OTHER Zones.

DNS Servers with zones have a TTL for each resource record or use the
DEFAULT TTL (from the SOA) for those records not explicitly set.

The OWNING DNS Server "tells" the requestor how long it is "ok" to
cache a record. The owning DNS server presumably knows how long
the record will be "stable" and so sets a sensible value.

About the only time you should see a problem is when MOVING IP
addresses (e.g., changing ISPs) -- when doing this you should/must
update your TTLs on your zone records at least ONE TTL AHEAD
of time to something smaller.

[mmccaws2]

On Apr 18, 12:06 pm, "Herb Martin" <n...@learnquick.com> wrote:
> "Chris" <Ch...@discussions.microsoft.com> wrote in message
>
> news:FFCB384C-0F97-4976-83E3-EF0DE6FF7B83@microsoft.com...
>
> > I'm confused with DNS TTL and the DNScacheonXP.
>
> > 1. a A record SVR1 is set with TTL 4 hours. WhenXPresolved SVR1 it will
> > have it cached locally for 24 hours (bydefault)? What will happen if the
> > 4
> > hours DNS TTL expired? Does the cached DNS record will be removed?
>
> That is not correct. The TTL will be a MAXIMUM of 24 hours (bydefault)
> OR the Actual TTL of the DNS Server resource record whichever is SMALLER.
>
> If the TTL (on the record) is 2 days, then the TTL of the client will still
> be
> one day.
>
> If the TTL (on the record) is 4 hours then this will be used.
>
> > 2. In the case mentioned above the real localcachewill depend on TTL and
> >XPmaxcacheTTL, whcihever the shortest one? Right?
>
> This is correct. Whichever is shorter.
>
> > 3. If I chahged the DNS TTL from 4 hours to 20 min before it expires the
> >XP
> > won't get updated TTL till next time it tried to resolve the name, right?
> > Then it will get the new TTL value.
>
> Correct again.
>
> > 4. Does DNS have its owncache? How to set the interval for its update?
> > If
>
> Yes, if it is an "intermediate" DNS it willcachethe record for (up to) the
> TTL
> time provided by the owner (master) of the zone/record where the record
> originates.
>
> > I set TTL short than thecacheupdate interval does thecachekeep the
> > record
> > or remove it?
>
> Thecacheon THIS server has NOTHING to do with the records/zones on
> THIS Server.
>
> Thecacheon THIS server is only used for caching OTHER Servers' records.
>
> > 5. How to force DNS update manually?
>
> What does that mean? And if you wish to flush the caches you might well
> explain "Why" you wish to do something that is practically never required.
>
> > I'm using Windows 2003 AD intergrated DNS.
>
> Clients (modern ones at least)cacherecords they get from DNS Servers.
>
> DNS Serverscacherecords they get from OTHER DNS Servers which
> hold OTHER Zones.
>
> DNS Servers with zones have a TTL for each resource record or use theDEFAULTTTL (from the SOA) for those records not explicitly set.
>
> The OWNING DNS Server "tells" the requestor how long it is "ok" tocachea record. The owning DNS server presumably knows how long
> the record will be "stable" and so sets a sensible value.
>
> About the only time you should see a problem is when MOVING IP
> addresses (e.g., changing ISPs) -- when doing this you should/must
> update your TTLs on your zone records at least ONE TTL AHEAD
> of time to something smaller.

I have a question along these lines.

I have an environment that has AD forest for each major department. I
operate the non-microsoft central dns business zone that ttl was set
to 24 hours. I learned the the departments had set their name server
to hold their cache for 24 hours. We made some changes where I set
the individual a and ptr records' ttl to 5 minutes. Without
intervention, how long could the records stay on the AD name servers
without being updated?

The problem I've seen in the past is that when I run 'nslookup -
type=soa domain.name and I get a response from the AD name servers
the serial numbers could be 20,000 or more out of date. So, I was
wondering if each record is held with it's own timestamp to mark the
24 hours or is it by zone?

I just recommended to them that the internal zones have a ttl of 15
minutes to keep up with DHCP changes. What would you recommend?

Thanks

Mike

[Herb Martin]

"mmccaws2" <mmccaws@comcast.net> wrote in message
news:e35fccc2-41b5-4434-8a19-a9a3e864450b@f36g2000hsa.googlegroups.com...

> DNS Servers with zones have a TTL for each resource record or use
> theDEFAULTTTL (from the SOA) for those records not explicitly set.
>
> The OWNING DNS Server "tells" the requestor how long it is "ok" tocachea
> record. The owning DNS server presumably knows how long
> the record will be "stable" and so sets a sensible value.
>
> About the only time you should see a problem is when MOVING IP
> addresses (e.g., changing ISPs) -- when doing this you should/must
> update your TTLs on your zone records at least ONE TTL AHEAD
> of time to something smaller.

I have a question along these lines.

I have an environment that has AD forest for each major department. I
operate the non-microsoft central dns business zone that ttl was set
to 24 hours.

* Then that is the MAXIMUM that any other DNS server or client
* should hold your records.

I learned the the departments had set their name server
to hold their cache for 24 hours. We made some changes where I set
the individual a and ptr records' ttl to 5 minutes. Without
intervention, how long could the records stay on the AD name servers
without being updated?

* Five minutes. No DNS Server or client will hold a record LONGER
* than the actual TTL on that record -- to do so would be foolish.

* Presuming they have done at least one lookup since you changed
* the value.

The problem I've seen in the past is that when I run 'nslookup -
type=soa domain.name and I get a response from the AD name servers
the serial numbers could be 20,000 or more out of date. So, I was
wondering if each record is held with it's own timestamp to mark the
24 hours or is it by zone?

* Serial numbers are NOT dates by default -- that is a convention
* of admins when updating them manually.

I just recommended to them that the internal zones have a ttl of 15
minutes to keep up with DHCP changes. What would you recommend?

* Perhaps, but remember that when a DHCP client updates its record
* it will overwrite the existing one so there is usually no strong
motivation
* for this.

* A client that is just offline cannot be reach in any case, and if you let
* the DHCP server do the registration AND de-registration it will be
* even more up to date.

* One might also wonder what motivates you to have the DHCP settings
* so short?

[mmccaws2]

On Apr 21, 5:18 pm, "Herb Martin" <n...@learnquick.com> wrote:
> "mmccaws2" <mmcc...@comcast.net> wrote in message
>
> news:e35fccc2-41b5-4434-8a19-a9a3e864450b@f36g2000hsa.googlegroups.com...
>
> > DNS Servers with zones have a TTL for each resource record or use
> > theDEFAULTTTL (from the SOA) for those records not explicitly set.
>
> > The OWNING DNS Server "tells" the requestor how long it is "ok" tocachea
> > record. The owning DNS server presumably knows how long
> > the record will be "stable" and so sets a sensible value.
>
> > About the only time you should see a problem is when MOVING IP
> > addresses (e.g., changing ISPs) -- when doing this you should/must
> > update your TTLs on your zone records at least ONE TTL AHEAD
> > of time to something smaller.
>
> I have a question along these lines.
>
> I have an environment that has AD forest for each major department. I
> operate the non-microsoft central dns business zone that ttl was set
> to 24 hours.
>
> * Then that is the MAXIMUM that any other DNS server or client
> * should hold your records.
>
> I learned the the departments had set their name server
> to hold their cache for 24 hours. We made some changes where I set
> the individual a and ptr records' ttl to 5 minutes. Without
> intervention, how long could the records stay on the AD name servers
> without being updated?
>
> * Five minutes. No DNS Server or client will hold a record LONGER
> * than the actual TTL on that record -- to do so would be foolish.
>
> * Presuming they have done at least one lookup since you changed
> * the value.
>
> The problem I've seen in the past is that when I run 'nslookup -
> type=soa domain.name and I get a response from the AD name servers
> the serial numbers could be 20,000 or more out of date. So, I was
> wondering if each record is held with it's own timestamp to mark the
> 24 hours or is it by zone?
>
> * Serial numbers are NOT dates by default -- that is a convention
> * of admins when updating them manually.
>
> I just recommended to them that the internal zones have a ttl of 15
> minutes to keep up with DHCP changes. What would you recommend?
>
> * Perhaps, but remember that when a DHCP client updates its record
> * it will overwrite the existing one so there is usually no strong
> motivation
> * for this.
>
> * A client that is just offline cannot be reach in any case, and if you let
> * the DHCP server do the registration AND de-registration it will be
> * even more up to date.
>
> * One might also wonder what motivates you to have the DHCP settings
> * so short?

Actually it was from experience. I could vpn into work, the ad name
servers would obtain that ip address. When I got to work, I found
that the AD name servers hadn't updated the entry. So, it looked as
though the name servers were not updating. And since the DHCP was
updating the non-microsoft name servers, I saw evidence that something
wasn't right.