Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Thu, 04 July 2013 08:25 UTC
Return-Path: <wouter@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6246621F9F50 for <dnsop@ietfa.amsl.com>; Thu, 4 Jul 2013 01:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EznfXeQeFjuO for <dnsop@ietfa.amsl.com>; Thu, 4 Jul 2013 01:25:19 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3B21F9AD3 for <dnsop@ietf.org>; Thu, 4 Jul 2013 01:25:18 -0700 (PDT)
Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r648PBJ4037898 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Thu, 4 Jul 2013 10:25:15 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl)
Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r648PBJ4037898
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1372926316; bh=jPpfuSjvMBimg9ahbOJQaFYvBpdP1hBWelgmG/5dduE=; h=Date:From:To:Subject:References:In-Reply-To; b=Gkl5/lXXsF7ECTlFurFMaXtOdbUAtxWqlf2kWDM+w6jxo12xwAbhKuwspew0acv4c dkiQIZeFaTWH0pasknRlMmQz70NmOyP529ruI14axZ9FW9wBP6r9BKHclBpLL/5Jra +uH+EjP7jQ6++VQgXDM90sSvz41adVYfTmI1YWao=
Message-ID: <51D53167.9090906@nlnetlabs.nl>
Date: Thu, 04 Jul 2013 10:25:11 +0200
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20130703210147.69996.qmail@joyce.lan> <EFD28A69-40DC-4A6C-B3E7-B35BC655AF7F@vpnc.org> <FAFC3938-13F8-44FD-8AD9-5D71D68E1A1A@kumari.net>
In-Reply-To: <FAFC3938-13F8-44FD-8AD9-5D71D68E1A1A@kumari.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 04 Jul 2013 10:25:15 +0200 (CEST)
Subject: Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 08:25:20 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > 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/ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR1TFiAAoJEJ9vHC1+BF+NcuUP/1u6cB9LVEwoEHmucXoPE8Tt z5frpV0xbfn6BaR0dvilorOHFr3KUe7HLa9ZRYHSaTDGqsYGqwmQC8HPx55r3sPn 9znMMxvAuX46BaAiLA1+7BEjKe96ubRkGZT6Lgt7C0UYcZfICG2U+CHOUVlPUJhU pBDRq+o0fwhrP4Wx9L8aGtQwy+cFoxMi1sgQNSwji3QXZjzw+5ioV43CGx8HnAFM 09triotHJtD/weHWbk5RksQ9Fh0ncWXXFwiIPbKFwAKs28UDqP+fCWBwG5CeooNM ruxuHRuJ7TEpWmPpB0WZfiCS6eIkGxr1ZaH0YKzni1+EC9qkpw7ziaUo19svZEEU QxSWKOfBXOgWbJQvFj9BBKmKojv7ShVfzpe20czmsPdXuZsVwqWfOPeVtuV7lqJQ 6SP38LZvBE9qs4rZiXvvROYZyU3yqtyhp9i5K2aMncR64gsAtWCScR1diJWPLpWP P55mHEmGaeu4xUsrvu49JMihDdxgSZYmZM4HdcUlShlzKYYOTuqKRh8C5Kzk7Ybq FK5OOSyc4r8+kSRAmPtzj4pNf1cR/Te1/MR5o8yc8ZAVIjJvATGbKJEk5qq4jxrK OukryH5g15wLAwJkC7M82fW4ua5PECwceeTkwAd+XETo/GZ4XPzZLBv9A8McWzF9 nnGDcxbx9rija3NTMv6A =8l0m -----END PGP SIGNATURE-----
- [DNSOP] Fwd: New Version Notification for draft-w… Warren Kumari
- Re: [DNSOP] Fwd: New Version Notification for dra… John Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Matthijs Mekking
- Re: [DNSOP] Fwd: New Version Notification for dra… W.C.A. Wijngaards
- Re: [DNSOP] Fwd: New Version Notification for dra… Antoin Verschuren
- Re: [DNSOP] New Version Notification for draft-wk… Suzanne Woolf
- Re: [DNSOP] New Version Notification for draft-wk… Edward Lewis
- Re: [DNSOP] New Version Notification for draft-wk… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-wk… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-wk… Edward Lewis
- Re: [DNSOP] Fwd: New Version Notification for dra… Hector Santos
- Re: [DNSOP] New Version Notification for draft-wk… John Levine
- Re: [DNSOP] New Version Notification for draft-wk… Doug Barton
- Re: [DNSOP] New Version Notification for draft-wk… Jaap Akkerhuis
- Re: [DNSOP] New Version Notification for draft-wk… Dickson, Brian
- Re: [DNSOP] New Version Notification for draft-wk… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-wk… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-wk… Hector Santos
- Re: [DNSOP] New Version Notification for draft-wk… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-wk… John Levine
- Re: [DNSOP] New Version Notification for draft-wk… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-wk… John R Levine
- Re: [DNSOP] New Version Notification for draft-wk… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-wk… W.C.A. Wijngaards
- Re: [DNSOP] New Version Notification for draft-wk… Phil Regnauld
- Re: [DNSOP] New Version Notification for draft-wk… Paul Wouters