Stretching DNS TTLs
draft-wkumari-dnsop-ttl-stretching-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Warren "Ace" Kumari | ||
| Last updated | 2017-05-17 (Latest revision 2016-11-13) | ||
| 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
The TTL of a DNS Resource Record expresses how long a record may be cached before it should be discarded. This document discusses the possibility of "stretching TTLS" (using them past their expiration) if they cannot be refreshed. This works on the assumption that stale data may be better than no data. PLEASE NOTE: This document is a strawman to drive discussion. It may or may not be a good idea; this document documents the idea so that there is something concrete to throw tomatoes at. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-ttl-stretching. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ]
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)