Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

神明達哉 <jinmei@wide.ad.jp> Wed, 03 February 2016 18:08 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 33E331B2A59 for <dnsop@ietfa.amsl.com>; Wed, 3 Feb 2016 10:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 cQlZaVL0De3D for <dnsop@ietfa.amsl.com>; Wed, 3 Feb 2016 10:08:24 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 DCE431B2A68 for <dnsop@ietf.org>; Wed, 3 Feb 2016 10:08:16 -0800 (PST)
Received: by mail-ig0-x22f.google.com with SMTP id ik10so92942139igb.1 for <dnsop@ietf.org>; Wed, 03 Feb 2016 10:08:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hnsyM75UGL+YvUrwr5Bw/E60VQwvQVaFUF9ZiQs3HNk=; b=bYGOJP7WehZzOst75RwwObAN4Gq3FballgRvSnDl7h3zkDzACsraC+W81itzd0RtQu /Hupsc5sWhDA4LXSV9dUn/jndfuhef9u01XCtpvkbFf21SCbGyI+l79/ivWFmreOePqw 2PuZZ+bL9KjLei4+UD2PCJpgbebdzIG0j5xQEpi/Vq7yGU553HyvHhYlTpVMo8oK5Oet 0uhF8pRqCZc901Hrk8Ce4//8o0QiFxaBV/HwQYgbVOC+ScMHmilZpnej4raIkCMY0ORg oMmZjBYfHLOQaI8exUo5niyu/ei8YS8UwVt4EV4A+i4D7nbiD020vW40rkWxIeRTd1Jy KyWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hnsyM75UGL+YvUrwr5Bw/E60VQwvQVaFUF9ZiQs3HNk=; b=hZxBleM50T0k8f46nfKt7a6TFU8NjQoOBTJPsC3fMPtNzY3zDHc4RWVOjriICB5WFS 9y9Hyv5mt92EQkU94xLEo2iBsHAaZFrrq0x3doPvOveCiPlHFWaMeKWcmqT6t76GRA8v S7K9nJJqp+T2MngwA+i362gp2rgfvelgmCqgtRHn6o8RAMmd4wWmSDYod+ChAIB0CWS0 1lY5oLdbimzVgIs5ACaq21Nf8O/Cr9ydYayhU/SQoYV3WSShgK0tRrrxhqWiUwiw/+5k RCy6isHNS3YHv4ZaAn8P8gg56vzExaZJtjOZrmpFxNBUtUJi10sUZLHEBPFWR+fQtMx3 c9lQ==
X-Gm-Message-State: AG10YOREm7KwzM5/visFNxIIW2Gw82AcqowJsiV39x5Ta31xWJH2fnbytlJD/5RiItV74AEibfLK4xlNKHSxQw==
MIME-Version: 1.0
X-Received: by 10.50.111.111 with SMTP id ih15mr25794628igb.78.1454522896211; Wed, 03 Feb 2016 10:08:16 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Wed, 3 Feb 2016 10:08:16 -0800 (PST)
In-Reply-To: <15BC8628-9FC6-43A3-852A-0B457E36CC62@vpnc.org>
References: <E19574D8-7460-4910-B65F-5355DFCA7313@vpnc.org> <CAJE_bqfWFGfjmXwEhXNfEsE_crH6e51Y1HrYrCD4AnWHwMVSiQ@mail.gmail.com> <4DC64D5D-CCCD-4A07-A285-C9E16773F56C@vpnc.org> <CAJE_bqdN-dn8VHmQo-iVOo40Z40=8SeK-3CvFKT7jTr-qJ4LOA@mail.gmail.com> <E764A09B-3E16-4F93-96B4-B8CDDEBE766B@vpnc.org> <CAJE_bqe7cgR1wAQ=ktjKPtVzgCg=1uUr_r3q64LNFn_zCPgPkA@mail.gmail.com> <15BC8628-9FC6-43A3-852A-0B457E36CC62@vpnc.org>
Date: Wed, 03 Feb 2016 10:08:16 -0800
X-Google-Sender-Auth: cd9T8rW4ftnZ0b5ukP2o7PuxGlU
Message-ID: <CAJE_bqcdwjiTw3PXGLKsiVqbdraKrWLJDVyjksMG5+WvLp1fPA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Q3glhAliv2KK2lD4cSovzFcZdKw>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming
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, 03 Feb 2016 18:08:25 -0000

At Wed, 03 Feb 2016 07:49:22 -0800,
"Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

> >> The priming response is expected to have an RCODE of NOERROR, and to
> >> have the
> >> AA bit set. Also, it is expected to have an NS RRSet in the Answer
> >> section (because the
> >> NS RRSet originates from the root zone), and an empty Authority
> >> section
> >> (because the
> >> NS RRSet already appears in the answer section). There may be an
> >> Additional section with A
> >> and/or AAAA RRSets for the root name servers pointed at by the NS
> >> RRSet.
> >
> > (sorry for the delayed response) in clarity it now looks good, but I'm
> > not sure this is enough as a description of priming query behavior.  I
> > would wonder what if the AAAA and/or A RRSets are missing - in that
> > case the result of the priming query is almost useless or could even
> > be harmful as you'd now only cache the new ./NS RRSet (which could be
> > totally different from that of the "hint").
> >
> > If I were to write this text, I'd say something like this:
> >
> > The priming response is expected to have an RCODE of NOERROR, and to
> > have the AA bit set. Also, it is expected to have an NS RRSet in the
> > Answer section (because the NS RRSet originates from the root zone),
> > and an empty Authority section (because the NS RRSet already appears
> > in the answer section).  The Additional section is conventionally
> > expected to include A and/or AAAA RRSets for the root name servers
> > pointed at by the NS RRSet.  Although these RRSets are not
> > guaranteed to be included by the protocol standards, they are
> > essential for the priming response to be useful in practice, and
> > currently deployed root servers actually meet the expectation.
>
> We should be a bit cautious here. They are *currently* essential, but if
> the root server operators choose a different naming scheme, they may not
> be essential in the future.

I'm not sure if you're disagreeing with me on some point or are just
making some general statement, and in the case of former whether it's
about my concern of "what if AAAA/A is missing" or about the specific
text I showed...as a general matter I tend to agree that we should
distinguish issues specific to the current practice and from general
matters, but I'm not sure how that's related to the above comment of
mine.

So, in the end, are you saying your revised text should be good
enough, or are you suggesting to revise my proposed text to clarify
what's based on the current practice, or something else?

--
JINMEI, Tatuya