Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis

"Wessels, Duane" <dwessels@verisign.com> Thu, 05 November 2020 18:50 UTC

Return-Path: <dwessels@verisign.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 9137E3A1954; Thu, 5 Nov 2020 10:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 lP5P2nCJMVqa; Thu, 5 Nov 2020 10:50:49 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 B662B3A13E9; Thu, 5 Nov 2020 10:50:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12464; q=dns/txt; s=VRSN; t=1604602248; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4genUKaoVbifJkJvsYWfv03smEdW3XTmVQ2spcE7yJc=; b=j7qR3JolxLm/kGZbC2k7fohi5NqRt8YWn+ou/6fKT7R6A6YSLkdYdL7x Vnnk0gESnXuT2YBpJmOgL+1CtBHOHFJ7/vBnn8biPZNEP+lvel3poerWW 73OzbIwcJyzURFuIMgK7qg+cjptPCtsld9T3URfqeP38gamC43kc//OrJ b+yvlbUUPOFi4vwEW7AQYxi+075xItLKgpG4AGkZCpM+yc+6JocDI6STu rh8PbxW6O93AAR1AD+6prgbaUT8YgAarQSvzusnOkaZC7/+fkzvWJqIX7 CbAN9DLjX+nvggs1HHzQyszwb0JudLQxkj9EGJLMV76gY2oAcO9CWaBLe w==;
IronPort-SDR: 75vzb93EkqPRfmH9i6rTAB5HGbWvOOSa8hPd9jHiGZv0SiLvlIE5snPr1KKosUOv4JOYdEDOpe bcOgmMRbYUywwUBYFqJu8YK0MA0mCxZ7wXke3xIFHWneyQgAr8RU9F2ss+MTdjKc6ejm+mHCJk MSw11A3iTJJnbIFsaTfKaJb+BnVY+qifVW9KiD6UB719Qzg9/2zRJ5Ldy21W7OZy9SU1TXPQgr vHSJJf8WwbarMe8X/ln0IaExOS3cT6mtGRFuvEA3n5KMf+Nw52w6YGuRbCm3S1b3BMvYb1pr3j l7E=
X-IronPort-AV: E=Sophos; i="5.77,454,1596499200"; d="p7s'?scan'208"; a="3097822"
IronPort-PHdr: =?us-ascii?q?9a23=3AhVB/fhb8CPbpuLDQSG+U5lz/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZrsW7bnLW6fgltlLVR4KTs6sC17OJ9fm4BidZuMrJmUtBWaQEbw?= =?us-ascii?q?UCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFR?= =?us-ascii?q?rlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRe7oR/MusUKg4ZuJbs9xg?= =?us-ascii?q?bGr3BVZ+lY2GRkKE6JkR3h/Mmw5plj8ypRu/Il6cFNVLjxcro7Q7JFEjkoKn?= =?us-ascii?q?g568L3uxbNSwuP/WYcXX4NkhVUGQjF7Qr1UYn3vyDnq+dywiiaPcnxTbApRT?= =?us-ascii?q?Sv6rpgRRH0hCsbMTMy7WfagdFygq1GuhKsvxxxzZDJboGJOvRwfa3dctEdS2?= =?us-ascii?q?pAQsleWDdMAoygY4sKFecBPfpUo5f7qlATrRW+Hw6sBOb3xzNGhnD5w7Y60/?= =?us-ascii?q?8/HgHCxwwsB88FvnrJrNrvMqcdT+65x7TPwDreYfJZxyz96JPWfRAluvGBRq?= =?us-ascii?q?xwftTLyUkuDAPFj1qQqYr/MzyJ0eQNtnGW4ux9Xu2gl2ApsRt+oiSzxsgykI?= =?us-ascii?q?nJgJoYx17a+Ch5wIg4O961RVJ1bNOnDZZdtyGUOpV4TM0sQ29luTg2xLIYtJ?= =?us-ascii?q?KmcyYExokrywLQZfGbboWF/hDuWuaVLDp+mXlre6q/ig6v/US80OHwS8u53V?= =?us-ascii?q?hQoiZYktTBuGoB2hPX58SfV/dx4l2t1SuN2gzP8O1IPE85mKnBJ5I8wbM9kI?= =?us-ascii?q?cYv17ZES/sgkr2ibebdkAj+ue19evqeq7mppqAN49sjQH+L7gultS/AesmNg?= =?us-ascii?q?gOWHCW9Pmg2rP74EH2QK1EgPI3naXFrpzWP9obqbK+Aw9PyoYv8QywACq83N?= =?us-ascii?q?QGh3kHN1RFdAibgIjuPlHCOPH4DfGhjFSwiDpn2uzKMqf8DpjPIHXPiqrtcL?= =?us-ascii?q?Zz5kJGxwc+ychT55dOBbEAJPLzVFXxtNvdDhIhLgO1zfjoCM5m1owAXWKPGb?= =?us-ascii?q?SUML3Mvl+S5+IvOOiMZIATuDrnN/cl4PvugWcjmVABZampwYcXaHegE/R6IU?= =?us-ascii?q?WYb2DggtYfHmcWsAozV+PqiFiYXj5SY3a+Rb4z5jY+CIi+F4fMWpitgKCd3C?= =?us-ascii?q?e8BpBZe2ZGCkuLEXfwbIiEWukDaD6cIsN7lTwET7ehQZc71R6yrA/616ZnLu?= =?us-ascii?q?3M9yIFs5Ljz9915/XKmR4u9Tx7FcWd03uWT2xvn2MHWSM23K5lrUx60FeD3v?= =?us-ascii?q?swv/sNKd1Wr8xIWQY8Lp3dh7hmCc+0Ww/dcP+GTV+nRpOtBjRnHfwrxNpbKX?= =?us-ascii?q?lwAM6viguHlwa3CrkY3fTfCIM56bnR22PZOctnym3H269nhF4jFJgcfVa6j7?= =?us-ascii?q?JyolCAT7XClF+Uwv6n?=
X-IPAS-Result: =?us-ascii?q?A2HpBAAQSKRf/zGZrQpiHgEBCxIMQINKgUuBFJUsJoN7m?= =?us-ascii?q?C4EBwEBAQEBAQEBAQQEAS8EAQGESgKCECY4EwIDAQELAQEBBQEBAQEBBgMBA?= =?us-ascii?q?QEChlqCNyKDdwEEAR1cBQsCAQgOOAIwJQIEDhODGAGCXBGwfoE0hVeEXxCBO?= =?us-ascii?q?IFTjAKBQj6BOAwQgk8+hCYXg0uCLASbIYEZm2cDB4JthFCCYpNaH4MYnlWVS?= =?us-ascii?q?5plg2ECBAIEBQIVgWuBe3AVZQGCPz0SFwINgVeNbQEJjRqBLAIGCgEBAwmMB?= =?us-ascii?q?C2BBoERAQE?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 5 Nov 2020 13:50:47 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.002; Thu, 5 Nov 2020 13:50:47 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
CC: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Thread-Topic: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
Thread-Index: AQHWs6SSZpkFfSS8i0OKvceLpr12xQ==
Date: Thu, 5 Nov 2020 18:50:47 +0000
Message-ID: <7852EA76-B27F-405B-8168-1EA028B7C30A@verisign.com>
References: <CADyWQ+H1cGN4abNXzr_=E2s-HKf9n4zbx7SESo1OFLSmBKK3Zw@mail.gmail.com>
In-Reply-To: <CADyWQ+H1cGN4abNXzr_=E2s-HKf9n4zbx7SESo1OFLSmBKK3Zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_5C86C406-A795-41DC-A93E-9226EF3D682D"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HkaUhbYfrJA5USyGbNDDxCbimmg>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
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: Thu, 05 Nov 2020 18:50:51 -0000

