Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 07 December 2016 04:03 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 D8D78129643; Tue, 6 Dec 2016 20:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ftgy4z4hhKO4; Tue, 6 Dec 2016 20:03:15 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 AF07B129553; Tue, 6 Dec 2016 20:03:15 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id a10so290482042ywa.3; Tue, 06 Dec 2016 20:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yaxo+7swTKe1reVvI3bZAfRQPrxEarZc0cwJa4OqhKE=; b=JaqzCkrsh5bAJz8gtLHm4zfJpIGSPsIcn/pqpGBQbOjE55M9aKIdZtclRqmHqwo07n 2yNpw7UkBfc24CFjyS5J0O6R+OJ2OP37eql97hl3A4fMOkSmLAcjxBphKL/RssFtl2Xh nT7tfW8BdqSCaw2ZrZD1+rJ+HyTaByLq4lxUQIXIYd1VlkEQqAm7iHxcxYQa6bC9VYt8 4RIbD42BNaEJjHXnVPhgLvleSnyGKlEOB9iYULFv8WGfDjJctYaRVGNaq1aI3VY/XCCh FKWxLTmmJyC6nVVA38onn7Vo/w8IIpR8NHWdnr1InEE/UTmSLxE9Yo4Eq0qIfXP4+XEc TCXQ==
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:from:date :message-id:subject:to:cc; bh=Yaxo+7swTKe1reVvI3bZAfRQPrxEarZc0cwJa4OqhKE=; b=EZSnZ/AhMff9/LgjCUfOduizKgveKuV2GigM75jz0yP+o+xx85zcjmFRfzTrHSaZcP 5VTKFFfvGL5aDhrrd3uwNbN1uUl8RFLH1PG2Q7Qb6P04vd+fHk3rvxGB7+YRJZOVSkjP j2jaSpfESBY3Zxhm2XOY/8Hx1onIcyAtci4hzxvQE3NRlbBQKoJmLp1iu0y7EeL4xTdq Yj8MjctHW5OSy+A4PTekmUTk7ZLci2D9PyppxirM/rlnmF4DTu0BLobXpV7nG2AOpblf mzR07tcKmp/3IlrdxkKZnqEPftFNbKNYHQsK6u+jS5chEwYGW5e+bZVM4Im8eElOcfLf qYIg==
X-Gm-Message-State: AKaTC00YlK5C4PJCFEjPLPU6b3uxxHf8HYtpY4ZVe2YPKpLy/DZmWz5KfD/8BwnIk/pXzHHsqxqiFGirE5hVFw==
X-Received: by 10.37.173.9 with SMTP id y9mr16058877ybi.121.1481083395024; Tue, 06 Dec 2016 20:03:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.176.5 with HTTP; Tue, 6 Dec 2016 20:03:14 -0800 (PST)
In-Reply-To: <F55BF018-5613-4BB3-AD91-6BA1BD20FEEE@vpnc.org>
References: <148046227837.11642.8747586791761273945.idtracker@ietfa.amsl.com> <339F67B8-B76F-469C-9E22-8EAB8B2E672B@vpnc.org> <CAKKJt-eF=MtwXLtRBU-1PngmM2iBtVm+inik7MWq4U6XCpAeCg@mail.gmail.com> <F55BF018-5613-4BB3-AD91-6BA1BD20FEEE@vpnc.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 06 Dec 2016 22:03:14 -0600
Message-ID: <CAKKJt-fq6-O+5_L5vSP7aPi3uVVZEEc_x=JX_ibX7xniiqA7wQ@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="f403045dc344a4b5140543099911"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/A9mVltaYxgduyHjc5g39dijB4ZE>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dnsop-resolver-priming@ietf.org
Subject: Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 07 Dec 2016 04:03:18 -0000

Hi, Paul,

On Tue, Dec 6, 2016 at 8:39 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> [[ BTW, sorry for not changing the subject line on this thread. It really
> does relate to all the IESG comments, not jus Ben's. ]]
>
> On 6 Dec 2016, at 18:32, Spencer Dawkins at IETF wrote:
>
> On 30 Nov 2016, at 22:48, Spencer Dawkins wrote:
>>>
>>> I find myself curious about both SHOULDs in
>>>
>>>>
>>>>    Resolver software SHOULD treat the response to the priming query as a
>>>>    normal DNS response, just as it would use any other data fed to its
>>>>    cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
>>>>
>>>> Do you think these SHOULDs (especially the first one) are required for
>>>> interoperation?
>>>>
>>>>
>>> Yes.
>>>
>>> I'm wondering (1) why they aren't MUSTs, and (2) why RFC
>>>
>>>> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs,
>>>> what happens if the resolver software violates them?
>>>>
>>>>
>>> We cannot tell. For the first one, if a resolver treats the response to
>>> the priming query in a special way, we don't know what "special" means.
>>>
>>
>>
>> I'm somewhat curious about why this isn't a MUST, but ... ok.
>>
>
> For example, an implementation might treat the responses special by
> altering the TTLs based on some understanding that the vendor has that only
> is relevant to priming queries. Why prevent that?


That wasn't my intention. Thanks for indulging my curiosity.

Sometimes, I'm a curious guy ;-)


>
>
> For the second one, if a resolver expects exactly 13 NS RRs and gets
>>> fewer, we don't know what it will do (fail to come up? retry incessantly?
>>> ...?)
>>>
>>>
>> I'm really curious about why this is not a MUST - can anything good happen
>> when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you
>> can assess the risks of doing it". Is that possible, in this case?
>>
>
> We could certainly say "SHOULD NOT expect exactly 13 NS RRs because
> historically some root servers have returned fewer".


That is exactly the kind of thing that seems uber-helpful to mention!

Thanks for the background.

Spencer