Subject: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-hammer-00.txt

From: Warren Kumari <[email-masked]>
Date: Mon, 1 Jul 2013 17:43:25 -0400

Hi there,

We would like to draw your attention to a new draft. 
If describes a simply optimization that, with minimal to no state, keeps popular records in recursive server's caches. 

W

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-wkumari-dnsop-hammer-00.txt
> Date: July 1, 2013 5:40:44 PM EDT
> To: Roy Arends <[email-masked]>, Suzanne Woolf <[email-masked]>, Warren Kumari <[email-masked]>
> 
> 
> A new version of I-D, draft-wkumari-dnsop-hammer-00.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
> 
> Filename:	 draft-wkumari-dnsop-hammer
> Revision:	 00
> Title:		 Highly Automated Method for Maintaining Expiring Records
> Creation date:	 2013-07-01
> Group:		 Individual Submission
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-hammer-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer
> Htmlized:        http://tools.ietf.org/html/draft-wkumari-dnsop-hammer-00
> 
> 
> Abstract:
>   This document describes a simple DNS cache optimization which keeps
>   the most popular records in the DNS cache.
> 
> 

No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 01:44:38 -0000

>We would like to draw your attention to a new draft. 

It looks like it should work, assuming that your cache uses the
existing logic to remember queries in progress so it doesn't hammer a
record that's already in the process of being refetched.

My main observation is that I have no idea what the tradeoffs are
between the increased DNS traffic and faster responses to clients.
Have you done simulations or live experiments?

R's,
John

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 02 Jul 2013 07:58:25 +0200

This sounds a lot like prefetch in unbound, and the configuration option
gives some analysis on increased traffic.

prefetch: <yes or no>
     If yes, message cache elements are prefetched before they expire
     to  keep  the  cache  up to date.  Default is no.  Turning it on
     gives about 10 percent more traffic and load on the machine, but
     popular items do not expire from the cache.

Also, if the original TTL of the RR is less than STOP * HAMMER_TIME then
the cache entry, it cannot be used anymore and the resolver should
"Break it down".

Best regards,
 Matthijs

On 07/02/2013 03:44 AM, John Levine wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 02 Jul 2013 09:53:39 +0200

Hi,

It is exactly that option.  With some small changes.  The draft has a
fixed time HAMMER_TIME.  Unbound has a hard-coded percentage, 10%,
which is not configurable (by choice, no option that hurts).  This
setting causes an upper bound on the extra work of about 10% and about
10% more traffic towards nameservers (so the prefetch option is not
deleterious to others).  Authority server owners can influence their
prefetch behaviour via the TTL (a larger TTL has a larger
'hammer-time' of 10% of TTL, but also still a larger cache-TTL as
well, and also the relative popularity that is necessary to be
prefetched goes down as you only need queries inside of a longer time
period to be prefetched).

We tested this in a large production resolver and found that the
benefits are small.  Likely when the cache expires there is no more
spike in latency for a couple of customers.  The cache hits increase
modestly, but not spectacularly; some percents more cache hits.

In the draft the "touch this" phrase is very funny, however I would
prefer implementation-independent phrasing, i.e. 'do not perform
prefetch for this element'.

Is a draft necessary for this?

Best regards,
   Wouter

On 07/02/2013 07:58 AM, Matthijs Mekking wrote:
> This sounds a lot like prefetch in unbound, and the configuration
> option gives some analysis on increased traffic.
> 
> prefetch: <yes or no> If yes, message cache elements are prefetched
> before they expire to  keep  the  cache  up to date.  Default is
> no.  Turning it on gives about 10 percent more traffic and load on
> the machine, but popular items do not expire from the cache.
> 
> 
> Also, if the original TTL of the RR is less than STOP * HAMMER_TIME
> then the cache entry, it cannot be used anymore and the resolver
> should "Break it down".
> 
> Best regards, Matthijs
> 
>> existing logic to remember queries in progress so it doesn't
>> hammer a record that's already in the process of being
>> refetched.
>> 
>> My main observation is that I have no idea what the tradeoffs
>> are between the increased DNS traffic and faster responses to
>> clients. Have you done simulations or live experiments?
>> 
>> R's, John _______________________________________________ DNSOP
>> mailing list [email-masked] 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 2 Jul 2013 12:07:48 +0200

> We would like to draw your attention to a new draft.

I like this draft and concept, but how new is it?
It's good to be documented though.

I feel like when a recursive resolver has implemented HAMMER, and
HAMMER_TIME is set to zero, we have an existing sticky resolver.

