Importance Of Parent-side TTLs For Referrals Several Layers Deep
draft-ihren-delegation-ttls-00
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Author | Johan Ihren | ||
| Last updated | 2003-10-21 | ||
| Stream | (None) | ||
| Formats |
Expired & archived
plain text
htmlized
pdfized
bibtex
|
||
| 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) |
https://www.ietf.org/archive/id/draft-ihren-delegation-ttls-00.txt
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.)