Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

Bob Harold <rharolde@umich.edu> Wed, 28 October 2015 20:37 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450B91AD049 for <dnsop@ietfa.amsl.com>; Wed, 28 Oct 2015 13:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22qDg8XWHQhu for <dnsop@ietfa.amsl.com>; Wed, 28 Oct 2015 13:36:57 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EE11ACD95 for <dnsop@ietf.org>; Wed, 28 Oct 2015 13:36:56 -0700 (PDT)
Received: by ykba4 with SMTP id a4so21167484ykb.3 for <dnsop@ietf.org>; Wed, 28 Oct 2015 13:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich_edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jtpv9KCq5ah15qlnI6YVIT//YjhONcND6TtDhP5YIz8=; b=JeeSXiJEBWeoMlsGdET2j3W52b6d2fnWIuJJLeP3ulCGmhk3S8iMQDCOBa/8GXBJ05 uzfz2zhAPyIwTK1VKuLvz6KITwlHhUTUDiZ5ckOJcNwcOMaKv/vS/rOzg0nL1jzloqCD Kzjal556Qqvbuxlg6fSXUZov04lXlBP/wGNN6t2LvPnAjkQi0pHrTgh567wMeBwTzPgO L8qWFLSp4kFMjj7VLimMGRx+yMC9LbiPvwIAMBn4QzUEt0xaNcnGNkwMTeudvbnvZr53 mBd8RI+Lxz4h8BcdCF+vjIyt9W0EEORFFydGxGYUimkHD/jWReOx5ESIIqOO9fQ3Dw8d CveA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jtpv9KCq5ah15qlnI6YVIT//YjhONcND6TtDhP5YIz8=; b=YhKLfSgNCxS0YfOYuZMdoGm4vFIjHWM+4pCpDuzySu0ZVqT4ByO1Olm2GawmGLQXgB vohBIjagMjUREsCkROELc+3b/YJX1DVdvwbW7Pqm6Smlwb1t54Pvb3riJNiztunuGzz5 aSR29f9uDnyBKm8EGXxLeQh47cjPQ8HvaNcVHKRC5uAbEp1gJuzXWTgwilExu8/b9AuU qMbh583CDm7wCVueAnO00Iaa2iT75AfL/rM64JO7k8Vf0kNj4uCnxNpDBwv6ll2pYycM d3yVDoULSLVx+6d3jybzan3728XBXCSOCXY/UzpGzrZ0w9CSoed3Qb5+zZ+5luDPldli qwsA==
X-Gm-Message-State: ALoCoQmhyJvaGJ1NQI+3Y6vBHNUBFFxMjr/MPD+LRpdLtY343v1cmFm6nvY/+o1b02cH9Akfhet7
MIME-Version: 1.0
X-Received: by 10.13.224.2 with SMTP id j2mr40250266ywe.165.1446064616090; Wed, 28 Oct 2015 13:36:56 -0700 (PDT)
Received: by 10.129.43.69 with HTTP; Wed, 28 Oct 2015 13:36:56 -0700 (PDT)
In-Reply-To: <20150929092049.4d005a16@casual>
References: <201509291227269136613@cnnic.cn> <20150929092049.4d005a16@casual>
Date: Wed, 28 Oct 2015 16:36:56 -0400
Message-ID: <CA+nkc8DExG8=hpJzmE8qmjbsj3njzVGQFNH5aXwEgUrG6GgE6g@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
To: Shane Kerr <shane@time-travellers.org>
Content-Type: multipart/alternative; boundary="94eb2c074626c3fb4c052330272e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/8PFd_97gavSFKrrOqe-FLY2lvlE>
Cc: Jiankang Yao <yaojk@cnnic.cn>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 28 Oct 2015 20:37:01 -0000

On Tue, Sep 29, 2015 at 5:20 AM, Shane Kerr <shane@time-travellers.org>
wrote:

> Jiankang Yao,
>
> I think a simpler approach that works in general is the "HAMMER"
> approach proposed by Warren Kumari, Roy Arends, and Suzanne Woolf a
> couple of years ago:
>
> https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
>
> Basically the idea is that if a query is made for a RRSET that is near
> expiration from the cache, then the resolver will answer normally but
> will also try to refresh the TTL by performing another query.
>
> Note that Unbound already implements something like this today, with
> the "prefetch" option:
>
> https://unbound.net/documentation/unbound.conf.html
>
> BIND 9 does as well, with "prefetch":
>
> https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache
>
> The "HAMMER" approach works for all domains, not just the root zone,
> and doesn't require any separate cache, or indeed any additional state
> at all.
>
> The approach you propose will have some small advantage if someone
> queries for an entry in the root zone that is not in cache. However
> given the long TTL of root zone entries, such a query will be rare so
> the benefit is quite small.
>
> Cheers,
>
> --
> Shane

...

>
> > Jiankang Yao
> >
> > From: internet-drafts
> > Date: 2015-09-29 12:20
> > To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong;
> Ning Kong
> > Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt
> >
> > A new version of I-D, draft-yao-dnsop-root-cache-00.txt
> > has been successfully submitted by Jiankang Yao and posted to the
> > IETF repository.
> >
> > Name: draft-yao-dnsop-root-cache
> > Revision: 00
> > Title: Decreasing Fetch time of Root Data by Improving the Mechanism of
> Root Data Cacheing
> > Document date: 2015-09-28
> > Group: Individual Submission
> > Pages: 10
> > URL:
> https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
> > Htmlized:
> https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00
> >
> >
> > Abstract:
> >    Many DNS recursive resolvers have long round trip times to the DNS
> >    root server.  It has been an obstacle to increse the performance of
> >    DNS query.  In order to decrease fetch time of DNS root data, this
> >    document proposes a new mechanism by improving the mechanism of root
> >    data cacheing.
>

Reading these various ideas brings up a question in my mind.  If a server
queries for the SOA of a zone and the serial number has not changed, can it
then assume that all of the entries in its cache for that zone should still
be valid now, and for the their original TTL value starting now?  If the
values had changed, wouldn't the serial # also change?  Seems like I must
be missing something here.

-- 
Bob Harold