One thing that fails though for this analogy to be complete, is how
iterative the "cache fill" query will be.
If a record from a zone is about to expire, but it still has a valid
NS set for that zone in it's cache, will it ignore or use that NS set
to issue the iterative query?
If it does use it, thereby being a full sticky resolver, it will
create less DNS traffic for static delegated zones, as it does not hit
the parent again.
If it doesn't, and ignores the NS set for the zone in it's cache, and
re-queries the parent, it will hit the parent harder than when it did
not implement HAMMER, and probably create more DNS traffic than
without HAMMER.

I feel this needs to be clarified in the draft.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 2 Jul 2013 09:10:18 -0400

Hi Antoin,

On Jul 2, 2013, at 6:07 AM, Antoin Verschuren <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Not to speak for Warren, but this is why I was willing to work on a draft.

> HAMMER_TIME is set to zero, we have an existing sticky resolver.

This is the idea, yes. 

> I feel this needs to be clarified in the draft.

This is the other reason for a draft :) 

I know this has been in the field in various forms, but AFAIK those questions haven't really
been asked across teams of implementors or groups of operators.

If they have, I'm happy to reduce my own ignorance and others' by documenting accordingly.

Suzanne

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Jul 2013 09:44:12 -0400

First, I don't see why this draft exists in the IETF.  How does this impact interoperability?

Further, this draft is hinting at a mixed signal.  In an era where operators are rushing to deploy RRL because of what appears on the surface to be overly aggressive clients, the document is telling cache servers that they ought to be (slightly) overly aggressive.  I get that this is *slightly* overly aggressive and that the use here is "benign" (chuckle if you want), but, well, 131 is still over the limit (of 130 kph).  And intent is immaterial when I see a query thrown my way.

Why is this important?  I looked at one popular name, just to pick one for the sake of an email message (not a whitepaper).  The TTL on an A record is 300 and my dig reported it took 19ms to get a response from an authoritative server.  I.e., the domain wants to change the A frequently but also has a fast authoritative infrastructure.  19ms is less than one-half of one percent of one percent of 300, if I plug that into an "efficiency" I'm dividing:

300 / 300.019 = 99.993%

I don't see the real-world benefit of this.

> No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jul 2013 07:06:22 -0700

>     popular items do not expire from the cache.

I thought unbound's prefetch kept the cache full all the time, not just when a nearly-expired name is gotten from the cache. HAMMER specifically grabs only when a name is used again close to its expiration. Or am I misunderstanding the unbound documentation?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jul 2013 08:06:38 -0700

> First, I don't see why this draft exists in the IETF.  How does this impact interoperability?

There are many drafts and RFCs produced by the IETF that do not "impact interoperability". This document describes an operational issue. That seems kind of appropriate for the DNSOP WG, yes?

> Further, this draft is hinting at a mixed signal.  In an era where operators are rushing to deploy RRL because of what appears on the surface to be overly aggressive clients, the document is tellin…

RRL is being deployed because of botnets, which are not clients at all: they simply use the DNS protocol. The draft is not for things that are overly aggressive at all.

> Why is this important?  I looked at one popular name, just to pick one for the sake of an email message (not a whitepaper).  The TTL on an A record is 300 and my dig reported it took 19ms to get a…

Fine: you don't need implement it. There are enterprise environments where the round-trip times are more significant to them than they seem to you in your enterprise environment.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Jul 2013 11:59:19 -0400

> There are many drafts and RFCs produced by the IETF that do not "impact interoperability". This document describes an operational issue. That seems kind of appropriate for the DNSOP WG, yes?

Since you asked, no.  [0]

I don't see an operational issue, not in the DNS operational sense.  If there is an application that is so sensitive to delay, it can pre-fetch data as it needs, this doesn't need to be pressed into the infrastructure.

As other messages indicate, implementations already do this.  It's fine for an individual submission to document what they do, what's the need for a WG review/development/stamp of approval?

[0] The charter is wide open to this, still I would say no.  It's worth noting that the charter's latest milestone is February 2008.

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Jul 2013 14:25:18 -0400

I like the idea. A fews ago we needed to write a local cache for our 
total system framework to create a single source API query for all of 
our apps within the framework using DNS.  The cache database was 
prepared with a query frequency field (QFF) with the idea in the future 
to come up with come correlation where an TTL override can be used.

In other words, if the QFF is low, then we just follow the TTL time to 
requery an expired recording. If the QFF was high, then this is where a 
"HAMMER" time idea would kick in.

I would venture that the efficiency or payoff of a HAMMER time is lower 
when the TTL is high.  So its payoff comes into play when there are low 
TTL values.

