Importance Of Parent-side TTLs For Referrals Several Layers Deep
draft-ihren-delegation-ttls-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Johan Stenstam | ||
| Last updated | 2003-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This memo documents a consequence of how the TTL re-writing mechanism works (or rather does not work) for the case of a resolver chasing a referral chain several layers deep. The most common example of this is the case of a recursive resolver trying to look up a third level domain name starting from the root. A result of how this works is that it seems to be a good idea to recommend an increase of the present standard TTL for delegations from the root zone from the present 48 hours to something significantly longer. But, more importantly, the choice of TTL for the referral from the parent should be a decision made by the child, not the parent.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)