Opened 12 years ago

Closed 12 years ago

#22 closed defect (fixed)

DNS TTL

Reported by: bernard_aboba@… Owned by: jon.peterson@…
Priority: critical Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

Section 5 indicates that DNS may not be appropriate for use in storing highly volatile data. This statement is not correct in general. Studies such as "DNS performance and the effectiveness of caching" have shown that TTL of some RRs can be set low with minimal effects.

In terms of more recent data, there was a presentation at IETF 79 (in the Name-Based Sockets BOF) on the effect of lowering TTL to zero:
http://www.ietf.org/proceedings/79/slides/nbs-9.pdf

As noted in the presentation, a 60x drop in DNS TTL value only results in a 33 percent increase in A RR requests, and lowering TTL to zero only results in a 225 percent increase in requests.

Note that this did not involve a site setting low TTL for its own NS records or the A RRs related to its NS RRs.

Change History (1)

comment:1 Changed 12 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

Corrected in response to R. Atkinson's comments - the issue is not just volatility as such:

I think here we are trying to say something a bit more specific than "low TTLs are bad," though. We're saying that if you're designing an application that needs to store highly volatile data somewhere, then inventing a new DNS resource record type or whatever and storing it in the proverbial golden root, rather than in an application-specific store accessed by some protocol other than DNS queries/responses, would probably be a bad idea. We mostly care about this in the applications context because people try to tie in the volatile state of external applications to the DNS - be it in the PSTN, or in SIP registrations, synchronizing that dynamic data with DNS records is redundant, of questionable utility, and extremely brittle (see That's really what we're trying for here, not just a blanket "low TTLs are bad" sort of statement. We'll quality this bullet with some additional text to tries to bring that out.

Note: See TracTickets for help on using tickets.