So possibly, what the HAMMER draft can include is a set of boundary 
conditions or TTL range for when the HAMMER time is applicable.  I think 
a formula can be created.

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2013 05:25:16 -0000

>Fine: you don't need implement it. There are enterprise environments where the round-trip times are more
>significant to them than they seem to you in your enterprise environment.

I'm still trying to figure out how I could tell whether prefetch makes
things better or worse, since the main thing I've learned from the few
DNS cache simulations I've done is that intuition is not a good guide.

I'm running unbound with verbosity 1 logging.  Any suggestions?

---

From: Doug Barton <[email-masked]>
Date: Tue, 02 Jul 2013 22:53:23 -0700

> I'm running unbound with verbosity 1 logging.  Any suggestions?

Well, first you have to define "better" and "worse" for your 
environment. :)  (And no, I'm not being snarky.)

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 03 Jul 2013 10:04:04 +0200

I'm still trying to figure out how I could tell whether prefetch
    makes things better or worse, since the main thing I've learned
    from the few DNS cache simulations I've done is that intuition is
    not a good guide.

The net effect it will have is that the average latency querying for
the prefetched domains will be lower at the cost of a (max 10% with
current values) bigger cache size and added traffic.

Verbosity 4 will give details and lots of debugging info as well so
you don't really want to run like that for a long time.

My intuition was (based on experiences from measurements on caches)
that the effect wouldn't been spectacular. That was confirmed by the
people who asked us for it.

	jaap

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 3 Jul 2013 15:44:04 +0000

On 7/3/13 4:04 AM, "Jaap Akkerhuis" <[email-masked]> wrote:

>the prefetched domains will be lower

I've seen at least one other comment about average latency.

Two observations on this:
(1) Average is probably not a useful measure here (nor what users
experience - they either get a cache hit or a miss.)
(2) Comparing anecdotal data isn't likely meaningful in the context of
this discussion.

The effect of implementing & using HAMMER is that pre-re-fetch of
sufficiently popular domains will occur.

However, it should be noted that (a) there are a lot of resolvers on the
planet, and (b) what is popular does not necessarily correspond to
topological proximity.

In other words, for a given resolver, there is no guarantee that any
particular popular domain will have low latency (and thus that the latency
to the user will be low).

The impact of pre-re-fetch will be to constrain the upper limit on client
resolution latency, and thus to flatten the client latency distribution
curve.

Additionally, the likelihood of having to retry is reduced (because the
only possible loss would be client-resolver, rather than both
client-resolver and resolver-authority), further flattening the curve
(regardless of how little, the upper bound of latency is reduced).

So, I am in favor of this being implemented, and in favor of it being
memorialized in an RFC (regardless of WG or individual, standard or
informational).

Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 13:30:22 -0400

>     popular items do not expire from the cache.

Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code?
> the cache entry, it cannot be used anymore and the resolver should

I got a few off-list questions asking about the odd naming (and I also remember the IETF Diversity thread on Discuss). 
For folk who have no idea what the hell we are on about:
http://www.youtube.com/watch?v=GbKAaSf6e10
http://www.youtube.com/watch?v=otCpCn0l4Wo

>> record that's already in the process of being refetched.

Hmm. Probably worth mentioning.

>> Have you done simulations or live experiments?
Nope.

This doesn't really change the average very much, but it should help decrease the jitter / spikes for the unlucky few who hit the resolver just as the cache entry expires.
The draft specified HAMMER_TIME as a time, not a percentage because:
A: I wanted to use the phrase HAMMER_TIME (and STOP HAMMER_TIME!) :-P
B: The main "issue" that the draft tries to solve is increased resolution times for the unlucky few who hit the resolver when the record has just expired. In order to decrease the added load caused by this, I chose a default that is somewhat longer than a "bad" resolution experience with a few failures along the way.
C: STOP was added to prevent doing a cache-fill request on every recursive request for records that have TTL of < HAMMER_TIME.
D: I was (tilting at windmills and) trying to get folk to not use TTLs of < a few seconds in the records :-)

From reading the unbound prefetch thing, I suspect maybe a better solution would be:
HAMMER_TIME defaults to 2 (or 1 or something) seconds
If the original TTL is < HAMMER_TIME, then only do the cache-fill when the TTL is 10% of the original TTL.

This means that:
if HAMMER_TIME is 2 and the original TTL is 600 seconds -- the auth servers will see approximately 0.3% additional traffic.
if HAMMER_TIME is 2 and the original TTL is 60 seconds -- the auth servers will see approximately 3.3% additional traffic.
if HAMMER_TIME is 2 and the original TTL is 1 seconds -- the auth servers will see approximately 10% additional traffic.

