IETF Logo Mail Archive

Re: [DNSOP] [Ext] Secdir last call review of draft-ietf-dnsop-7706bis-07

Paul Hoffman <paul.hoffman@icann.org> Fri, 28 February 2020 18:48 UTC

Return-Path: <paul.hoffman@icann.org>
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 ACA203A1C8E; Fri, 28 Feb 2020 10:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JxEBnnGi3C2q; Fri, 28 Feb 2020 10:48:31 -0800 (PST)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6773A1C85; Fri, 28 Feb 2020 10:48:31 -0800 (PST)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 01SImPjV003301 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 18:48:26 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 28 Feb 2020 10:48:23 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Fri, 28 Feb 2020 10:48:23 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Linda Dunbar <linda.dunbar@futurewei.com>
CC: secdir <secdir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dnsop-7706bis.all@ietf.org" <draft-ietf-dnsop-7706bis.all@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Secdir last call review of draft-ietf-dnsop-7706bis-07
Thread-Index: AQHV62cOmX4hsSIFCUW9l6yT30xrp6gxfpsA
Date: Fri, 28 Feb 2020 18:48:23 +0000
Message-ID: <F7AAA5D0-090F-4039-9479-DD9ACF1C3C6D@icann.org>
References: <158258558771.24222.13223272462077841258@ietfa.amsl.com>
In-Reply-To: <158258558771.24222.13223272462077841258@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_41AB472E-1B74-4814-B758-4B4E57D3A287"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_06:2020-02-28, 2020-02-28 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OyoG8ASsDyMRDBhtC4UYykhFqT0>
Subject: Re: [DNSOP] [Ext] Secdir last call review of draft-ietf-dnsop-7706bis-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 28 Feb 2020 18:48:34 -0000

Thanks for the review! Answers to your questions here:

On Feb 24, 2020, at 3:06 PM, Linda Dunbar via Datatracker <noreply@ietf.org> wrote:
> - What if
> the node is not authorized to have the entire records? It would desirable for
> the Resolvers to have all the records of the root zone. Is there any scenario
> that the Resolvers simply cannot get all the records of the root zone?

No, there is no such scenario. Every resolver can always get and cache any record in the root zone.

> -  How to detect if any records stored in the Resolver are STALE?

Resolvers would treat the records gotten from transferring the root zone wholesale as if they had requested each one from a root server. Thus, record staleness is handled for these records exactly as they are for normal queries.

> Page 3, last sentence of the 3rd paragraph:  is it a typo? or miss a verb?
> "... it would all responses from a remote root server"

Good catch. We'll fix that to "just as it would validate all responses from a remote root server".

--Paul Hoffman

v2.23.0 | Report a Bug | By Email