All,

I have a few comments, focusing on the algorithm in section 3.


> 3.  Algorithm to Perform QNAME Minimisation
> 
>   This algorithm performs name resolution with QNAME minimisation in
>   the presence of zone cuts that are not yet known.
> 
>   Although a validating resolver already has the logic to find the
>   zone cuts, implementers of resolvers may want to use this algorithm
>   to locate the zone cuts.
> 
>   (0)  If the query can be answered from the cache, do so; otherwise,
>       iterate as follows:
> 
>   (1)  Get the closest delegation point that can be used for the
>       original QNAME/QTYPE combination from the cache.

Shouldn't that be just "original QNAME" since the QTYPE should be irrelevant
in locating zone cuts and delegation points?


> 
>       (1a)  For queries with QTYPE=DS this is the NS RRset with the
>            owner matching the most labels with the QNAME stripped by
>            one label.  The QNAME will be a subdomain of (but not equal
>            to) this NS RRset.  Call this ANCESTOR.

How confident are we that DS will remain the only RR with parent-side
authoritative data?  There was recently a proposal
(draft-peetterr-dnsop-parent-side-auth-types) to reserve a range for types
with this property, but I guess it was pretty quickly shot down.  If a new
authoritative-in-parent RR type is defined in the future, then would it
need to update this specification?