W

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I care."  -- Terry Prachett

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 13:35:52 -0400

On Jul 2, 2013, at 6:07 AM, Antoin Verschuren <[email-masked]> wrote:

> Signed PGP part

Not very :-)

> It's good to be documented though.

Thank you! INd a(and RFCs) to me seem like a reasonable place to document implementation advice, warnings, etc, regardless of if they require protocol change or affect interoperability.

> HAMMER_TIME is set to zero, we have an existing sticky resolver.

Yup. 

> I feel this needs to be clarified in the draft.

Yup, good point.
W

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. 
   ---maf

Warren Kumari
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Jul 2013 13:59:31 -0400

well, for a moment, I did have to think about this draft being a joke or 
not.  But the acronym was perfect. :)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2013 11:41:05 -0700

> Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code?

My question earlier still stands: does Unbound do what HAMMER says (waits for a request before refreshing the cache) or does it just refresh the cache automatically? The Unbound doc is unclear (at least to me).

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2013 21:01:47 -0000

>My question earlier still stands: does Unbound do what HAMMER says
>(waits for a request before refreshing the cache) or does it just
>refresh the cache automatically? The Unbound doc is unclear (at least
>to me).

If it did it automatically, I'd expect a lot more than 10% more
traffic.  I enabled it on my not terribly busy server and I see
numbers that look like they're in the 1% range:

Jul 03 14:23:21 unbound[40669:0] info: server stats for thread 0: 47798 queries, 20108 answers from cache, 27690 recursions, 242 prefetch
Jul 03 15:23:21 unbound[40669:0] info: server stats for thread 0: 53322 queries, 20319 answers from cache, 33003 recursions, 291 prefetch
Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 queries, 20697 answers from cache, 34563 recursions, 272 prefetch

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2013 14:14:15 -0700

> Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 queries, 20697 answers from cache, 34563 recursions, 272 prefetch

Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ).

---

From: "John R Levine" <[email-masked]>
Date: 3 Jul 2013 17:28:16 -0400

> Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ).

I looked at the unbound source code.  It prefetches when it's responding 
to a query, code in daemon/worker.c.  The code is considerably complicated 
by defensive code to deal with the situation where the parent of the 
record to be prefetched has changed since the record was originally 
fetched.  (Feel free to check my work.)  That's probably worth mentioning 
in the I-D.

There is a separate option to prefetch DNSSEC key records.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 17:56:20 -0400

> Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ).

It *appears* to me from looking at the source that Unbound triggers upon an incoming query (basically what HAMMER suggests).
I should note that this is the first time I have looked at the Unbound source, and so it is entirely possible that I'm missing something.

It seems that worker_handle_request() in worker.c has the interesting bits.
From what I can tell, the worker will only have this sort of request if it was initiated by an incoming query.

Horrendous pseudocode seems like:
worker_handle_request()
 if answer_from_cache:
    if prefetch_ttl_expired:
       reply_and_prefetch()

/** Reply to client and perform prefetch to keep cache up to date */
reply_and_prefetch() 
  reply()
    /* create the prefetch in the mesh as a normal lookup without
	 * client addrs waiting, which has the cache blacklisted (to bypass
	 * the cache and go to the network for the data). */
	/* this (potentially) runs the mesh for the new query */
    	mesh_new_prefetch(worker->env.mesh, qinfo, flags, leeway + 
		PREFETCH_EXPIRY_ADD);

There is also a PREFETCH_EXPIRY_ADD which I don't really understand:

/** 
 * seconds to add to prefetch leeway.  This is a TTL that expires old rrsets
 * earlier than they should in order to put the new update into the cache.
 * This additional value is to make sure that if not all TTLs are equal in
 * the message to be updated(and replaced), that rrsets with up to this much
 * extra TTL are also replaced.  This means that the resulting new message
 * will have (most likely) this TTL at least, avoiding very small 'split
 * second' TTLs due to operators choosing relative primes for TTLs (or so).
 * Also has to be at least one to break ties (and overwrite cached entry).
 */
#define PREFETCH_EXPIRY_ADD 60

I must admit that I'm somewhat shaky on much of the above, it would be great if someone who is more familiar with the architecture / code could comment/

W

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 04 Jul 2013 10:25:11 +0200

Hi,

On 07/03/2013 11:56 PM, Warren Kumari wrote:
>>>> My question earlier still stands: does Unbound do what HAMMER
>>>> says (waits for a request before refreshing the cache) or
>>>> does it just refresh the cache automatically? The Unbound doc
>>>> is unclear (at least to me).

Yes, it waits for a request before refreshing the cache.  The request
is the excuse to bother the authority server, since it could pretend
the entry had fallen out of the cache.  And also the request indicates
a continued interest (the item is still popular).  It was also simpler
to implement :-)

So, prefetch also prefetches fairly impopular names, that have about
10 queries per TTL.  And one query hits the 10% last of the TTL.  For
a TTL of 3600, getting about 10 queries in 3600 seconds would
statistically make you hit one query in the last 10% (a little) often.
 And that is one query per 360 seconds, which is fairly impopular, but
it is prefetched.

>> Those are pictures. Source code, or developer assurance, or it
>> didn't happen ( to badly bastardize a phrase that the kids these
>> days use ).

Yes I wrote the code and say so.  (Not sure how that is better than
reading the source).  Results, anecdotally, are very modest.  It does
remove latency spikes for popular names.

> It *appears* to me from looking at the source that Unbound triggers
> upon an incoming query (basically what HAMMER suggests). I should
> note that this is the first time I have looked at the Unbound
> source, and so it is entirely possible that I'm missing something.

Yes, it trigger upon an incoming query.

> /** * seconds to add to prefetch leeway.  This is a TTL that
> expires old rrsets * earlier than they should in order to put the
> new update into the cache. * This additional value is to make sure
> that if not all TTLs are equal in * the message to be updated(and
> replaced), that rrsets with up to this much * extra TTL are also
> replaced.  This means that the resulting new message * will have
> (most likely) this TTL at least, avoiding very small 'split *
> second' TTLs due to operators choosing relative primes for TTLs (or
> so). * Also has to be at least one to break ties (and overwrite
> cached entry). */ #define PREFETCH_EXPIRY_ADD 60
> 
> I must admit that I'm somewhat shaky on much of the above, it would
> be great if someone who is more familiar with the architecture /
> code could comment/

Prefetch happens before the TTL expires, x seconds before.  You can
determine x in many different ways, a fixed value works for very
highly popular names (i.e. draft submitter's employer), but for less
popular ones (i.e. my employer :-) ), prefetch can also work but needs
a bigger value, that is why I chose a fraction instead of absolute
value.  Unbound uses x + 60 to replace 'old' RRsets when the new reply
comes in.  This x+60 is subtracted from the TTL in the cache for
RRsets to determine if they are 'old' (with respect to the reply for
this prefetch).  Because if it used exactly x, then the cache could
contain a remaining cache TTL x+1 for another RRset that forms up the
reply from cache that we would use for further queries.  So we could
only answer for 1 second extra because we refused to update some RRs
that make up the response (but we updated the RR that was about to
expire).   The value 60 is one that I picked with a similar idea as
when you talked about tilting at the windmills of small TTLs, but it
does not actually prevent the zone operator from choosing small TTLs,
it stops the hammer system from generating such small TTLs in the
cache from the larger TTLs that the authority system sends.  The
defensive code about NS records you refer to is to make sure that this
system can handle a zone operator change without 'sticking' to the old
operator; e.g. 'if x+60 > remaining cache TTL of NS RRset' then we
must go up to the parent operator, even though the child NS has not
expired yet.

Aside, I agree that prefetching before the TTL expires is overly
aggressive.  But lengthening the TTL is worse (for DNSSEC rollovers
TTLs MUST expire, or the signatures become bogus).

Best regards,
   Wouter

---

From: Phil Regnauld <[email-masked]>
Date: Thu, 4 Jul 2013 12:57:13 +0200

> remove latency spikes for popular names.

	What does the latency spike translate to in terms of extra traffic
	(clients) ? A thundering herd effect ? Congestion ? Considering
	how many tricks modern browsers have up their sleeves (including
	prefetching data linked on a page), I'm wondering how the two
	interact. I've always mentioned the expiring RR prefetch option
	to be a cool feature of Unbound, but in reality, what does it mean
	for users ?

> aggressive.

	If it mitigates other issues...

> But lengthening the TTL is worse (for DNSSEC rollovers

	:)

	P.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 13 Jul 2013 19:27:39 -0400 (EDT)

> Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code?

I'm pretty sure Wouter added the code, but I'm not sure who came up with
the idea. Probably multiple people. It's a feature you really need when
running DNS(SEC) on the stub or else you're continuously dealing with
waiting on DNS.

I believe the option was added to unbound 1.4.2 released around march 2010,
and the RHEL and Fedora packages enabled prefetching then as well. So
it's been there for over three years!

Paul