> 
>       (1b)  For queries with other original QTYPEs this is the NS RRset
>            with the owner matching the most labels with the QNAME.  The
>            QNAME will be equal to or a subdomain of this NS RRset.
>            Call this ANCESTOR.
> 
>   (2)  Initialise CHILD to the same as ANCESTOR.
> 
>   (3)  If CHILD is the same as the QNAME, or if the CHILD is one label
>       shorter than the QNAME and the original QTYPE is DS, resolve the
>       original query using ANCESTOR's name servers, and finish.

Throughout this section (and maybe elsewhere) the document should be
consistent with "the CHILD" and "the QNAME" or just "CHILD" and "QNAME".
My suggestion is to drop "the".


> 
>   (4)  Otherwise, add a label from the QNAME to the start of CHILD.

I'd like to see a lot more specificity here.  e.g., not just "a label" but
the next relevant label.

Also Section 2.3 talks about appending more than one label per iteration
in some cases, which isn't mentioned here.


> 
>   (5)  Look for a cache entry for the RRset at CHILD with the original
>       QTYPE.  If this entry is for an NXDOMAIN and the resolver has
>       support for [RFC8020], the NXDOMAIN can be used in response to
>       the original query, and stop.  If the entry is for a NOERROR
>       answer (either positive or negative), go back to step 3.  If the
>       entry is for an NXDOMAIN answer and the resolver does not support
>       RFC 8020, go back to step 3.

I find this step somewhat confusing as written.  My interpretation of it
goes something like this:

    if A and B then X;
    if C then Y;
    if A and not B then Y;

I would like to see it (if not the whole algorithm!) as a flow chart, or
maybe pseudo-code?

Wording like "an NXDOMAIN" and "the NXDOMAIN" is imprecise.  It really
means a cached response whose RCODE is NXDOMAIN.

This talks about RCODES NXDOMAIN and NOERROR.  What about others, SERVFAIL,
REFUSED?  Assumes they are never cached?

Since NXDOMAIN means there are no RRsets of any type for the name, I would
expect the (original) QTYPE to be irrelevant when looking for a cached
NXDOMAIN response, especially in the RFC 8020 case.

Instead of "If the entry is for a NOERROR answer (either positive or
negative).." consider "If the cached response code is NOERROR (including
NODATA)..."


> 
>   (6)  Query for CHILD with the selected QTYPE using ANCESTOR's
>       name servers.  The response can be:

Using one of ANCESTOR's name servers?


> 
>       (6a)  A referral.  Cache the NS RRset from the authority section,
>            and go back to step 1.
> 
>       (6b)  A NOERROR answer (either positive or negative).  Cache this
>            answer, and go back to step 3.

again consider "(including NODATA)" instead of "(either positive or
negative)".


> 
>       (6c)  If the resolver is doing RFC 8020 with strict NXDOMAIN, an
>            NXDOMAIN answer.  Return an NXDOMAIN answer in response to
>            the original query, and stop.  If the resolver does not
>            support RFC 8020, go back to step 3.

This would be better as:

(6c) An NXDOMAIN response.  If the resolver supports RFC8020, return an
NXDOMAIN response to the original query and stop.  If the resolver does
not support RFC8020, go to step 3.

> 
>       (6d)  An answer with another RCODE, or no answer.  Try another
>            name server at the same delegation point.  Stop if none of
>            them are able to return a valid answer.

This seems to be specifying (requiring?) some retry behavior.  I don't
know if or where resolver retry behavior is specified in other RFCs but
it seems like this document should not introduce new retry behavior, and
just leave it up to the implementation or other specifications.

Proposed text:

(6d) A timeout or response with another RCODE.  The implementation may
choose to retry step (6) with a different ANCESTOR name server.

Is it obvious what the resolver should do if retries are exhausted or the
algorithm doesn't produce useful results?  Fall back to non-minimized
resolution?  SERVFAIL?


DW