From nobody Fri May 1 04:41:29 2020 Return-Path: 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 BDBAF3A1041 for ; Fri, 1 May 2020 04:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 KuidhIU8pQ-c for ; Fri, 1 May 2020 04:41:26 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 698683A1023 for ; Fri, 1 May 2020 04:41:24 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id r7so7039718edo.11 for ; Fri, 01 May 2020 04:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1HEpVQmTCMrCH/a1Gn55TtQRbTPy24UqyFMtZ/lHXQ0=; b=WrjIciYAYoOdE0SWmaIU7Ih/GOoGa1Dt8KEL1ysynEuREfvs8dA8+EkvuY90cpMROL zTetHdQDfKf5XRJVWHSJvwpi827j0QeMHDUFguCgq3qzEkDnE5lZScXOj9bZXccchXHL Q3ddakXruVeP6v1+br6l6yb5API+pzDtnW8tWfcaie84g8QrhYplaffhMjOVqNgbG8r0 W/6ziOuTKfGtCH6Ig0xbUu6xsmtYTTev8auMrAnOQzGR9rmDKuMxscxbBRRvt37tRoI7 rgj7w/ecu3L71KlxsCYYtDjBOR8SihSN7s3r9/vKpbsIm4dauxLQlV5foBVdLMMpdj5W 3wGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1HEpVQmTCMrCH/a1Gn55TtQRbTPy24UqyFMtZ/lHXQ0=; b=iNoTubaybgtlHOPBb8CzUZ75IRj3laq7wb0XCPRZDEbjPeiaPSlBo03p66zxNY2n9b V/yerYk2XOM2F6H4VM+Zen8yUir88atva/t7ksuumEBQ3OKzWJPb9GOvXM1e7CdGIFBy H/dlvv9aPjUtHl61ZyDBMOkNWHqcTYjw3soRnkXHv6cMDZJFDpLnQsQk4QwWc4EDfjFW 52DFkoecDSvVUdl9e2aJun6Dhf9g/rvpE7bmnCyCeXjnTm2hXf1Ok2gdLH7RQEzp0HRJ uqrUrdkwprcNyjDg8cc9t4j+QHorPdVjchShumRQCSDISi03wbDgzgC9lW6mopdG1NeS rvFQ== X-Gm-Message-State: AGi0PuZUVl57m1Mrfn6xW4v6D2lN0YfI7wABQRmrWTbwy7jWkJfaFMQg xXVHW1nnB9K0IGXYqPvYj0OI52G9yjKEWNTV6AThHkta X-Google-Smtp-Source: APiQypJu3QEerGMoh+jANkyTivAwkScZhcvidnfIHhA2wkP5bVUjHTde1MfyBRiMr5T4TX1OvPvf2KkNEZKZkUpP9TA= X-Received: by 2002:aa7:d783:: with SMTP id s3mr3227647edq.64.1588333282392; Fri, 01 May 2020 04:41:22 -0700 (PDT) MIME-Version: 1.0 References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com> <129b0546-0123-30e0-cfca-8a66721ab046@nthpermutation.com> <6311BB51-4617-4316-A56D-EEA73A42D4A0@fugue.com> <2F9A828C-FC80-498D-B8C2-3DC804D75B0E@fugue.com> In-Reply-To: <2F9A828C-FC80-498D-B8C2-3DC804D75B0E@fugue.com> From: Shumon Huque Date: Fri, 1 May 2020 07:41:11 -0400 Message-ID: To: Ted Lemon Cc: Michael StJohns , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000015016405a494a9bc" Archived-At: Subject: Re: [DNSOP] Validating responses when following unsigned CNAME chains... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 11:41:28 -0000 --00000000000015016405a494a9bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon wrote: > On Apr 30, 2020, at 2:31 PM, Michael StJohns > wrote: > > Because an attacker can twiddle with a CNAME. So while the recipient see= s > a CNAME pointing at a validatable end item, that may not have been the en= d > name the publisher provided. I'd probably say unsecure though, as I don= 't > expect the client can detect bogus in this case unless there was a rule > saying this was a bogus configuration. > > Mike > > ps - What's the validation level for a secured CNAME that points at an > unsecured CNAME that points to a secured A record? > > I think that what we=E2=80=99re really talking about is that we have some= chain of > items where some items are provably not signed, and some are provably > signed and have been validated. Any items that do not match one of these > two criteria can be treated as =E2=80=9Cunknown.=E2=80=9D So: > > * If _all_ the items are provably signed and have been validated, the > answer sets the AD bit. > yes. > * If _some_ of the items have been validated, and others are provably not > signed, then the answer doesn=E2=80=99t set the AD bit, but an answer is = sent. > yes. > * If we have a partial answer because we didn=E2=80=99t get some answers,= is that > any different than the case where we got bogus answers? > Depending on what we didn't get, this answer would be Bogus or Indeterminate, per RFC 4035, Section 4.3. I think the practical effect of this is the same for any client of the resolver: SERVFAIL (or if client set checking disabled, return the partial answers with AD=3D0,CD=3D1). Shumon. --00000000000015016405a494a9bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon= <mellon@fugue.com> wrote:
On Apr 30, 2020, at 2:= 31 PM, Michael StJohns <msj@nthpermutation.com> wrote:

Because an attacker can twiddle with a CNAME.= =C2=A0 So while the recipient sees a CNAME pointing at a validatable end it= em, that may not have been the end name the publisher provided.=C2=A0=C2=A0= I'd probably say unsecure though, as I don't expect the client can= detect bogus in this case unless there was a rule saying this was a bogus = configuration.

Mike

ps - What&#= 39;s the validation level for a secured CNAME that points at an unsecured C= NAME that points to a secured A record?=C2=A0

I= think that what we=E2=80=99re really talking about is that we have some ch= ain of items where some items are provably not signed, and some are provabl= y signed and have been validated. Any items that do not match one of these = two criteria can be treated as =E2=80=9Cunknown.=E2=80=9D =C2=A0So:
* If _all_ the items are provably signed and have been validate= d, the answer sets the AD bit.

= yes.
=C2=A0
* If _some_ of the items h= ave been validated, and others are provably not signed, then the answer doe= sn=E2=80=99t set the AD bit, but an answer is sent.

yes.
=C2=A0
* If = we have a partial answer because we didn=E2=80=99t get some answers, is tha= t any different than the case where we got bogus answers?

Depending on what we didn't get, this answer= would be Bogus or Indeterminate, per RFC 4035, Section 4.3. I think the pr= actical effect of this is the same for any client of the resolver: SERVFAIL= (or if client set checking disabled, return the partial answers with AD=3D= 0,CD=3D1).

Shumon.

--00000000000015016405a494a9bc-- From nobody Fri May 1 05:10:20 2020 Return-Path: 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 ED6893A1123 for ; Fri, 1 May 2020 05:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 DiR5NPJ5xRld for ; Fri, 1 May 2020 05:10:16 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 3FF253A1122 for ; Fri, 1 May 2020 05:10:16 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id n17so7312125ejh.7 for ; Fri, 01 May 2020 05:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9i38ZMLtv4zg+VySVpKzGWfH6UyLCKQW6B0pN974pis=; b=htWjJ6X+g0PJT7bRBr6XXvFkM06YxvF/Z+wOMitzefZvLEtIRxQopu+auwdxnzToYD SqXzz7wC3dxB+P2yK02hGI+My56NsZLAXywXXPyDH1Dh/wnoNiG1+irFNcGAUBCSkc5m 2H8+oVX+dXdjTuHl/tF5hfzVCUeI4aJ3yNybOWKGVLlHQVwR+WFCcvsMQ7bVKXi+DSnR ieEMT0BbnCRGI0bPLWyIvAK+J3tCCUC6fJSJkSoJYyYGCx1pWslIN54Q6P7amKSU7f8f 0Fp+phNEtP39RRlnPqpj5peHSAGMjkUhtKvC6l2eEQqQDpgdSRgatGXNG5f7d51SalGz j9Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9i38ZMLtv4zg+VySVpKzGWfH6UyLCKQW6B0pN974pis=; b=Fff4RX9zYBwZ/QUC9ZAS066va7AEvfyUMvdMLfuZQZiDtsluSlmNJliTuXtX6xkazE /K952aYEKQBi6oRwlO/7/C3GPIMfBfP6GlpwPDWqgcok8GD8MCdUI3poldyQuBUrs6Ax d0EEko9E3qpJtmqpuz1429bEVWxQsyAci6deiNqZzwGrxv0L1quWRrrUH0gCeNUG0oFE P8fb6YUD/v7sH8zy9g+1IE32Mo4y4kAH76hpiz1lD2RSLABybEb8pM1gPtf8AFk8nH8K 8Wp2BU/gKeKWYfzZFlOh5TWBQCkg2Ko3vIdibPZ3eE75q0NzWiZ2sX2NCrbKg9xA5A26 iUKg== X-Gm-Message-State: AGi0PubysqrqzZfs88RUh+JqQLzL4RGUIGfSd9JTW8M4Cq5EI8evmPw0 /DPYys9V2Cbc1kwqmDib1j7KKW6nnQlEkv/E3DmweiEu X-Google-Smtp-Source: APiQypIg3APub5QpgtrOAyMiLSPomh6g2QCr8ZKsfGwtSWYbYOp1yTUCAr1TgYOmWrAqvO3gZgW0L3EkotOzeR2L7jw= X-Received: by 2002:a17:906:5347:: with SMTP id j7mr2234947ejo.173.1588335014489; Fri, 01 May 2020 05:10:14 -0700 (PDT) MIME-Version: 1.0 References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com> <9D709E73-83E1-40A8-8E97-CCBDBBDF80E8@fugue.com> In-Reply-To: From: Shumon Huque Date: Fri, 1 May 2020 08:10:02 -0400 Message-ID: To: Ted Lemon Cc: dnsop Content-Type: multipart/alternative; boundary="00000000000052b4fd05a4951018" Archived-At: Subject: Re: [DNSOP] Validating responses when following unsigned CNAME chains... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 12:10:18 -0000 --00000000000052b4fd05a4951018 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 30, 2020 at 11:14 AM Ted Lemon wrote: > > To be clear, I think that if we=E2=80=99ve been asked to do DNSSEC, we sh= ould > always validate what we can when the answer includes some data that is > provably insecure and some data that is provably secure and can be > validated. I just don=E2=80=99t think the specs explicitly say that, so I= =E2=80=99m > wondering if people agree with me on this. > Yes, I completely agree. Whether or not the specs (clearly) state this is debatable. I quickly scanned 4035 again, and I believe it is implied, from a combination of : * Section 3.2.3 saying _all_ RRsets in the answer section, and relevant RRsets in the authority section need to be authenticated before determining whether AD=3D1 can be set, and the further statement that the resolver MUST follow the procedure in Section 5 to determine whether the RRs are authentic. * Section 5 , which describes full chain DNSSEC authentication. This implies to me that _any_ RRset that the validator is processing needs to be subjected to the full DNSSEC validation algorithm to determine its security state. CNAME redirections aren't explicitly described, but are arguably covered by the above. The only mention of the CNAME case, is the exception to 3.2.3 that allows unsigned CNAMEs to be included in the answer and assessed to be authentic because they were provably synthesized by a signed DNAME. Shumon. --00000000000052b4fd05a4951018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 30, 2020 at 11:14 AM Ted Lemo= n <mellon@fugue.com> wrote:

To= be clear, I think that if we=E2=80=99ve been asked to do DNSSEC, we should= always validate what we can when the answer includes some data that is pro= vably insecure and some data that is provably secure and can be validated. = I just don=E2=80=99t think the specs explicitly say that, so I=E2=80=99m wo= ndering if people agree with me on this.

<= /div>
Yes, I completely agree.

Whether or not = the specs=C2=A0(clearly) state this is debatable. I quickly scanned 4035 ag= ain, and I believe it is implied, from a combination of :

* Section 3.2.3 saying _all_ RRsets in the answer section, and rele= vant RRsets in the authority section need to be authenticated before determ= ining whether AD=3D1 can be set, and=C2=A0the further statement that the re= solver MUST follow the procedure in Section 5 to determine whether the RRs = are authentic.

* Section 5 , which describes full = chain DNSSEC authentication.

This implies to me th= at _any_ RRset that the validator is processing needs to be subjected to th= e full DNSSEC validation algorithm to determine its security state.

CNAME redirections=C2=A0aren't explicitly described, = but are arguably covered by the above. The only mention of the CNAME case, = is the exception to 3.2.3 that allows unsigned CNAMEs to be included in the= answer and assessed to be authentic because they were provably synthesized= by a signed DNAME.

Shumon.

--00000000000052b4fd05a4951018-- From nobody Fri May 1 11:02:55 2020 Return-Path: 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 C54E43A18F5 for ; Fri, 1 May 2020 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 udQiYm6Q8PmM for ; Fri, 1 May 2020 11:02:46 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 35DC73A18F0 for ; Fri, 1 May 2020 11:02:45 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id z22so4297226lfd.0 for ; Fri, 01 May 2020 11:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=czjrowPNJp4pFwOC21Jy7kOoBA3/Xiy457OIc04gAHA=; b=FrxWjMCkDmg9RMsFCkp/IJzqRKQDTCLVPpn+WNQg6InofiUBW3tat7Oy/0EaAN5bS0 chcUMo/AlAV/OXdtgnbqRYWJXY7pKBwM5A3oldv+gTYqi0do6jNeDWPr3Wt3mvQRUcEA S6PDG2M2tGTjFu99YUMwzRa1JqKTvkMPD85N1chwFIGY0uLg91IN6x80joHXRAJ7Kfx+ ps/0J3T9gOFI4kZfgseHcYnD+Dz9LmtaILCOkLIcSwrn7QCZ7eP2X2MDeQPceK4oWNcj WnQYu4iq71GtHi2hEyJgfKLK/5HV1b3DACyf0QRFWnA8J6iXHW0LcQNB1WLvVCI4eePY A1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czjrowPNJp4pFwOC21Jy7kOoBA3/Xiy457OIc04gAHA=; b=g6GFIUtZNXNw7ii/Rlasye+kESIAGUQ5myH31B4Coidh95ih3fcLS0DxrU380wDj6J GHXL7wEN7e32k5EUpha4ZJYSvBA1fMUvvsgeYq0SQVkD7byMDejgV+Et3m515jnRMK3l dEQQ16c5e0WEeGt3GWI/9ZbtowdkY9Mklxk+/+LeJKfx1nh2Rw/yPQNr99oewE2joEyD L3XDoQt0dyYPSxCoq/kIaAXnifdQnf+CKwh4d78wzFtFuIcWxPddOyLmU5wvlZkXnRJB qkQXCDOjaHVZsqP5gNwvU6aokgFiAwJhHGr9LD8DRTZALfU2iZrfl9uhjd+5kcVyXcdN 6gFg== X-Gm-Message-State: AGi0PubHrspndQiUp9tKqPod1iy6m3Y3F3/eQNnRwcJt5wXNgY9SzOCt 1zDZmanqqAYTMfXDENb1vawIDVPVVmTd2PoGlX4tEmA7 X-Google-Smtp-Source: APiQypIRwr1lqQZ8xYnw6tBeGKsGkUKiOzeU7VUTc7RZw+4sh1XAj5nAwyTKtSqpj8MFrqE1LKJSKLkksx/FpjUTcUY= X-Received: by 2002:a19:4b90:: with SMTP id y138mr3148435lfa.39.1588356163812; Fri, 01 May 2020 11:02:43 -0700 (PDT) MIME-Version: 1.0 References: <20200501014428.427E818950D7@ary.qy> In-Reply-To: <20200501014428.427E818950D7@ary.qy> From: Bob Harold Date: Fri, 1 May 2020 14:02:32 -0400 Message-ID: To: John Levine Cc: IETF DNSOP WG , Wes Hardaker Content-Type: multipart/alternative; boundary="000000000000ebdaa705a499fcbc" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:02:52 -0000 --000000000000ebdaa705a499fcbc Content-Type: text/plain; charset="UTF-8" On Thu, Apr 30, 2020 at 9:44 PM John Levine wrote: > In article you write: > >Yep, I suspect some of the bigger TLDs probably couldn't opt in to this > >draft simply because they're full of, um, "history". Until that history > >is cleaned, they probably couldn't deploy it. > > It's not just history. All of the nominet TLDs and many Verisign TLDs > have signed A records that are clearly deliberate. There's also a fair > number of TXT records named zz--zz. that have some sort of info > about when the zone was updated. > > I think it's benign to allow any sort of record as an immediate child > of the domain, since you need to go two levels down for split zones. > That handes the nominet and zz--zz cases. > > R's, > John > > Is there any chance that a user trying to reach https://example.com could get the orphan glue A record for example.com instead of the A record in the real zone? (Just trying to think of cases where orphan glue might make a difference.) -- Bob Harold --000000000000ebdaa705a499fcbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Apr 30, 2020 at 9:44 PM John Levi= ne <johnl@taugh.com> wrote:
In article <yblr1w43= 8fb.fsf@w7.hardakers.net> you write:
>Yep, I suspect some of the bigger TLDs probably couldn't opt in to = this
>draft simply because they're full of, um, "history".=C2= =A0 Until that history
>is cleaned, they probably couldn't deploy it.

It's not just history.=C2=A0 All of the nominet TLDs and many Verisign = TLDs
have signed A records that are clearly deliberate.=C2=A0 There's also a= fair
number of TXT records named zz--zz.<domain> that have some sort of in= fo
about when the zone was updated.

I think it's benign to allow any sort of record as an immediate child of the domain, since you need to go two levels down for split zones.
That handes the nominet and zz--zz cases.

R's,
John


Is there any chance that a use= r trying to reach https://example.com c= ould get the orphan glue A record for exampl= e.com instead of the A record in the real zone?
(Just trying = to think of cases where orphan glue might make a difference.)
--=C2=A0
Bob Harold
=C2=A0
--000000000000ebdaa705a499fcbc-- From nobody Fri May 1 11:20:42 2020 Return-Path: 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 1A4EE3A1948 for ; Fri, 1 May 2020 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 YJWRjJy9ivVS for ; Fri, 1 May 2020 11:20:34 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 D8BE83A1945 for ; Fri, 1 May 2020 11:20:33 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id ep1so5156867qvb.0 for ; Fri, 01 May 2020 11:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=n0Q/b2ZdP3DJFS8NWx2l128hKkVJV3TNGTFq3pgi9o8=; b=lN1LnIayEYVbvg+QVyo8KsaNDN7m0ip6DSR/BdYdvfnukQYfm6AFyhJqtIfaPOPRia N+ps+STUT7lX3/QctjsUC7RTkwvpgeOOSqEE2+A3N+c/3bdzfWB23OZxWaa9t6ka5DaL 2WGnamhgnSUWL/SX1RsJfLDL7jQizw+dgttlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=n0Q/b2ZdP3DJFS8NWx2l128hKkVJV3TNGTFq3pgi9o8=; b=Gf3tRg1DEHvJRVN7UBK089EnK1113/GaF+VI/Xu+js16DFYoqF71H7UWDesRRtzq0M EmtanHIEvZq6Su0hcymX0AjSjtTpUyGnufWtNMivgMp/070vvLrQfSwfYXiRj5WYMJIg 5Ka3qA5iqdvPO/729UbIHYpJ3zhLCxTHGBAh2vxvmdVD1CI65msEE6+nqpfmFq2h2dg9 AFEi7NzVYcA1u/+jCAASePnmW3vUqcaFlWqo9XwrMEbhO80wb+uZb4Loxwcm7KNqTkET QDnasTW89df+KpZn/gdRLNAV9mfKH9gcJjfhQgWsVUc4XZFGsKDJTz/dkRHG39siVxSL D+SA== X-Gm-Message-State: AGi0PuaQOkaabDLyIb23QlQgmjq+sjzWPt23FMz3txRCeasbUUOkuTD4 PvCh1uq56Ypn2PJeReDhOjceTkqT0hmxGdgZ X-Google-Smtp-Source: APiQypK/WlMOImsISTuDTlGGENGoKS2oUwbBbY+p1j+uMba3EyYsfEF7ct8TzMAVjrsXVqLbPP3VAg== X-Received: by 2002:ad4:4462:: with SMTP id s2mr5214940qvt.221.1588357232681; Fri, 01 May 2020 11:20:32 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:c0aa:fef0:9558:611e? ([2607:f2c0:e784:c7:c0aa:fef0:9558:611e]) by smtp.gmail.com with ESMTPSA id d23sm3111082qkj.26.2020.05.01.11.20.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2020 11:20:31 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D92E5546-7309-4CA4-866B-FCC302F3AD32"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 1 May 2020 14:20:29 -0400 In-Reply-To: Cc: John Levine , IETF DNSOP WG , Wes Hardaker To: Bob Harold References: <20200501014428.427E818950D7@ary.qy> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:20:39 -0000 --Apple-Mail=_D92E5546-7309-4CA4-866B-FCC302F3AD32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bob, On 1 May 2020, at 14:02, Bob Harold wrote: > Is there any chance that a user trying to reach https://example.com = could get the orphan glue A record for example.com instead of the A = record in the real zone? If the A record is orphan glue, there is no real zone (by being = orphaned, it's no longer really glue). So there's not just a chance that the A record from the parent zone = would be returned, it's expected behaviour. Joe --Apple-Mail=_D92E5546-7309-4CA4-866B-FCC302F3AD32 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXqxobQAKCRA0jwy9hlI6 LFS/AJ44d9x2qrsYltmFtkh6KaMPS7AqzwCgmA5GnLaVDIR6Ru9oErWbqawH/mo= =VE/R -----END PGP SIGNATURE----- --Apple-Mail=_D92E5546-7309-4CA4-866B-FCC302F3AD32-- From nobody Fri May 1 11:23:46 2020 Return-Path: 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 9EE643A1948 for ; Fri, 1 May 2020 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dQXNc2D7; dkim=pass (1536-bit key) header.d=taugh.com header.b=W+2H5gps 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 UeUdAPSB8aCq for ; Fri, 1 May 2020 11:23:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6D0FD3A1945 for ; Fri, 1 May 2020 11:23:39 -0700 (PDT) Received: (qmail 29631 invoked from network); 1 May 2020 18:23:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=73bd.5eac6929.k2005; i=johnl-iecc.com@submit.iecc.com; bh=lmHSG0rLz9lGju3vqLk6CASaBiZjKTff8JeOnZFC6zU=; b=dQXNc2D70rGcBYZGw7cHOTLtaeWQx7DyMwHJsfxIfLALHlAJZhDMPKxEMFwNGba7y5Wdm9b7F2S0m4HDjhopmR22UkSwlsrIv5vTi8IyfSpZgcdePamkr+IWC9BBUE7rarkzn1w8NDixzHTKHYOdJWJa0/Wc6ejOyN7KHYnkQ8Fun5VuWpYdWUhS63Jl1e5vYoUsI0IAijOrbj1yrPDiQuH3RG8TsaOZehyLrF56DKpPl9wfsIY7Mvyn6ePXRgKA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=73bd.5eac6929.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=lmHSG0rLz9lGju3vqLk6CASaBiZjKTff8JeOnZFC6zU=; b=W+2H5gpsP07rfwlSiKpfQaVwiLgyVz1RERK3DFz75bsuv9qG9Kgcv8I3Lup4hiRjZNdAFFyYrjqsqYpd0/w6CQwBJKhQO5xzfQ9/9oyOWe6+3BEGaUhdIBtQwbXIPngg6fZCf1Yg9BhjAnezRjq3oyM07JTkoqDTSi94CwRVh4VYdmpoinTWDK/8rwFABOZqsQlEI9xuLXol0qV1Ac+hmsDIJse20dqju9vc8U7MDO1gwSNFWJJ1Bcue3DVszMYe Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 May 2020 18:23:37 -0000 Date: 1 May 2020 14:23:37 -0400 Message-ID: From: "John R Levine" To: "Bob Harold" Cc: "IETF DNSOP WG" In-Reply-To: References: <20200501014428.427E818950D7@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:23:44 -0000 > On Thu, Apr 30, 2020 at 9:44 PM John Levine wrote: >> I think it's benign to allow any sort of record as an immediate child >> of the domain, since you need to go two levels down for split zones. >> That handes the nominet and zz--zz cases. > Is there any chance that a user trying to reach https://example.com could > get the orphan glue A record for example.com instead of the A record in the > real zone? > (Just trying to think of cases where orphan glue might make a difference.) Only if the zone had NS and A at the same name, which would be pretty broken. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 1 11:32:34 2020 Return-Path: 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 D7FB93A1965 for ; Fri, 1 May 2020 11:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 dPPQb4RcgYTl for ; Fri, 1 May 2020 11:32:25 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 1C1753A1963 for ; Fri, 1 May 2020 11:32:24 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id i136so5994289qke.10 for ; Fri, 01 May 2020 11:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w7QXqbczKQE1X9FBkghToUWQNxttOwUUx5FS7AoscF8=; b=O2avNkkbPXqPTFGKXY3Fr7p4JfXd2Xnt+8evtmxXMT3BtpGqJHOEWH6OldE1amQoqf OdDm5SNysLrcS4jd23vm9bTBPAanOINja5mnEJe089SM5vinGKZjHbmiC0QgsuCLP1S7 WkI1+UoNNSU1s7DrrfCG6N9WOMYPhcB7K6m0k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w7QXqbczKQE1X9FBkghToUWQNxttOwUUx5FS7AoscF8=; b=MkUI7yYPPGrc8x4kvg9Aw916yKPDS2E7sxOtJBbWBF0eU+x7Zvij/QQZnlIaiS22ip BNOTGL8AQMTcHRBwJVU0ZNMojT+2OYfVtz9bTrnQbuXn+5aeMT3WRmE1TfBHj7tt4jgX BpSY4DKp1WzYCVM8RRlJSiHEn9w5J1AZauao0vi7baiEUl4qxcS7fSmeKojm3WJyMdbL cHjOutr+s6cfN2XZkUkiKV9g6kPPPVD6J+7rUDyok/XO32sv2ygIoz3PdCbouRnyxDnk XDCuEslhLOYaxAXI0DYmBQvRgPATqOEcnI3h/pcXMiB5eCqm7x+6JTQZEfHk0iSQAZZp Ud7g== X-Gm-Message-State: AGi0PuZXrVokQr786Mt3jxXXnMZLgo2kKtBv8ppBTeYS4mtCLTLojVNd o+/vPK0FA4dd4F7dHRw/oPF/YcHpRZAQQAGr X-Google-Smtp-Source: APiQypLHSeS5j5ij/SFgRb2KsjxBPy42C1dNXPcNMIpmSptDos2TajGDWBGReoerfZo4kVVa++AFYA== X-Received: by 2002:a37:4e08:: with SMTP id c8mr3074692qkb.60.1588357942568; Fri, 01 May 2020 11:32:22 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:c0aa:fef0:9558:611e? ([2607:f2c0:e784:c7:c0aa:fef0:9558:611e]) by smtp.gmail.com with ESMTPSA id g8sm3229043qkb.30.2020.05.01.11.32.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2020 11:32:21 -0700 (PDT) From: Joe Abley Message-Id: <63868088-59C8-44A2-9FB3-EC17EC23667D@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_9A0DFB78-BF8D-4204-9EF2-60A45EA48D96"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 1 May 2020 14:32:19 -0400 In-Reply-To: Cc: Bob Harold , IETF DNSOP WG To: John R Levine References: <20200501014428.427E818950D7@ary.qy> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:32:30 -0000 --Apple-Mail=_9A0DFB78-BF8D-4204-9EF2-60A45EA48D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, On 1 May 2020, at 14:23, John R Levine wrote: >> On Thu, Apr 30, 2020 at 9:44 PM John Levine wrote: >>> I think it's benign to allow any sort of record as an immediate = child >>> of the domain, since you need to go two levels down for split zones. >>> That handes the nominet and zz--zz cases. >=20 >> Is there any chance that a user trying to reach https://example.com = could >> get the orphan glue A record for example.com instead of the A record = in the >> real zone? >> (Just trying to think of cases where orphan glue might make a = difference.) >=20 > Only if the zone had NS and A at the same name, which would be pretty = broken. Oh, interesting. In a sense, a glue record with the same owner name as a zone cut could = be equivalent to a glue record with an owner name that is subordinate to = a zone cut. I don't have enough of the spec in my head to know why they = would definitively be different from the protocol perspective. I realise = it's not normal, but I don't know that it's prohibited. I definitely don't know operationally how different DNS or registrar = software implementations treat that case. I don't think the registry = systems I'm familiar with allow host and domain objects with the same = name to coexist, but I realise I could quite well be wrong. If I had any more energy to spend at the keyboard today I might be = tempted to find out :-) Joe --Apple-Mail=_9A0DFB78-BF8D-4204-9EF2-60A45EA48D96 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXqxrMwAKCRA0jwy9hlI6 LDX0AKDFurZePGAdZjc3AviIbiC9lbjYogCfYDtQRZnlo3GcjS5QfcX9tTg+LEY= =iKp+ -----END PGP SIGNATURE----- --Apple-Mail=_9A0DFB78-BF8D-4204-9EF2-60A45EA48D96-- From nobody Fri May 1 12:18:32 2020 Return-Path: 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 EB7923A1A48 for ; Fri, 1 May 2020 12:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=wSHSpxdt; dkim=pass (1536-bit key) header.d=taugh.com header.b=kZMN5Mv+ 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 bl-4uFXUqQNR for ; Fri, 1 May 2020 12:18:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6BEC63A1A46 for ; Fri, 1 May 2020 12:18:27 -0700 (PDT) Received: (qmail 55687 invoked from network); 1 May 2020 19:18:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d983.5eac7601.k2005; i=johnl-iecc.com@submit.iecc.com; bh=O5Y2Z5R/ivRIGS8pFR4H4KzNL7ilnXXdR0sJjTu73BE=; b=wSHSpxdtxgptwyafkV73MR10kKUSBCwg1sY2+l5UugunbX8pdIRaeTYTB8vIKc2O5D8WrJ0fGneSYh807EeEK8kYyQdGohyML6AftkYMF3LGCsUDMDTX5Sz9EXsLMvSCVpJ9OrfR75aH3qD6meHUxJsyrhqDTZFYjrL7sLTNGlNQTEA+t+fQ+GI8QGsS/BiUsPN23FYfr+BJtt8gZGN8hjnkMOI3TwJJChgG0pzza6QuYa7M8pygL7/Mqb2ci72f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d983.5eac7601.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=O5Y2Z5R/ivRIGS8pFR4H4KzNL7ilnXXdR0sJjTu73BE=; b=kZMN5Mv+DCj8+IfNk51dK0iAQ1DoA0Io3B1SYimMsc7rZToOsUHsWEYoLjsM+WjdWwBNxBxVT9m7ovOuyBdz0sqDaNj4jeuWnwLznvwc2UWQDCUz0/Xdh37FL97vXhBrq92IvIl9ls3/YQAPMXsuLC4y8MO8JNwYutUAT8S8mrhod6Ae3cwQO+QG2IJhfwUrEwv39tTS+i/wraRWiCptdo/BlKjg4ABlGq1lzSbY0BF3c1melaKacvQW+uOMm2ch Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 May 2020 19:18:25 -0000 Date: 1 May 2020 15:18:25 -0400 Message-ID: From: "John R Levine" To: "Joe Abley" Cc: "IETF DNSOP WG" In-Reply-To: <63868088-59C8-44A2-9FB3-EC17EC23667D@hopcount.ca> References: <20200501014428.427E818950D7@ary.qy> <63868088-59C8-44A2-9FB3-EC17EC23667D@hopcount.ca> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 19:18:30 -0000 > In a sense, a glue record with the same owner name as a zone cut could be equivalent to a glue record with an owner name that is subordinate to a zone cut. I don't have enough of the spec in my head to know why they would definitively be different from the protocol perspective. I realise it's not normal, but I don't know that it's prohibited. > > I definitely don't know operationally how different DNS or registrar software implementations treat that case. I don't think the registry systems I'm familiar with allow host and domain objects with the same name to coexist, but I realise I could quite well be wrong. I'm pretty sure I've never seen it in any TLD file. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 1 16:51:24 2020 Return-Path: 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 8CF0C3A1DB7; Fri, 1 May 2020 16:51:15 -0700 (PDT) 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 gqfmpjlahEx3; Fri, 1 May 2020 16:51:12 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D773A15AA; Fri, 1 May 2020 16:51:11 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 6AD562B014; Fri, 1 May 2020 16:51:10 -0700 (PDT) From: Wes Hardaker To: Joe Abley Cc: Mark Andrews , Wes Hardaker , Tim Wicinski , dnsop , dnsop-chairs References: <7262A449-1171-49E8-BDF6-69601DB034EE@hopcount.ca> <8F265AC8-9369-40B6-9AE8-C8D8ED190320@isc.org> Date: Fri, 01 May 2020 16:51:10 -0700 In-Reply-To: (Joe Abley's message of "Thu, 30 Apr 2020 20:07:12 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 23:51:22 -0000 Joe Abley writes: > Anyway, I am fairly confident in saying that there are legitimate, > normal operational processes that can result in orphan glue, and that > it's not correct to infer that they all exist for reasons of poor > hygiene. For the record: I certainly (and I doubt Paul) envisioned that this draft would be useful and deployable to every possible TLD/registration-point. It, hopefully, will be desired by some. Though ones that want to "convert" hanging glue in their zone to something that this draft could accommodate should be able to insert a new zone NS and delegate to their own servers with a new zone (and new dnskey). The odd corner case someone mentioned is if the NS record was pointing to company.example, rather than ns1.company.example or something. Then there is the interesting discussed question of whether company.example can delegate an NS to its own name [curious minds want to know]. -- Wes Hardaker USC/ISI From nobody Sat May 2 07:09:31 2020 Return-Path: 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 1E8BA3A1277 for ; Sat, 2 May 2020 07:09:27 -0700 (PDT) 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 aqPrMkyZUvaa for ; Sat, 2 May 2020 07:09:25 -0700 (PDT) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 282A53A1279 for ; Sat, 2 May 2020 07:09:25 -0700 (PDT) Received: from PFE112-VA-1.pexch112.icann.org (out.east.pexch112.icann.org [162.216.194.7]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 042E9MGd011104 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 2 May 2020 14:09:23 GMT Received: from PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) by PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 2 May 2020 10:09:18 -0400 Received: from PMBX112-E1-VA-1.pexch112.icann.org ([162.216.194.24]) by PMBX112-E1-VA-1.PEXCH112.ICANN.ORG ([162.216.194.24]) with mapi id 15.00.1497.006; Sat, 2 May 2020 10:09:18 -0400 From: Roy Arends To: dnsop Thread-Topic: new version submitted for draft-arends-private-use-tld Thread-Index: AQHWIItE05+QJLlxTkKndWwLM3CT3g== Date: Sat, 2 May 2020 14:09:18 +0000 Message-ID: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> 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.47.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_9EBE6BDB-6DF1-4459-8926-B877904A7742"; 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.676 definitions=2020-05-02_07:2020-05-01, 2020-05-02 signatures=0 Archived-At: Subject: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 14:09:28 -0000 --Apple-Mail=_9EBE6BDB-6DF1-4459-8926-B877904A7742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Ed and I just submitted a new version of our private-use TLD draft.=20 https://www.ietf.org/id/draft-arends-private-use-tld-01.txt This draft has substantial more information than the first draft. It = explains that a private-use namespace does not exist, why it is needed, = and how a namespace aligned with the user-assigned alpha-2 code elements = in the ISO-3166-1 standard can be used as private-use namespace. It contains plenty of examples of how user-assigned code elements are = used in the field, including other ISO standards, the UN, UNICODE, = CAB/forum, and the IETF itself. This new version came about after fruitful discussions with peers inside = and outside the IETF. Most discussions were productive. This has lead to = the removal of the advice/example to use ZZ, as it was distracting from = the point of the draft: these two-letter top level domains are available = for private-use.=20 Warmly, Roy= --Apple-Mail=_9EBE6BDB-6DF1-4459-8926-B877904A7742 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Aw ggWaMIIEgqADAgECAhAC8rGsZZEVwDggOu7Mu2E3MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xOTAxMTcwMDAwMDBaFw0yMjAx MTcxMjAwMDBaMIG7MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUm95IEFyZW5kcyAoMjAxOTAxMTcpMSMwIQYJKoZI hvcNAQkBFhRyb3kuYXJlbmRzQGljYW5uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALIUjLA9qXUR1zgYOLSdC8rPQqrXJlVnshs8UWZfAu1Iwuj5jALoUWuvF+YWEBZZkgFuLbY5 ocPBgrnxv3l8rgCyoJMtf89edKCFOdHEsv+K3/9EG+gqlYm9GRg+cxqCq7WIPhbnawBOkSkpoT/J MxEMTIBLKEroumaZsM7XcY1vgr+vOxbBJ/+aO16BynB3/YbqR4zvQR8xOiPhfgl/Brg6fRtGm47h gU0DKrQ8MQqKaHhrWXjvQvnr0VzGnxANbjUK1ggVFXkIO4+7szB56Acp7ERrmxCYqYVK+7en9GNx IBnmN6lnERmvcfRyb0H8HPgWLkKH8BI4m/Zsko5JyP0CAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBSxk+GbMVrJevh7fdqWM6pZVXFyjTAMBgNV HRMBAf8EAjAAMB8GA1UdEQQYMBaBFHJveS5hcmVuZHNAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB5pbggxD+KqyTcLnhSvXAI 0f3pRnss8vUiAuNM1coPPDTPa3O8z9mPKFYCzIiZ7yUcSFHwJGzmvpYHCm7cy7yhG9YKDl6TBgAi tbBMQa1WJ1bPViAMQrxVPVXZ2xJO8mWRGZzK/64r2+azahVS9c0Szu73LSgJReoTraJnZqYUfRlF Uvz+e1XA3ClFmcXTH2ufUQsMhQ94f2j5p2WZtNDBAKkVBQYw2zrVn9doNSMQGfDg5eNJrj1iRo0g sVAvVlgsTlt/wuWnEnz4D491ToWE/biLxS3DL7DrqWgixBid3MFpz575Xdg1mBFFSXCs8vQItF2p Ebs5HeLkGxdhkY6/MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAykwggMlAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAC8rGsZZEVwDggOu7Mu2E3MA0G CWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0yMDA1MDIxNDA5MThaMC8GCSqGSIb3DQEJBDEiBCAWUiUw4Xx4kvo67IdGJeKCmkW/ze/H1XjA DdLIjr+5oDCBiAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl cnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7YTcwgYoGCyqGSIb3DQEJEAILMXugeTBlMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7 YTcwDQYJKoZIhvcNAQEBBQAEggEAAzQVCYwHdJRHCtYMDRxiH00pQ0IpwqqIftRKmaw9T0L00dln 586bikPioL+sNoVjvmcwqtotoJ3ScJ+EWRbfTLk1xPmh1cCdxH5fMTtpFk158xapCdIelY0qKwo1 A7GBVok0K0s7ONpab2XwZsT64GgNFoN6/s+udp8DLvlhSXAjZa+Y1FY4P6PF8cg45DU6Nt2klww+ AUbJ/Hz/FPWPwANO1Hs8+dYxNPp/i8RDfD5IOCBGMSOJ9RTaQ6DPhgFxWs5Z1D735ieum9diQmUJ sNCwvwJfMiojVez5v7KUFkUtdhaBnm3M3KG0m/OdQy5nLPaXsyYf/pz15POa2cvLmAAAAAAAAA== --Apple-Mail=_9EBE6BDB-6DF1-4459-8926-B877904A7742-- From nobody Mon May 4 05:20:14 2020 Return-Path: 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 9F8F33A0841 for ; Mon, 4 May 2020 05:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 MBhqJxSBHFLl for ; Mon, 4 May 2020 05:20:12 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 1355F3A0843 for ; Mon, 4 May 2020 05:20:12 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id s3so13686700eji.6 for ; Mon, 04 May 2020 05:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4OAneTeYF8rdlWRhXEj22zXXHof4NuOH9Chh2o8cdo=; b=Q5/qbo+d0ku81ULXFO7AlhBXc3Jn9NcixxrNb7gx1Q37bLJyugo6B9LCeesSKw0LhQ O//vsXCZ9ZabqFzbabnloAzwXJYFYZda3AOAInrrOOqj9nJtvfBwuP1Y8qgcPSRbykke MyBDI6hO7qIPXIclxJrPzXqF9HXSsBaEcyXZpCkRm5R5iIGYC+/neYPULOaxFQuFpb6J LCURtbD+qKJnZLa2fgWafsu59+t+YGt/Gr3qV2+b1gZIZqWr09UeLxDQ3D1jNmddCdWw IWz6jrNjM8Lqv5tNQXArrdknQbKRxxRE8w31C9JHmAR+JmZXaRgYWhPUpFAMfD7pl2Ox yhGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4OAneTeYF8rdlWRhXEj22zXXHof4NuOH9Chh2o8cdo=; b=NOr8BGC1lgZ494SF3uXT93zi2PAffCesBwnjY2wgR/ePdykOWO8sZx4k8Z6tSpT8f6 Oi9Iw68sR2hZ80Ov3bEiSQEJbxbhX0g8bHdxZ5BXF5U0W67Uizq9MxG0eYpJX1QPppwU HKr/8rDovcR/+/qh73B+lRf0vfGqgFRBA9LvNJ/vuTImry/B2+5Hq21NDOEIYhEPqRcu 68vg+dGh741CdUzxbTfuRdM3exysWicl2fVu27Y9kOeSivFi+vX8s64+ZmxwO+a01ILw L9oD7QAF8bZTGPfUGDMP3qHCdlbx+7PlimCCR/LTVv8jVc32ET0Pmf8+Y7qJhuCVf0qb t2Rw== X-Gm-Message-State: AGi0PuaodstIPRSnsZEoAZFEataKJssrYn6riupgH6AeFxLLEuNdzko+ Z6kq5+vqzD5IaH1x17IYDfuOTiXabcmeMC+UQLw= X-Google-Smtp-Source: APiQypJSLYn30wjtXxfjgtsJFv1j3mgSNEw+mYCN0lYauwjfqyQ5HVvGqS8tpico2xCyojcJxGGQ7xESm6uabdbE2ok= X-Received: by 2002:a17:906:131b:: with SMTP id w27mr14581253ejb.230.1588594810457; Mon, 04 May 2020 05:20:10 -0700 (PDT) MIME-Version: 1.0 References: <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> In-Reply-To: From: Shumon Huque Date: Mon, 4 May 2020 08:19:57 -0400 Message-ID: To: Daniel Migault Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="0000000000005e90fc05a4d18d1f" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 12:20:14 -0000 --0000000000005e90fc05a4d18d1f Content-Type: text/plain; charset="UTF-8" On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault wrote: > Hi, > > I discovered this draft during the interim meeting. We had similar > thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our > motivation for supporting this work are that it 1) improves the > reliability of the resolution as well as 2) removes the temptation to > (inadvertently) break resolution by fixing in appearance a > misconfiguration. In other words it eases the operation. > Thank you Daniel. Will read your draft shortly, but in the meantime .. Your note reminded me of the question you asked during the interim meeting about why we can't just use the DS TTL as the revalidation interval. Our response was that the main impediment was that DNSSEC deployment is far from ubiquitous, but also that there is no reason that it could not be factor, when available. Here's what the draft already says about DS: Technically, if both parent and child zone are DNSSEC [RFC4033] [RFC4034] [RFC4035] signed with a corresponding secure delegation between them, then expiration of the DS record will cause revalidation of the current child zone's DNSKEY set, so responses from the orphaned child nameservers would no longer be trusted. However, delegation revalidation is still necessary to locate the current nameserver addresses. In practice, the DS and delegating NS TTL do not always match. COM for example uses 2 day NS and 1 day DS TTL for all its delegations. So where DS is lower, that could be used as the upper bound. We'll queue up some text on this subject for the next revision of the draft. Shumon. --0000000000005e90fc05a4d18d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 29, 2020 at 11:57 AM Daniel M= igault <mglt.ietf@gmail.com&g= t; wrote:
Hi,=C2=A0

I discov= ered this draft during the interim meeting. We had similar thoughts in our = "Recommendations for DNSSEC Resolvers Operators". Our motivation = for supporting this work are that it=C2=A0 1) improves the reliability of t= he resolution as well as 2) removes the temptation to (inadvertently) break= resolution by fixing in appearance=C2=A0a misconfiguration. In other words= it eases the operation.=C2=A0

= Thank you Daniel. Will read your draft shortly, but in the meantime ..

Your note reminded me of the question you asked during= the interim
meeting about why we can't just use the DS TTL a= s the revalidation
interval. Our response was that the main imped= iment was that DNSSEC
deployment is far from ubiquitous, but also= that there is no reason that it
could not be factor, when availa= ble.

Here's what the draft already says about = DS:

=C2=A0 =C2=A0Technically, if both parent and c= hild zone are DNSSEC [RFC4033]
=C2=A0 =C2=A0[RFC4034] [RFC4035] signed= with a corresponding secure delegation
=C2=A0 =C2=A0between them, then = expiration of the DS record will cause
=C2=A0 =C2=A0revalidation of the = current child zone's DNSKEY set, so responses
=C2=A0 =C2=A0from the = orphaned child nameservers would no longer be trusted.
=C2=A0 =C2=A0Howe= ver, delegation revalidation is still necessary to locate the
=C2=A0 =C2= =A0current nameserver addresses.

=
In practice, the DS and delegating NS TTL do not= always match.
COM for example uses 2 day N= S and 1 day DS TTL for all its
delegations.= So where DS is lower, that could be used as the upper
bound. We'll queue up some text on this subject for the nex= t revision
of the draft.

Shumon.

--0000000000005e90fc05a4d18d1f-- From nobody Mon May 4 05:44:14 2020 Return-Path: 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 989B53A0848 for ; Mon, 4 May 2020 05:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 4kqLMoiVlDJA for ; Mon, 4 May 2020 05:44:10 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 B35E93A0845 for ; Mon, 4 May 2020 05:44:10 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id g2so10971937vsb.4 for ; Mon, 04 May 2020 05:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3GcCue49r7zCWEOiGH76c4mzuyvmv8ZnsldF5U8/t9c=; b=Vk8dsNkrv0O7rrIEafoAe5hpg92W4dq2E3PcRWxNIhCUsp4JVYK9tH80qv/l2d1nqB KYkWVUeMLk+a+L0ke72J6rFnc4ybgzhAYruxnF4L93CmDQ9CdNqpzmLh6DynwoCJEQnS Rf/uOPsp6dQ9sVpjSaAaiJ9nHEQrluRRQI5bbf9qf/yuNncmtNL24dDKl4LewYHkp4bm MPHt+wG9uVRO7qBpvx2nCvesWkAm06J/VqkILb0MCPkVzF3qhkCn+MQaHKjZIUqZ3JS1 iAa3C8eoc61shs1BqcS/EL4u2xEFnngLT5lZ+W0k/a1X4KcLoYWJRGxqAQaisxO8HhG6 GQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3GcCue49r7zCWEOiGH76c4mzuyvmv8ZnsldF5U8/t9c=; b=EwynUi3qUOBgLf41iLdnozZ4kKvwEXOBlILG9yDY8Wf1kY6QnXz03Sg0MId76I8RAe +O29MnKVpOveMMtAgZErPEEmuR3gIZ5onIB6tABkywbx6rgoxiuwZSI66s0KNj92OQnD hIoMfZ3h0562TlrDHq0BQ28zXAQCYmgzIOu4DnFLVwDuZFm2VTsEhsqHN4I3M/aSijrg MVkntxSpanpweVD/4ncPpAIKipuZBC+hFk1J1+ejLgkAMDKFxnqE1xNXzG7LE8zvBw20 o0V3OI/1owzDjN8GOJtp61/prVl0MdPQTo7PHzLFZ2aaVWz+RWy4KBfumoWDLj12CTt9 DGtQ== X-Gm-Message-State: AGi0PuZdlOwUa70TqqDlaWrFShCcdiGjoLs9EOVfU7EKW7DL1w4zStKa /xPpjGO/mgND6cy1SlqbYjHcibS1dzqRLxVvMRo= X-Google-Smtp-Source: APiQypIcZghIs43kMHIZ4vWL3UCoNuZ9NX0rLamtD1IEX3W/oiRg0Lc5pDBBW53pWQDJMTCBea8lmklF3rywPg02Mto= X-Received: by 2002:a05:6102:208f:: with SMTP id h15mr12352997vsr.69.1588596249714; Mon, 04 May 2020 05:44:09 -0700 (PDT) MIME-Version: 1.0 References: <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> In-Reply-To: From: Daniel Migault Date: Mon, 4 May 2020 08:43:58 -0400 Message-ID: To: Shumon Huque Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="00000000000027e24405a4d1e38d" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 12:44:13 -0000 --00000000000027e24405a4d1e38d Content-Type: text/plain; charset="UTF-8" Thanks, that will be appreciated. I will make sure the two documents are synchronised. Yours, Daniel On Mon, May 4, 2020 at 8:20 AM Shumon Huque wrote: > On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault > wrote: > >> Hi, >> >> I discovered this draft during the interim meeting. We had similar >> thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our >> motivation for supporting this work are that it 1) improves the >> reliability of the resolution as well as 2) removes the temptation to >> (inadvertently) break resolution by fixing in appearance a >> misconfiguration. In other words it eases the operation. >> > > Thank you Daniel. Will read your draft shortly, but in the meantime .. > > Your note reminded me of the question you asked during the interim > meeting about why we can't just use the DS TTL as the revalidation > interval. Our response was that the main impediment was that DNSSEC > deployment is far from ubiquitous, but also that there is no reason that it > could not be factor, when available. > > Here's what the draft already says about DS: > > Technically, if both parent and child zone are DNSSEC [RFC4033] > [RFC4034] [RFC4035] signed with a corresponding secure delegation > between them, then expiration of the DS record will cause > revalidation of the current child zone's DNSKEY set, so responses > from the orphaned child nameservers would no longer be trusted. > However, delegation revalidation is still necessary to locate the > current nameserver addresses. > > In practice, the DS and delegating NS TTL do not always match. > COM for example uses 2 day NS and 1 day DS TTL for all its > delegations. So where DS is lower, that could be used as the upper > bound. We'll queue up some text on this subject for the next revision > of the draft. > > Shumon. > > -- Daniel Migault Ericsson --00000000000027e24405a4d1e38d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, that will be appreciated. I will make sure the two= documents are synchronised.=C2=A0
Yours,=C2=A0
Daniel
On Mon, = May 4, 2020 at 8:20 AM Shumon Huque <shuque@gmail.com> wrote:
On Wed, Apr 29, 2020 at = 11:57 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
= Hi,=C2=A0

I discovered this draft during the interim mee= ting. We had similar thoughts in our "Recommendations for DNSSEC Resol= vers Operators". Our motivation for supporting this work are that it= =C2=A0 1) improves the reliability of the resolution as well as 2) removes = the temptation to (inadvertently) break resolution by fixing in appearance= =C2=A0a misconfiguration. In other words it eases the operation.=C2=A0

Thank you Daniel. Will read your dr= aft shortly, but in the meantime ..

Your note remi= nded me of the question you asked during the interim
meeting abou= t why we can't just use the DS TTL as the revalidation
interv= al. Our response was that the main impediment was that DNSSEC
dep= loyment is far from ubiquitous, but also that there is no reason that it
could not be factor, when available.

Here&= #39;s what the draft already says about DS:

=C2=A0= =C2=A0Technically, if both parent and child zone are DNSSEC [RFC4033]=C2=A0 =C2=A0[RFC4034] [RFC4035] signed with a corresponding secure delega= tion
=C2=A0 =C2=A0between them, then expiration of the DS record will ca= use
=C2=A0 =C2=A0revalidation of the current child zone's DNSKEY set= , so responses
=C2=A0 =C2=A0from the orphaned child nameservers would no= longer be trusted.
=C2=A0 =C2=A0However, delegation revalidation is sti= ll necessary to locate the
=C2=A0 =C2=A0current nameserver addresses.

In pract= ice, the DS and delegating NS TTL do not always match.
COM for example uses 2 day NS and 1 day DS TTL for all its
delegations. So where DS is lower, that could b= e used as the upper
bound. We'll queue = up some text on this subject for the next revision
of the draft.

Shumon.



--
Daniel Migault
Ericsson
--00000000000027e24405a4d1e38d-- From nobody Mon May 4 07:29:31 2020 Return-Path: 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 A26763A0911 for ; Mon, 4 May 2020 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 JXk3Dh3MCXgY for ; Mon, 4 May 2020 07:29:27 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 E20093A08FA for ; Mon, 4 May 2020 07:29:26 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id k81so14054444qke.5 for ; Mon, 04 May 2020 07:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=MhPVMIc4OQ/1hMhOLBqxt3rfOSherxjZsAhKBTWmK5A=; b=Xn4J1Efan7kajGETNpiaGIveaoUhXXRiWHPtxy95Tts61r+hhThridzvodnXyYqWWU I+F3mU96Hd0cRHYjvgL+PivTNiVBbnt88ERq6bemuxGrxqGTc/uX0Xh9kxrt3GXdko3D PvbX+nfvKHBq9snkAll/KfUWFVdxFyVUwKzure+ikI9fyp1U2+tQF6z3RY6whY5BXy7Z txJldVx3VqGLXWrxS46C0AEhnTN//TcIIROZ+ZA03CPdIE4MZfJ33cc5PyZuCDA3a314 oE5M+HZQ4lErKFeBvJ1QLCZy6oM/3urP9zAKUenmhnZjfRU99ZBErJhnFAnoSa4CBlES sTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=MhPVMIc4OQ/1hMhOLBqxt3rfOSherxjZsAhKBTWmK5A=; b=rsR7RflF7ke0P+sQ25o7iAF3up1eVTn6pPfAXb7MbDqNp8b5AyVT++Ej+xj4QOmxva C6ivPp+BchyaI0FJ0w6+lWClrBcqxOlwXyPSh4tPfNMqqEqUdJpyO564ntHWqbagFPfG c2qsVTDpcZu5NTTQduVYBUzOs9EgLmuNgMKf3AneUceKGZrxTcd4F2QT6u5jx26+zYSJ gKn0/hT6QZhELdV5mp1Q0B1E0i5hvZWmK/IgjdKcy7p3NSGWGCyp3UUbqoFeUPPItNI8 8DlwI5TfDbBJLh7Cy2SIgJ0p5x0OZJw5oJDuePAmdXvPnR62T4et3f+E/mM2uOVtgVyV tlvQ== X-Gm-Message-State: AGi0PuZt3JxcvYtF3iK9mkkII3n5EC0bMN8vwBRcfmBUvj/U0LfKmR5F ru8b2irwSVlq/InOCxIOVHwBOe+ZKv4= X-Google-Smtp-Source: APiQypJJCumw2Dugvy+5Qdvk1te1YnImG/mUgzFrP++rSMl8i3aAU2eQwjEAAcLItHyLk8Xi35MZUw== X-Received: by 2002:a37:5c46:: with SMTP id q67mr16291877qkb.210.1588602565413; Mon, 04 May 2020 07:29:25 -0700 (PDT) Received: from ?IPv6:2601:181:c381:c700:b00b:eb80:ad52:c1c5? ([2601:181:c381:c700:b00b:eb80:ad52:c1c5]) by smtp.gmail.com with ESMTPSA id s74sm3552806qka.54.2020.05.04.07.29.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 07:29:24 -0700 (PDT) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_0BF90504-DA0D-4C0D-969E-2F2CD8534CAB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <9EA4745F-6814-43CE-9E5F-2CF3706C635B@gmail.com> References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> To: dnsop@ietf.org Date: Mon, 4 May 2020 10:29:23 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [DNSOP] Fwd: Reminder: Survey on planning for possible online IETF meetings X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 14:29:29 -0000 --Apple-Mail=_0BF90504-DA0D-4C0D-969E-2F2CD8534CAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Colleagues, The IETF Executive Director and leadership need community input on how = to handle the possibility that future IETF meetings will not be able to = proceed in person. Please see below for details on a survey. Thanks, Suzanne=20 > Begin forwarded message: >=20 > From: IETF Executive Director > Subject: Reminder: Survey on planning for possible online IETF = meetings > Date: May 4, 2020 at 3:03:35 AM EDT > To: "IETF Announcement List" > Reply-To: ietf108planning@ietf.org >=20 > This is a reminder that we need the IETF community to help us plan for = the possibility that one or more upcoming IETF meetings in 2020 and = possibly 2021 may not be able to go ahead in person. You can help us = with this by filling out the following survey:=20 >=20 > https://www.surveymonkey.com/r/5328FFJ >=20 > So far we have 114 responses and we would ideally like 500 or more. >=20 > The survey contains the following pages and will take 15-20 minutes to = complete: >=20 > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else >=20 > We run the survey in anonymous mode which means that we only see data = that you explicitly provide. >=20 > Thank you in advance for your help. >=20 > --=20 > Alissa Cooper, IETF Chair > Jay Daley, IETF Executive Director > Colin Perkins, IRTF Chair >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_0BF90504-DA0D-4C0D-969E-2F2CD8534CAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Colleagues,

The IETF Executive Director and leadership need community = input on how to handle the possibility that future IETF meetings will = not be able to proceed in person. Please see below for details on a = survey.


Thanks,
Suzanne 


Begin = forwarded message:

From: = IETF Executive Director <exec-director@ietf.org>
Subject: = Reminder: Survey = on planning for possible online IETF meetings
Date: = May 4, 2020 at 3:03:35 AM = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Reply-To: = ietf108planning@ietf.org

This is a reminder that we = need the IETF community to help us plan for the possibility that one or = more upcoming IETF meetings in 2020 and possibly 2021 may not be able to = go ahead in person.  You can help us with this by filling out the = following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or = more.

The survey contains the following = pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the = subsequent virtual interims
3. Replacing a cancelled = in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the = hallway environment
7. Fees
8. Thanks and = anything else

We run the survey in = anonymous mode which means that we only see data that you explicitly = provide.

Thank you in advance for your = help.

--
Alissa Cooper, IETF = Chair
Jay Daley, IETF Executive Director
Colin= Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail=_0BF90504-DA0D-4C0D-969E-2F2CD8534CAB-- From nobody Mon May 4 11:00:56 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA173A0E3F; Mon, 4 May 2020 11:00:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158861524282.17593.4472067175192027315@ietfa.amsl.com> Date: Mon, 04 May 2020 11:00:42 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:00:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Secret Key Transaction Authentication for DNS (TSIG) Authors : Francis Dupont Stephen Morris Paul Vixie Donald E. Eastlake 3rd Olafur Gudmundsson Brian Wellington Filename : draft-ietf-dnsop-rfc2845bis-08.txt Pages : 29 Date : 2020-05-04 Abstract: This document describes a protocol for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client, or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets: it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism. This document obsoletes RFC2845 and RFC4635. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc2845bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 4 11:07:26 2020 Return-Path: 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 B58B13A0E88 for ; Mon, 4 May 2020 11:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=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 KiLFcmxqVAvu for ; Mon, 4 May 2020 11:07:20 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 C9DE23A0E83 for ; Mon, 4 May 2020 11:07:19 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id g12so530821wmh.3 for ; Mon, 04 May 2020 11:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:references :to:message-id; bh=Mzq5pb7kOQL2SlLVi7N9dRc4wa7txZUGJv65CW5uRJg=; b=O84mh2bGKdEYJla3N0wghHzdrMiH7CyJtYrwsAaJC0BIurTCbVMhq1kPKAWLTcP/hh JcREoF4Q4t0iQLNdgld2PcGTgOaefrxg+igjt8p3S7e47i46bxZfe86H5WGajT1dV2t4 ZR2NR9Gp81a8acbxqdcm8qquJIk049Q0lkLwxz8zRSkftNj+bE6b79lTgZeYCR2y0UUC ZAQJgycL4ILD2xxZDMqhzDPfnS7v7nF/wNv0l6BlcZZbhAiluupM3V40AbWPxR+wyoaP MsG/dKkQJcOn2dhnSfxNRXC/0HWyXYX1JwIWEzgF68gjlZQS0kYa+8M6j4hlL9kjJzOf nGSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:references:to:message-id; bh=Mzq5pb7kOQL2SlLVi7N9dRc4wa7txZUGJv65CW5uRJg=; b=hmQ9vxMcv/Q4DLCKkrLVuuXx4Ve6GjUWlBBJvCREg5y/K090I4A78TRg4gbdA0hVuB AAkgwftxJaRWnPiIgOJbDhJ5Dxt2t4unfXULTZkX9D80noUh9TNBnE8gzXLDHZGRK0/b reN1UD7+LQm//i2JqWN90LEAXvtbkE2SLVWxGe6E33AwehPHBslh0rSmiFu1vimoab/A z8WVZ7olszAb2u2ocLYjU5xb3QueeiuD9pB2d36GupEI2PKcAFhwKiNvvU8cCcV/M1BP hqwPAD8YtOfiHI92D5dAtbpfCuI7gcSuvfwbpMfo9NaK5mHGeKbMiXuNzLJAECrqxLD9 4m0w== X-Gm-Message-State: AGi0PuazkiG1wkebnam9AN/T+vPlLhPJArwRZzn7HSa2N/4I2ghUA9y4 /RcB7Z36rJVlhFUS/uHnC4D/Gd5s X-Google-Smtp-Source: APiQypI/qDCjH23wGTScjsVvpYFVjWEPN1TLa90AsmG6peQ8VdfMb4N3gAy7l/mrcwwpccWmLzkCjg== X-Received: by 2002:a1c:41d7:: with SMTP id o206mr16069931wma.89.1588615636839; Mon, 04 May 2020 11:07:16 -0700 (PDT) Received: from [192.168.0.10] (cpc117486-shep15-2-0-cust40.8-3.cable.virginm.net. [82.8.78.41]) by smtp.gmail.com with ESMTPSA id q184sm306947wma.25.2020.05.04.11.07.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 11:07:14 -0700 (PDT) From: Stephen Morris Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 May 2020 19:07:12 +0100 References: To: dnsop@ietf.org Message-Id: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:07:25 -0000 > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations WG of = the IETF. >=20 > Title : Secret Key Transaction Authentication for DNS = (TSIG) > Authors : Francis Dupont > Stephen Morris > Paul Vixie > Donald E. Eastlake 3rd > Olafur Gudmundsson > Brian Wellington > Filename : draft-ietf-dnsop-rfc2845bis-08.txt > Pages : 29 > Date : 2020-05-04 The update addresses to the draft comments made during the IESG review. = There were a fair number of these which led to a number of changes to = the document. These are listed below. One significant change is that the list of acceptable algorithms has = been extended, and WG approval for this is sought. Stephen Comments from Roman Danyliw --- > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly = following that document (and the related [RFC4635]) were discovered to = have security problems related to this feature=E2=80=9D, consider = providing a reference to the published vulnerabilities (i.e., = CVE-2017-3142 and CVE-2017-3143) I=E2=80=99ve added these (and one other related CVE) as informative = references. Using just the CVE number as a reference seemed a bit = spartan, so I=E2=80=99ve added a title to each incident. As the = description of the CVEs in Mitre=E2=80=99s database don=E2=80=99t = contain a title (only a description, which can be rather long), I=E2=80=99= ve taken the title from ISC=E2=80=99s KnowledgeBase (for the BIND CVEs) = and from the Knot release notes (for the Knot CVE). > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated so = the MD5 security considerations apply to SHA-1 in a similar manner. = Although support for hmac-sha1 in TSIG is still mandatory for = compatibility reasons, existing uses should be replaced with hmac-sha256 = or other SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >=20 > -- It=E2=80=99s worth repeating those MD5 security considerations here I=E2=80=99m not really keen on doing this, since the security = considerations in RFC 6151 cover two paragraphs and including them - or = even a summary of them - would detract from the flow of the document. = However, I have explicitly included a reference to RFC 6151 in the text. > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) = it=E2=80=99s worth including references to the recent SHA-1 = cryptoanalysis provided in the SECDIR review Added references to just one of these papers (=E2=80=9DSHA1 is a = Shambles=E2=80=9D). We=E2=80=99re not doing a general analysis of the = algorithms, so a simple reference to a paper than describes a SHA1 = collision is all that is needed. (As an aside, the paper doesn't give = the date of publication, so I had to search the Web looking for = references to it. I think I=E2=80=99ve got the date correct, but I=E2=80=99= d be grateful for a double-check.) > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). Done - see Table 2 > ** Section 10. Per =E2=80=9CFor all of the message authentication = code algorithms listed in this document, those producing longer values = are believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s = SECDIR review, this could be misconstrued as the algorithm choice not = the digest length provides the security. Recommend rephrasing (or = making some statement =20 I=E2=80=99ve reworded this paragraph (in section 10). It now reads: "Although the strength of an algorithm determines its security, there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker. However, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104]." > ** Editorial > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message, = this is the message after the TSIG RR and been removed and the ARCOUNT = field has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t = parse (is missing a word). >=20 > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in = wire format.=E2=80=9D, this isn=E2=80=99t a sentence. Section 4.3.2 has been reworded to address these issues. Comments from Benjamin Kaduk > Thanks for putting together this update; it's good to see the security > issue getting closed off in the udpated spec, and progression to full > Internet Standard! I do have several substantive comments (as well as > some minor/nit-level ones), many of which are listed here at the top = but > a few of which are interspersed in the per-section comments. >=20 >=20 > I considered making this a Discuss point, but it should be pretty > uncontroversial and I trust that the right thing will happen even if I > don't: there's a couple lingering remnants of SHA-1 being the > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 = and > 10 (further detailed in the per-section comments). The document now mentions SHA1 collisions and notes that the MD5 = security considerations apply to SHA1. It also mentions that support = for SHA1 is mandatory for compatibility reasons but in existing uses it = should be replaced by a stronger one. > I also initially had made the following point a Discuss-level point, = but > decided to not do so since I don't remember any BCP-level guidance > relating to cross-protocol attacks. Nevertheless, I strongly = encourage > the authors to consider that cryptographic best practice is to use any > given key with exactly one cryptographic algorithm. The record format > listed in Section 4.2 has the key name and algorithm as separately > conveyed, which would allow for a given key to be used with all > implemented algorithms. We should include some discussion that it's > best to only use a single algorithm with any given key. The following text has been added to the Security Considerations = section: "To prevent cross-algorithm attacks, there SHOULD only be one algorithm associated with any given key name." > We also have a 16-bit wide field for "Fudge", which (since it counts > seconds) corresponds to a maximum window of something like +/- 18 = hours; > it's hard to believe that we really want to give people the rope to > allow for that much time skew. (Yes, I understand that = implementations > will set something sane in practice but that doesn't necessarily mean > that the protocol still has to allow it.) That was set in the original RFC 2845. Although I agree with the = comments, changing the size of that field would be a significant = undertaking. However, section 10 does state that the RECOMMENDED fudge = value in most circumstances is 300 seconds. > Our authoritative list of algorithm names (Table 1) is rather divorced > from the references to be consulted for the individual hash algorithms > to be used with the HMAC procedure. The ones used here are = sufficiently > well-known that I'm not terribly concerned about it, though. The first paragraph of the IANA considerations section lists the = algorithms and references to where they are described, and I didn=E2=80=99= t want to duplicate the information. > Abstract >=20 > The title says "DNS" but maybe the body of the abstract should as = well? In the abstract, changed: "It can be used to authenticate dynamic updates as coming from an = approved client" to "It can be used to authenticate dynamic updates to a DNS zone as coming = from an approved client" > Section 1.1 >=20 > Some of this language feels like it might not age terribly well, e.g., > "this can provide" or "[t]here was a need". >=20 > addresses that need. The proposal is unsuitable for general server > to server authentication for servers which speak with many other > servers, since key management would become unwieldy with the number > of shared keys going up quadratically. But it is suitable for many > resolvers on hosts that only talk to a few recursive servers. Changed to: "The authentication mechanism proposed here provides a simple and efficient authentication between clients and local = servers by using shared secret keys to establish a trust relationship = between two entities. Such keys must be protected in a manner similar = to private keys, lest a third party masquerade as one of the = intended parties (by forging the MAC). The proposal is unsuitable for = general server to server authentication for servers which speak with = many other servers, since key management would become unwieldy with = the number of shared keys going up quadratically. But it is suitable = for many resolvers on hosts that only talk to a few recursive = servers.=E2=80=9D > Should zone transfers be mentioned here as well? Zone transfers are mentioned in the preceding paragraph. > Section 1.2 >=20 > I don't understand the motivation for changing terminology from MACs = to > "signatures"; they're still MACs even though they're = transaction-based. The mention of signatures in section 1.2 is intended as a link between = the name of the RR (TSIG or Transaction Signature) and the term MAC used = in the rest of the document. > MAC of the query as part of the calculation. Where a response > comprises multiple packets, the calculation of the MAC associated > with the second and subsequent packets includes in its inputs the = MAC > for the preceding packet. In this way it is possible to detect any > interruption in the packet sequence. >=20 > I suggest mentioning the lack of mechanism to detect truncation of the > packet sequence. That is a fair point. I=E2=80=99ve modified the last sentence to read: "In this way it is possible to detect any interruption in the packet = sequence, although not its premature termination." > Section 4.2 >=20 > NAME The name of the key used, in domain name syntax. The name > should reflect the names of the hosts and uniquely identify = the > key among a set of keys these two hosts may share at any given > time. For example, if hosts A.site.example and=20 > B.example.net >=20 > share a key, possibilities for the key name include > .A.site.example, .B.example.net, and > .A.site.example.B.example.net. It should be possible for > more than one key to be in simultaneous use among a set of > interacting hosts. >=20 > I'd suggest adding a note along the lines of "This allows for periodic > key rotation per best operational practices, as well as algorithm > agility as indicated by [BCP201].=E2=80=9D Added. > The name may be used as a local index to the key involved and > it is recommended that it be globally unique. Where a key is >=20 > (nit?): this feels more like a "but" than an "and", to me. Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than = =E2=80=9Cand=E2=80=9D > * MAC Size - an unsigned 16-bit integer giving the length of > MAC field in octets. Truncation is indicated by a MAC size > less than the size of the keyed hash produced by the > algorithm specified by the Algorithm Name. >=20 > nit: I would suggest "output size", as there are potentially a few > different sizes involved (key size, block size, and output size, for > starters, though I think the possibility of confusion here is low). I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference = to this field, and the other size mentioned - that of the keyed hash is, = I think, also unambiguous. > * Other Len - an unsigned 16-bit integer specifying the = length > of the "Other Data" field in octets. >=20 > * Other Data - this unsigned 48-bit integer field will be > empty unless the content of the Error field is BADTIME, in > which case it will contain the server's current time as the > number of seconds since 00:00 on 1970-01-01 UTC, ignoring > leap seconds (see Section 5.2.3). >=20 > I'm slightly confused at the interplay between the explicit length = field > and the "empty unless" directive. Does this mean that the only = allowed > values in the "Other Len" are 0 and 6? Does "empty" mean = "length-zero=E2=80=9D? I=E2=80=99ve rewritten this slightly in a bid to make it clearer that = =E2=80=9COther Data=E2=80=9D being empty means that =E2=80=9COther = Len=E2=80=9D is zero. > Section 4.3.1 >=20 > Only included in the computation of a MAC for a response message (or > the first message in a multi-message response), the validated = request > MAC MUST be included in the MAC computation. If the request MAC > failed to validate, an unsigned error message MUST be returned > instead. (Section 5.3.2). >=20 > side note: while Section 5.3.2 specifies how to create an unsigned = error > message, it looks like Section 5.2 (and subsections lists specific > RCODEs that are to be used. That is the case. Section 4 is a description of the TSIG RR and its = fields. Section 5 describes the contents of the fields in various = situations (client transmission, server reception, server transmission, = client reception). > Section 4.3.2 >=20 > When verifying an incoming message, this is the message after the > TSIG RR and been removed and the ARCOUNT field has been decremented. > If the message ID differs from the original message ID, the original > message ID is substituted for the message ID. (This could happen, > for example, when forwarding a dynamic update request.) >=20 > I trust (based on this text having survived while going for full IS) > that there are no interesting record-keeping considerations with = respect > to knowing the message ID(s) to substitute, in the "forwarding a > dynamic-update request" case, presumably since this is just the field > from the TSIG RDATA and not some externally retained state. That is correct - the original ID is stored in the TSIG record=E2=80=99s = RDATA and it is from there that the original ID is retrieved when a = substitution is made. > Section 4.3.3 >=20 > The RR RDLEN and RDATA MAC Length are not included in the input to > MAC computation since they are not guaranteed to be knowable before > the MAC is generated. >=20 > I appreciate that this is explicitly noted; there are some security > considerations regarding the non-inclusion of the (truncated) mac = length > as input, though. The local truncation policy helps here, but not = 100%. OK > For each label type, there must be a defined "Canonical wire format" >=20 > Just to check my understanding: label types only come into play for = the > two fields that are in domain name syntax, key name and algorithm = name? There was actually an error in the text here: RFC 4034 section 6.1 is = concerned with Canonical Name Order. It is section 6.2 that details the = canonical wire format - I=E2=80=99ve changed the reference. Going back to the original point, yes, that is correct. Label type 00 = is uncompressed name. (11 is a compressed name, and label types 01 and = 10 are discouraged - see RFC 6891 section 5). > Section 5.1 >=20 > the server. This TSIG record MUST be the only TSIG RR in the = message > and MUST be last record in the Additional Data section. The client >=20 > (Is there anything else that tries to insist on being the last record = in > the additional data section? I guess it doesn't really make sense to > try to Update: 1035 just to note this requirement.) Not to our knowledge. > MUST store the MAC and the key name from the request while awaiting > an answer. >=20 > [This is going to end up alongside the request-ID that it has to store > already, right?] Yes. The request MAC is included as one of the components used by the = server to generate the response - which should be encoded using the same = key as used in the request. > Note that some older name servers will not accept requests with a > nonempty additional data section. Clients SHOULD only attempt = signed > transactions with servers who are known to support TSIG and share > some algorithm and secret key with the client -- so, this is not a > problem in practice. >=20 > (The context in which this "SHOULD" appears makes it feel like it's > repeating an admontion from elsewhere and not the only instance of the > requirement, in which case a reference might be appropriate.) I=E2=80=99ve removed this paragraph. The reference to older name = servers is now completely out of date (it was a carry-over from the = original 20-year old text). The rest of the paragraph seems superfluous = - rather like stating that TCP clients should only connect to servers = that support TCP. =20 > Section 5.2 >=20 > If the TSIG RR cannot be understood, the server MUST regard the > message as corrupt and return a FORMERR to the server. Otherwise = the > server is REQUIRED to return a TSIG RR in the response. >=20 > As written, this could be read as an attempt to make a normative > requirement of servers that do not implement this spec. Presumably = it's > just restating a requirement of the core protocol, though? It is the core protocol. I see your point though. However, by implication we are talking about a = server that implements TSIG. > Section 5.2.2 >=20 > Using the information in the TSIG, the server should verify the MAC > by doing its own calculation and comparing the result with the MAC > received. If the MAC fails to verify, the server MUST generate an >=20 > Is there any other way to verify the MAC? (Should this be a "MUST > verify=E2=80=9D?) Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. > Section 5.2.2.1 >=20 > When space is at a premium and the strength of the full length of a > MAC is not needed, it is reasonable to truncate the keyed hash and > use the truncated value for authentication. HMAC SHA-1 truncated to > 96 bits is an option available in several IETF protocols, including > IPsec and TLS. >=20 > Also Kerberos, where it was the strongest option for a while and we = had > to define a new encryption type to provide a better option (RFC 8009). >=20 > This text seems to be implying that HMAC SHA-1 truncated to 96 bits is = a > recommendable option, which is ... far from clear. I'd prefer to have = a > note that this specific truncation was appropriate when initially > specified but may not provide a security level appropriate for all = cases > in the modern environment, or preferrably to just change the reference > to (e.g.) SHA-384-192 or SHA-256-128. Added the following an the end of the paragraph: However, while this option is kept for backwards compatibility, it may not provide a security level appropriate for all cases in the modern environment. In these cases, it is preferable to use a hashing algorithm such as SHA-256-128, SHA-384-192 or SHA-256-128 [RFC4868]. I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D, = =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80=9D = as optional algorithms to the algorithm table. > This is sent when the signer has truncated the keyed hash output > to an allowable length, as described in [RFC2104], taking = initial > octets and discarding trailing octets. TSIG truncation can only >=20 > (Or when an on-path attacker has performed truncation.) True, but an on-path attacker can manipulate the message in any way = possible. I=E2=80=99m not sure whether adding this caveat will add = anything to the document. > Section 5.2.3 >=20 > (BADTIME). The server SHOULD also cache the most recent time signed > value in a message generated by a key, and SHOULD return BADTIME if = a > message received later has an earlier time signed value. A response >=20 > (But there's no fudge factor on this check, other than the inherent > limit of seconds granularity, as alluded to by the last paragraph of > this section?) The last paragraph in the section states that handling this issue should = be left up to implementations and that the exact method (and by = implication, the size of the fudge factor) be determined by the = implementation themselves. =20 > Section 5.3.1 >=20 > A zone transfer over a DNS TCP session can include multiple DNS > messages. Using TSIG on such a connection can protect the = connection > from hijacking and provide data integrity. The TSIG MUST be = included >=20 > (I assume that "hijacking TCP" means a sequence-number-guessing attack > that would require the attacker to be winning the race against the > legitimate sender to cause modified data to be introduced into the TCP > stream? This is maybe not the best word to use for such a case.) I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D.= > on all DNS messages in the response. For backward compatibility, a > client which receives DNS messages and verifies TSIG MUST accept up > to 99 intermediary messages without a TSIG. The first message is >=20 > (side note: I'm kind of curious what such compatibility is needed = with. > Also, this gives an attacker some flexibility into which to = incorporate > a collision, though given the near-real-time constraints and the > strength of the HMAC construction I don't expect any practical = impact.) The original RFC 2845 did not require all packets in a message stream to = contain a TSIG, it just stated that there be no more than 99 = intermediary messages without a TSIG (presumably to cut down on the = overhead required in message calculations - remember that RFC 2845 was = published 20 years ago). Although many DNS implementations now add a = TSIG to every message, it is by no means certain that all do. (In fact, = less than three years ago, a bug was introduced into BIND, causing it to = require that all packets in a zone transfer would contain a TSIG. A fix = allowing BIND to accept up to 99 packets between signed ones was = released shortly afterwards after reports were received of zone = transfers failing.) > Section 5.3.2 >=20 > Request MAC (if the request MAC validated) > DNS Message (response) > TSIG Variables (response) >=20 > The reason that the request is not included in this MAC in some = cases > is to make it possible for the client to verify the error. If the > error is not a TSIG error the response MUST be generated as = specified > in Section 5.3. >=20 > This makes it sound like the server excludes the request MAC from the > digest if it failed to validate (something the client cannot predict), > so that the client must perform trial verification of both versions in > order to validate the response. Is that correct? No. If the incoming MAC failed to validate, the server should send back = an unsigned response (MAC size =3D=3D 0 and empty MAC). > Also, I think that the "in some cases" is not properly placed: as-is, = it > says that the request (not request MAC) is sometimes not included > (implying that sometimes it is), which does not match up with the > specification for the digest components. I presume that the intent is > to say that in some cases the client could not verify the error, if = the > request itself was always included in the digest. Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. If the MAC could not be verified, it is possible that it was corrupted, = which would prevent the client verifying the response. But a major = reason is that an incorrect MAC included in a signed response led to the = CVEs that prompted this document update. > Section 5.4.1 >=20 > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG > validates and the TSIG key recognised by the client but different > from that used on the request, then this is a Key Error. The client >=20 > nits: missing words "key is recognized" and "but is different=E2=80=9D It now reads =E2=80=9Ckey is recognized but different" > Section 5.5 >=20 > destination or the next forwarder. If no transaction security is > available to the destination and the message is a query then, if the > corresponding response has the AD flag (see [RFC4035]) set, the > forwarder MUST clear the AD flag before adding the TSIG to the > response and returning the result to the system from which it > received the query. >=20 > Is there anything to say about the CD bit? (It's independent crypto, = so > I don't expect so, but it seems worth checking.) No. CD is just a mechanism by which a client can request that the = server not do DNSSEC signature validation on the data and so allow the = client to receive the data instead of a SERVFAIL response. > Section 6 >=20 > The only message digest algorithm specified in the first version of > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], > [RFC2104]). Although a review of its security [RFC6151] concluded > that "it may not be urgent to remove HMAC-MD5 from the existing > protocols", with the availability of more secure alternatives the > opportunity has been taken to make the implementation of this > algorithm optional. >=20 > It seems worth noting that the advice from RFC 6151 is already nine > years old. I=E2=80=99ve use the phrasing "Although a review of its security some = years ago=E2=80=9D. > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 > security considerations apply to SHA-1 in a similar manner. = Although >=20 > I'd consider referencing (e.g.)=20 > shattered.io > for the "collisions have > been demonstrated" claim, though it's pretty optional. A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D = paper. > support for hmac-sha1 in TSIG is still mandatory for compatibility > reasons, existing uses should be replaced with hmac-sha256 or other > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >=20 > Is this "sha1 mandatory for compatibility" going to age well? If we > have two implementations that can operate with sha2 variants, is it > required to keep this as mandatory (vs. optional with a note about > deployed reality at time of publication) for progression to Internet > Standard? This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2=80= =9D column in RFC4635 (from which Table 2 was derived) into = =E2=80=9CImplementation=E2=80=9D and =E2=80=9CUse=E2=80=9D. SHA1 is = required to be implemented (for backwards compatibility) but its use is = not recommended. > Optional hmac-sha224 >=20 > It's not clear there's much reason to keep this around, or if we do, = it > could probably be "not recommended". (I assume that just dropping it > entirely makes things annoying w.r.t. the IANA registry.) It has been left in for compatibility reasons, but its use is not = recommended. > Section 9 >=20 > Previous specifications [RFC2845] and [RFC4635] defined values for > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >=20 > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where > HMAC qualifies both hash algorithms is not terribly clear. Changed to=20 Previous specifications [RFC2845] and [RFC4635] defined names = for the HMAC-MD5 and the various HMAC-SHA algorithms. > Section 10 >=20 > I suggest some discussion that the way truncation policy works, an > attackers ability to forge messages accepted as valid is limited by = the > amount of truncation that the recipient is willing to accept, not the > amount of truncation used to generate messages by the legitimate = sender. I think this is already taken care of by the reference to a local policy = in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section = (5.2.4). > There's also some fairly standard content to put in here about = allowing > for an unsigned error response to a signed request, so an attacker = (even > off-path) can spoof such resposnes. (Section 5.4 indicates that the > client should continue to wait if it gets such a thing, which helps a > lot.) I=E2=80=99ve just added text that an unsigned response is not considered = acceptable because can be subject to spoofing and manipulation. > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two > entities. >=20 > I suggest adding "; any such additional sharing would allow any party > knowing the key to impersonate any other such party to members of the > group=E2=80=9D. Added. > A fudge value that is too large may leave the server open to replay > attacks. A fudge value that is too small may cause failures if > machines are not time synchronized or there are unexpected network > delays. The RECOMMENDED value in most situations is 300 seconds. >=20 > Our experience with kerberos in modern network environments has shown > that 5 minutes is much larger than needed, though it's not clear = there's > a strong need to change this recommendation right now. The value is recommended (and even then, only in =E2=80=9Cmost = situations=E2=80=9D), so implementations are free to set their own = value. However, any guidance as to typical time skews measured across a = network would be useful in a number of protocols. > Significant progress has been made recently in cryptanalysis of hash > functions of the types used here. While the results so far should > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are being > made mandatory as a precaution. >=20 > Please revise this note to not imply that SHA-1 is considered = "strong=E2=80=9D. Text revised to Significant progress has been made recently in cryptanalysis of = hash functions of the types used here. While the results so far = should not affect HMAC, the stronger SHA-256 algorithm is being made = mandatory as a precaution. > Section 11.2 >=20 > I'm not sure why RFC 2104 is listed as informative. RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a = possible downref if the reference is placed in the =E2=80=9CNormative=E2=80= =9D section. Comments from Mirja K=C3=BChlewind > I only had limited time for a quick review of this document, so I = might not be aware of all the needed background and details. Still I = have two quick questions on retries: >=20 > 1) Sec 5.2.3: > "Implementations should be aware > of this possibility and be prepared to deal with it, e.g. by > retransmitting the rejected request with a new TSIG once outstanding > requests have completed or the time given by their time signed plus > fudge value has passed." > I might not be aware of all protocol details and maybe this is already = specified somewhere: While unlikely, it is possible that a request might = be retransmitted multiple times, as that could cause president = congestion over time, it's always good practice to define a maximum = number of retransmissions. If that is already defined somewhere, maybe = adding a note/pointer would be good as well. If someone can suggest a suitable number (and a reason for it), we can = consider doing this. In the meantime, I=E2=80=99ve merely stated that = implementation should limit the number of retransmissions and so leave = the choice up to the implementation. > 2) Sec 5.3.1: > " This allows the client to rapidly detect when the session has been > altered; at which point it can close the connection and retry." > When (immediately or after some waiting time) should the client retry = and how often? I think that should be down to the implementation to decide. > You further say=20 > "The client SHOULD treat this the > same way as they would any other interrupted transfer (although the > exact behavior is not specified here)." > Where is that specified? Can you provide a pointer in the text? That was a mistake in transcribing the original RFC2845 text. The final = word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads: The client SHOULD treat this the same way as they would any = other interrupted transfer (although the exact behavior is not = specified). > 3) Sec 8. Shared Secrets: Would it be appropriate to use more = normative language here? There are a bunch of lower case shoulds in this = section; is that on purpose? The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is = very general security advice. Although this is something users ought to = do, it is not really a specific recommendation. Comments from Barry Leiba > =E2=80=94 Section 4.2 =E2=80=94 >=20 > * Other Len - an unsigned 16-bit integer specifying the = length > of the "Other Data" field in octets. > * Other Data - this unsigned 48-bit integer field will be >=20 > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits? = If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is = always 6? If so, then shouldn=E2=80=99t it say that? If not, then what = don=E2=80=99t I understand? Benjamin Kaduk also made the same comment, it has been addressed above. > =E2=80=94 Section 5.1 =E2=80=94 >=20 > Clients SHOULD only attempt signed > transactions with servers who are known to support TSIG and share > some algorithm and secret key with the client -- so, this is not a > problem in practice. >=20 > Why SHOULD and not MUST? Benjamin Kaduk also noted an issue here. The paragraph has been = removed. > =E2=80=94 Section 5.3.2 =E2=80=94 >=20 > The server SHOULD also cache the most recent time signed > value in a message generated by a key >=20 > I tripped over this until I realized you mean =E2=80=9CTime Signed = value=E2=80=9D. You capitalize it elsewhere, and it helps the parsing = if it=E2=80=99s consistent. There are four uncapitalized instances in = this section. =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in the = description of the field, =E2=80=9Ctims signed=E2=80=9D has been = replaced with =E2=80=9Ctime the message was signed=E2=80=9D. Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9CF= udge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2=80=9D= have not been capitalised, as the context of that is that it is = referring to the contents of the Fudge field). Also, =E2=80=9Cother = data=E2=80=9D and =E2=80=9Cother data length=E2=80=9D have been replaced = with the (capitalised) field names, =E2=80=9COther Data=E2=80=9D and = =E2=80=9COther Len=E2=80=9D. > =E2=80=94 Section 9 =E2=80=94 >=20 > There is no structure > required other than names for different algorithms must be unique > when compared as DNS names, i.e., comparison is case insensitive. >=20 > I found this sentence to be really awkward and hard to parse. May I = suggest this?: >=20 > NEW > There is no structure to the names, and algorithm names are compared = as if they were DNS names (the comparison is case-insensitive). > END >=20 > I don=E2=80=99t think you really need to say that each name is = different/unique, right? Agreed. The text has been changed to that suggested. > other algorithm > names are simple (i.e., single-component) names. >=20 > Nitty thing that you can completely ignore, but I would avoid the = Latin abbreviation thus: =E2=80=9Cother algorithm names are simple, = single-component names.=E2=80=9D Changed. Comments from =C3=89ric Vyncke > Thank you for the work put into this document. It is clear and easy to = read. >=20 > Please find below some non-blocking COMMENTs and NITs. An answer will = be appreciated. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > There are 6 authors while the usual procedure is to limit to 5 = authors. Personally, I do not care. >=20 > -- Section 1.3 -- > It is a little unclear to me whether the "two nameservers" were two = implementations or two actual DNS servers. Agreed, it was unclear. Changed to =E2=80=9Ctwo name server = implementations=E2=80=9D. > -- Section 5.2 -- > Suggest to provide some justifications about "copied to a safe = location": the DNS message was sent in the clear, why does the TSIG part = be copied in a safe location? Please define what is meant by "safe = location" (Mainly for my own curiosity) It is a bit over-specified and has been changed. The text now reads: Upon receipt of a message with exactly one correctly placed TSIG RR, a copy of = the TSIG RR is stored, and the TSIG RR is removed from the DNS = Message, and decremented out of the DNS message header's ARCOUNT. > "cannot be understood" is also quite vague. Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. > -- Section 5.3 -- > About rejecting request with a time signed value being earlier than = the last received value. I wonder what is the value of this behavior if = there is no 'fudge' as well... The last paragraph of this section = describes this case and push the error handling to the request = initiator. Any reason why being flexible on the receiving site was not = selected ? The fudge value is to cope with clock skew between the sender and = receiver. This won't impact on the order in which the packets are = received by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is = a first-level check. (It is not fool-proof - a number of packets signed = by the sender within a second of one another may have the same =E2=80=9CTi= me Signed=E2=80=9D field.) Pushing the error handling to the initiation goes back to the original = RFC 2845. > =3D=3D NITS =3D=3D >=20 > -- Section 4.3.2 -- > Is " A whole and complete DNS message in wire format." a complete and = valid sentence? This was also pointed out by Roman Danyliw and has been addressed. Other changes made during editing * There was no description of the contents of the =E2=80=9CError=E2=80=9D = and =E2=80=9COther Data=E2=80=9D fields were in a request. This has now = been corrected (Error is set to 0. The contents of =E2=80=9COther = Data=E2=80=9D are stated to be undefined to allow for extensions such as = draft-andrews-dnsop-defeat-frag-attack.) From nobody Mon May 4 12:09:03 2020 Return-Path: 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 35E903A12C3; Mon, 4 May 2020 12:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 0MlP4r_evgns; Mon, 4 May 2020 12:08:52 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 C3B413A12AC; Mon, 4 May 2020 12:08:32 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id z25so9845499otq.13; Mon, 04 May 2020 12:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=AWL3q61e4zOnwzX42bMdBz4toUQguqImU4M4lEoQ/dw=; b=Uw8/tUoduF/UqW9Ib9vB6T3YQVJkHUVZ06+DcHW4KFZ0ZBqaYGNj41d3x5Lr8G2EXZ U+HEt+ORjxufQ0zgieGrRpT0imJyr2PPIRZkdvhKmK4TYfxyzrc2DXtX2+XX+oAwqk6j zQjPwvuo9TzBgnGf2BgRLVCvW4/yGAtixsbeZQjjRPXg5VAZII2mn1dK9Jf5S8ZGqg88 yXLUV26Wh31YrKX1xDhEeBZZ2mytTbgDnskeBTt/DIvvKoFTtWPOPRnvVDFXgu9CCKDt xyDk6tOQMnngFb0YhSHGplr1Xf4MBha9CUpZOWSQG7bgHaOBAs1SF5K9LyhpoHzqN+qq HokA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=AWL3q61e4zOnwzX42bMdBz4toUQguqImU4M4lEoQ/dw=; b=iOvkIGpS+MQGg3wRVdvgwhtkyyER2jsj9YbgfDlxPZLotk4U71bNjXhWVh3sRdiGff BvG/WkQc6eXSm2utbAGRxTslw0+FtD8NKXh0NHd4GMBEmqOGFHq+QG+Ve8KgfIC4DP1e 0Msp/MRFodalrwcvwlw+8UNp+k71IBZlVCe/T7/0VTyoyrfF9ae385gUAPblrwbh/IhZ 6ZGUxMQnaNcVohcX4IHeTeZZFcdDYvq6J+S1b8FJQ2Kl24FR+P3ImfEa+JwIv8ytG5Qm zznsIoN+BArMNjqu9lowhbPtSS2Ec5lKby3AvVqj0qVwZ9cYlwIv8amJwt+jDJm1ZpYn 8NJA== X-Gm-Message-State: AGi0PuZx3V1UhgKK7j3WFLSLpc6gcD6VIwVrCmsfPXacq4MLw7WmpCnU wiixR1UDlUb4ToymZawyRDpxf2eMe9ilQ4SoJCwpjfFo X-Google-Smtp-Source: APiQypJBgRDqphfOCz1s6UgsfIot7svKT5VNHxW3lShaw0/oDDgQM3bRMNr7wW672C5lw5muEVhgDGbCithneMAvO4A= X-Received: by 2002:a05:6830:1d0:: with SMTP id r16mr16626352ota.4.1588619311720; Mon, 04 May 2020 12:08:31 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Mon, 4 May 2020 15:08:20 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000c22e7e05a4d741cf" Archived-At: Subject: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 19:08:56 -0000 --000000000000c22e7e05a4d741cf Content-Type: text/plain; charset="UTF-8" All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-requirements The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 18 May 2020 Thanks, tim wicinski DNSOP co-chair --000000000000c22e7e05a4d741cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


All,

As we stated in the meeting and in our chairs action= s, we're going to run
regular call for adoptions over next few month= s. =C2=A0
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-requ= irements

The draft is available here: https://data= tracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/

Please review this draft to see if you think it is suitable for ad= option
by DNSOP, and comments to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, et= c.

This call for adoption ends: 18 May 2020

Thanks,
tim wi= cinski
DNSOP co-chair

--000000000000c22e7e05a4d741cf-- From nobody Mon May 4 12:11:06 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70E3A0F0B; Mon, 4 May 2020 12:11:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158861946403.9316.9132034162941715598@ietfa.amsl.com> Date: Mon, 04 May 2020 12:11:04 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 19:11:04 -0000 The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ From nobody Mon May 4 12:11:48 2020 Return-Path: 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 B86693A12C0; Mon, 4 May 2020 12:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 j38g36zA865Y; Mon, 4 May 2020 12:11:44 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 C7B263A137A; Mon, 4 May 2020 12:10:11 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id i27so9883502ota.7; Mon, 04 May 2020 12:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AJCFR8w+LT3cBGyKvix/N+oOumA6ORJIeTtVWzsNHbo=; b=Qx1strQvBwd7i2jSUDP09myXRtGX8kVcaHxJfndn3+OeQLKisa1gmQ5elLAq+gxIZW oIVHj4ZgP/757CRv9q7ZJAZcLLt32c3+QsyHf0qkNZELPbmOUqvE6WZ8aUHlD2sKEuem 9QHKdjWCCFivd0hOQfJDTpY6fTxuyKFalY95OtAJUEKBSTtK4zU6DNAVFQO7g596KpxG Z0Bri94GMoeEKqUaFlvY/ywgL5yZdXc/uWW4ck4XFiERwnxRUBtLnQqEJsJNTTFYqG/u 1jKhO4DwMaEbb94vNduT98zl54ePptJUmx1Qjz9C3lI+pdX+DMYWhHMQg+HUV8p4CU74 913g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AJCFR8w+LT3cBGyKvix/N+oOumA6ORJIeTtVWzsNHbo=; b=XGzw9CtwxnMnybvW+ChgnQMtCzlEGA37HyLfcLBFoUx/PU4cq1IoDbu3ZD+pONY+Y6 7Pyu/KscJJS0qvIWVh/VHIO18hTAL0DBpy4rPnX2cBTehCR/6t6veVT1RPeInxuL9umw A2MB8y/pqmzd1RQcIKPI10EN7eX21v8sQI1gP72pqCf5zFR6NSAaU1dWpFxGO6y8i81W CjbCqcQqTNLL89ut9cTIfsjYul/KNQBT2qKeHMpIU/IE1sgU/9jSQMFkblYt5NCtmECd iXDKciZeGbrx5uNg1jTcQDSX6f0ZXCot/jG8AL2cZjhsofG/ekG59vyb7Bsrp1zqfvuZ oKMw== X-Gm-Message-State: AGi0PubQOGqaz/w91GeJ4dPOz1tL3lpHvgkFRsaElqfiH35bM/Jw/wnq rjzwTB2qO9Kl/bciI03MsDZ4Y/ABQbxCujhW3WQ= X-Google-Smtp-Source: APiQypKM7ia5Zx+HVmdZjFRJ5oGAgvpCQlhML9A9pnsIiCHixyzQnPCHlZw7qemBL0/sN9m2T29I7jwl5wP+0m8t4S8= X-Received: by 2002:a9d:620c:: with SMTP id g12mr15934632otj.158.1588619411052; Mon, 04 May 2020 12:10:11 -0700 (PDT) MIME-Version: 1.0 References: <7262A449-1171-49E8-BDF6-69601DB034EE@hopcount.ca> <8F265AC8-9369-40B6-9AE8-C8D8ED190320@isc.org> In-Reply-To: From: Tim Wicinski Date: Mon, 4 May 2020 15:09:59 -0400 Message-ID: To: Wes Hardaker Cc: Joe Abley , Mark Andrews , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000addd2805a4d747a7" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 19:11:47 -0000 --000000000000addd2805a4d747a7 Content-Type: text/plain; charset="UTF-8" All The call for adoption period has ended and there has been enough consensus to adopt this and work on this. thank you tim On Fri, May 1, 2020 at 7:51 PM Wes Hardaker wrote: > Joe Abley writes: > > > Anyway, I am fairly confident in saying that there are legitimate, > > normal operational processes that can result in orphan glue, and that > > it's not correct to infer that they all exist for reasons of poor > > hygiene. > > For the record: I certainly (and I doubt Paul) envisioned that this > draft would be useful and deployable to every possible > TLD/registration-point. It, hopefully, will be desired by some. > > Though ones that want to "convert" hanging glue in their zone to something > that this > draft could accommodate should be able to insert a new zone NS and > delegate to their own servers with a new zone (and new dnskey). The odd > corner case someone mentioned is if the NS record was pointing to > company.example, rather than ns1.company.example or something. Then > there is the interesting discussed question of whether company.example > can delegate an NS to its own name [curious minds want to know]. > > -- > Wes Hardaker > USC/ISI > --000000000000addd2805a4d747a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
The ca= ll for adoption period has ended and there has been enough consensus
<= div class=3D"gmail_default" style=3D"font-family:monospace">to adopt this a= nd work on this.=C2=A0

thank you=C2=A0

tim


On Fri, May 1, 2020 at 7:51 PM Wes Hardaker <wjhns1@hardakers.net> wrote:
Joe Abley <jabley@hopcount.ca>= writes:

> Anyway, I am fairly confident in saying that there are legitimate,
> normal operational processes that can result in orphan glue, and that<= br> > it's not correct to infer that they all exist for reasons of poor<= br> > hygiene.

For the record: I certainly (and I doubt Paul) envisioned that this
draft would be useful and deployable to every possible
TLD/registration-point.=C2=A0 It, hopefully, will be desired by some.

Though ones that want to "convert" hanging glue in their zone to = something that this
draft could accommodate should be able to insert a new zone NS and
delegate to their own servers with a new zone (and new dnskey).=C2=A0 The o= dd
corner case someone mentioned is if the NS record was pointing to
company.example, rather than ns1.company.example or something.=C2=A0 Then there is the interesting discussed question of whether company.example
can delegate an NS to its own name [curious minds want to know].

--
Wes Hardaker
USC/ISI
--000000000000addd2805a4d747a7-- From nobody Mon May 4 13:28:54 2020 Return-Path: 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 AC7C03A1018 for ; Mon, 4 May 2020 13:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 lO5qF5olTDr4 for ; Mon, 4 May 2020 13:28:52 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 917763A1011 for ; Mon, 4 May 2020 13:28:42 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id x73so564377lfa.2 for ; Mon, 04 May 2020 13:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9Im/QBLGommnX7cWVUXzR6hsxPbD+oPKhdv276QI1+M=; b=bLPA2o/oHQCsiEcI5JFxhg3IL/yIG2J6vOPzoR6SXoqNPccF2CjWZ8Vkq8n6acHsC9 EkMPH0v5JUvmmK/WC/heygzPx2LYyfp0XMChLuBZYAME4F0B9gT/Kw9CDvPu09rldQf4 PSSjmAPxr3nfu4Uim4aL7oHwlfjEWt73y7V5ra0O82ttNtSqjVSNs4NQeQLlc6AjGc6I nV7s84Fqd5Aou4DuI/nIqEWq9JjFS9py1JYR9mbYqH4ffhef/lgQP5WRJWbjk2cI3ztE BtzrtjHxFOybbRm0Yb85tFKmQAGIyf9siZSicaE9RGDKhu2B4ZQJw55xJxvY9k5ItBxs 0PZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9Im/QBLGommnX7cWVUXzR6hsxPbD+oPKhdv276QI1+M=; b=CvxtwfzH7gk05t9wQIntFdyJcYABPqo5Jrk4DnL2iNIsvXq7avJpTTJazIPJAT4phr xy0X/6xO/XFffdJGMkjX6WyGca2JiiQ4jaMlcWHwogjAJy81QJEpfjVo+cctzEQpbnHz +hBLo5tx0lDwCOLMvJ5wC7xfDEroH8Xf4arh5yE+9tYzdvusbbEg4l8mNTbjU8gMi3fi uFgRqVPgev/qqzKjD021cuF9qCu1+8FsPnlaqXD5D/NIxGxKRxZYWjJvSzOJ04WL/F8B BSlAo/vVwUpIRLCSR9afdXjmS4Se0f4QFLyzzQXArEUjc4Ht8TLfPPTkZZvsb7Srf7hx ZiHw== X-Gm-Message-State: AGi0PubWt5X/isCniZsTTaJZS7CjILcGiN7e/uFjx/IZ1ryHHfMLO1r6 2S6CyAJeOWc2FnkpmV0nBWitQXxPFA8fnEdoGES6Pjuu X-Google-Smtp-Source: APiQypI6qW08G5PhOSpCrljQNwZh5LwYBpoq6X+7N9zL442TPXgBIh0QrkWMandhn7etVpFcRdabkn9B/m/r1LB7ou4= X-Received: by 2002:ac2:5dfc:: with SMTP id z28mr11660596lfq.1.1588624120423; Mon, 04 May 2020 13:28:40 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: <158861946403.9316.9132034162941715598@ietfa.amsl.com> From: Bob Harold Date: Mon, 4 May 2020 16:28:29 -0400 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary="00000000000061430f05a4d86070" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 20:28:54 -0000 --00000000000061430f05a4d86070 Content-Type: text/plain; charset="UTF-8" Looks useful, I will review. -- Bob Harold On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > > The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in > state Call For Adoption By WG Issued (entered by Tim Wicinski) > > The document is available at > > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000061430f05a4d86070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat &= lt;ietf-secretariat-repl= y@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000061430f05a4d86070-- From nobody Tue May 5 07:32:40 2020 Return-Path: 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 EE5803A07A9 for ; Tue, 5 May 2020 07:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 41bThTZoCeI2 for ; Tue, 5 May 2020 07:32:36 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 9C4CA3A07F5 for ; Tue, 5 May 2020 07:32:34 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id u12so1380266vsq.0 for ; Tue, 05 May 2020 07:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nE1ED0QuCoGgBQw0ZyTjM2thUOVfXtye4qfaw8UvEOs=; b=MJPWz2XfUpPHH/JpPEykqTuOtm9WFgM5s3IBKa0Ym9yLcIq19ZLusFcWrWSavxII8z EbVuyDtfnIpYKwY+ayTFNEt/UVtSKGGHSqfQIbxMXuHP0w+l9BJXLZnzRsorjl1WsHc9 HB+EONuwVb6eF7rZAY+1wA491/jvk7RHhf2dXHBBzM9MNTbZ24Gqgh20DLtLrCLf/5xm qpqPNwa9/T8g3dGpA5YtxtppSgrhVUEHvZtBSj3fEWG+bSwjoCQix3twWTjXGKlacAxd Pu6jKgGV25GFNhvKHZyz3LySzq9bZBxOa3dUs33nX04t4UWq1fEIe+/zFCL/jJSkCeY8 NqqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nE1ED0QuCoGgBQw0ZyTjM2thUOVfXtye4qfaw8UvEOs=; b=CGSyJPoQ6aUViEtKTb49MXRa1v7RBuxgbrAlxDDAGLG0NN7pJemUu3Hp/QOUYw1Q2m gt8cNT3rEev1ih4oN7igT0WinidunnPgDyvqkNcHvhjoY58N48GvpxI7OEUaslkMc8rL S8nrJE8BR4nv5R9QYzI3eWwizz1/Hb0RubztiMySkj35fF80l5Fly7vYS5sS9cGT8W1H syLOFEcuhptDQjzw25WdTuGkwm1Ke/8qsdVxdSgUrsG1I/NNyy8iW4vrpAX8rPaU+ftK mgpnUTpNP+zYrW2/LyU2f29IiOd17gWIyKF/6W57yVoywVfmCJqzi4X7mw4XYoq2oPSO jh+Q== X-Gm-Message-State: AGi0PuacqNoubebRwUdxvsF18YUqgXg2yVuxdhDaVTYNgROFIKKzZLWn YZ5mS7aCASrVZLhybHIIpAZWLWwBNJb5tfXjnJQ= X-Google-Smtp-Source: APiQypKn7oVBJRMUV3Xs5vpcpBqrJWHYi/GkZwo1CcLuQj8a9EUML/6f8j3nZboK4MSrkggUBQnuq0hNikOakXtL0JI= X-Received: by 2002:a67:680e:: with SMTP id d14mr3199144vsc.180.1588689153602; Tue, 05 May 2020 07:32:33 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Tue, 5 May 2020 10:32:22 -0400 Message-ID: To: Bob Harold Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="000000000000a8b79805a4e7841f" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 14:32:38 -0000 --000000000000a8b79805a4e7841f Content-Type: text/plain; charset="UTF-8" Hi, As a co-author, I am supporting the draft. I believe the document is useful to encourage enabling DNSSEC validation on resolvers. Yours, Daniel On Mon, May 4, 2020 at 4:29 PM Bob Harold wrote: > Looks useful, I will review. > > -- > Bob Harold > > > On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < > ietf-secretariat-reply@ietf.org> wrote: > >> >> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in >> state Call For Adoption By WG Issued (entered by Tim Wicinski) >> >> The document is available at >> >> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --000000000000a8b79805a4e7841f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

As a co-author, I am supporti= ng the draft. I believe the=C2=A0document is useful=C2=A0to encourage enabl= ing DNSSEC validation on resolvers.

Yours,=C2=A0
Daniel

On Mon, May 4, 2020 at 4:29 PM Bob Harold <rharolde@umich.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Looks use= ful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <ietf-secretar= iat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--000000000000a8b79805a4e7841f-- From nobody Tue May 5 07:50:54 2020 Return-Path: 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 5F5363A0882 for ; Tue, 5 May 2020 07:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 iMZDEZnnYdWN for ; Tue, 5 May 2020 07:50:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 369383A0872 for ; Tue, 5 May 2020 07:50:42 -0700 (PDT) Received: from [192.168.6.18] (nat-45.starnet.cz [178.255.168.45]) by mail.nic.cz (Postfix) with ESMTPSA id 9B78613FB56 for ; Tue, 5 May 2020 16:50:39 +0200 (CEST) To: dnsop@ietf.org References: <158828214716.7748.7938281376930754647@ietfa.amsl.com> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz> Date: Tue, 5 May 2020 16:50:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158828214716.7748.7938281376930754647@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 14:50:53 -0000 Hello, I'm still a bit skeptical. 1. Validation without logging. At the end of 3.1 you claim that mode is still useful.  When I focus on intentional attacks, signing a malicious DS seems among the easiest ones, and that can't be detected without the attacked machine doing logging (the DS might be served to specific targets only).  Consequently I'm doubtful about implementing and deploying such a "half-secure" approach in validators, especially as the RFC draft feels very hazy about the way logging might be done. 2. Amount of logging. The draft implies it would allow to very significantly decrease the amount of data that needs to be logged.  Zones without the bit perhaps won't be logged, but I hope that wasn't a significant point.  The draft doesn't explicitly say what would be logged; my conclusion for zones using this bit is that "we" would need basically any authoritative (i.e. signed) data except for NSEC* records that have DS bit and miss opt-out bit.  Am I missing something?  As for large TLD zones, even in best currently practical case the reduction seems by less than a half?  (missing DS bits in about half delegations) I expect that the whole trust chains to the logged records are also needed, so that the logger can prove they haven't forged the records. --Vladimir From nobody Tue May 5 08:52:07 2020 Return-Path: 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 8FE563A0836 for ; Tue, 5 May 2020 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 p2cS4f1ov0GC for ; Tue, 5 May 2020 08:52:03 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690055.outbound.protection.outlook.com [40.107.69.55]) (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 7FF8E3A082F for ; Tue, 5 May 2020 08:52:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzJM5DBdKbXmAf2vnV8UMrtRDXItHpzVkNhXd09Iv4wmBHxIBW/lyvf9ricUsbazoTnqrZhQu99dgsW+QMBK3vX+Wal1x0EZPQluITH6Tj7o3KU2mhKt4uqhpPobaclZ9JUu+dVF/ExVqZQD1TXg2o8eKjmFuO5mqrAz16nsI3VZlgbr6ZeApabDoz0XBbneLQSZ/jM7iXaNIxebCv6xFlOoLeUnXH7ZlVAZ+m1yFJWcKZKzisnBjBwjpxZKy1/J7MZ/eYl8OkxAGKqA5ln0EpFyqrvJ/PNphSYC46/DbyNlOnf58q+Yy9I1MvS6wrd09wAcV4QK/h3WZ7d93wWMAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FNlSxx+/JzQhFsFUkXP3UP5oif/asR93es/X9FbKaYc=; b=nHm78kqu56j5uufEWRTfCA0ojBqz38+94QnUt681idQiQWUQCvThZFcGL5ljBGrFpIcvmatYVDi4pGI+XOJKbeKbZUvbjU2uJJiXNzQ5Fx7G8BmSPvWJFpK6BdUPYJOeMJTzMNCdWfXT4IUdvu10aifRR1QFoOWZy8Tauz8wK/TOSlpaeYa8RazR7gSLf1Dq/WOzUw573M0Fa4tjq+v8DtyBiI82NkOvvO2rhJ8hCJyYH7CXzNxhJlLTkDblhdsUKlEuA2rsxta/OxKapF5DNuREjRETpm9jZBe2wOJxIsr4MuL9llTY32eXqDzU8e1VFEna75VaB5xaM7PHSrHQuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FNlSxx+/JzQhFsFUkXP3UP5oif/asR93es/X9FbKaYc=; b=PKxdxPe5+dpfoJjvOWBFRGEeQ6pzjjIJ1LoGWACzW9TVX+uMm0eZ9U03vcBCWpNA0xHc15CQ0XSNOY0kiLqgBQVi0ttCkFryL+odVaJZ/PCRHKc8qXcxCk1mW9nbpFOZ3P7K3Dr9sWlvyrhHWhI0isbn05I5y00OB+r1xweo730= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SA0PR15MB3853.namprd15.prod.outlook.com (2603:10b6:806:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Tue, 5 May 2020 15:52:02 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::d8e8:2ec6:b919:f687]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::d8e8:2ec6:b919:f687%5]) with mapi id 15.20.2958.030; Tue, 5 May 2020 15:52:02 +0000 From: Daniel Migault To: Bob Harold CC: dnsop Thread-Topic: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" Thread-Index: AQHWIkgTTkxuD0lvdkKTIY7Mf2UtQKiYYJSAgAAASQCAAT9JFQ== Date: Tue, 5 May 2020 15:52:02 +0000 Message-ID: References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: umich.edu; dkim=none (message not signed) header.d=none;umich.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f067768-f139-4232-94c3-08d7f10c40bd x-ms-traffictypediagnostic: SA0PR15MB3853: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vlqXbyWSd1y92wThLLp8jcoT/JKOL4owKcOAcFljTSIYi9T+1/LNJOHvVrdTE08pGIID0NBTq4vWsw2uSpWYKuot7A+05mtzI4SfXnjmOwn5b/PrDKZiTExUgnMNSqBEhCEBj8Ma9yUl1Jxd/chHbqgHn0jAY1tQ506LpNovwPvBzUYhcpvqIJhc29biTYvujX4qLZCLaZNS2oKHLxDJG7YWfIgMwP8gNXkVE/YOIcA9cL9bym7UaXcL1JVbQqYE2+25MDz1e0Ya63gsHYDWqp6Eiih15aG9YmZvP+tPCyjzc3+JASMiheGnPAixkf4lkN8SpWZ3OthzPoYkxVD0/+51jtgGayFwWe0eXpJChFt2x5rvLuXY5v2syZF/PHKN3sjig2fcb2hJIIXOTI33Azo4FVLW/eBQ1yW4sznDHQY+FUP1PYXGQfKwG0pkAWw06/6kf9QYsEMMig9fH2juqLLokNT8t2H21H4rBB/daXMT93obQHjK5w2RRYkrE11NenquQ3PTBUrRXcGnd3HPggvqd9WxEg7xRswIhRBLl+RsxHIgZC+KmJOFOh36MB54cXuKjWHvU5AqHxqs6kriX4PzTQCaBaab9sVJ4aCorqE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39860400002)(376002)(136003)(366004)(33430700001)(7696005)(86362001)(55016002)(2906002)(8936002)(33656002)(19627405001)(186003)(33440700001)(26005)(52536014)(66556008)(71200400001)(478600001)(66446008)(4326008)(66476007)(6916009)(64756008)(76116006)(5660300002)(966005)(91956017)(66946007)(316002)(53546011)(8676002)(9686003)(44832011)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SXqMXgPObnYKBdnmFkiqcxqKUbHhgOcap0CCxk4E3ab5TY3jM4LPMY8UOptn3KMt89IwZms0hNUih6PRgF++oN5vR/xc/ttCh8k12Zo+17PICTqfMYrmCFzgkpweZ/aCdK70BiP6HLV0tem9FBLEmjA1hbANsewoI8lIYf1TbQ1Bs5Ynygvbq1+JZ+fW51jBCSpBFDfyqLmo2cpBV6pKMGVlfdLkX2Va45KQfMf4Lg7l0Xij/iiL48BuN1CIRjJr+hXgcOD4yadsfaZJ+Wbo0sD2dxo9Sl31bUx/n9pdriH3gmTeGkqMVKRKpNGqp7XqGwBqQbkitSx+F6nHiUoxUpkPxkIVurrmOgTwy0Pl2ZgcXPiDPLW4Q73XVbSUupUY8oMuc6xzG/YnSB42UqYqXkA7HKdMM0BODjJ0mDMgP6RqUaTHV1m7cOrIoFzjNaA9LBqIOZdubPQ0xahp8gek/PPzOg1g1mHDp5+3EfqakQxdoYLFWVOTGWfY17ruPBeOorN0qWFlhVQpES3s21QCYhl34W1T5Yihbrt9r7jvNUPWT2gewpSvL0zGaFWDVzU6tksKYHXJR6KgzuFzOxUufcTiOjqFo5XHkOqXgXlHhirZhazpvhRAVUndkjWaH/T0y7vE5r0R8wbpDevN74w93mk4+HqnH/jpPBAEnq9PG7xeUjvV1uYGsuc4LL69sOv1rOsO3udt8E+PCAJwvzJGz2IolFb18cVz+/QPDMALNOKR4lig7R2rR8uFf6K/lokmWS27z72lL6Eit0f9RojkmqnuYVLpXP8fxScdBSaUGps= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB379199F512D21F540C066464E3A70SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f067768-f139-4232-94c3-08d7f10c40bd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 15:52:02.3655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EysamToZ2ug3tWX5DA+ixyPTgunCfJ2E5PajWZqb+WzgpfEdfHYxodTax9CSJeHEjlzbeVny/QF6+mlet9hgur6OjMRG6uNGs/OxbiNUFJw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR15MB3853 Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 15:52:06 -0000 --_000_SA0PR15MB379199F512D21F540C066464E3A70SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2]. I propose the following text. Does it clarify the concern ? Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems. "Not updating the configuration file prevents a failed synchronization to to the absence of write permission that are hardly in the control of the software." [1] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/= blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd [2] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/= commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce208282= 8d70d2bf35 [https://avatars1.githubusercontent.com/u/6602698?s=3D400&v=3D4] bob's comment =B7 mglt/draft-mglt-dnsop-dnssec-validator-requirements@f8ab6= 74 Contribute to mglt/draft-mglt-dnsop-dnssec-validator-requirements developme= nt by creating an account on GitHub. github.com ________________________________ From: Bob Harold Sent: Monday, May 4, 2020 4:29 PM To: Daniel Migault Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valid= ator-requirements in state "Call For Adoption By WG Issued" Minor nits: 7. Trust Anchor Related Recommendations Last sentence, last few words: "in section Section 8" > "in Section 8" addressed 7.2.1. Automated Updates to DNSSEC Trust Anchors "TA updates is" > "TA updates are" addressed "but due to human" > "due to human" addressed 7.2.2. Automated Trust Anchor Check "Not updating the configuration file prevents a failed synchronization to to the absence of write permission that are hardly in the control of the software." I propose the following text. Does it clarify the concern ? Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems. Seems confusing, please rewrite. "The TA can be queries" > "The TA can be queried" addressed "does not only concerns" > "does not only concern" addressed "if the mismatch result" > "if the mismatch resulted" addressed 8. Negative Trust Anchors Related Recommendations "disable the signature check for that key the time" > "disable the signatur= e check for that key until the time" addressed "This does not prevents" > "This does not prevent" addressed "either an attack or a failure into" > "either an attack or a failure in" addressed 10.1. Automated Reporting "will take the appropriated steps" > "will take the appropriate steps" addressed -- Bob Harold ---------- Forwarded message --------- From: Bob Harold > Date: Mon, May 4, 2020 at 4:28 PM Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued" To: IETF DNSOP WG > Looks useful, I will review. -- Bob Harold On Mon, May 4, 2020 at 3:13 PM IETF Secretariat > wrote: The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirem= ents/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --_000_SA0PR15MB379199F512D21F540C066464E3A70SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bob, 

Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2]. 

I propose the following text. Does it clarify the concern ?
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.


"Not updating the configuration file prevents a failed
   synchronization to to the absence of write permission that are= hardly
   in the control of the software."

<mglt>
<= ;/mglt>




From: Bob Harold <rharol= de@umich.edu>
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnsse= c-validator-requirements in state "Call For Adoption By WG Issued"= ;
 
Minor nits:

7.  Trust Anchor Related Recommendations

Last sentence, last few words:
"in section Section 8" > "in Section 8"

<mglt>
addressed
</mglt>

7.2.1.  Automated Updates to DNSSEC Trust Anchors

"TA updates is" > "TA updates are"

<mglt>
addressed
</mglt>

"but due to human" > "due to human"

<mglt>
addressed
</mglt>

7.2.2.  Automated Trust Anchor Check

"Not updating the configuration file prevents a failed
   synchronization to to the absence of write permission that are= hardly
   in the control of the software."

<mglt>
I propose the following text. Does it clarify the concern = ?
Avoiding the configuration file to be updated prevents old= configuration file to survive to writing error on read-only file systems.<= br>
</mglt>

Seems confusing, please rewrite.

"The TA can be queries" > "The TA can be queried"

<mglt>
addressed
</mglt>

"does not only concerns" > "does not only concern" <mglt>
addressed
</mglt>
"if the mismatch result" > "if the mismatch resulted"= ;
<mglt>
addressed
</mglt>

8.  Negative Trust Anchors Related Recommendations

"disable the signature check for that key the time" > "di= sable the signature check for that key until the time"
<mglt>
addressed
</mglt>

"This does not prevents" > "This does not prevent" <mglt>
addressed
</mglt>
"either an attack or a failure into" > "either an attack = or a failure in"
<mglt>
addressed
</mglt>
10.1.  Automated Reporting

"will take the appropriated steps" > "will take the appro= priate steps"
<mglt>
addressed
</mglt>
--
Bob Harold


---------- Forwarded message ------= ---
From: Bob Harold= <rharolde@umich.edu>=
Date: Mon, May 4, 2020 at 4:28 PM
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued"
To: IETF DNSOP WG <dnsop@ietf.org&= gt;


Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF= Secretariat <ietf-secretariat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--_000_SA0PR15MB379199F512D21F540C066464E3A70SA0PR15MB3791namp_-- From nobody Tue May 5 09:02:48 2020 Return-Path: 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 3D4553A0879 for ; Tue, 5 May 2020 09:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 A6_MzJwBq_tr for ; Tue, 5 May 2020 09:02:40 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 698173A08B8 for ; Tue, 5 May 2020 09:02:31 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id u203so622131vkb.11 for ; Tue, 05 May 2020 09:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L62r6+Dr81YMmuPuoWfqcQFwbNHEJ6DI1naryCjEdNE=; b=bY7Hi8PrEcnAUXl/y+vQJ6wNWOaD9HsuIwGLmk/1uHg551y9Y0A8VD3/keXvBH1rpv gS/yoCEQ4Fzw2g79tVpVsymtaYuG9H8txR4fspXwZhodzkGROsinjjH53HwdKj2v+rUb GQt0YFDI0YKFztypSU1thVnExzJ1iqP9eKkqd6bzL1dimdo4XosFmfwlehETv1mxsnG3 YJJrJx9nnANaCMnUhdzAeobitWR4fAkqOiSLAu+p0r7cxOHXwmLNOdrGGBBfwLgtgJPd lQeNQERBTvLN8Neo9uTK92JdjdN78dXajnKdavfZexEkMkgY7a1okSCt2PVp8mrpSG0z EcbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L62r6+Dr81YMmuPuoWfqcQFwbNHEJ6DI1naryCjEdNE=; b=e4+YxnhY/olcyVPWExGZRENnAIKGLl9ecXCsK4uO22A/F1Gkb7HxT9+5+q5EJ6XTvp qtMGyuA/uqugp5ed04c7MwQ+reR2hTQYOFErpDx61eH9munBuVLEz69o2z/SPNRp+kY5 yCSlaaEl83JLSXiA9extaz6uT6rlyK53wRC5Z9bb4pm7n8g0Wj1DysCXY/OyB1i9mLy7 TkSbkPFiYvW/c/T07Hd6oEBALooRWsy7O9yclR57sv21g6bwW0rpZDJV4lZXaopIiCNz v0utv4YlbvapkOAMHwM4B1xmWIwUS1mk1pCuIw4qxfYKJLpwxtDpaEo/I1pyToj+5rMx OU7g== X-Gm-Message-State: AGi0Puae0RAt3QhQKHyqaAZ8MiggBmb/fpvEf/zampSBhnAnfgNX/bU5 AJxaJcpdbQvYKzhdFb75X2Jh98cOgYxFkge9mly+R/ur X-Google-Smtp-Source: APiQypKHt3GtAZBlSan3M4B+BgqmuxyuIfIj3b0V6ybCjyRFbWarHWK6uRWa5LHHLeZF22Gzs++FTRPQPeehV7BZW2k= X-Received: by 2002:ac5:c2ce:: with SMTP id i14mr3234729vkk.30.1588694550281; Tue, 05 May 2020 09:02:30 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Tue, 5 May 2020 12:02:18 -0400 Message-ID: To: Bob Harold Cc: dnsop Content-Type: multipart/alternative; boundary="00000000000053816705a4e8c6da" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 16:02:45 -0000 --00000000000053816705a4e8c6da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, I apology the previous email has just been sent unexpectedly. Thanks for the comments. The new version of the file is available here [1] and a diff is available at [2]. I propose the following text for clarification. Feel free to let me know if that addresses your concern. OLD: Not updating the configuration file prevents a failed synchronization to to the absence of write permission that are hardly in the control of the software." NEW Avoiding the configuration file to be updated prevents old configuration file to survive to writing error on read-only file systems. Please inline other comments. Yours, Daniel [1] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob= /master/draft-mglt-dnsop-dnssec-validator-requirements.mkd [2] https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/comm= it/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70= d2bf35 On Tue, May 5, 2020 at 11:52 AM Daniel Migault wrote: > Hi Bob, > > Thanks for the comments. The new version of the file is available here [1= ] > and diff can be seen at [2]. > > I propose the following text. Does it clarify the concern ? > Avoiding the configuration file to be updated prevents old configuration > file to survive to writing error on read-only file systems. > > > "Not updating the configuration file prevents a failed > synchronization to to the absence of write permission that are hardly > in the control of the software." > > > > > [1] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/bl= ob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd > [2] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/co= mmit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d= 70d2bf35 > > > bob's comment =C2=B7 mglt/draft-mglt-dnsop-dnssec-validator-requirements@= f8ab674 > > Contribute to mglt/draft-mglt-dnsop-dnssec-validator-requirements > development by creating an account on GitHub. > github.com > > > > ------------------------------ > *From:* Bob Harold > *Sent:* Monday, May 4, 2020 4:29 PM > *To:* Daniel Migault > *Subject:* Fwd: [DNSOP] The DNSOP WG has placed > draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoptio= n > By WG Issued" > > Minor nits: > > 7. Trust Anchor Related Recommendations > > Last sentence, last few words: > "in section Section 8" > "in Section 8" > > > addressed > > > 7.2.1. Automated Updates to DNSSEC Trust Anchors > > "TA updates is" > "TA updates are" > > > addressed > > > "but due to human" > "due to human" > > > addressed > > > 7.2.2. Automated Trust Anchor Check > > "Not updating the configuration file prevents a failed > synchronization to to the absence of write permission that are hardly > in the control of the software." > > > I propose the following text. Does it clarify the concern ? > Avoiding the configuration file to be updated prevents old configuration > file to survive to writing error on read-only file systems. > > > Seems confusing, please rewrite. > > "The TA can be queries" > "The TA can be queried" > > > addressed > > > "does not only concerns" > "does not only concern" > > addressed > > "if the mismatch result" > "if the mismatch resulted" > > addressed > > > 8. Negative Trust Anchors Related Recommendations > > "disable the signature check for that key the time" > "disable the > signature check for that key until the time" > > addressed > > > "This does not prevents" > "This does not prevent" > > addressed > > "either an attack or a failure into" > "either an attack or a failure in" > > addressed > > 10.1. Automated Reporting > > "will take the appropriated steps" > "will take the appropriate steps" > > addressed > > -- > Bob Harold > > > ---------- Forwarded message --------- > From: *Bob Harold* > Date: Mon, May 4, 2020 at 4:28 PM > Subject: Re: [DNSOP] The DNSOP WG has placed > draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoptio= n > By WG Issued" > To: IETF DNSOP WG > > > Looks useful, I will review. > > -- > Bob Harold > > > On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < > ietf-secretariat-reply@ietf.org> wrote: > > > The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in > state Call For Adoption By WG Issued (entered by Tim Wicinski) > > The document is available at > > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requir= ements/ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 Daniel Migault Ericsson --00000000000053816705a4e8c6da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,=C2=A0

I apology the previous email has just been sent un= expectedly.
=C2=A0
Thanks for the comments. The new version of the file is available here [1] = and a diff is available at [2].=C2=A0

I propose the following text for clarification. Feel free to let me know if= that addresses your concern.=C2=A0

OLD:
Not updating the = configuration file prevents a failed=C2=A0synchronization to to the absence= of write permission that are hardly in the control of the software."<= br>

NEW
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.

<= div style=3D"margin:0px;color:rgb(50,49,48)">Please inline other comments.<= /div>
Yours,=C2=A0
Daniel



On Tue, May 5, 2020 at 11:5= 2 AM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi Bob,=C2=A0

Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2].=C2=A0

I propose the following text. Does it clarify the concern ?
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.


"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
</mglt>

3D""
Contribute to mglt/draft-mglt-dnsop-dnssec-validator-requirements developme= nt by creating an account on GitHub.



From= : Bob Harold <rharolde@umich.edu>
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnsse= c-validator-requirements in state "Call For Adoption By WG Issued"= ;
=C2=A0
Minor nits:

7.=C2=A0 Trust Anchor Related Recommendations

Last sentence, last few words:
"in section Section 8" > "in Section 8"

<mglt>
addressed
</mglt>

7.2.1.=C2=A0 Automated Updates to DNSSEC Trust Anchors

"TA updates is" > "TA updates are"

<mglt>
addressed
</mglt>

"but due to human" > "due to human"

<mglt>
addressed
</mglt>

7.2.2.=C2=A0 Automated Trust Anchor Check

"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
I propose the following text. Does it clarify the concern = ?
Avoiding the configuration file to be updated prevents old= configuration file to survive to writing error on read-only file systems.<= br>
</mglt>

Seems confusing, please rewrite.

"The TA can be queries" > "The TA can be queried"

<mglt>
addressed
</mglt>

"does not only concerns" > "does not only concern" <mglt>
addressed
</mglt>
"if the mismatch result" > "if the mismatch resulted"= ;
<mglt>
addressed
</mglt>

8.=C2=A0 Negative Trust Anchors Related Recommendations

"disable the signature check for that key the time" > "di= sable the signature check for that key until the time"
<mglt>
addressed
</mglt>

"This does not prevents" > "This does not prevent" <mglt>
addressed
</mglt>
"either an attack or a failure into" > "either an attack = or a failure in"
<mglt>
addressed
</mglt>
10.1.=C2=A0 Automated Reporting

"will take the appropriated steps" > "will take the appro= priate steps"
<mglt>
addressed
</mglt>
--
Bob Harold


---------- Forwarded message ---------
From: Bob Harold <rharolde@umich.= edu>
Date: Mon, May 4, 2020 at 4:28 PM
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued"
To: IETF DNSOP WG <d= nsop@ietf.org>


Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <ietf-secreta= riat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--00000000000053816705a4e8c6da-- From nobody Tue May 5 11:53:21 2020 Return-Path: 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 46D253A00D4 for ; Tue, 5 May 2020 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 0YCZN6ES5Vug for ; Tue, 5 May 2020 11:53:18 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4ACC93A00D5 for ; Tue, 5 May 2020 11:53:12 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id t2so49824lfc.3 for ; Tue, 05 May 2020 11:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=puWQhGXSRdessEMV64JuTmqj4sPOStNr9K3r6ch+Nb4=; b=HDwBkY+dJeiX9a56P2lylGX3oac3zTyVs1nREwIiK51PwYn1IMjTfvtqgkWqkXGBm7 Jc3jO8sD568MK/WyLF8m2Izn342RYcfziYYrww5nJ36Z7kp5Ox8ZNFi6X1VBF5LOZvHp JSIZd3IzufLYNdpRDFuFoVbOzA+E41DVkOs4TjV0yGGKnwWhMxEYzDFPuUxWNbcLgHAI M/bgMe/cdnvaIToPga4jRswQVkHHrd9Cv+gbq3fejblrveEqstEV6VnvE65g9QyzP+mG W/uaEHeu0FwyqzcIPzGPrgwUyEZw2B2lGj2luA0x7LZPx23VQ0EAe038HUaDWiINqGx8 16MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=puWQhGXSRdessEMV64JuTmqj4sPOStNr9K3r6ch+Nb4=; b=RY0bIUHrQlgbuugbaMcVSTpVhrpJ0YNVKkxkEp1Mv2ERCYJkAy8WZsJUV9cJTavRhK WY+GqTUCkTHf10YdOyuhj7kw95CuNaBAR0OKxn2AiGn2I1U258CjGCO8c9Pdqwp0Z7u3 W0/vmb2689kfKn881XeITWY59ycitRt/tW2bnc3NY5i7b8JYDBnpt/tboNnrgoksKTjo SThWjV7ZRO0ycdqJzTuEE66KS0Cp39Wd3BOeFXkATXLUFujUXxvkQabEFC8tNG3KIEks eVr3BA2KwUr27u2rrigAsKO8EaObhcv39/Un7Zz+67Kl2OCE30SOKctW5vVA9FKaWWUS dwJQ== X-Gm-Message-State: AGi0PuYI9+NJgY43K19J9rujbm1zZhCBjqCYkK+poQwtW5gv2Wg9D4rl SieE+ELgt1YgHp8oVAs25j9Tqh8QNV5y11RfqJUi7A== X-Google-Smtp-Source: APiQypIuxRKrdOsXcKaqBK+mFAHtmzhKcjGl0z1/PRmYnQ6mP0HfZYLFSZhH269Rctho2YDOOOya8xF66wZDB4NEO6s= X-Received: by 2002:ac2:531c:: with SMTP id c28mr2534105lfh.138.1588704790329; Tue, 05 May 2020 11:53:10 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: From: Bob Harold Date: Tue, 5 May 2020 14:52:59 -0400 Message-ID: To: Daniel Migault Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000ae4eca05a4eb28c6" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 18:53:20 -0000 --000000000000ae4eca05a4eb28c6 Content-Type: text/plain; charset="UTF-8" On Tue, May 5, 2020 at 12:02 PM Daniel Migault wrote: > Hi Bob, > > I apology the previous email has just been sent unexpectedly. > > Thanks for the comments. The new version of the file is available here [1] > and a diff is available at [2]. > > I propose the following text for clarification. Feel free to let me know > if that addresses your concern. > > OLD: > Not updating the configuration file prevents a failed synchronization to > to the absence of write permission that are hardly in the control of the > software." > > NEW > Avoiding the configuration file to be updated prevents old configuration > file to survive to writing error on read-only file systems. > I understand that we do not want the system to fail due to missing write permissions. It seems like this could be handled two ways: 1. Just keep in memory, and do not try to write a new configuration. That works, until the old trust anchor is removed, then it fails if the service is restarted. 2. Attempt to write a new configuration, but keep going even if that fails. If the write succeeds, then this works even after the old trust anchor is removed. I would prefer the second method. I think that is what some software already does. (BIND?) -- Bob Harold > > Please inline other comments. > > Yours, > Daniel > > [1] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd > [2] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 > > > On Tue, May 5, 2020 at 11:52 AM Daniel Migault 40ericsson.com@dmarc.ietf.org> wrote: > >> Hi Bob, >> >> Thanks for the comments. The new version of the file is available here >> [1] and diff can be seen at [2]. >> >> I propose the following text. Does it clarify the concern ? >> Avoiding the configuration file to be updated prevents old configuration >> file to survive to writing error on read-only file systems. >> >> >> "Not updating the configuration file prevents a failed >> synchronization to to the absence of write permission that are hardly >> in the control of the software." >> >> >> >> >> [1] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >> [2] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >> >> ------------------------------ >> *From:* Bob Harold >> *Sent:* Monday, May 4, 2020 4:29 PM >> *To:* Daniel Migault >> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed >> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >> By WG Issued" >> >> Minor nits: >> >> 7. Trust Anchor Related Recommendations >> >> Last sentence, last few words: >> "in section Section 8" > "in Section 8" >> >> >> addressed >> >> >> 7.2.1. Automated Updates to DNSSEC Trust Anchors >> >> "TA updates is" > "TA updates are" >> >> >> addressed >> >> >> "but due to human" > "due to human" >> >> >> addressed >> >> >> 7.2.2. Automated Trust Anchor Check >> >> "Not updating the configuration file prevents a failed >> synchronization to to the absence of write permission that are hardly >> in the control of the software." >> >> >> I propose the following text. Does it clarify the concern ? >> Avoiding the configuration file to be updated prevents old configuration >> file to survive to writing error on read-only file systems. >> >> >> Seems confusing, please rewrite. >> >> "The TA can be queries" > "The TA can be queried" >> >> >> addressed >> >> >> "does not only concerns" > "does not only concern" >> >> addressed >> >> "if the mismatch result" > "if the mismatch resulted" >> >> addressed >> >> >> 8. Negative Trust Anchors Related Recommendations >> >> "disable the signature check for that key the time" > "disable the >> signature check for that key until the time" >> >> addressed >> >> >> "This does not prevents" > "This does not prevent" >> >> addressed >> >> "either an attack or a failure into" > "either an attack or a failure in" >> >> addressed >> >> 10.1. Automated Reporting >> >> "will take the appropriated steps" > "will take the appropriate steps" >> >> addressed >> >> -- >> Bob Harold >> >> >> ---------- Forwarded message --------- >> From: *Bob Harold* >> Date: Mon, May 4, 2020 at 4:28 PM >> Subject: Re: [DNSOP] The DNSOP WG has placed >> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >> By WG Issued" >> To: IETF DNSOP WG >> >> >> Looks useful, I will review. >> >> -- >> Bob Harold >> >> >> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < >> ietf-secretariat-reply@ietf.org> wrote: >> >> >> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in >> state Call For Adoption By WG Issued (entered by Tim Wicinski) >> >> The document is available at >> >> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> >> > > -- > Daniel Migault > Ericsson > --000000000000ae4eca05a4eb28c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi Bob,=C2=A0

I apology the previous email has just been sent un= expectedly.
=C2=A0
Thanks for the comments. The new version of the file is available here [1] = and a diff is available at [2].=C2=A0

I propose the following text for clarification. Feel free to let me know if= that addresses your concern.=C2=A0

OLD:
Not updating the = configuration file prevents a failed=C2=A0synchronization to to the absence= of write permission that are hardly in the control of the software."<= br>

NEW
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.

I understand that we do not want= the system to fail due to missing write permissions.=C2=A0 It seems like t= his could be handled two ways:
1. Just keep in memory, and do not= try to write a new configuration.=C2=A0 That works, until the old trust an= chor is removed, then it fails if the service is restarted.
2= . Attempt to write a new configuration, but keep going even if that fails.= =C2=A0 If the write succeeds, then this works even after the old trust anch= or is removed.

I would prefer the second method.= =C2=A0 I think that is what some software already does.=C2=A0 (BIND?)
=

--
Bob Harold
=C2=A0
=

On Tue, May 5, 2020 at 11:52 AM Daniel Migault <daniel.migault=3D40ericsson.com= @dmarc.ietf.org> wrote:
Hi Bob,=C2=A0

Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2].=C2=A0

I propose the following text. Does it clarify the concern ?
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.


"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
</mglt>


From: Bob Harold <rharolde@umich.edu>
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnsse= c-validator-requirements in state "Call For Adoption By WG Issued"= ;
=C2=A0
Minor nits:

7.=C2=A0 Trust Anchor Related Recommendations

Last sentence, last few words:
"in section Section 8" > "in Section 8"

<mglt>
addressed
</mglt>

7.2.1.=C2=A0 Automated Updates to DNSSEC Trust Anchors

"TA updates is" > "TA updates are"

<mglt>
addressed
</mglt>

"but due to human" > "due to human"

<mglt>
addressed
</mglt>

7.2.2.=C2=A0 Automated Trust Anchor Check

"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
I propose the following text. Does it clarify the concern = ?
Avoiding the configuration file to be updated prevents old= configuration file to survive to writing error on read-only file systems.<= br>
</mglt>

Seems confusing, please rewrite.

"The TA can be queries" > "The TA can be queried"

<mglt>
addressed
</mglt>

"does not only concerns" > "does not only concern" <mglt>
addressed
</mglt>
"if the mismatch result" > "if the mismatch resulted"= ;
<mglt>
addressed
</mglt>

8.=C2=A0 Negative Trust Anchors Related Recommendations

"disable the signature check for that key the time" > "di= sable the signature check for that key until the time"
<mglt>
addressed
</mglt>

"This does not prevents" > "This does not prevent" <mglt>
addressed
</mglt>
"either an attack or a failure into" > "either an attack = or a failure in"
<mglt>
addressed
</mglt>
10.1.=C2=A0 Automated Reporting

"will take the appropriated steps" > "will take the appro= priate steps"
<mglt>
addressed
</mglt>
--
Bob Harold


---------- Forwarded message ---------
From: Bob Harold <rharolde@umich.= edu>
Date: Mon, May 4, 2020 at 4:28 PM
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued"
To: IETF DNSOP WG <d= nsop@ietf.org>


Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <ietf-secreta= riat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


--
Daniel Mi= gault
Ericsson
--000000000000ae4eca05a4eb28c6-- From nobody Tue May 5 13:51:47 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 623303A0AD5; Tue, 5 May 2020 13:51:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158871188730.7528.4018207019268407373@ietfa.amsl.com> Date: Tue, 05 May 2020 13:51:27 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 20:51:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Extended DNS Errors Authors : Warren Kumari Evan Hunt Roy Arends Wes Hardaker David C Lawrence Filename : draft-ietf-dnsop-extended-error-16.txt Pages : 15 Date : 2020-05-05 Abstract: This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 5 14:38:56 2020 Return-Path: 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 CF66A3A0BB1 for ; Tue, 5 May 2020 14:38:54 -0700 (PDT) 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 fZjV7rAFS-rp for ; Tue, 5 May 2020 14:38:53 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1103A0BCE for ; Tue, 5 May 2020 14:38:53 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id C56F42C86C; Tue, 5 May 2020 14:38:52 -0700 (PDT) From: Wes Hardaker To: Eric Orth Cc: dnsop References: <158775255558.2213.3792198241620384409@ietfa.amsl.com> Date: Tue, 05 May 2020 14:38:52 -0700 In-Reply-To: (Eric Orth's message of "Fri, 24 Apr 2020 15:15:27 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:38:55 -0000 Eric Orth writes: > "Because long EXTRA-TEXT fields may trigger truncation, which is undesira= ble given > the=C2=A0supplemental nature of EDE.=C2=A0 Implementers and operators cre= ating EDE=C2=A0options SHOULD avoid > lengthy EXTRA-TEXT contents." Thanks for pointing that out; it was indeed a failed edit at a different problem and has been fixed. > "As such, EDE content should be treated=C2=A0only as diagnostic informati= on and MUST NOT alter DNS > protocol=C2=A0processing." >=20 > (Sorry for not getting back and responding further on this subject in > the previous thread.) And I'm sorry for delaying getting back to you about you getting back to me about me getting... anyway. FYI, at least two of the authors agree with you, as resolvers are already making decisions based on unauthenticated information (rcodes). But this has been heavily discussed (multiple times) in the WG and the conclusion was that EDE cannot alter processing, hence the strong language. So in the end we didn't change the text to soften it, as it would counter the decisions of the larger past discussions. --=20 Wes Hardaker USC/ISI From nobody Tue May 5 15:17:34 2020 Return-Path: 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 D219B3A0BEB for ; Tue, 5 May 2020 15:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eJ7vZEpfht00 for ; Tue, 5 May 2020 15:17:30 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 569F83A0BEC for ; Tue, 5 May 2020 15:17:30 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id z6so201569wml.2 for ; Tue, 05 May 2020 15:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mxBB2CCmv/um9spAK0Ip19mWVKvIMwGZFGSHgyGLPGA=; b=el6bp83Gw+7onMLU+gf0VPDFphc+byqQJwC8a4wgZvE47+WBEQz/QIcmwUwijYZBVk ZvqmRisqrD6bxyfuE/3n/0XfZ0FEiGU5aFIaV7xMy6hOBHNCLB4NxoTOAVvZNST9j2r1 2UZF2El7RjY6FddOmHplVzHYrJwLLkODPwFnTbxYND58TywDb1kFjBkVXAhSjqwJ3Jkq z9hqmRHMS9lf0M8+LRnOsU9ixv4xTQSsuWm16Q3iQr2d+MgbbS7ZCtXQ7lxmxZe2Iho7 NDdZfewKtHekMurgaFm5KEGoLWxMntq8dcRmIPRA2j54WxicUhUzwVSjl/y4c3K9Te5z G8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mxBB2CCmv/um9spAK0Ip19mWVKvIMwGZFGSHgyGLPGA=; b=ixmJ/w8ZxD+1rP4tTTsyF5HoI6rg8YEeFi5/yNtpE65gLmSJ67RaoL2EtA+ip0NZCo TXvu1EzoFybRQd4evJCjjRIAVodmaRRNQhNdkpaJIrX+KQgd7Gsvt2bJ3KdbhcYfrwrY QQxYyN9o5avEeabeQ5xNtTq38xMoOYqjmsC6saPE1xmmfW0HNF1BLZhKYsRRf7uPM4I1 IyX9/4HdnRts1srAb7mct7IwX6yZ8BWTETaoFSYsiGjExNf+Otc3NoTcyNsd/j5Pxm5d qbW7NZaWQ+5tmzM+BooHAgRSPRhqU0JeP316RPYFTOTslGCZHtxH5sBPILzBZm0sy9BF 8qpQ== X-Gm-Message-State: AGi0Puai49Tp4Mq6xRAvM88FTjoFz6Q+exZAKAHGbhhC5BGlA4xC+qOL kiZIr4WWptqLPOVSPdkogsq28LFsKMesZjEKVEuYYh+G X-Google-Smtp-Source: APiQypIcl2f2YNXDbdyQKTdC6+6TpXdamIPwOyECaqE2W32KH686DfCbqWSKhEcq0MBRU/cW4OSaHSr8dphprYLAlaU= X-Received: by 2002:a05:600c:2c47:: with SMTP id r7mr782910wmg.50.1588717048267; Tue, 05 May 2020 15:17:28 -0700 (PDT) MIME-Version: 1.0 References: <158775255558.2213.3792198241620384409@ietfa.amsl.com> In-Reply-To: From: Eric Orth Date: Tue, 5 May 2020 18:17:17 -0400 Message-ID: To: Wes Hardaker Cc: dnsop Content-Type: multipart/alternative; boundary="0000000000004ff3af05a4ee0389" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 22:17:33 -0000 --0000000000004ff3af05a4ee0389 Content-Type: text/plain; charset="UTF-8" On Tue, May 5, 2020 at 5:39 PM Wes Hardaker wrote: > Eric Orth writes: > > > "As such, EDE content should be treated only as diagnostic information > and MUST NOT alter DNS > > protocol processing." > > > > (Sorry for not getting back and responding further on this subject in > > the previous thread.) > > And I'm sorry for delaying getting back to you about you getting back to > me about me getting... anyway. > > FYI, at least two of the authors agree with you, as resolvers are > already making decisions based on unauthenticated information (rcodes). > But this has been heavily discussed (multiple times) in the WG and the > conclusion was that EDE cannot alter processing, hence the strong > language. So in the end we didn't change the text to soften it, as it > would counter the decisions of the larger past discussions. > My counterargument is that I feel my objection is more language-based concerning ambiguity and not counter to the previous WG discussions. The general WG consensus was that EDE should be primarily for "diagnostic purposes". This draft goes beyond such consensus by banning "altering processing", a very ambiguous phrase that does not necessarily ban just non-diagnostic behavior or important decision making, as it could be debated whether clearly-WG-acceptable alterations such as altering logging counts as altering processing. I think the end result of the language as-is is that EDE receivers will either have to abandon EDE handling entirely to avoid any ambiguous potential of not being compliant with the spec, or we'll have to just willfully ignore this newly-added imperative to do whatever processing alterations we want (hopefully only for diagnostic purposes, but who knows). --0000000000004ff3af05a4ee0389 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 5, 2020 at 5:39 PM Wes Ha= rdaker <wjhns1@hardakers.net= > wrote:
Eric= Orth <ericorth=3D40google.com@dmarc.ietf.org> writes:

> "As such, EDE content should be treated=C2=A0only as diagnostic i= nformation and MUST NOT alter DNS
> protocol=C2=A0processing."
>
> (Sorry for not getting back and responding further on this subject in<= br> > the previous thread.)

And I'm sorry for delaying getting back to you about you getting back t= o
me about me getting...=C2=A0 anyway.

FYI, at least two of the authors agree with you, as resolvers are
already making decisions based on unauthenticated information (rcodes).
But this has been heavily discussed (multiple times) in the WG and the
conclusion was that EDE cannot alter processing, hence the strong
language.=C2=A0 So in the end we didn't change the text to soften it, a= s it
would counter the decisions of the larger past discussions.

My counterargument is that I feel my objection is more= language-based concerning ambiguity and not counter to the previous WG dis= cussions.=C2=A0 The general WG consensus was that EDE should be primarily f= or "diagnostic purposes".=C2=A0 This draft goes beyond such conse= nsus by banning "altering processing", a very ambiguous phrase th= at does not necessarily ban just non-diagnostic behavior or important decis= ion making, as it could be debated whether clearly-WG-acceptable alteration= s such as altering logging counts as altering processing.

I think the end result of the language as-is is that EDE receivers = will either have to abandon EDE handling entirely to avoid any ambiguous po= tential of not being compliant with the spec, or we'll have to just wil= lfully ignore this newly-added imperative to do whatever processing alterat= ions we want (hopefully only for diagnostic purposes, but who knows).
=
--0000000000004ff3af05a4ee0389-- From nobody Tue May 5 16:26:19 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F633A0C31; Tue, 5 May 2020 16:26:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-dnsop-extended-error@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, rfc-editor@rfc-editor.org, tjw.ietf@gmail.com, The IESG , Tim Wicinski , barryleiba@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158872117153.13289.8313420797853358463@ietfa.amsl.com> Date: Tue, 05 May 2020 16:26:11 -0700 Archived-At: Subject: [DNSOP] Protocol Action: 'Extended DNS Errors' to Proposed Standard (draft-ietf-dnsop-extended-error-16.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 23:26:12 -0000 The IESG has approved the following document: - 'Extended DNS Errors' (draft-ietf-dnsop-extended-error-16.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ Technical Summary This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Working Group Summary The document went through a rigorous consensus process, and there were several points which took a few iterations to resolve, but they were all resolved to strong approval from the working group. Document Quality There are no current implementations, but both software vendors and third party DNS providers are planning to implement these error codes now that the specifics have been agreed on. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba From nobody Tue May 5 18:18:29 2020 Return-Path: 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 675313A0CAA for ; Tue, 5 May 2020 18:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 m16fUa7d2Pd1 for ; Tue, 5 May 2020 18:18:24 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 8C3D13A0CB1 for ; Tue, 5 May 2020 18:18:24 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id 23so408389qkf.0 for ; Tue, 05 May 2020 18:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k+1+AxPe0Ocsrzxd6a9qrCQcIN15nqXs6JzemB7XADw=; b=E7QtcrRlu8LU0NspbIiQEQIRWytBEdQmIFWTg90oAus8M7gVyK6qDk5EPzXvBgUNNX nya56rIqrodNJgjoF7DuDjdtRVz98AGdR24phsNqu9fKTtKCSNPStKLvbibFfLV99TaK UluhqKDnAno69flWIeOZ0CiiaPbuVwGPZ8b/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k+1+AxPe0Ocsrzxd6a9qrCQcIN15nqXs6JzemB7XADw=; b=Gy+KtjywT99WJ3TPZbhvsPY4zXtr5ItwmIM2sNS3xsyTqUpj9ZBHhotwhfc0dForKT QNsFlddC9QSGklkhQoL7Jwzv8biT9eG7IwdtWs8tziqCGo6j7LWbiD3Lfn8XQEMkpD2n KCx/lyeNtgwQZS1af1nwczFMvji/VV9v5e97qqujYBqO5zgSr6YC4hk0x33PBvd7Hn/A ymWBMOVzpSp9ZZv8+hfJSeIDmURD6mdSCJtai9wNhUWc2w9ILI7MMkXPLGGLBrtHfTy9 ubCd0KpOBvUsBi8JjnyHFh3mULM/0iq1inJFivtqapFSpAOupGgSy2HtEuKTwReA6U9T pcKQ== X-Gm-Message-State: AGi0Puau7bNaJTCtb0umNn1umei9Iw9PEibADtAfqGGENFdsDoApAKd3 YaJ0qUopRmHJmzEmZcoNTHCpzOCDWkfUZrX7 X-Google-Smtp-Source: APiQypIXClzbWtDcpsUwAxfbpymOzSVHM6RkH8tyn8dcABcc48kgG4NDGNEF6CyjNbzyC1LoKaaxWA== X-Received: by 2002:a05:620a:1222:: with SMTP id v2mr6374485qkj.463.1588727902950; Tue, 05 May 2020 18:18:22 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:1d2f:a0ca:a0a1:1ab1? ([2607:f2c0:e784:c7:1d2f:a0ca:a0a1:1ab1]) by smtp.gmail.com with ESMTPSA id u13sm523518qkj.44.2020.05.05.18.18.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 18:18:21 -0700 (PDT) From: Joe Abley Message-Id: <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_63714ECF-69EC-4E23-ACAC-3CBA37D9D7E5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 5 May 2020 21:18:17 -0400 In-Reply-To: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> Cc: dnsop To: Roy Arends References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 01:18:28 -0000 --Apple-Mail=_63714ECF-69EC-4E23-ACAC-3CBA37D9D7E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Roy, On 2 May 2020, at 10:09, Roy Arends wrote: > Ed and I just submitted a new version of our private-use TLD draft. >=20 > https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >=20 > This draft has substantial more information than the first draft. It = explains that a private-use namespace does not exist, why it is needed, = and how a namespace aligned with the user-assigned alpha-2 code elements = in the ISO-3166-1 standard can be used as private-use namespace. >=20 > It contains plenty of examples of how user-assigned code elements are = used in the field, including other ISO standards, the UN, UNICODE, = CAB/forum, and the IETF itself. >=20 > This new version came about after fruitful discussions with peers = inside and outside the IETF. Most discussions were productive. This has = lead to the removal of the advice/example to use ZZ, as it was = distracting from the point of the draft: these two-letter top level = domains are available for private-use. I have read this document and I like it. There have been other proposals to make recommendations like this in the = past that I have not been very enthusiastic about. The reason I like = this draft-arends proposal more is that it neatly avoids the problem of = who gets to make policy about this stuff by pointing out that suitable = policies already exist and that hence the problem is already solved. I also like the happy accident that the names on the user-assigned list = are all pretty much equally arbitrary in every language in which = US-ASCII labels have the potential to have semantic meaning. This seems = better than choosing a label that is a recognisable word in some = languages but not others. I have two suggestions for the document. I have some doubt about the = second suggestion, but the first one seems definitely great. :-) 1. While this document currently includes instructions to the IANA that = could be viewed as specifying TLD naming policy, it might be possible to = avoid that particular hidden foot-operated explosive device with some = re-wording. This document could simply make the observation that since existing = ccTLD label policy is to defer completely to ISO-3166 alpha-2 (citation = needed) and since ISO-3166 alpha-2 includes user-assigned codes that = will never be assigned to a territory (citation needed) then it is = consistent with existing policies that those user-assigned codes will = never be delegated from the root zone in the DNS and, for that reason, = will never give rise to collisions with any future new TLD. That would leave this document simply as a clarifying description of = existing policy, instead of appearing to have ambitions to change or = specify policy in the root zone (which is the kind of thing that ICANN = is also plausibly responsible for). The consequence of that small change = might be (is, I think) to make this document completely uncontroversial = whilst preserving the core advice. No worm containment failure required. 2. The document stops short of making a clear recommendation in section = 5. While the decision to anchor a private namespace in something that = looks like a TLD is not necessarily the only plausible answer (I could = anchor such a namespace at a domain that I reserve through normal domain = registration, for example) the document *could* say "for applications = that require a private namespace anchored at something that looks like a = TLD, our recommendation is to do this". It is possible, of course, that a clear recommendation might have an = XKCD-927 effect (which would be unfortunate but perhaps tolerable) or no = effect whatsoever (which at least seems benign, but which is also a bit = useless). However, if the document is not going to make any clear = recommendation, I'm not sure what the point of publishing it is. Joe --Apple-Mail=_63714ECF-69EC-4E23-ACAC-3CBA37D9D7E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXrIQWQAKCRA0jwy9hlI6 LFgPAJ4yPhfV0DcfvwE7NH+q9T5HxIz/BwCbBCVUVeRjjlr9Um106qGV11mtMCg= =12Us -----END PGP SIGNATURE----- --Apple-Mail=_63714ECF-69EC-4E23-ACAC-3CBA37D9D7E5-- From nobody Tue May 5 19:57:42 2020 Return-Path: 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 06B663A0D04 for ; Tue, 5 May 2020 19:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Pah56OAP; dkim=pass (1536-bit key) header.d=taugh.com header.b=dtT6fET3 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 Wk_ggnFoLnAI for ; Tue, 5 May 2020 19:57:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D8E753A0D03 for ; Tue, 5 May 2020 19:57:37 -0700 (PDT) Received: (qmail 67644 invoked from network); 6 May 2020 02:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1083a.5eb227a0.k2005; bh=IQ4KA0GKlPirsJIfIuFlgdNPjWJqCd1aaB1KRakX0Vo=; b=Pah56OAPwiJI7O8/Rl07z7e8btfr5tqWP/GyACNT1+w4IZhpZK0D7snsna9gtg/Q3nraTPMlBVVI+7gtJ4+RWzTcDvPjQgsYD6zgiqLzBA9MKXocojXVpM4Mw3kT3nczVhavNgD1mQXqXTP/+fbJxzuWnHtfwH43sJt5ZHJbk+XGcGuZdQM+5CcaEB1tBGeCsE2t2IX/Q4pjV922pgpHHuRZzzp5ZhqsqKlc71auytrZITRYUeTJuJig86H55elZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1083a.5eb227a0.k2005; bh=IQ4KA0GKlPirsJIfIuFlgdNPjWJqCd1aaB1KRakX0Vo=; b=dtT6fET35KO9yLoXIFwt7Xij0R9ROSPu2u/Kqt5Uu35sQFUUmvwy8OehGIjPAeSihja0M7LeMMB/AGapCPpS87DgL2Z+xml1lV3G+dunWq8DTQxBLrXkeETmRoMh4DDPgis9U7wfSLtm7/uBkoBcPvxBHzd9Jy7bqWyXgRbXr2Ftj5MJJVCQqZaeX+q5KSJ/GbsKH4CMzsQaAKcrXHFHQPnN02kvmAZ/EnMBppJ6yMKdLt+Lfd9OSKxm2DmTT662 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 May 2020 02:57:35 -0000 Received: by ary.qy (Postfix, from userid 501) id 920A518D0160; Tue, 5 May 2020 22:57:34 -0400 (EDT) Date: 5 May 2020 22:57:34 -0400 Message-Id: <20200506025735.920A518D0160@ary.qy> From: "John Levine" To: dnsop@ietf.org Cc: jabley@hopcount.ca In-Reply-To: <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 02:57:40 -0000 In article <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> you write: >> It contains plenty of examples of how user-assigned code elements are used in the field, including >other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself. I also think it's an improvement, and concur with Joe's advice not to tell IANA to do anything since they're already doing it. R's, John PS: I don't suppose there's any chance that the IETF could mount an expedition to Western Sahara or Palmyra atoll and claim .EH or .UM? From nobody Wed May 6 01:48:45 2020 Return-Path: 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 C74593A0061; Wed, 6 May 2020 01:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 xlm-n4i7tDBy; Wed, 6 May 2020 01:48:40 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 E5FF83A00DB; Wed, 6 May 2020 01:48:39 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E962628053E; Wed, 6 May 2020 10:48:36 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id E284C28066E; Wed, 6 May 2020 10:48:36 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id DA85F28053E; Wed, 6 May 2020 10:48:36 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D39FD663E080; Wed, 6 May 2020 10:48:36 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id C105C3FD5F; Wed, 6 May 2020 10:48:36 +0200 (CEST) Date: Wed, 6 May 2020 10:48:36 +0200 From: Stephane Bortzmeyer To: Tim Wicinski Cc: dnsop , dnsop-chairs Message-ID: <20200506084836.GA14813@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 10.3 X-Kernel: Linux 4.19.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000883, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 08:48:43 -0000 On Mon, May 04, 2020 at 03:08:20PM -0400, Tim Wicinski wrote a message of 64 lines which said: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements I think it is important to have such a document, because DNSSEC failures may seriously endanger the deployment of DNSSEC (which is already too low). The current draft seems a good starting point and I support its adoption. I'm willing to review. Let's start immediately with -09: draft-ietf-dnsop-extended-error (recently approved by the IESG) should be mentioned, since one of the biggest operational problem with DNSSEC is the difficulty to understand why a resolver returns a SERVFAIL to you. > More often, to date, failed validation is due to operator error and > not an attempt to forge data. It can be a bug in software, too. Specially with complicated things like NSEC3+optout+ENT+dynupdate :-{ The draft apparently do not mention advices on expiration slack (such as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a consensus on (I quote Unbound documentation) "The signature inception and expiration dates are allowed to be off by 10% of the signature lifetime"? > However, a DNSSEC validator is not able to determine other than by > trying whether a signature scheme is supported by the authoritative > server. This one is unclear. First, the signer is not always an authoritative server, signature can be done offline. Second, querying the DNSKEY is enough, no? (Or querying the signatures, but I assume a zone won't publish a DNSKEY without being able to sign with this algorithm.) Section 12 "Invalid Reporting Recommendations" is questionable. Since most DNSSEC validation errors are not attacks, reporting these errors may overload the DRO with problems she can do nothing about. Monitoring is a good idea but monitoring what? "Important" (for the DRO) domains? Also, the draft has many, it seems, grammar / language problems. ("This introduces a potentially huge vector for configuration errors, but due to human intervention as well as potential misunderstanding of ongoing operations.") From nobody Wed May 6 07:40:38 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35E3A09C1; Wed, 6 May 2020 07:40:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158877603626.19950.8270190025944203627@ietfa.amsl.com> Date: Wed, 06 May 2020 07:40:36 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 14:40:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : The DELEGATION_ONLY DNSKEY flag Authors : Paul Wouters Wes Hardaker Filename : draft-ietf-dnsop-delegation-only-00.txt Pages : 11 Date : 2020-05-06 Abstract: This document introduces a new DNSKEY flag called DELEGATION_ONLY that indicates that the particular zone will never sign zone data across a label. That is, every label (dot) underneath is considered a zone cut and must have its own (signed) delegation. Additionally, it indicates the zone is expecting its parent to never bypass or override the zone. DNSSEC Validating Resolvers can use this flag to mark any data that violates the DELEGATION_ONLY policy as BOGUS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-only/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-delegation-only-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 08:13:32 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60A3A0743; Wed, 6 May 2020 08:13:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158877800996.24219.1835457493453226032@ietfa.amsl.com> Date: Wed, 06 May 2020 08:13:30 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:13:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Transport over TCP - Operational Requirements Authors : John Kristoff Duane Wessels Filename : draft-ietf-dnsop-dns-tcp-requirements-06.txt Pages : 27 Date : 2020-05-06 Abstract: This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. This includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this best common practice is not upheld. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-06 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-tcp-requirements-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-tcp-requirements-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 08:17:26 2020 Return-Path: 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 691793A080E for ; Wed, 6 May 2020 08:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 2tp0QwbQ8RUc for ; Wed, 6 May 2020 08:17:22 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 F21D13A07F5 for ; Wed, 6 May 2020 08:17:21 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id b2so2785545ljp.4 for ; Wed, 06 May 2020 08:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mcuS/bUHp1B5/QF7bFXvxakRzuJA5GPt2VX+xTrtkMI=; b=OggF/IB9tSO+DijOPZLA86jGxRPuSfOGGnON2aOklSVXYzknwBhPdvocfy3dRVHsPW rhQEuDPGxn9fgQJg1IZrowB5cp+d+7MImLxhAqOhDBryPaeXkbl6D5sd6QGZz/X1rFI6 LVHSWXGFKvTymqv2nmC7g2CZdiLhGUqqviEVC3R0eEJx4B2MI7KhgN8IWfSFQCxr4p0Q i5hnp23haGtnwRgOk+xaAu2gddMTjSbOfGw5dAFMYoBejRR0pUpwifG4di2KjbHgTp+e mFKUkmgh7KjBaSNpg/LWscWRbtRm2eaKYe+7TvxpXfNtSgsmYK3WPObmwiupgVpmdIDt W7Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mcuS/bUHp1B5/QF7bFXvxakRzuJA5GPt2VX+xTrtkMI=; b=E0K/rBUweJ2IlEiWQYVK0u0AKqLw582TsL9G+EdNg98S2FGfpsPuuHQ9oRpvY7i5s6 guOkTsq1MtWJVfsxragJzStCliY7CBdn9cEAjhFkmnKQO5rBKGm3pY5MIwpUAayuJfZE Fv4fj1amaE9Td2Trjxx7NtCe4UIKm9c5pisgMOj54VT3/3dmkLRc5WRHnzpYO/TdKSsG A6OUA8A7pfE2nGjRrtTNR8B8HyI4N4AZunmxTwF5ZVj+4k77emU9Vf51UpCdns+reeR3 GOofyndofiLpDUVEQEYxt+r4TaqSQFmJEhRSRqvij27zljQLVQLREDxpN5OcjgPJeRtN Cg+Q== X-Gm-Message-State: AGi0PuZZiVegGUbDdOK2aNhx4Wg/Px4Dj62EOYY7qk69jdW87R9mQxEr yL55r6JH6W6QPC7MuP8rrEgl9ymJezEVSYkci3LXubLGK88= X-Google-Smtp-Source: APiQypLQoWS3eSrxCY1EQkcRCpCVpAnbG78fTG6CbDUp5WksV2/o5YHv4JK6M3/1VXFBJjUKGKGO07+bpl1QDIHhGL4= X-Received: by 2002:a2e:7d0f:: with SMTP id y15mr5471242ljc.91.1588778239844; Wed, 06 May 2020 08:17:19 -0700 (PDT) MIME-Version: 1.0 References: <158877603626.19950.8270190025944203627@ietfa.amsl.com> In-Reply-To: <158877603626.19950.8270190025944203627@ietfa.amsl.com> From: Bob Harold Date: Wed, 6 May 2020 11:17:08 -0400 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary="0000000000009cfb4705a4fc4244" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:17:25 -0000 --0000000000009cfb4705a4fc4244 Content-Type: text/plain; charset="UTF-8" On Wed, May 6, 2020 at 10:40 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : The DELEGATION_ONLY DNSKEY flag > Authors : Paul Wouters > Wes Hardaker > Filename : draft-ietf-dnsop-delegation-only-00.txt > Pages : 11 > Date : 2020-05-06 > > Abstract: > This document introduces a new DNSKEY flag called DELEGATION_ONLY > that indicates that the particular zone will never sign zone data > across a label. That is, every label (dot) underneath is considered > a zone cut and must have its own (signed) delegation. Additionally, > it indicates the zone is expecting its parent to never bypass or > override the zone. DNSSEC Validating Resolvers can use this flag to > mark any data that violates the DELEGATION_ONLY policy as BOGUS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-only/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-delegation-only-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-00 > > Looks good to me. Minor note: 3.1. Affected parties and their roles "Validating Resolver: A validating that" -> "Validating Resolver: A validating resolver that" -- Bob Harold --0000000000009cfb4705a4fc4244 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, May 6, 2020 at 10:40= AM <internet-drafts@ietf.or= g> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The DELEGATION_ONLY DNSKEY flag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Wouters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wes Hardaker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-delegation-only-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-05-06

Abstract:
=C2=A0 =C2=A0This document introduces a new DNSKEY flag called DELEGATION_O= NLY
=C2=A0 =C2=A0that indicates that the particular zone will never sign zone d= ata
=C2=A0 =C2=A0across a label.=C2=A0 That is, every label (dot) underneath is= considered
=C2=A0 =C2=A0a zone cut and must have its own (signed) delegation.=C2=A0 Ad= ditionally,
=C2=A0 =C2=A0it indicates the zone is expecting its parent to never bypass = or
=C2=A0 =C2=A0override the zone.=C2=A0 DNSSEC Validating Resolvers can use t= his flag to
=C2=A0 =C2=A0mark any data that violates the DELEGATION_ONLY policy as BOGU= S.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-delegation-only/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-dnsop-delegation-only-00
https://datatracker.ietf.or= g/doc/html/draft-ietf-dnsop-delegation-only-00



Looks good to me.
=

Minor note:

3.1.=C2=A0 Affected par= ties and their roles
"Validating Resolver: A validating that&q= uot; -> "Validating Resolver: A validating resolver that"

--=C2=A0
Bob Harold

--0000000000009cfb4705a4fc4244-- From nobody Wed May 6 08:19:42 2020 Return-Path: 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 566983A0AAF for ; Wed, 6 May 2020 08:19:40 -0700 (PDT) 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 ekhKdaFGuo_c for ; Wed, 6 May 2020 08:19:38 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 CBEB73A0833 for ; Wed, 6 May 2020 08:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8021; q=dns/txt; s=VRSN; t=1588778378; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=DBefkFRIbE+/rU3i8pGi+STskRdmL+q1laytuSzHFQY=; b=EjT8XwHjrY/Ey6y/lCUqxxa8BjI9JbKAlH78w7yCf/KodO+lxy95mzuh UpK/2IYaXL2Pg0dMRsolMrbFCu4UVZvCpEhU2AQrhZWcAV7E3YFWZ0kAf bJzqogYf+FiM76o3Xf8O6RaA0hGghUC8a9XMOghuGO1yankAB/UaMMkL3 41t4Ob7SrNr87goGkDFdoTMgzeC2/+Oo9NZeYqqBOrABOSwFm1hH1OXvH WNarLeJ606UOEPNZWq4CtzixlhiMTV3mDj3ecOGby3YlzQcpgL4S+Ljov mUrxA5PuHqJzW21mx7vonu8vx5h/1J6kuldDwb18ZFWeJDst4cHvUDo68 Q==; IronPort-SDR: T85zYGcqxWpj/pCrdQDqpNG5UwTF6Ocfk72Aoau6uVrB2aRFw+iL5pToez8pYoL/KQSsIkzIq+ bQmC3IbBRHrnsGY3jLQrHSaNDnteOYaadsekMBpxpjrOtPpXnVE36CXlUoXyh0CS7WECA3O1Nd T1fCy5Rppyv8PuvwkihELrgXWsesCIEubY+5ar8Bw7OGGEKehRNvfJE33IOVoJesBBtvNmZd2/ XWEPV9sDRP7yuscxqUvNrdK7w2fSVTqRCmXXeWGDb0w7OM+5DNocB65Nulf46YjBhYhrODtfOp kgE= X-IronPort-AV: E=Sophos; i="5.73,359,1583193600"; d="p7s'?scan'208"; a="1514674" IronPort-PHdr: =?us-ascii?q?9a23=3A0hPUqRSMjUj27u6aJxClnXj1ldpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa6yYxGN2/xhgRfzUJnB7Loc0qyK6v2mBjxLsc/JmUtBWaQEbw?= =?us-ascii?q?UCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFR?= =?us-ascii?q?rlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRW7oR/Tu8QVjodvKbs9wQ?= =?us-ascii?q?bVr3VVfOhb2XlmLk+JkRbm4cew8p9j8yBOtP8k6sVNT6b0cbkmQLJBFDgpPH?= =?us-ascii?q?w768PttRnYUAuA/WAcXXkMkhpJGAfK8hf3VYrsvyTgt+p93C6aPdDqTb0xRD?= =?us-ascii?q?+v4btnRAPuhSwaMTMy7WPZhdFqjK9DoByvuQFxw5Labo+WOvpxfKTTfdIGSm?= =?us-ascii?q?VORctRWDBNAoamYosPE+YNI+BVpJT9qVsUqhu+ABGhCO3vxTBWnX/2xrM10+?= =?us-ascii?q?A6EQ3ewQcuEc8Ov27SrNrrOqsZTOe4w7TGzDrddPNWwiny6IzTch06v/GDQ6?= =?us-ascii?q?hwccvKyUkuGAPFiE+cppDiPzOQz+kAtXWQ4OV8W+y1kWEntx1xrSa1xscqko?= =?us-ascii?q?TEiJwYx1DE+yhnw4s4OdO1RU1mbNOkEJVdqS+UOYV2TM4jXW1mtzg3xqAJt5?= =?us-ascii?q?C1YSQG1JspygLCZvGbcYWG4hbuWeCMKjl7nHJoYK+ziwqo/US9yODxWNO43E?= =?us-ascii?q?tKoydLiNXBuXMA2wTO5sSbUPdx40Ws1SqV2wzO5exJIlo4mbfYJpMn37U+jI?= =?us-ascii?q?AcsV7ZES/zgEj2iaiWeVg69eWw8OTnZ6nmpoebN49plgHyKqQuldK7AeQ/Kg?= =?us-ascii?q?UDQnSV9/yh2LLj5UP3T7RFguErnqXDrpDVOcMbprShAwNPyIks9gyzDym80N?= =?us-ascii?q?QDm3kLNk5KeBWCj4TxOlHOJu73DeunjlixjDtn3e3KM7/vD5nXM3TOkLnsca?= =?us-ascii?q?xy5kNf0AYzyMpQ55NQCrEPOvLzXUrxucTFAR43LQO02P3nB8t51oMFQm+PHL?= =?us-ascii?q?GWMLnTsV+T5+IvLO+MaJUJtzb6Lvgp/+TugmMhmV8BYamp2oMaZ22+HvR9JE?= =?us-ascii?q?WZeWHhgtYfHmcWsAoyVuvqiEeNUW0bW3HnFa46/TYjIIOrEYmFQZqiyvTV0C?= =?us-ascii?q?GgGYV+Z21aBBaLC3i+JKueXPJZIh2fOdRslidAHZS8Qoksn1n6uBD30KFqKv?= =?us-ascii?q?H85CACtIni294z7OrWw0JhvQdoBtiQhjneB1p/mXkFEmc7?= X-IPAS-Result: =?us-ascii?q?A2E5BAA/1LJe/zCZrQpmHQEBAQEJARIBBQUBQIFHg0OBB?= =?us-ascii?q?gqVAyWDcpYFgWcEBwEBAQEBAQEBAQMEAS8EAQGERAKCJjgTAgMBAQsBAQEFA?= =?us-ascii?q?QEBAQEFAwEBAQKGQAuCOyKDaQEBAQECAWcHEAsCAQgYLgIwJQIEEw6DGAGCX?= =?us-ascii?q?BGzSHSBNIVQhHYQgTiBU4pUN4FCPoE4DBCCTT6EED2DRoItBJgDmk4DB4JIh?= =?us-ascii?q?BSCS5FUnSCQF5lYg0QCBAIEBQIVgWmBeXAVGiEqAYI+PhIYDZ8KdDcCBggBA?= =?us-ascii?q?QMJkTaBEAEB?= Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 6 May 2020 11:19:36 -0400 Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1913.005; Wed, 6 May 2020 11:19:36 -0400 From: "Wessels, Duane" To: "dnsop@ietf.org" Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-06.txt Thread-Index: AQHWI7j1Wf3LX+yCjk6SxV0lhiy88aibbxyA Date: Wed, 6 May 2020 15:19:36 +0000 Message-ID: <812280E0-3106-4444-8ADB-47F3C993EA3E@verisign.com> References: <158877800996.24219.1835457493453226032@ietfa.amsl.com> In-Reply-To: <158877800996.24219.1835457493453226032@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.14) x-originating-ip: [10.170.148.18] Content-Type: multipart/signed; boundary="Apple-Mail=_10F68363-C160-445D-83B2-3DDD1D7F35D4"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 15:19:41 -0000 --Apple-Mail=_10F68363-C160-445D-83B2-3DDD1D7F35D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi DNSOP, The changes from -05 to -06 of this document include: - addressing mailing list comments (thank Puneet) - spelling, grammar, and punctuation editing pass - added a reference to dnstap DW > On May 6, 2020, at 8:13 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations WG of = the IETF. >=20 > Title : DNS Transport over TCP - Operational = Requirements > Authors : John Kristoff > Duane Wessels > Filename : draft-ietf-dnsop-dns-tcp-requirements-06.txt > Pages : 27 > Date : 2020-05-06 >=20 > Abstract: > This document encourages the practice of permitting DNS messages to > be carried over TCP on the Internet. This includes both DNS over > unencrypted TCP, as well as over an encrypted TLS session. The > document also considers the consequences with this form of DNS > communication and the potential operational issues that can arise > when this best common practice is not upheld. >=20 --Apple-Mail=_10F68363-C160-445D-83B2-3DDD1D7F35D4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDbgw ggZgMIIFSKADAgECAhB2hcsHqODMD9LFTY85NbMSMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA2MDcwMDAwMDBaFw0yMTA2MDYyMzU5NTlaMIHJ MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRl cm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAt/g/DCuDIyCFpk1JAVE62t1QM77jBKQ6PqNhZkw0wuh0cHVJpbdJ7N2zkpzdeQ3iufq4 OTy+heOM7215o6a3CL+cTL4+mI6s23yaK+wFKDBfKRszTUTVcOhWIpmmPp1CW+sjp2OdLSywLj8Y 8ynNGjaJhJLHV3BbcIXmOKF8UOM3OIhlW2vLOSoEsYKqGQT/oH8/o9uRRXZmo2vzhSNeTtmFXXWn oBX3wQB04OXKlEJlmsI3eouoUKy/l3Rnd9Eyp6+Ny5OpJUK0MBp0CuIlEBDLdGdVD8sU/EFQCqR8 TQsL+QWpNflFpzHxgLuiyT7OdjnhKv92UOfoUSLfLc+4MwIDAQABo4ICPzCCAjswEgYDVR0TAQH/ BAgwBgEB/wIBADA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2Ey LWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVZlcmlTaWdu TVBLSS0yLTU2MB0GA1UdDgQWBBTYSCmoXyoXkuL6nnvvb2CD+Li43DCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0g Rm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTBsBgNV HSAEZTBjMGEGC2CGSAGG+EUBBxcCMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5j b20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMA0GCSqGSIb3 DQEBBQUAA4IBAQCmKpsHQMns/7OI6EXaNNEXDygtt6WFZzHNwebVKYY4rOLwWRsM4aFFziR472nB sExhokjZaE+6/nVUN7pYaerBdqU2QuqeZniQINmVaiR5VM3eWhqKO64YlXLQJdjSRr40MKeAnvFW ziAebGfJTU95h4niLoDWnu0mYWWiA9DF4vMouStJaYJn7NXpNKQu3GIipIVNSONqApTyzf3kZ8hJ vKrVx+c83oexEGtdB1wZ5Gug9E+Zy9y1WwzMMvlq5HTAKlg3ebP7zcM0b+F23RAHAGOLB04nF5JH mw6+3g0ThRH8oi9lfcw6rB5Ua1ZnxO6lhyIjFytwVsPxrndcJ8E5MIIHUDCCBjigAwIBAgIQUgHO uRrE8f0+lHpp6LMu3zANBgkqhkiG9w0BAQsFADCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eTAeFw0yMDAzMjQwMDAwMDBaFw0yMTA0MjIyMzU5NTlaMHAxJDAiBgkqhkiG9w0BCQEWFWR3 ZXNzZWxzQHZlcmlzaWduLmNvbTEXMBUGA1UEAwwOV2Vzc2VscywgRHVhbmUxFjAUBgNVBAsMDUVO VEVSUFJJU0UgSVQxFzAVBgNVBAoMDlZlcmlTaWduLCBJbmMuMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAwbeXxaBWlxe5DxiPcGA+avq1cFigXZu2lAVx5DMmtWuUx8s+am03tuwU7tw6 xHG4sfrR9d2BucS54VpdZGxZO0ShzZ0WDatTINezhPQTh0Xumy2dbc8d7xTlSa2ZGGw/Zq78jq4C 7f3dEMMk7pqY+gBIE9d7GdjQYkwrF558PKIQIzUAcxVLTLhOqcmnA2g0WaTxWEjev2LdC41G15z8 ZIEJDWGfd7lWLNKrD4p9vG+aKTbxEaaKcRj7ZQCFbqNNAQA0YFf2xtvgUHQIh+ciuCKBlwiTVkCl KZpGkfTx0tSE47BvtNkAFxqyKTNNYrceG7/g7KaxynTfKO7zYjO1uQIDAQABo4IDijCCA4YwDAYD VR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwQwHQYDVR0O BBYEFFaFSmgtcRDwfRFiqt3Vq8LJCLn5MCAGA1UdEQQZMBeBFWR3ZXNzZWxzQHZlcmlzaWduLmNv bTAfBgNVHSMEGDAWgBTYSCmoXyoXkuL6nnvvb2CD+Li43DCCAXAGCCsGAQUFBwEBBIIBYjCCAV4w JwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCCATEGCCsGAQUFBzAChoIB I2xkYXA6Ly9kaXJlY3Rvcnkuc3ltYXV0aC5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNz JTIwMiUyMFNoYXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJD T1UlMjAlM0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNj cmliZXIlMjBDQSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRl O2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8w N2JiN2Q2NDc3Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMw YQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMw KAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUw MzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpg hkgBhvhFARADBB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQr MCkCAQAWJGFIUjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQsF AAOCAQEAeD6Ith/v5S1X1k35R2h8AK4YbmVNDgPivPZcQcpKRJ6YntyZf9l2e19igK2d0floI6ez PCEEGUwQArGOBc9nBrEPDioIq2WJCPshT4/fk2UdOo9+Yc80JlhPE3eU3HkYhu0B33Hj3tjc5g60 Y+wdR2jInSF+LnvP66yJthoXLID1NpkhitIx52m5MkKPZTxb/SHVI2MQ5x4DWtr+Obe/+YCRQ/K2 UzMSVXmVwdHLpUrm4P4uyWQ2ZuIwFbnLl7OtwKOZIaQxqXDI/jWO65hVqHgiRc1Sao/lYtKfu/jC dmXM6v0Sd+t4dJFEjH2a1gqsf4DraqnvJ4Ak6RNTCazfUTGCBF0wggRZAgEBMIHeMIHJMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVj IFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlh dGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBSAc65GsTx/T6Uemnosy7fMA0GCWCGSAFlAwQCAQUA oIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MDYxNTE5 MzZaMC8GCSqGSIb3DQEJBDEiBCBdBgwtwjavxxyY75fAA1gYJ5/Nb8xKz+WFPGSYhcYKQzCB7wYJ KwYBBAGCNxAEMYHhMIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9y YXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIg TWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBD bGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBSAc65GsTx /T6Uemnosy7fMIHxBgsqhkiG9w0BCRACCzGB4aCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEG A1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1 dGhvcml0eQIQUgHOuRrE8f0+lHpp6LMu3zANBgkqhkiG9w0BAQEFAASCAQBFQHJR+k27bfG+TDM2 Ed1uNG/LWv16mNpn+ufPEOGSKUZrtPaxDFlrIRvyq8KKXvRowvxU+Q2IflNzB8+AiYmj6RbZ06GG OIVXq5LWobUDhK0FgO9jWpb/hIWpuNg88njvnTPyKxW+QmU1TeqUFO3hWJsIS50tWLIAdZRcG7A5 wWejtQK+UOrpazWts6PJ4kjA2n/Cj69gnJjvYQ2dVPZrJEvhn9cEX33PZf8l24Jr+bJ4q1MO7RWx 58fb/bWx8e8m0VvSoxCJzhXbHUFSH+wPRvVyukyagYiZJUaAJfu+WJ7YOK0coDcFdqlXop8h/8tB uuTUrmQZZzroZAssvRFeAAAAAAAA --Apple-Mail=_10F68363-C160-445D-83B2-3DDD1D7F35D4-- From nobody Wed May 6 09:16:22 2020 Return-Path: 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 2C2A53A0BBF for ; Wed, 6 May 2020 09:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 Dim7JYjehDCd for ; Wed, 6 May 2020 09:16:15 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 AF2DF3A0BE3 for ; Wed, 6 May 2020 09:16:08 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id i5so714099uaq.1 for ; Wed, 06 May 2020 09:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=euyeWDkf8YQisTqtEfVurQ4zV4pSNP4ImBvYQN2HjyA=; b=N2ZkgdMyizkcnOKO5/S2FOQrrvd6ExdS1xj0a4kfPXMqgKUvrRb3Cwg9Ti1iM191wd DdPnt4wKQei2qB0LiWYPgvqxKUGI2BGaYx7nTn6yFNOdXm7Jsyn3FDqNoBD5FWSdOQg2 L3kaFntWujDuEFmlwZgisApPdG5iZbUxOLM9qYe4FKXM1zsi0FweT7+zPJrkDfarFMBi d/grfoglk7YMvRMLiUtDiwWXo4n6sgdpvVFBVlwx2sfeWL3VRrb2lHu3tKxbPSO3o/D5 pI0vk7OFYLCRTya2tgD94OdNh5Cmkiq4ISxBqLHjPpaDxrpm4raT3UfbiYpUHbnsz9v6 Q6OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=euyeWDkf8YQisTqtEfVurQ4zV4pSNP4ImBvYQN2HjyA=; b=s/0LkhHqv3saqDjcD7KyTcYmTFPhOwhjU2GsD0XY+gZoR81I92HBae7xskAzVXH173 aFosJXFZBXcwB734vNj2vuAkIJVJYOVMV5BlC77LmVI5/eKTGDMkMcKPLNmMxWDxT8O/ Z/tkryw5q5bgelM1icZcN9JlfgqbmF5A/uqG8Okswe3MCi2oGKRtO7ioqcXOMlCH1ri7 v96UHzRjA35bcX6m5dC8u3pSUeYwCrocD/VgvkbCT7QVEKrZ2IZ1c1nobsPMtId1LSbR fu48p2CqiedfoEpEhLcWvT0SOxWu5WPWexPHhrr0LabWjjYFWSsPH1Dwn17b/NaImC9X ZXOA== X-Gm-Message-State: AGi0PuaIx8oSq9074alucLDgZLcX7JbBixp0LLdvZBOppaXnVvJuzFe4 CQgG5E960Av4IXA5aDVo75VZ2fJTBEZpyY7X/kU= X-Google-Smtp-Source: APiQypKgU7fZ6cdWXTeOgUt54Rr6NcSmh96KStX+Wx5FIG/2LYfHPAcELFnzEUhg6dlmir557tWuLwIi+F8eVv/0hL8= X-Received: by 2002:a9f:222c:: with SMTP id 41mr7771501uad.88.1588781767577; Wed, 06 May 2020 09:16:07 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Wed, 6 May 2020 12:15:56 -0400 Message-ID: To: Bob Harold Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000e2209905a4fd14dc" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:16:20 -0000 --000000000000e2209905a4fd14dc Content-Type: text/plain; charset="UTF-8" On Tue, May 5, 2020 at 2:53 PM Bob Harold wrote: > > On Tue, May 5, 2020 at 12:02 PM Daniel Migault > wrote: > >> Hi Bob, >> >> I apology the previous email has just been sent unexpectedly. >> >> Thanks for the comments. The new version of the file is available here >> [1] and a diff is available at [2]. >> >> I propose the following text for clarification. Feel free to let me know >> if that addresses your concern. >> >> OLD: >> Not updating the configuration file prevents a failed synchronization to >> to the absence of write permission that are hardly in the control of the >> software." >> >> NEW >> Avoiding the configuration file to be updated prevents old configuration >> file to survive to writing error on read-only file systems. >> > > I understand that we do not want the system to fail due to missing write > permissions. It seems like this could be handled two ways: > 1. Just keep in memory, and do not try to write a new configuration. That > works, until the old trust anchor is removed, then it fails if the service > is restarted. > 2. Attempt to write a new configuration, but keep going even if that > fails. If the write succeeds, then this works even after the old trust > anchor is removed. > > I would prefer the second method. I think that is what some software > already does. (BIND?) > > Thank you for your feed backs, though this may be changed, in the current document we encourage to have an instantiation process that performs some validation and checks before the service is started. One of these checks is to ensure the configuration is up-to-date. With such process in place, we expect that every instance of the service is appropriately provisioned. A concrete (simple) deployment can always retrieve the service from a repo or perform a check for updates. With that set, 1 or 2 would work the same. The reason I would maybe prefer 1) over 2) is that 1 is known to carry the old configuration which will force the necessary check at startup. On the other hand 2) works fine unless KSK roll over happens and a write error happens. This means that most of the time this will work fine and this is what makes it dangerous in my opinion. But again, I am happy to update this with what the WG thinks it mostly appropriated. I have raised the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/1 > -- > Bob Harold > > >> >> Please inline other comments. >> >> Yours, >> Daniel >> >> [1] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >> [2] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >> >> >> On Tue, May 5, 2020 at 11:52 AM Daniel Migault > 40ericsson.com@dmarc.ietf.org> wrote: >> >>> Hi Bob, >>> >>> Thanks for the comments. The new version of the file is available here >>> [1] and diff can be seen at [2]. >>> >>> I propose the following text. Does it clarify the concern ? >>> Avoiding the configuration file to be updated prevents old configuration >>> file to survive to writing error on read-only file systems. >>> >>> >>> "Not updating the configuration file prevents a failed >>> synchronization to to the absence of write permission that are hardly >>> in the control of the software." >>> >>> >>> >>> >>> [1] >>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >>> [2] >>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >>> >>> ------------------------------ >>> *From:* Bob Harold >>> *Sent:* Monday, May 4, 2020 4:29 PM >>> *To:* Daniel Migault >>> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed >>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >>> By WG Issued" >>> >>> Minor nits: >>> >>> 7. Trust Anchor Related Recommendations >>> >>> Last sentence, last few words: >>> "in section Section 8" > "in Section 8" >>> >>> >>> addressed >>> >>> >>> 7.2.1. Automated Updates to DNSSEC Trust Anchors >>> >>> "TA updates is" > "TA updates are" >>> >>> >>> addressed >>> >>> >>> "but due to human" > "due to human" >>> >>> >>> addressed >>> >>> >>> 7.2.2. Automated Trust Anchor Check >>> >>> "Not updating the configuration file prevents a failed >>> synchronization to to the absence of write permission that are hardly >>> in the control of the software." >>> >>> >>> I propose the following text. Does it clarify the concern ? >>> Avoiding the configuration file to be updated prevents old configuration >>> file to survive to writing error on read-only file systems. >>> >>> >>> Seems confusing, please rewrite. >>> >>> "The TA can be queries" > "The TA can be queried" >>> >>> >>> addressed >>> >>> >>> "does not only concerns" > "does not only concern" >>> >>> addressed >>> >>> "if the mismatch result" > "if the mismatch resulted" >>> >>> addressed >>> >>> >>> 8. Negative Trust Anchors Related Recommendations >>> >>> "disable the signature check for that key the time" > "disable the >>> signature check for that key until the time" >>> >>> addressed >>> >>> >>> "This does not prevents" > "This does not prevent" >>> >>> addressed >>> >>> "either an attack or a failure into" > "either an attack or a failure in" >>> >>> addressed >>> >>> 10.1. Automated Reporting >>> >>> "will take the appropriated steps" > "will take the appropriate steps" >>> >>> addressed >>> >>> -- >>> Bob Harold >>> >>> >>> ---------- Forwarded message --------- >>> From: *Bob Harold* >>> Date: Mon, May 4, 2020 at 4:28 PM >>> Subject: Re: [DNSOP] The DNSOP WG has placed >>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >>> By WG Issued" >>> To: IETF DNSOP WG >>> >>> >>> Looks useful, I will review. >>> >>> -- >>> Bob Harold >>> >>> >>> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < >>> ietf-secretariat-reply@ietf.org> wrote: >>> >>> >>> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in >>> state Call For Adoption By WG Issued (entered by Tim Wicinski) >>> >>> The document is available at >>> >>> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >>> >>> >> >> -- >> Daniel Migault >> Ericsson >> > -- Daniel Migault Ericsson --000000000000e2209905a4fd14dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 5, 2020 at 2:53 PM Bob Ha= rold <rharolde@umich.edu> w= rote:

On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
<= /div>
Hi Bob,=C2=A0

I apology the previous email has just been sent un= expectedly.
=C2=A0
Thanks for the comments. The new version of the file is available here [1] = and a diff is available at [2].=C2=A0

I propose the following text for clarification. Feel free to let me know if= that addresses your concern.=C2=A0

OLD:
Not updating the = configuration file prevents a failed=C2=A0synchronization to to the absence= of write permission that are hardly in the control of the software."<= br>

NEW
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.

I understand that we do not want= the system to fail due to missing write permissions.=C2=A0 It seems like t= his could be handled two ways:
1. Just keep in memory, and do not= try to write a new configuration.=C2=A0 That works, until the old trust an= chor is removed, then it fails if the service is restarted.
2= . Attempt to write a new configuration, but keep going even if that fails.= =C2=A0 If the write succeeds, then this works even after the old trust anch= or is removed.

I would prefer the second method.= =C2=A0 I think that is what some software already does.=C2=A0 (BIND?)
=


Thank you for y= our feed backs, though this may be changed, in the current document we enco= urage to have an instantiation process that performs some validation and ch= ecks before the service is started. One of these checks is to ensure the co= nfiguration is up-to-date. With such process in place, we expect that every= instance of the service is appropriately provisioned. A concrete (simple) = deployment can always retrieve the service from a repo or perform a check f= or updates.

With that set, 1 or 2 would work the s= ame. The reason I would maybe prefer 1) over 2) is that 1 is known to carry= the old configuration which will force the necessary check at startup. On = the other hand 2) works fine unless KSK roll over happens and a write error= happens. This means that most of the time this will work fine and this is = what makes it dangerous in my opinion.=C2=A0

But a= gain, I am happy to update this with what the WG thinks it mostly appropria= ted. I have raised the following issue:
=C2=A0

=C2=A0

<= /div>

=C2=A0 =C2=A0=C2=A0

=C2= =A0
--
Bob Harold
=C2=A0
<= div dir=3D"ltr">


On Tue, May 5, 2020 at 11:52 AM Daniel Migaul= t <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi Bob,=C2=A0

Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2].=C2=A0

I propose the following text. Does it clarify the concern ?
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.


"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
</mglt>


From: Bob Harold <= ;rharolde@umich.edu= >
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnsse= c-validator-requirements in state "Call For Adoption By WG Issued"= ;
=C2=A0
Minor nits:

7.=C2=A0 Trust Anchor Related Recommendations

Last sentence, last few words:
"in section Section 8" > "in Section 8"

<mglt>
addressed
</mglt>

7.2.1.=C2=A0 Automated Updates to DNSSEC Trust Anchors

"TA updates is" > "TA updates are"

<mglt>
addressed
</mglt>

"but due to human" > "due to human"

<mglt>
addressed
</mglt>

7.2.2.=C2=A0 Automated Trust Anchor Check

"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
I propose the following text. Does it clarify the concern = ?
Avoiding the configuration file to be updated prevents old= configuration file to survive to writing error on read-only file systems.<= br>
</mglt>

Seems confusing, please rewrite.

"The TA can be queries" > "The TA can be queried"

<mglt>
addressed
</mglt>

"does not only concerns" > "does not only concern" <mglt>
addressed
</mglt>
"if the mismatch result" > "if the mismatch resulted"= ;
<mglt>
addressed
</mglt>

8.=C2=A0 Negative Trust Anchors Related Recommendations

"disable the signature check for that key the time" > "di= sable the signature check for that key until the time"
<mglt>
addressed
</mglt>

"This does not prevents" > "This does not prevent" <mglt>
addressed
</mglt>
"either an attack or a failure into" > "either an attack = or a failure in"
<mglt>
addressed
</mglt>
10.1.=C2=A0 Automated Reporting

"will take the appropriated steps" > "will take the appro= priate steps"
<mglt>
addressed
</mglt>
--
Bob Harold


---------- Forwarded message ---------
From: Bob Harold <rharolde@umich.= edu>
Date: Mon, May 4, 2020 at 4:28 PM
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued"
To: IETF DNSOP WG <d= nsop@ietf.org>


Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <ietf-secreta= riat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


--
Daniel Mi= gault
Ericsson


--
Daniel Migault
Ericsson
--000000000000e2209905a4fd14dc-- From nobody Wed May 6 09:48:10 2020 Return-Path: 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 CF84B3A0412 for ; Wed, 6 May 2020 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 JDJzXVQxs27J for ; Wed, 6 May 2020 09:48:02 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 2CD543A05E2 for ; Wed, 6 May 2020 09:48:02 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id a21so3086421ljb.9 for ; Wed, 06 May 2020 09:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kQLU+/EY50Mg8Tn4Uowo+pKzLxK7y1ENzQLu0ObmncM=; b=f8vQk1iD41a4sm7+q5nHbyOedcuki1BMACgzHDgwyUFj2OWUk3AiZfLx8vaYdwAKBc vU39z+pS/ay3W4dVCD4+ECB3ZKi0haEvngMOqd7MjPnGjcGV13j+H4YcgUyH42dI1/TH qLtzaFokpmuSFN/u/zSo/esA3T45dXDxuQms84t5UwbUClsHSASRbYDQZ7QcfOV4Unj0 o4cERbpxKYlsjHg3kIPFiRTvIuh/iSQxz4I8WJCi4UjLyiTnmOdKQsQRi7tXsGsFxOkv n5BY/PiC7hvy8BLmF7jpglFde3SOTHzl2u7ZZtt6xJGZBYY9u/5BjGaowXu6jOteq4hc 0iIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kQLU+/EY50Mg8Tn4Uowo+pKzLxK7y1ENzQLu0ObmncM=; b=NimAqhzK2I+Q4//hx2y3DwJ5Ez6dWgU+I0AuD19/bAX38c78KtaAU+1ef9UThGiYG2 EcnBeUN0GACPWE1AqL7y2cpZDuLEm9/nzM81RtdYz/tPlYjxjaWso+zCczi9KzzqzeB6 Bl+4ypBhsU4bv9aSDOzfNWhdM/83j6aWR0HJCMqsBTXiYxPNSeFlp/r4IWJhfDhPnPMg P7U9rMIg+cy2kbU2+hMRRq8Q51EeUt+L8MdMWfkuI7DF3GRgYUYWD/9OT4Mwvrwps3n4 K0Un1FQa2zN03ZJmqh4QVZnEQ6U9ySEPebol/fqufGZOBbcV2yW7s38ml2vKyTWxol3Q AH2w== X-Gm-Message-State: AGi0PuZMYS9OmvAbji7c0OeL1JoeYyVeEpRvRb8fR2iKqyJ5oUAIhL30 lomUqTiYSRC9ZLcJRLLO6q5ZpzlE5UkOuxwTvbEhXg== X-Google-Smtp-Source: APiQypIBIHCeKxjNuMdVsWaQE/KmShOGSNhNCNL638pGKRZmfxlYh9riYndlFFs7fUFse3X4DYpkv6Sm0gg/DPWB69Q= X-Received: by 2002:a2e:7d0f:: with SMTP id y15mr5745159ljc.91.1588783680260; Wed, 06 May 2020 09:48:00 -0700 (PDT) MIME-Version: 1.0 References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> In-Reply-To: From: Bob Harold Date: Wed, 6 May 2020 12:47:48 -0400 Message-ID: To: Daniel Migault Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000e3205f05a4fd8658" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:48:06 -0000 --000000000000e3205f05a4fd8658 Content-Type: text/plain; charset="UTF-8" On Wed, May 6, 2020 at 12:16 PM Daniel Migault wrote: > > > On Tue, May 5, 2020 at 2:53 PM Bob Harold wrote: > >> >> On Tue, May 5, 2020 at 12:02 PM Daniel Migault >> wrote: >> >>> Hi Bob, >>> >>> I apology the previous email has just been sent unexpectedly. >>> >>> Thanks for the comments. The new version of the file is available here >>> [1] and a diff is available at [2]. >>> >>> I propose the following text for clarification. Feel free to let me know >>> if that addresses your concern. >>> >>> OLD: >>> Not updating the configuration file prevents a failed synchronization to >>> to the absence of write permission that are hardly in the control of the >>> software." >>> >>> NEW >>> Avoiding the configuration file to be updated prevents old configuration >>> file to survive to writing error on read-only file systems. >>> >> >> I understand that we do not want the system to fail due to missing write >> permissions. It seems like this could be handled two ways: >> 1. Just keep in memory, and do not try to write a new configuration. >> That works, until the old trust anchor is removed, then it fails if the >> service is restarted. >> 2. Attempt to write a new configuration, but keep going even if that >> fails. If the write succeeds, then this works even after the old trust >> anchor is removed. >> >> I would prefer the second method. I think that is what some software >> already does. (BIND?) >> >> > Thank you for your feed backs, though this may be changed, in the current > document we encourage to have an instantiation process that performs some > validation and checks before the service is started. One of these checks is > to ensure the configuration is up-to-date. With such process in place, we > expect that every instance of the service is appropriately provisioned. A > concrete (simple) deployment can always retrieve the service from a repo or > perform a check for updates. > > With that set, 1 or 2 would work the same. The reason I would maybe prefer > 1) over 2) is that 1 is known to carry the old configuration which will > force the necessary check at startup. On the other hand 2) works fine > unless KSK roll over happens and a write error happens. This means that > most of the time this will work fine and this is what makes it dangerous in > my opinion. > > But again, I am happy to update this with what the WG thinks it mostly > appropriated. I have raised the following issue: > > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/1 > > > Thanks for explaining. I had forgotten about the checks before starting. In my case I was hoping to only need the root trust anchor, and keep it updated by just patching regularly. Might be wishful thinking. -- Bob Harold > > > > > > > >> -- >> Bob Harold >> >> >>> >>> Please inline other comments. >>> >>> Yours, >>> Daniel >>> >>> [1] >>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >>> [2] >>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >>> >>> >>> On Tue, May 5, 2020 at 11:52 AM Daniel Migault >> 40ericsson.com@dmarc.ietf.org> wrote: >>> >>>> Hi Bob, >>>> >>>> Thanks for the comments. The new version of the file is available here >>>> [1] and diff can be seen at [2]. >>>> >>>> I propose the following text. Does it clarify the concern ? >>>> Avoiding the configuration file to be updated prevents old >>>> configuration file to survive to writing error on read-only file systems. >>>> >>>> >>>> "Not updating the configuration file prevents a failed >>>> synchronization to to the absence of write permission that are hardly >>>> in the control of the software." >>>> >>>> >>>> >>>> >>>> [1] >>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >>>> [2] >>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >>>> >>>> ------------------------------ >>>> *From:* Bob Harold >>>> *Sent:* Monday, May 4, 2020 4:29 PM >>>> *To:* Daniel Migault >>>> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed >>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >>>> By WG Issued" >>>> >>>> Minor nits: >>>> >>>> 7. Trust Anchor Related Recommendations >>>> >>>> Last sentence, last few words: >>>> "in section Section 8" > "in Section 8" >>>> >>>> >>>> addressed >>>> >>>> >>>> 7.2.1. Automated Updates to DNSSEC Trust Anchors >>>> >>>> "TA updates is" > "TA updates are" >>>> >>>> >>>> addressed >>>> >>>> >>>> "but due to human" > "due to human" >>>> >>>> >>>> addressed >>>> >>>> >>>> 7.2.2. Automated Trust Anchor Check >>>> >>>> "Not updating the configuration file prevents a failed >>>> synchronization to to the absence of write permission that are hardly >>>> in the control of the software." >>>> >>>> >>>> I propose the following text. Does it clarify the concern ? >>>> Avoiding the configuration file to be updated prevents old >>>> configuration file to survive to writing error on read-only file systems. >>>> >>>> >>>> Seems confusing, please rewrite. >>>> >>>> "The TA can be queries" > "The TA can be queried" >>>> >>>> >>>> addressed >>>> >>>> >>>> "does not only concerns" > "does not only concern" >>>> >>>> addressed >>>> >>>> "if the mismatch result" > "if the mismatch resulted" >>>> >>>> addressed >>>> >>>> >>>> 8. Negative Trust Anchors Related Recommendations >>>> >>>> "disable the signature check for that key the time" > "disable the >>>> signature check for that key until the time" >>>> >>>> addressed >>>> >>>> >>>> "This does not prevents" > "This does not prevent" >>>> >>>> addressed >>>> >>>> "either an attack or a failure into" > "either an attack or a failure >>>> in" >>>> >>>> addressed >>>> >>>> 10.1. Automated Reporting >>>> >>>> "will take the appropriated steps" > "will take the appropriate steps" >>>> >>>> addressed >>>> >>>> -- >>>> Bob Harold >>>> >>>> >>>> ---------- Forwarded message --------- >>>> From: *Bob Harold* >>>> Date: Mon, May 4, 2020 at 4:28 PM >>>> Subject: Re: [DNSOP] The DNSOP WG has placed >>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >>>> By WG Issued" >>>> To: IETF DNSOP WG >>>> >>>> >>>> Looks useful, I will review. >>>> >>>> -- >>>> Bob Harold >>>> >>>> >>>> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < >>>> ietf-secretariat-reply@ietf.org> wrote: >>>> >>>> >>>> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements >>>> in >>>> state Call For Adoption By WG Issued (entered by Tim Wicinski) >>>> >>>> The document is available at >>>> >>>> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >>>> >>>> >>> >>> -- >>> Daniel Migault >>> Ericsson >>> >> > > -- > Daniel Migault > Ericsson > --000000000000e3205f05a4fd8658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, May 6, 2020 at 12:16 PM Daniel Mi= gault <mglt.ietf@gmail.com>= ; wrote:


On Tue, May 5, 2020 at 2:53 PM Bob Harold &l= t;rharolde@umich.ed= u> wrote:

On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.ietf@gmail.com> wr= ote:
Hi Bob,=C2=A0

I apology the previous email has just been sent un= expectedly.
=C2=A0
Thanks for the comments. The new version of the file is available here [1] = and a diff is available at [2].=C2=A0

I propose the following text for clarification. Feel free to let me know if= that addresses your concern.=C2=A0

OLD:
Not updating the = configuration file prevents a failed=C2=A0synchronization to to the absence= of write permission that are hardly in the control of the software."<= br>

NEW
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.

I understand that we do not want= the system to fail due to missing write permissions.=C2=A0 It seems like t= his could be handled two ways:
1. Just keep in memory, and do not= try to write a new configuration.=C2=A0 That works, until the old trust an= chor is removed, then it fails if the service is restarted.
2= . Attempt to write a new configuration, but keep going even if that fails.= =C2=A0 If the write succeeds, then this works even after the old trust anch= or is removed.

I would prefer the second method.= =C2=A0 I think that is what some software already does.=C2=A0 (BIND?)
=


Thank you for y= our feed backs, though this may be changed, in the current document we enco= urage to have an instantiation process that performs some validation and ch= ecks before the service is started. One of these checks is to ensure the co= nfiguration is up-to-date. With such process in place, we expect that every= instance of the service is appropriately provisioned. A concrete (simple) = deployment can always retrieve the service from a repo or perform a check f= or updates.

With that set, 1 or 2 would work the s= ame. The reason I would maybe prefer 1) over 2) is that 1 is known to carry= the old configuration which will force the necessary check at startup. On = the other hand 2) works fine unless KSK roll over happens and a write error= happens. This means that most of the time this will work fine and this is = what makes it dangerous in my opinion.=C2=A0

But a= gain, I am happy to update this with what the WG thinks it mostly appropria= ted. I have raised the following issue:
=C2=A0
<= div>
Thanks for explaining.=C2=A0 I had forgotten about the c= hecks before starting.=C2=A0 In my case I was hoping to only need the root = trust anchor, and keep it updated by just patching regularly.=C2=A0 Might b= e wishful thinking.

--=C2=A0
Bob Harold<= /div>
=C2=A0
=C2=A0


=C2=A0 =C2=A0=C2=A0

=C2=A0
=
--
Bob Harold
=C2=A0


On Tue, May 5, 2020 = at 11:52 AM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org&g= t; wrote:
Hi Bob,=C2=A0

Thanks for the comments. The new version of the file is available here [1] = and diff can be seen at [2].=C2=A0

I propose the following text. Does it clarify the concern ?
Avoiding the configuration file to be updated prevents old configuration fi= le to survive to writing error on read-only file systems.


"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
</mglt>


= From: Bob Harold <rharolde@umich.edu>
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Subject: Fwd: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnsse= c-validator-requirements in state "Call For Adoption By WG Issued"= ;
=C2=A0
Minor nits:

7.=C2=A0 Trust Anchor Related Recommendations

Last sentence, last few words:
"in section Section 8" > "in Section 8"

<mglt>
addressed
</mglt>

7.2.1.=C2=A0 Automated Updates to DNSSEC Trust Anchors

"TA updates is" > "TA updates are"

<mglt>
addressed
</mglt>

"but due to human" > "due to human"

<mglt>
addressed
</mglt>

7.2.2.=C2=A0 Automated Trust Anchor Check

"Not updating the configuration file prevents a failed
=C2=A0 =C2=A0synchronization to to the absence of write permission that are= hardly
=C2=A0 =C2=A0in the control of the software."

<mglt>
I propose the following text. Does it clarify the concern = ?
Avoiding the configuration file to be updated prevents old= configuration file to survive to writing error on read-only file systems.<= br>
</mglt>

Seems confusing, please rewrite.

"The TA can be queries" > "The TA can be queried"

<mglt>
addressed
</mglt>

"does not only concerns" > "does not only concern" <mglt>
addressed
</mglt>
"if the mismatch result" > "if the mismatch resulted"= ;
<mglt>
addressed
</mglt>

8.=C2=A0 Negative Trust Anchors Related Recommendations

"disable the signature check for that key the time" > "di= sable the signature check for that key until the time"
<mglt>
addressed
</mglt>

"This does not prevents" > "This does not prevent" <mglt>
addressed
</mglt>
"either an attack or a failure into" > "either an attack = or a failure in"
<mglt>
addressed
</mglt>
10.1.=C2=A0 Automated Reporting

"will take the appropriated steps" > "will take the appro= priate steps"
<mglt>
addressed
</mglt>
--
Bob Harold


---------- Forwarded message ---------
From: Bob Harold <rharolde@umich.= edu>
Date: Mon, May 4, 2020 at 4:28 PM
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-valida= tor-requirements in state "Call For Adoption By WG Issued"
To: IETF DNSOP WG <d= nsop@ietf.org>


Looks useful, I will review.

--
Bob Harold


On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <ietf-secreta= riat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.= ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


--
Daniel Mi= gault
Ericsson


--
Daniel Migault
Ericsson
--000000000000e3205f05a4fd8658-- From nobody Wed May 6 09:50:06 2020 Return-Path: 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 516253A041A for ; Wed, 6 May 2020 09:50:04 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=portfast.net 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 l7F-NpM8STON for ; Wed, 6 May 2020 09:50:02 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 8C3B13A0412 for ; Wed, 6 May 2020 09:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=f7opj4ArRunq1crHargYj+YoAYycaXOFhsNw1fJf6e0=; b=CU/KsG6qDLew54rkMVlUIBEDt8 iRIjAfUtCjH0rSdasthE2wQ8P/FdPOw2qyDh7wY5f2NGmnqiSPhc1frOp8MU4xgqEq7X5XIQX7e5g rS54idhOSWZLKfSXETYcnIKpX+FgYDrifYD4RxWV7yVRMFvOFzpe73tnquszMz8LfD8Y=; Received: from [88.212.170.130] (port=64321 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jWNFA-0005MU-20 (Exim 4.89) for dnsop@ietf.org (return-path ); Wed, 06 May 2020 17:50:00 +0100 To: IETF DNSOP WG References: <158877603626.19950.8270190025944203627@ietfa.amsl.com> From: Ray Bellis Autocrypt: addr=ray@bellis.me.uk; keydata= mQENBFvQpEEBCADBbsjhl44JARZXZoAZXoAxsd/227/ItxFHmo+cogL0qhIvn1F++OozY3mR S6ut5iuI1XMGCz2/ewqfp43k2f+o9DxjIBEqKA+M1hg8ivBMWD8//yo8S80DT2Y6GmLnRz64 sRpw0Z3LcmKULKKDU3lD9Uo05s8c2xUzJTxwxFfpjqA108nEemGnu549qV38Jz1OeuD+7P4R 3du97DyaaW5gyj/ggtiQxQtkbHG9aFRn0ASGON0uu49vRxaeuKwaGExb6FWYXJJSQLScfJ3i 356RdwaO/KezCGAhRiJ06AbPTxq2j9cvnShVb1IsxXQn73JgHVsPKDjdYo98ePWYuHWPABEB AAG0HVJheSBCZWxsaXMgPHJheUBiZWxsaXMubWUudWs+iQFUBBMBCAA+AhsDBQsJCAcCBhUK CQgLAgQWAgMBAh4BAheAFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0P8ACgkQ lD9Tw3qX+kJ+MwgAoW1eeAyyDqykaFO+N9XWMcQeFQamm1hWhjNRCOFuygycbwAe0oJPYn+i VsDoooJ/5zoHPdRV6boG8jEq8JcFwNHd5AXBPpAY9VA44ro83K7BSLMQRSfXB/OXCf5uSpb7 6DZQzem3wFys5g4bYqdSzFRiN42SjhSNxyi8KGrcEpqHgrnOBLUh+aPUgcTeFd3Dwxa21Hb/ qpOZvlKwQ7XjnAA6sMqPOmVJF4bg9D5Jg1jUOexPmwtZ1HN1wbpPZWqy3nGPXaHxHCVBp08M 7ZAIKf4QTVXcHbNxLwZtFO0TU7SK35xhzx4oy3faQIVh8K+CUMPQGU8TA3o78SefoPI8DrkB DQRb0KRXAQgAvveTWC0LkjJ2qTJcYqu0ksRKY44UCHyBNy+SfylH7cGd3FTG5qgPnOAhRAfP p7q+rxAep2adQCY4odd0CWQpmg3KhBf1qARW4HqUKMjff8+Gv7YZTiolsH+P8qQamCNemhSa 8+/vsY0roS25ZWHaHDVSIyyvHU6MsDVX8Z1nc1PwNUEqZST3I5ERVUWY/SQOTJp3fVeaU1Mo X3Bmk+7ugmUfb8Ztr63Fv3OrdEVk4ivHD8KP5c49UD9yTsVksfHqV2LN6/zdTU0CvW4SIEtX f7xQNG/o2/J50yW4e7g59ElYQZJxCjJwKusIV61aAmCe3OLLN05Kp23RrX4AwY26ewARAQAB iQE8BBgBCAAmAhsMFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0OkACgkQlD9T w3qX+kKHIggAncjGFT/LRZncAnX1IBwJfqzOzYWLOG4QHPMoHkaxrb+q3GAHXd6RAWgc8UIR fLJDowI1f2oMXh/PvqZkiVdy0qNPwhNP+i7r8OE8Co3Q1VA9Cw3Ysj2UGF5TQ2cF36XjuH9H uMp8Qy0k3lmHZgf7E/hu8u+O3AoBFG5FQ61fJjKTBazRqZmyxcbVyHHAVoAbOYJU+Mb3vfmy UlDa0FHxLHI6+pYEe7IQxzv22lGzdSgr7oVJnAz2V9sodeB2ALs+Jjh2kR0+SVPg+ED+zXWe p5alounzwhu2brS/vAJwXQXSb1R/65L4HliZk4poaC7UxC+6j0Fu7ICZa2IR9JpNnA== Message-ID: Date: Wed, 6 May 2020 17:49:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158877603626.19950.8270190025944203627@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 16:50:05 -0000 §8 of the draft says: > Some TLDs have a requirement for certain Fully Qualified Domain Names > (FQDN) within their TLD, such as "whois.example" or "nic.example". > These usually appear as signed data of the TLD and not as a delegated > child zone. These names would have to be converted to delegated > zones before enabling the DELEGATION_ONLY flag Requiring such records to become delegations may be impossible if the existing names (that might now become apex records) require a CNAME. Another non-delegation record also commonly found in TLDs is _nicname._tcp. SRV. Ray From nobody Wed May 6 10:52:03 2020 Return-Path: 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 A48153A0948 for ; Wed, 6 May 2020 10:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 qjfkp2CGuEVu for ; Wed, 6 May 2020 10:52:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 CEEED3A0947 for ; Wed, 6 May 2020 10:51:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49HPL30RRGzF1d; Wed, 6 May 2020 19:51:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588787515; bh=FdGCFVaPOOZsxBQMaIayFCqxlM/xSx0SrDV8pOYLBHM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LxjBlxp0c90FRWgdtteQZU0fIUh1kETXWAMS/oeztIOaTIRHPIx1OhoB7eyT+ssEi +QI4SmZ3fUEYF3TZw8+yB0m8muhoS3cAg7v+uwbmxh92sDPLjQKDbwG1saXvdNxMhG GH0btldqkJEIRhzrMmQlWmzOoFJwP1Ul3M6BxcOw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Tbw3SqFRjyUF; Wed, 6 May 2020 19:51:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 6 May 2020 19:51:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 083166029BA6; Wed, 6 May 2020 13:51:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0493E66B7C; Wed, 6 May 2020 13:51:53 -0400 (EDT) Date: Wed, 6 May 2020 13:51:52 -0400 (EDT) From: Paul Wouters To: Ray Bellis cc: IETF DNSOP WG In-Reply-To: Message-ID: References: <158877603626.19950.8270190025944203627@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 17:52:02 -0000 On Wed, 6 May 2020, Ray Bellis wrote: > §8 of the draft says: > >> Some TLDs have a requirement for certain Fully Qualified Domain Names >> (FQDN) within their TLD, such as "whois.example" or "nic.example". >> These usually appear as signed data of the TLD and not as a delegated >> child zone. These names would have to be converted to delegated >> zones before enabling the DELEGATION_ONLY flag > > Requiring such records to become delegations may be impossible if the > existing names (that might now become apex records) require a CNAME. Why would this _require_ to be a CNAME ? If whois.example. is now a CNAME to somewhere.something.example. then you could setup a new zone for whois.example. You are saying the tools cannot set the A/AAAA records of this new zone to point to the old CNAME? Or you are afraid the "CNAME update procedure" cannot be easilly ported to a "A/AAAA update procedure" ? I would say that a TLD should probably be capable of handling this. > Another non-delegation record also commonly found in TLDs is > _nicname._tcp. SRV. _underscore labels are excempted in the draft already, because it is understand that these really always apply to the zone itself, and are never valid delegations to other entities. Paul From nobody Wed May 6 11:01:35 2020 Return-Path: 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 766AD3A0954 for ; Wed, 6 May 2020 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 OE84b4q_6Ad7 for ; Wed, 6 May 2020 11:01:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 319143A0969 for ; Wed, 6 May 2020 11:01:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49HPXs6Y72zF5j; Wed, 6 May 2020 20:01:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588788077; bh=BxsAnLQY/bbf3NvVEn1vv1i8fkJIo3vfoHNeDeYzmNk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AQXunKJgXSF3vkSDIUITWYHwQ8lLZCDsViImL/bqIR7TJxDdMh2z0Yr73iOxcajQ0 DPxUnaxKe1rgEUkCwRazP/YGuYW3+4ecz6gKSUHQA1AtbZ10YHQ+lE4188Gczh3SAM mIa6zDd/rTmswcS29jCZjr97tmee3N+ACBZQNg/w= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yuQ8DdsPdOfv; Wed, 6 May 2020 20:01:17 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 6 May 2020 20:01:17 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 229236029BA6; Wed, 6 May 2020 14:01:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 21DD566B7C; Wed, 6 May 2020 14:01:16 -0400 (EDT) Date: Wed, 6 May 2020 14:01:16 -0400 (EDT) From: Paul Wouters To: Bob Harold cc: IETF DNSOP WG In-Reply-To: Message-ID: References: <158877603626.19950.8270190025944203627@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:01:26 -0000 On Wed, 6 May 2020, Bob Harold wrote: > Looks good to me. > 3.1.  Affected parties and their roles > "Validating Resolver: A validating that" -> "Validating Resolver: A validating resolver that" Fixed locally, will go out on the next revision. thanks! Paul From nobody Wed May 6 11:16:06 2020 Return-Path: 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 F2A4B3A09EF; Wed, 6 May 2020 11:15:31 -0700 (PDT) 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 mrvFcMooIiDR; Wed, 6 May 2020 11:15:28 -0700 (PDT) Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB893A09E0; Wed, 6 May 2020 11:15:27 -0700 (PDT) X-Virus-Scanned: by SpamTitan at cira.ca Authentication-Results: mx2.cira.ca; none Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 6 May 2020 14:15:22 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca%14]) with mapi id 15.01.1531.010; Wed, 6 May 2020 14:15:22 -0400 From: Jacques Latour To: Stephane Bortzmeyer , Tim Wicinski CC: dnsop , dnsop-chairs Thread-Topic: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements Thread-Index: AQHWI4Mt4hKYxGgDuEmEhGolTTycBaibW+zw Date: Wed, 6 May 2020 18:15:22 +0000 Message-ID: References: <20200506084836.GA14813@nic.fr> In-Reply-To: <20200506084836.GA14813@nic.fr> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [EXT] Re: Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:15:32 -0000 I support the adoption of this document as well, perhaps a bit long but as = St=E9phane stated with draft-ietf-dnsop-extended-error, it would nice to ha= ve a good story on understanding why resolvers return SERVFAIL. =20 >-----Original Message----- >From: DNSOP On Behalf Of Stephane Bortzmeyer >Sent: May 6, 2020 4:49 AM >To: Tim Wicinski >Cc: dnsop ; dnsop-chairs >Subject: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-vali= dator-requirements > >On Mon, May 04, 2020 at 03:08:20PM -0400, > Tim Wicinski wrote > a message of 64 lines which said: > >> This starts a Call for Adoption for >> draft-mglt-dnsop-dnssec-validator-requirements > >I think it is important to have such a document, because DNSSEC >failures may seriously endanger the deployment of DNSSEC (which is >already too low). The current draft seems a good starting point and I >support its adoption. > >I'm willing to review. Let's start immediately with -09: > >draft-ietf-dnsop-extended-error (recently approved by the IESG) should >be mentioned, since one of the biggest operational problem with DNSSEC >is the difficulty to understand why a resolver returns a SERVFAIL to >you. > >> More often, to date, failed validation is due to operator error and >> not an attempt to forge data. > >It can be a bug in software, too. Specially with complicated things >like NSEC3+optout+ENT+dynupdate :-{ > >The draft apparently do not mention advices on expiration slack (such >as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >consensus on (I quote Unbound documentation) "The signature inception >and expiration dates are allowed to be off by 10% of the signature >lifetime"? > >> However, a DNSSEC validator is not able to determine other than by >> trying whether a signature scheme is supported by the authoritative >> server. > >This one is unclear. First, the signer is not always an authoritative >server, signature can be done offline. Second, querying the DNSKEY is >enough, no? (Or querying the signatures, but I assume a zone won't >publish a DNSKEY without being able to sign with this algorithm.) > >Section 12 "Invalid Reporting Recommendations" is questionable. Since >most DNSSEC validation errors are not attacks, reporting these errors >may overload the DRO with problems she can do nothing >about. Monitoring is a good idea but monitoring what? "Important" (for >the DRO) domains? > >Also, the draft has many, it seems, grammar / language >problems. ("This introduces a potentially huge vector for >configuration errors, but due to human intervention as well as >potential misunderstanding of ongoing operations.") > > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed May 6 13:17:43 2020 Return-Path: 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 28F043A0B05 for ; Wed, 6 May 2020 13:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 WV_3YDkY2akP for ; Wed, 6 May 2020 13:17:39 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 7309A3A0B00 for ; Wed, 6 May 2020 13:17:39 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id j8so3533262iog.13 for ; Wed, 06 May 2020 13:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FiEEj4nKRmDkXLx8v5lYVOFKMxc80YIBMI6vwog6bTI=; b=fc5lI41nfl/wR0nAF2UQVsYIRirTuoPqyvXSLYXmCiwVMrA4nBI2BepRlYVhRenlrd YA1/RdjOhZNFBu/dqD2wfRvffIozLawlVkmfx6Fzh8cAbIuoQV4/i5mYKkAVN+p8lwar qucguYpCdlKqMc57lAloT4+q4mCqDEdu+aV/HrpZTEnJRf88JfTAa0DlPOp0rIkQ3IZR OWkNec+xwT5l7aq80M6EKtY8u4duSVYWSSmZJZE70KbzkvqM3nrz9LLfWp/lH8iXO6DW 7tJLcQgxPdVAxW0xxDG1fHHOZ79gNbrFk3KocMkSRwgz/INJf5C4fjUcr9TKSbYcirLR NIEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FiEEj4nKRmDkXLx8v5lYVOFKMxc80YIBMI6vwog6bTI=; b=FSiPcJUf/o2ojbBmMGSOCxWMdHMsDyibJCFjNallRINxmCAfA3XvWczH/9AXt2XaEm /C52AsNemUsBUUt7DBQXBv3g/RaNv/4ayUl88IvdPWEsz60KDTsQmKgEGaGZthYVTaM+ 3QFruYm9EvJImJkCHKPW5l1KFymUyUAWTPLJu8xr0tH2I54vwdq0JnsUdEgG0bMq/4hK w6eHFqrIYvGZlqUramjYagec0CfmdxPUuQCK1kJRlVTHTrsvUI9k6Cb01Uisc3CchDx8 wKvoAtBo7zj3Bw3Q+TTlg+nClSTAcSmQoKhsxAey2JjXNyPvwPrbcO8nUQ145PHeeKp5 4yeQ== X-Gm-Message-State: AGi0Pub7uvCk0tcdnaaRBrkKfOGp4YKXJJA7LQvFYpooWcHcjydQO6am mTIRcHWQm17FdtVOn3OxAyqx8p6dW1Pz0kVjUgdsdd81 X-Google-Smtp-Source: APiQypLMPfxuWuwq2QJ7tl83CCijjjFn3q7aB3gV5JL8KSvveQH1oBE7cyazIn05ZaISJc9Kf/subdiOY6KAqFdSmCM= X-Received: by 2002:a5e:8c03:: with SMTP id n3mr10083136ioj.160.1588796258573; Wed, 06 May 2020 13:17:38 -0700 (PDT) MIME-Version: 1.0 From: Dragana Damjanovic Date: Wed, 6 May 2020 22:17:27 +0200 Message-ID: To: dnsop@ietf.org Content-Type: multipart/alternative; boundary="0000000000009ce63405a5007472" Archived-At: Subject: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:17:42 -0000 --0000000000009ce63405a5007472 Content-Type: text/plain; charset="UTF-8" I have some minor comments and clarification questions. 1) in "Example: Protocol enhancements": > and the key=value pairs indicate that it supports QUIC in addition to > HTTPS over TLS > Should "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS 2) Clarification question: Can SvcDomainName point to another AliasForm record? As I understand it, it cannot. It can point to a CNAME that points to an AliasForm record. The descriptions of the server and client behavior sections do not mention this. Should they mention this again? I am just wondering if the description in "Client behavior" and "DNS Server Behavior" should be more precise and mention this constraint and also the limit for a chains of CNAME and SVCB of 8? 3) Proxies should not use SVCB/HTTPSSVC. section "Clients using a Proxy" should say that explicitly. (To make useful for a proxy to use SVCB/HTTPSSVC records, there should be a way to communicate back to the client about that SVCB/HTTPSSVC parameters. This does not exist at the moment and will add a delay in some cases, etc.) 4) If no-default-alpn is present the alpn parameter must be present as well, otherwise the "ALPN set" is empty? 5) A clarification question: In the section "ipv4hint and ipv6hint": > An empty list of addresses is invalid. Empty hints will not mean that the record is malformed, i.e. it is not a fatal error that will make the whole record invalid? 6) Nit: > As discussed in {{client-behavior}}, clients MUST be able fetch additional > information that is required to use > s/MUST be able fetch/MUST be able to fetch dragana --0000000000009ce63405a5007472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have some minor comments and clarification question= s.

1) in "Example: Protocol enhancements&= quot;:
and= the key=3Dvalue pairs indicate that it supports QUIC in addition to HTTPS over TLS
=C2=A0
Shoul= d=C2=A0 "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is = also HTTPS over TLS


2) Clarific= ation question: Can=C2=A0 SvcDomainName point to another AliasForm record? = As I understand it, it cannot. It can point to a CNAME that points to an Al= iasForm record.
The descriptions of the server and client be= havior sections do not mention this. Should they mention this again?
I am just wondering if the description in "Client behavior&quo= t; and "DNS Server Behavior" should be more precise and mention t= his constraint and also the limit for a chains of CNAME and SVCB of 8?


3) Proxies should not use SVCB/HTTPSSVC= . section "Clients using a Proxy" should say that explicitly. (To= make useful for a proxy to use SVCB/HTTPSSVC records, there should be a wa= y to communicate back to the client about that SVCB/HTTPSSVC parameters. Th= is does not exist at the moment and will add a delay in some cases, etc.)

4) If no-default-alpn is present the alpn parameter must b= e present as well, otherwise the "ALPN set" is empty?
<= br>
5) A clarification question: In the section "ipv4hint an= d ipv6hint":
An e= mpty list of addresses is invalid.
Empty hints will = not mean that the record is malformed, i.e. it is not a fatal error that wi= ll make the whole record invalid?

6) Nit:
As discussed in {{c= lient-behavior}}, clients MUST be able fetch additional information that is required to use

s= /MUST be able fetch/MUST be able to fetch

drag= ana
--0000000000009ce63405a5007472-- From nobody Wed May 6 13:20:39 2020 Return-Path: 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 1EBF33A0B0B for ; Wed, 6 May 2020 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tjE9/Flt; dkim=pass (1536-bit key) header.d=taugh.com header.b=wQ+s6mLH 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 Xkb_LJNNWMBo for ; Wed, 6 May 2020 13:20:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 962A03A0DFE for ; Wed, 6 May 2020 13:19:48 -0700 (PDT) Received: (qmail 77574 invoked from network); 6 May 2020 20:19:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12f03.5eb31be3.k2005; bh=woWqjzLDu/fM2tGpB+Jrx6xw+7aYYh85oXyVme3nUS4=; b=tjE9/FltR5V+aJemAnddCSUTYc+3yjM/NgZVOQdwYcCyatH0FvgHJqxU9VYw11JQ58aDtPZSkyETeyHwri9G0ndSuyzyce/RzBlI3A2JD89eGJUmfhG0xpijevW2jdBwyM/qZQo7B+sVBPIrozZhDB1Xxlptd+xu/QLoZEe+A3wgH+K9taXb/8D+a1/oGmOsNTANmeKUcYhq+iT+zrsgnr8ReEwsZv22QoKgXDMQB62qBBbTWh6wDkOom0s7Tmgh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12f03.5eb31be3.k2005; bh=woWqjzLDu/fM2tGpB+Jrx6xw+7aYYh85oXyVme3nUS4=; b=wQ+s6mLH1d2BSD8Ggvc6bI6qqNrqcEVMUM/n3vdAzeI48VYgqwN+qNd1d+rnjO4ZgVBICo+Vh0Uoc3KCpk/iF9gUPQueDCTlH/G5DwslFUX6thPmyb8FeBcFLgV94bO2ivsF3CY1QiVszjnqs3A4uD4l1AK6Hfbqf9RjcAwYcny6koSkwWNwJqES3twaJ97ELAc/DPy3PhEvPsbTRJjzNNqXMwuMwO4Vny5aTOlhAIek5wuDQ5jaseIaTEb/6m3z Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 May 2020 20:19:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 0F48918D9BA0; Wed, 6 May 2020 16:19:46 -0400 (EDT) Date: 6 May 2020 16:19:46 -0400 Message-Id: <20200506201947.0F48918D9BA0@ary.qy> From: "John Levine" To: dnsop@ietf.org Cc: paul@nohats.ca In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-only-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:20:37 -0000 In article you write: >> Requiring such records to become delegations may be impossible if the >> existing names (that might now become apex records) require a CNAME. > >Why would this _require_ to be a CNAME ? Administrative require, not technical. This seems pretty hypothetical, since I don't think I've ever seen a CNAME in a TLD zone. >> Another non-delegation record also commonly found in TLDs is >> _nicname._tcp. SRV. > >_underscore labels are excempted in the draft already, because > [ they're not host names ] Right, but that still doesn't deal with stuff like monitor-nominet.horse. How about instead saying the zone has only names one level below the zone cut, other than _underscore ones. That prevents shadowed delegations just as well and matches actual zone files a lot better. From nobody Wed May 6 14:48:47 2020 Return-Path: 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 466E33A093F; Wed, 6 May 2020 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 McewA5NQjDAz; Wed, 6 May 2020 14:48:42 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 167753A091A; Wed, 6 May 2020 14:48:42 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id s11so2048782vsm.3; Wed, 06 May 2020 14:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6sheKa8O7jgImMGJJxQEAknIASQZYZpRQ39cJZLwyUI=; b=N+nhmVG7ZEo6D/xpkNV426LGh4qo6O667l1HTk307nG9pKgvOonLML0n4Jjq6u725y OD37WM8QYzbE5GeWXMQrNb5r9MMXmP9j9rxw/WEvl/gvxY40SQ1HJhSFq9qtkjp8T89m b5bHkC4MHEW3HT3KQt+/6oEXGqiKEDs4n/qvNgULnDSIMgbuDVaHZ6rrCFzqpP/Gw+pW jMom7+x2Wm6gOym8O/jb0k4g0gaW/vGQ/d55ei5HzVRZnfpUEjfWr9pOMx9jZJIxD89s B164UI77gA8Koo8Y2Cg8ameaBdDUN81FhJEOtq5t8cUogA7Ij06IuYi0XCzlNzdlg7sV 4j1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6sheKa8O7jgImMGJJxQEAknIASQZYZpRQ39cJZLwyUI=; b=NkPqtAlWsdaBkP4MoT9AyyWtRVSEvfGbbtlzgJL1caz7TDmHV62drmV8J+HK5uEI8U mZqbFc22YhxnJrg5h+Aku9gzPPF3tsG2+No+jJJudlkliJrGize6xkwTeEm2Ke5Nvn7U E86B8U58HTCzjU9Gwa4A+ZMNx9p+5pG8IDxbLgp1RFeaP5q4BcqmS+2bps73ykoKkww+ MHm0VblsJ8sw9NyiPilnTrguNc8+WeWM5QF7uOvX+WxlPImffMh/tPBRRaCC9I4ctwIb hQzdLuEPYo2AWtVNOME5HMuRhfT/WpjSLJHgt0WZA1nlFvzbG5KwDBVQWB4e/VVsqk62 VweA== X-Gm-Message-State: AGi0PubTJ0byrV25gSBPcQdeM3x5FdNQk7Df11XGpDEGI1WRUtxS/Owy uXh9Yf8DbX3y8lwdDVCVFJheZzg7qn31dMgFU8A= X-Google-Smtp-Source: APiQypIk9mKUhuS9DTklKuwTrXT/ZfZqSAQdeF0NTfXMI35k5lhcTN/9U+Eu49QhiYVflGPxB5V/odv2uHSU7KLxlbY= X-Received: by 2002:a67:2e01:: with SMTP id u1mr9120023vsu.31.1588801720720; Wed, 06 May 2020 14:48:40 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: <20200506084836.GA14813@nic.fr> From: Daniel Migault Date: Wed, 6 May 2020 17:48:29 -0400 Message-ID: To: Stephane Bortzmeyer Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000002ea25405a501baa5" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 21:48:44 -0000 --0000000000002ea25405a501baa5 Content-Type: text/plain; charset="UTF-8" Hi Stephane, Thanks you for the comments. Please see inline my responses. Yours, Daniel On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer wrote: > On Mon, May 04, 2020 at 03:08:20PM -0400, > Tim Wicinski wrote > a message of 64 lines which said: > > > This starts a Call for Adoption for > > draft-mglt-dnsop-dnssec-validator-requirements > > I think it is important to have such a document, because DNSSEC > failures may seriously endanger the deployment of DNSSEC (which is > already too low). The current draft seems a good starting point and I > support its adoption. > > I'm willing to review. Let's start immediately with -09: > > draft-ietf-dnsop-extended-error (recently approved by the IESG) should > be mentioned, since one of the biggest operational problem with DNSSEC > is the difficulty to understand why a resolver returns a SERVFAIL to > you. > > This is a good catch and the DNS client side is yet missing in the draft. Activation of EDE should be recommended. This provides the DNS client has a better understanding of the resolution, increases trust in the resolver. I have created an issue here and will come with additional text. https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2 > More often, to date, failed validation is due to operator error and > > not an attempt to forge data. > > It can be a bug in software, too. Specially with complicated things > like NSEC3+optout+ENT+dynupdate :-{ > This is correct. I cannot say this case the "bug" is entirely clear to me, but at a high level the problem was due to a difference of interpretation between a signer and authoritative server. This resulted in data the resolver could not result in a proper validation. Even when fixed on the authoritative part, some resolver were not handling this properly. I believe that the experience associated to that bug could impact the document as follows: 1) the draft should mention that validation failure can also be due to software bugs. 2) we should have a recommendation for running different implementations and provide the ability to switch to one in case a bug is detected. 3) What is unclear to me is how EDE could have helped in this case. I opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/3 > The draft apparently do not mention advices on expiration slack (such > as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a > consensus on (I quote Unbound documentation) "The signature inception > and expiration dates are allowed to be off by 10% of the signature > lifetime"? > > Correct. This is not considered in the current document. I am happy to consider the consensus. The following issue has been opened: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/4 > > However, a DNSSEC validator is not able to determine other than by > > trying whether a signature scheme is supported by the authoritative > > server. > > This one is unclear. First, the signer is not always an authoritative > server, signature can be done offline. Second, querying the DNSKEY is > enough, no? (Or querying the signatures, but I assume a zone won't > publish a DNSKEY without being able to sign with this algorithm.) > > Correct. In this section I wanted to emphasize on providing a validator some means to ensure that it can safely deprecate an algorithm. While a resolver that supports a signature scheme can apply that signature to all received signed RRset. On the authoritative side, each zone needs to be requested. The problem associated to request this is mostly the knowledge of the zone. I think the section should: 1) clarify the text and mentioning how the signature schemes are discovered. 2) It is unclear if we should keep track of the requested domain, in order to be able to request the DNSKEYs 3) emphasize on a communication of supported algorithms between authoritative servers and resolvers. I have opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/5 Section 12 "Invalid Reporting Recommendations" is questionable. Since > most DNSSEC validation errors are not attacks, reporting these errors > may overload the DRO with problems she can do nothing > about. Monitoring is a good idea but monitoring what? "Important" (for > the DRO) domains? > > I agree that we could be a little be more specific. At minimum I envisioned logging the domains with the number of failures and reporting those with a threshold. I opened the following issue: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/6 > Also, the draft has many, it seems, grammar / language > problems. ("This introduces a potentially huge vector for > configuration errors, but due to human intervention as well as > potential misunderstanding of ongoing operations.") > > This erro has been raised by Bob and already corrected in the version on the repository: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd The correct text is: This introduces a potentially huge vector for configuration errors, due to human intervention as well as potential misunderstanding of ongoing operations. Others grammar and language issues have also been corrected. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --0000000000002ea25405a501baa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephane,=C2=A0
=
Thanks you for the comments. Please see inline m= y responses.

Yours,=C2=A0
Da= niel

On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, May 04, 2020 at 03:08:20PM -0= 400,
=C2=A0Tim Wicinski <tjw.ietf@gmail.com> wrote
=C2=A0a message of 64 lines which said:

> This starts a Call for Adoption for
> draft-mglt-dnsop-dnssec-validator-requirements

I think it is important to have such a document, because DNSSEC
failures may seriously endanger the deployment of DNSSEC (which is
already too low). The current draft seems a good starting point and I
support its adoption.

I'm willing to review. Let's start immediately with -09:

draft-ietf-dnsop-extended-error (recently approved by the IESG) should
be mentioned, since one of the biggest operational problem with DNSSEC
is the difficulty to understand why a resolver returns a SERVFAIL to
you.

=C2=A0This is a good catch and the DNS client side is= yet missing in the draft. Activation of EDE should=C2=A0be recommended.=C2= =A0This provides the DNS client =C2=A0has a better understanding of the res= olution, increases trust in the resolver.

I have = created an issue here and will come with additional text.


> More often, to date, failed validation is due to operator error and > not an attempt to forge data.

It can be a bug in software, too. Specially with complicated things
like NSEC3+optout+ENT+dynupdate :-{

Thi= s is correct. I cannot say this case the "bug" is entirely clear = to me, but at a high level the problem was due to a difference of interpret= ation between a signer and authoritative server. This resulted in data the = resolver could not result in a proper validation.=C2=A0Even when fixed on t= he=C2=A0authoritative part, some resolver were not handling this properly. = I believe that the experience associated to=C2=A0that=C2=A0bug could impact= the document as follows:
1) the draft should mention that valida= tion failure can also be due to software bugs.
2) we should have = a recommendation for running different implementations and provide the abil= ity to switch to one in case a bug is detected.=C2=A0
3) What is = unclear to me is how EDE could have helped in this case.=C2=A0=C2=A0
<= div>
I opened the following issue:
=C2=A0
=C2=A0
=C2=A0
The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception<= br> and expiration dates are allowed to be off by 10% of the signature
lifetime"?


Correct. This is not considered in the= current document. I am happy to consider the consensus. The following=C2= =A0issue has been opened:
=C2=A0
> However, a DNSSEC validator is not able to determine other than by
> trying whether a signature scheme is supported by the authoritative > server.

This one is unclear. First, the signer is not always an authoritative
server, signature can be done offline. Second, querying the DNSKEY is
enough, no? (Or querying the signatures, but I assume a zone won't
publish a DNSKEY without being able to sign with this algorithm.)


Correct. In this section I wanted to e= mphasize on providing a validator some means to ensure that it can safely d= eprecate an algorithm. While a resolver that supports a signature scheme ca= n apply that signature to all received signed RRset. On the authoritative s= ide, each zone needs to be requested. The problem associated to request thi= s is mostly the knowledge of the zone.=C2=A0

I thi= nk the section should:
1) clarify the text and mentioning how the= signature schemes are discovered.
2) It is unclear if we should = keep track of the requested domain, in order to be able to request the DNSK= EYs=C2=A0
3) emphasize on a communication of supported algorithms= between authoritative servers and resolvers.=C2=A0
=C2=A0
<= div>I have opened the following issue:

Section 12 "Invalid Reporting Recommendations" is questionable. S= ince
most DNSSEC validation errors are not attacks, reporting these errors
may overload the DRO with problems she can do nothing
about. Monitoring is a good idea but monitoring what? "Important"= (for
the DRO) domains?


I agree that we could be a little be m= ore specific. At minimum I envisioned logging the domains with the number o= f failures and reporting those with a threshold.=C2=A0=C2=A0
I op= ened the following issue:
https://github.com/mgl= t/draft-mglt-dnsop-dnssec-validator-requirements/issues/6=C2=A0=C2=A0
=C2=A0
Also, the draft has many, it seems, grammar / language
problems. ("This introduces a potentially huge vector for
configuration errors, but due to human intervention as well as
potential misunderstanding of ongoing operations.")

This erro=C2=A0has been raised by Bob and already corrected in the v= ersion on the repository:

The correct text is:
This introduces a= potentially huge vector for configuration errors, due to human interventio= n as well as potential misunderstanding of ongoing operations.
=

Others grammar and language issues have also been corre= cted.=C2=A0
=C2=A0
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--0000000000002ea25405a501baa5-- From nobody Wed May 6 14:58:12 2020 Return-Path: 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 ADA063A0AA3; Wed, 6 May 2020 14:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 3wuaiNn3pZOt; Wed, 6 May 2020 14:58:08 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 96C773A0B92; Wed, 6 May 2020 14:58:08 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id z16so1108825uae.11; Wed, 06 May 2020 14:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FOuG06Ty7A/DrqSNyC2YdRkLIXJI3dytEf+XxXcZEkU=; b=q/fvVx5AyNcHv5db/HnSDMTEiofBbU2Bg4P7J4Ufj9va4JcMc+APSU7q+ks6bjBUJE VNd2ujtJS3BOIx5g0jOaZ8iLfDJreOF1y7bFNtRH9SkcqJU0cKxCYSsEVbdeRyAuiJdy IUrKKBSy6hShLwIPloZkN04u7Y+W2oFlRiXO7OwcTDNVcbz5jYYPWft+xNEju+eI0T5a +BruiD8nS405jkq6fRZcexQHnX2N+u0dySEpAkdYi/eOAhmQ2zDo9XhKJC1e3QGEYz1k MpSxPbV9E0w4tv/reGbNP9UIb5KuB9L5CsfAXKD2vzjtitKrZ/n0lMu6ThAB8VUdb4P9 6FFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FOuG06Ty7A/DrqSNyC2YdRkLIXJI3dytEf+XxXcZEkU=; b=OSVGliscl9bsjO1c0hSC85BOHcwEEL4wMMPfl337yMmmNQ4SeGNCSovAuUURRn5txa N2ZEOBhXNlmiat4Hzu4EiiD635ew3TFuZonF/zBqI9P6OheyoRLhGPLWn1oBnXjpQmR5 BJeqIWHl3eU0cXKwDRLcHKTJyR4nT8qAI6mUA38FU+13x5LPpAdrtODImdciafc4ybh8 gAFqVgnUUEY6deS8Zu9gfCQwbmJS5mM53txQn2OgU7TFaN94VmKs7b6pjawJ2Qg8Gw7t f3nQWKKgM+YObFrl57AULNEQclEWvnXm8jxACIKACqLM1FfCKWsFfdbzeF25pUQr/h1f bmEA== X-Gm-Message-State: AGi0PubBWvS7ejicYcKyFoqRf/eQL0fbTlWoQ+EgmkXj7LKYdB8UVzq5 tOWKB/6umjZBn2WzgsAROOnRBljh77/9o7G+cDs= X-Google-Smtp-Source: APiQypIh5gcCBB8KEXBJpmyLpCvtAmyVDF/EtvAZseWekABj36ersdbEsoD6jZc1ehQIgCURHXAjUZQUdfvCVc6uetA= X-Received: by 2002:a9f:222c:: with SMTP id 41mr9081962uad.88.1588802287427; Wed, 06 May 2020 14:58:07 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: From: Daniel Migault Date: Wed, 6 May 2020 17:57:56 -0400 Message-ID: To: Jacques Latour Cc: Stephane Bortzmeyer , Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000f5e81705a501dbd3" Archived-At: Subject: Re: [DNSOP] [EXT] Re: Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 21:58:11 -0000 --000000000000f5e81705a501dbd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jacques, Thanks you for the feedbacks. As suggested by Stephane, the document needs to emphasize on the communication between the client and the resolver. I open the following issue and will address this in the next version. https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issu= es/2 Yours, Daniel On Wed, May 6, 2020 at 2:16 PM Jacques Latour wrote: > I support the adoption of this document as well, perhaps a bit long but a= s > St=C3=A9phane stated with draft-ietf-dnsop-extended-error, it would nice = to have > a good story on understanding why resolvers return SERVFAIL. > > >-----Original Message----- > >From: DNSOP On Behalf Of Stephane Bortzmeyer > >Sent: May 6, 2020 4:49 AM > >To: Tim Wicinski > >Cc: dnsop ; dnsop-chairs > >Subject: [EXT] Re: [DNSOP] Call for Adoption: > draft-mglt-dnsop-dnssec-validator-requirements > > > >On Mon, May 04, 2020 at 03:08:20PM -0400, > > Tim Wicinski wrote > > a message of 64 lines which said: > > > >> This starts a Call for Adoption for > >> draft-mglt-dnsop-dnssec-validator-requirements > > > >I think it is important to have such a document, because DNSSEC > >failures may seriously endanger the deployment of DNSSEC (which is > >already too low). The current draft seems a good starting point and I > >support its adoption. > > > >I'm willing to review. Let's start immediately with -09: > > > >draft-ietf-dnsop-extended-error (recently approved by the IESG) should > >be mentioned, since one of the biggest operational problem with DNSSEC > >is the difficulty to understand why a resolver returns a SERVFAIL to > >you. > > > >> More often, to date, failed validation is due to operator error and > >> not an attempt to forge data. > > > >It can be a bug in software, too. Specially with complicated things > >like NSEC3+optout+ENT+dynupdate :-{ > > > >The draft apparently do not mention advices on expiration slack (such > >as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a > >consensus on (I quote Unbound documentation) "The signature inception > >and expiration dates are allowed to be off by 10% of the signature > >lifetime"? > > > >> However, a DNSSEC validator is not able to determine other than by > >> trying whether a signature scheme is supported by the authoritative > >> server. > > > >This one is unclear. First, the signer is not always an authoritative > >server, signature can be done offline. Second, querying the DNSKEY is > >enough, no? (Or querying the signatures, but I assume a zone won't > >publish a DNSKEY without being able to sign with this algorithm.) > > > >Section 12 "Invalid Reporting Recommendations" is questionable. Since > >most DNSSEC validation errors are not attacks, reporting these errors > >may overload the DRO with problems she can do nothing > >about. Monitoring is a good idea but monitoring what? "Important" (for > >the DRO) domains? > > > >Also, the draft has many, it seems, grammar / language > >problems. ("This introduces a potentially huge vector for > >configuration errors, but due to human intervention as well as > >potential misunderstanding of ongoing operations.") > > > > > >_______________________________________________ > >DNSOP mailing list > >DNSOP@ietf.org > >https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 Daniel Migault Ericsson --000000000000f5e81705a501dbd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jacques,=C2=A0

Thanks you for the fe= edbacks. As suggested by Stephane, the document needs to emphasize on the c= ommunication between the client and the resolver. I open the following issu= e and will address this in the next version.

Yours,=C2=A0
Danie= l

On Wed, May 6, 2020 at 2:16 PM Jacques Latour <Jacques.Latour@cira.ca> wrote:
I support the adoption of thi= s document as well, perhaps a bit long but as St=C3=A9phane stated with dra= ft-ietf-dnsop-extended-error, it would nice to have a good story on underst= anding why resolvers return SERVFAIL.

>-----Original Message-----
>From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Stephane Bortzmeyer
>Sent: May 6, 2020 4:49 AM
>To: Tim Wicinski <tjw.ietf@gmail.com>
>Cc: dnsop <dnsop= @ietf.org>; dnsop-chairs <dnsop-chairs@ietf.org>
>Subject: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-v= alidator-requirements
>
>On Mon, May 04, 2020 at 03:08:20PM -0400,
> Tim Wicinski <tjw.ietf@gmail.com> wrote
> a message of 64 lines which said:
>
>> This starts a Call for Adoption for
>> draft-mglt-dnsop-dnssec-validator-requirements
>
>I think it is important to have such a document, because DNSSEC
>failures may seriously endanger the deployment of DNSSEC (which is
>already too low). The current draft seems a good starting point and I >support its adoption.
>
>I'm willing to review. Let's start immediately with -09:
>
>draft-ietf-dnsop-extended-error (recently approved by the IESG) should<= br> >be mentioned, since one of the biggest operational problem with DNSSEC<= br> >is the difficulty to understand why a resolver returns a SERVFAIL to >you.
>
>> More often, to date, failed validation is due to operator error an= d
>> not an attempt to forge data.
>
>It can be a bug in software, too. Specially with complicated things
>like NSEC3+optout+ENT+dynupdate :-{
>
>The draft apparently do not mention advices on expiration slack (such >as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
>consensus on (I quote Unbound documentation) "The signature incept= ion
>and expiration dates are allowed to be off by 10% of the signature
>lifetime"?
>
>> However, a DNSSEC validator is not able to determine other than by=
>> trying whether a signature scheme is supported by the authoritativ= e
>> server.
>
>This one is unclear. First, the signer is not always an authoritative >server, signature can be done offline. Second, querying the DNSKEY is >enough, no? (Or querying the signatures, but I assume a zone won't<= br> >publish a DNSKEY without being able to sign with this algorithm.)
>
>Section 12 "Invalid Reporting Recommendations" is questionabl= e. Since
>most DNSSEC validation errors are not attacks, reporting these errors >may overload the DRO with problems she can do nothing
>about. Monitoring is a good idea but monitoring what? "Important&q= uot; (for
>the DRO) domains?
>
>Also, the draft has many, it seems, grammar / language
>problems. ("This introduces a potentially huge vector for
>configuration errors, but due to human intervention as well as
>potential misunderstanding of ongoing operations.")
>
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org<= br> >https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--000000000000f5e81705a501dbd3-- From nobody Wed May 6 18:32:52 2020 Return-Path: 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 B19513A0E0D for ; Wed, 6 May 2020 18:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 66S_x8GEA5qM for ; Wed, 6 May 2020 18:32:41 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 CF5AF3A0E0F for ; Wed, 6 May 2020 18:32:40 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id z6so4841759wml.2 for ; Wed, 06 May 2020 18:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XBlneT7QA562ap91OrFMjqAcJqpjCXGZWfoQU+nj37k=; b=QceYSIRQbPlJ+yjBl6SSlJCDhQd9lH/x5dymO+Zv62CvCCRRFm2d1qEaW/63r1vK74 I2329lLfo8nvMzRx2lyjCGfHcqJl0hzfIeHh+KvoL0mAt+9W6cVMC/Lv29QLz1LQSYn3 Qf47d9lDFpNeuLZg4wC8i3bi2+uhBpEWn2kaD1OcHHV2ytcxbtIMv7sefQVNeyLC9evb Dd4OyVLXBqHd4uzWhG+W0bDYXLYu7X7ae5t9IQdOKWHfh416k/FXSk2sB3+8Q+5kVB1O xRxA0k8MBqmd9ymLvVcyfDbE12vwaEVBOPrNYrxn5y0fucGzxlB/BSxzP7PqiEG+RBM+ af+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XBlneT7QA562ap91OrFMjqAcJqpjCXGZWfoQU+nj37k=; b=K/2KecNNQlufnjzOLCLeEBL2E+xen0US91s8IEIsGqoSmduQQaB6Bh62GcYrZ70cBM hil/XnZkmfCALAS9YIijQKVSZXo8Bppqb7wXMOXMm4elZKhi0BTVUmzMup7RFgybO1fs x7eicnkzoRKi4HIKIULn6iQsG+JHSyPAMWR07TG83pzGoKKihCJ3MNU+S6LgaHaJrsEX 6c+wX2p44Z2ZnibWtnQfpxefaqF7x/p2JAZGAKiNQ70beCaB5B6kAeKT11trt5apdMD7 2GQq77dcbha6qw+zQ8sGVBMTpZRZ2oD3+I61+LKBYu+zMuagLaI4CtsQRqRWtMPxA+ho d+1w== X-Gm-Message-State: AGi0Puad68Rn8ATUS4J4BAQ4Hil2E/vIWf+4Cb2702UFe7DqMu4KkapE AKiX8ZU6jiia7H0CUclMyd1v4SxldGd8yWad5wud/A== X-Google-Smtp-Source: APiQypKwJlzeb59lQkAavF32B3qrpGVrcKygHDY0R+4j30vezvBGLQxCb1trv2hA/0Y/BNOJZV/Ie1EGXyk0maS/IKw= X-Received: by 2002:a05:600c:230f:: with SMTP id 15mr4461963wmo.101.1588815158592; Wed, 06 May 2020 18:32:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 6 May 2020 21:32:26 -0400 Message-ID: To: Dragana Damjanovic Cc: dnsop Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002f004605a504db52" Archived-At: Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 01:32:48 -0000 --0000000000002f004605a504db52 Content-Type: multipart/alternative; boundary="00000000000024b51105a504db54" --00000000000024b51105a504db54 Content-Type: text/plain; charset="UTF-8" On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic wrote: > I have some minor comments and clarification questions. > > 1) in "Example: Protocol enhancements": > >> and the key=value pairs indicate that it supports QUIC in addition to >> HTTPS over TLS >> > > Should "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS > You're right; that would be clearer. Change proposed at https://github.com/MikeBishop/dns-alt-svc/pull/146. > 2) Clarification question: Can SvcDomainName point to another AliasForm > record? As I understand it, it cannot. > Technically, SvcDomainName doesn't point to a record. It provides a domain name, and the recursive resolver should perform some queries to that name. The QTYPE of those queries can vary depending on context. If the SVCB record is in AliasForm (priority=0), the resolver should query A, AAAA, and SVCB for the SvcDomainName. If the SVCB record is in ServiceForm, the resolver should query A and AAAA records on the SvcDomainName. All of these queries follow CNAMEs as per usual. It can point to a CNAME that points to an AliasForm record. > >From SVCB's perspective, CNAME is completely transparent. ... > I am just wondering if the description in "Client behavior" and "DNS > Server Behavior" should be more precise and mention this constraint and > also the limit for a chains of CNAME and SVCB of 8? > The chain length limit has been discussed at some length here without consensus. The current draft says > Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?) prior to reaching terminal address records. I suspect that we are going to end up removing this number entirely, and leaving the choice of limit to implementations. This isn't ideal for interoperability, but it seems to be no worse than the status quo with CNAME. 3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy" > should say that explicitly. (To make useful for a proxy to use > SVCB/HTTPSSVC records, there should be a way to communicate back to the > client about that SVCB/HTTPSSVC parameters. This does not exist at the > moment and will add a delay in some cases, etc.) > I agree that transport proxies cannot issue SVCB or HTTPSSVC queries, because they do not know what protocol/scheme is running over the transport. Tracked at https://github.com/MikeBishop/dns-alt-svc/issues/147. 4) If no-default-alpn is present the alpn parameter must be present as > well, otherwise the "ALPN set" is empty? > Correct. 5) A clarification question: In the section "ipv4hint and ipv6hint": > >> An empty list of addresses is invalid. > > Empty hints will not mean that the record is malformed, i.e. it is not a > fatal error that will make the whole record invalid? > An RR with an empty IP hint is malformed, in presentation format or wire format. 6) Nit: > >> As discussed in {{client-behavior}}, clients MUST be able fetch >> additional information that is required to use >> > > s/MUST be able fetch/MUST be able to fetch > Thanks. Fixed! > > dragana > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic wrote: > I have some minor comments and clarification questions. > > 1) in "Example: Protocol enhancements": > >> and the key=value pairs indicate that it supports QUIC in addition to >> HTTPS over TLS >> > > Should "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS > > > 2) Clarification question: Can SvcDomainName point to another AliasForm > record? As I understand it, it cannot. It can point to a CNAME that points > to an AliasForm record. > The descriptions of the server and client behavior sections do not mention > this. Should they mention this again? > I am just wondering if the description in "Client behavior" and "DNS > Server Behavior" should be more precise and mention this constraint and > also the limit for a chains of CNAME and SVCB of 8? > > > 3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy" > should say that explicitly. (To make useful for a proxy to use > SVCB/HTTPSSVC records, there should be a way to communicate back to the > client about that SVCB/HTTPSSVC parameters. This does not exist at the > moment and will add a delay in some cases, etc.) > > 4) If no-default-alpn is present the alpn parameter must be present as > well, otherwise the "ALPN set" is empty? > > 5) A clarification question: In the section "ipv4hint and ipv6hint": > >> An empty list of addresses is invalid. > > Empty hints will not mean that the record is malformed, i.e. it is not a > fatal error that will make the whole record invalid? > > 6) Nit: > >> As discussed in {{client-behavior}}, clients MUST be able fetch >> additional information that is required to use >> > > s/MUST be able fetch/MUST be able to fetch > > dragana > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000024b51105a504db54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 6, 2020 at 4:18 PM Dragan= a Damjanovic <dragana.damja= no@gmail.com> wrote:
I have some minor comments and clarificat= ion questions.

1) in "Example: Protocol e= nhancements":
and the key=3Dvalue pairs indicate that it supports QUIC in addition to HTTPS over TLS
=C2=A0
Shoul= d=C2=A0 "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is = also HTTPS over TLS

You'= ;re right; that would be clearer.=C2=A0 Change proposed at=C2=A0https://github.com/Mike= Bishop/dns-alt-svc/pull/146.
=C2=A0
2) Clarification questi= on: Can=C2=A0 SvcDomainName point to another AliasForm record? As I underst= and it, it cannot.

Technically,= SvcDomainName doesn't point to a record.=C2=A0 It provides a domain na= me, and the recursive=C2=A0resolver should perform some queries to that nam= e.=C2=A0 The QTYPE of those queries can vary depending on context.

If the SVCB record is in AliasForm (priority=3D0), the res= olver should query A, AAAA, and SVCB for the SvcDomainName.=C2=A0 If the SV= CB record is in ServiceForm, the resolver should query A and AAAA records o= n the SvcDomainName.=C2=A0 All of these queries follow CNAMEs as per usual.=

It can point to a CNAME that points to an AliasForm reco= rd.

From SVCB's perspe= ctive, CNAME is completely transparent.
=C2=A0
...
I = am just wondering if the description in "Client behavior" and &qu= ot;DNS Server Behavior" should be more precise and mention this constr= aint and also the limit for a chains of CNAME and SVCB of 8?

The chain length limit has been discussed= at some length here without consensus.=C2=A0 The current draft says=C2=A0<= /div>

>=C2=A0=C2=A0Chains of consecutive SVCB and CNA= ME records SHOULD be limited to (8?) prior to reaching terminal address rec= ords.

I suspect that we are going to end up removi= ng this number entirely, and leaving the choice of limit to implementations= .=C2=A0 This isn't ideal for interoperability, but it seems to be no wo= rse than the status quo with CNAME.

3) Proxies should no= t use SVCB/HTTPSSVC.. section "Clients using a Proxy" should say = that explicitly. (To make useful for a proxy to use SVCB/HTTPSSVC records, = there should be a way to communicate back to the client about that SVCB/HTT= PSSVC parameters. This does not exist at the moment and will add a delay in= some cases, etc.)

I agree = that transport proxies cannot issue SVCB or HTTPSSVC queries,=C2=A0because = they do not know what protocol/scheme is running over the transport.=C2=A0 = Tracked at=C2=A0https://github.com/MikeBishop/dns-alt-svc/issues/147.
<= br>
4) If no-default-alpn is present the alpn parameter must be present a= s well, otherwise the "ALPN set" is empty?

Correct.

5) A clarification question= : In the section "ipv4hint and ipv6hint":
An empty list of addresses is invalid.
Empty hints will not mean that the record is malformed, i.= e. it is not a fatal error that will make the whole record invalid?

An RR with an empty IP hint is mal= formed, in presentation format or wire format.

6) Nit:
As discussed in {{= client-behavior}}, clients MUST be able fetch additional information that is required to use

s= /MUST be able fetch/MUST be able to fetch
=
Thanks.=C2=A0 Fixed!
=C2=A0

dragana
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic <dragana.damjano@gmail.com>= ; wrote:
I have some minor comments and clarification questions.
<= /div>

1) in "Example: Protocol enhancements": =
and the ke= y=3Dvalue pairs indicate that it supports QUIC in addition to HTTPS over TLS
=C2=A0
Shoul= d=C2=A0 "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is = also HTTPS over TLS


2) Clarific= ation question: Can=C2=A0 SvcDomainName point to another AliasForm record? = As I understand it, it cannot. It can point to a CNAME that points to an Al= iasForm record.
The descriptions of the server and client be= havior sections do not mention this. Should they mention this again?
I am just wondering if the description in "Client behavior&quo= t; and "DNS Server Behavior" should be more precise and mention t= his constraint and also the limit for a chains of CNAME and SVCB of 8?


3) Proxies should not use SVCB/HTTPSSVC= .. section "Clients using a Proxy" should say that explicitly. (T= o make useful for a proxy to use SVCB/HTTPSSVC records, there should be a w= ay to communicate back to the client about that SVCB/HTTPSSVC parameters. T= his does not exist at the moment and will add a delay in some cases, etc.)<= br>

4) If no-default-alpn is present the alpn parameter must = be present as well, otherwise the "ALPN set" is empty?
=
5) A clarification question: In the section "ipv4hint a= nd ipv6hint":
An = empty list of addresses is invalid.
Empty hints will= not mean that the record is malformed, i.e. it is not a fatal error that w= ill make the whole record invalid?

6) Nit:
As discussed in {{= client-behavior}}, clients MUST be able fetch additional information that is required to use

s= /MUST be able fetch/MUST be able to fetch

drag= ana
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000024b51105a504db54-- --0000000000002f004605a504db52 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCf/5OfHdU41AckJ0sYFIB8Sfkqc57FcywqIajEicdvOzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MDcwMTMyMzlaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAYscsClr5XZ3bgUIToQBJvoIAK633owfYk94I1BskLp2nvp3oQCHn+/B9KQhpJlJUjjCPZB1k LNAvCQvPtMEqcgwcK9xSlFVk5V4YHi1irvsF/GOAEyxzzyXUWnxxlZPuCGav0vBe6J0LilcCqvWD uxI4P9isEl5GHCB8o+NxN5jUHcBI2GiXBleaZTCPrdUOwn5+1vg2ezBYDI3A66/Uil4KIUweuRWc 25pYH7kBOjSGLIGWiYcWe2cq+TIgXkgywl/H0ODo9CIN+iSk5Ekk4ih1og0Pwc4NHUIyr39HY23M kG7Zm9Ghx01LUiQ0pQyMgkgMftU2UJzWyL1/kfwaDw== --0000000000002f004605a504db52-- From nobody Wed May 6 21:06:51 2020 Return-Path: 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 45D453A0823 for ; Wed, 6 May 2020 21:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 qnqM_y1nWnmU for ; Wed, 6 May 2020 21:06:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5539F3A0821 for ; Wed, 6 May 2020 21:06:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49HfzS0Q1Hzp9; Thu, 7 May 2020 06:06:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588824404; bh=bIwmqfrM2MycXBityfMzazbd5FOUm9YedH3nj3gu6qQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q4JMheI28G6hI3LdKUJFGMEmjNYbazUD3+GmFkKHbdb1S+rxZ48kQew9ClZtRyt9u xlIFLFHC4sEM/q6DIHPeC5duB3K2Jt31tCYqL3mkpg35OJ+S1RX0EcmJIDxCP83dxM RvtXydeIsSRCf4mHp8ktQaZyE1LFK4YPDLDyhQKE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id QcJ8b57QvoCO; Thu, 7 May 2020 06:06:42 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 May 2020 06:06:42 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9BD7F6020D9F; Thu, 7 May 2020 00:06:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 988F866B7C; Thu, 7 May 2020 00:06:41 -0400 (EDT) Date: Thu, 7 May 2020 00:06:41 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-2?Q?Vladim=EDr_=C8un=E1t?= cc: dnsop@ietf.org In-Reply-To: <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz> Message-ID: References: <158828214716.7748.7938281376930754647@ietfa.amsl.com> <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 04:06:50 -0000 On Tue, 5 May 2020, Vladimír Čunát wrote: > 1. Validation without logging. > At the end of 3.1 you claim that mode is still useful.  When I focus on > intentional attacks, signing a malicious DS seems among the easiest > ones, and that can't be detected without the attacked machine doing > logging (the DS might be served to specific targets only). Serving to specific targets is getting harder and harder, because we see more and more people defaulting to not use their DHCP obtained DNS server. And when picking another non-local server, DoH or DoT is preventing man in the middles from replacing DS records in responses. So they would either have to publicly replace the DS for everyone, or add a DS for everyone. That becomes a very visible event. >  Consequently > I'm doubtful about implementing and deploying such a "half-secure" > approach in validators, especially as the RFC draft feels very hazy > about the way logging might be done. This draft is not trying to specify the DNSSEC logging. But I described things in earlier messages already. The way we had our experimental logging done with Linus Nordberg, is that we used dnssec-chains (RFC 7901) as the record format for the DNS data, wrapped in the regular append-only style transparency log using merckle trees. > 2. Amount of logging. > The draft implies it would allow to very significantly decrease the > amount of data that needs to be logged.  Zones without the bit perhaps > won't be logged, but I hope that wasn't a significant point. Right. Anything without DNSSEC cannot be helped. >  The draft > doesn't explicitly say what would be logged; my conclusion for zones > using this bit is that "we" would need basically any authoritative (i.e. > signed) data except for NSEC* records that have DS bit and miss opt-out > bit.  Am I missing something? You would need to log the DS, and possibly log the denial of existence of the DS record. If the delegation-only bit it set, you can further log anything that should not have been signed but was signed, so any records outside of the apex that are signed. But this data is already dropped by supporting validators as BOGUS, so those hooks could be used for logging it. It should not be common. As soon as you see any of this, the zone is basically malicious and a public inquery should be started. As for opt-out, again zones without DNSSEC cannot be helped. Zones with DNSSEC, you log the DS and the denial of existence of DS. When to log this is a bit similar to the CT gossip protocol that was proposed. You log things when you see a modification (no-DS to DS or visa versa, or old-DS to new-DS). But that is outside the scope of this draft. >  As for large TLD zones, even in best > currently practical case the reduction seems by less than a half?  You are missing the point that currently resolvers cannot determine if a TLD is delegation-only. For example, if you assume all TLDs are delegation-only, you break things, such as .de where registrations can be done without NS record, straight signed by the .de key. The point of the DNSKEY DELEGATION_ONLY flag is to indicate that yes this zone does not do this and THUS you can log these things when you see them. > (missing DS bits in about half delegations) I expect that the whole > trust chains to the logged records are also needed, so that the logger > can prove they haven't forged the records. Yes, you log an RFC 7901 chain from the root to the record in question you want to see logged. Not only to prevent the logger from lying, but also to proof you have the top-most offender in the chain. Paul From nobody Thu May 7 05:34:39 2020 Return-Path: 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 BB9A93A02BC; Thu, 7 May 2020 05:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 t5ZnYeEIbf-k; Thu, 7 May 2020 05:34:35 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 ADDEC3A02BB; Thu, 7 May 2020 05:34:34 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id p16so5187536edm.10; Thu, 07 May 2020 05:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QFvWaiYT9J0vN8yek7Up350SBQZycFqNc5m5ZhkStJ8=; b=YszZK1V5liGXLFiycIzEcAyksqvHzYGm5SI2K4FqIDFir9bIbQ36fGGbMV94uMJu6E sk1lxyXjcICKfaQ4MQ4Z/oQj5F3aorjNFYGkLtdybHCBEa78ssCc7YkS3BRJiSghZypW a634M/OA3Yt56yTwc2v6mM00AmfHnYUYlq1U6jjGzCtTksVs7PVb2f3Z4IU/ydCHRNWx afgPp5b0+wcH/8jbvM+w88ZiYCnv13NNo3B2SOsxrHz7ibE1pFiHSi47V6+O3VUA2ZRv yU3ta5lbQ7QFzgMTVlrw8jKEt/O69KXhjggjA+Bvi8jpXhgrWspB+AM7xfj2xY6gZbK5 PmBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QFvWaiYT9J0vN8yek7Up350SBQZycFqNc5m5ZhkStJ8=; b=OpdCsyWRVe5Di1wRwo61X8Zte2cbM9qbvcqjuBwFd5Lt9epHGsuo0ObLP1eT1/PAXq GqgYDLtOzH5vAqzPk1qRk6tkkBEIWeq45153ksbOUxR8vyGad5qcejHciX6pmzIe1aUg Cb7GogKkLRhb+VxIh/27uHHvjuqyJpFIFfF4c/A1k6cmUh5wOJZ5lt8YmGhvyRTDufQ4 boUk37S+sI3GADInnxdayOqH8E0rj9+Yz8J9qJ6T/VRyJROnXQPbIZhbFJWIUp7R1UFU sTym6l5a6nd2MFTmlMq+NIH3xGIolrOjw8APC9jgGpxG1BZ+f/b5CEy/KES4rxqLAV1J r8nA== X-Gm-Message-State: AGi0PuaZ/HR1vcWylcR3CyzPcYItrWizRiek/eZS7zOEyf7vXWclhmgI pWvt4hZbkJjmQuxiSYszTmGaBZx0J2MVi0szhSo= X-Google-Smtp-Source: APiQypK1s8mBT/T5F8lxf4J2x3PAvXRglc1l1Mn+PDlqW3jTeCdsWEiXJNoNF1Pqfi9/v+/pvJqp8KQv4lIe969ivRs= X-Received: by 2002:aa7:d783:: with SMTP id s3mr11975267edq.64.1588854873203; Thu, 07 May 2020 05:34:33 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: <20200506084836.GA14813@nic.fr> From: Shumon Huque Date: Thu, 7 May 2020 08:34:21 -0400 Message-ID: To: Stephane Bortzmeyer Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="00000000000051258705a50e1a72" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:34:37 -0000 --00000000000051258705a50e1a72 Content-Type: text/plain; charset="UTF-8" On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer wrote: > On Mon, May 04, 2020 at 03:08:20PM -0400, > Tim Wicinski wrote > a message of 64 lines which said: > > > This starts a Call for Adoption for > > draft-mglt-dnsop-dnssec-validator-requirements > > I think it is important to have such a document, because DNSSEC > failures may seriously endanger the deployment of DNSSEC (which is > already too low). The current draft seems a good starting point and I > support its adoption. > I also support adoption and will review/contribute etc. I'm willing to review. Let's start immediately with -09: > > draft-ietf-dnsop-extended-error (recently approved by the IESG) should > be mentioned, since one of the biggest operational problem with DNSSEC > is the difficulty to understand why a resolver returns a SERVFAIL to > you. > Yup. > More often, to date, failed validation is due to operator error and > > not an attempt to forge data. > > It can be a bug in software, too. Specially with complicated things > like NSEC3+optout+ENT+dynupdate :-{ > Yes, unfortunately I concur. My experience recently deploying DNSSEC for a large organization made it clear to me that even recent versions of mature DNS implementations often have a variety of operationally impacting DNSSEC bugs. The draft apparently do not mention advices on expiration slack (such > as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a > consensus on (I quote Unbound documentation) "The signature inception > and expiration dates are allowed to be off by 10% of the signature > lifetime"? > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having a reasonable signature inception offset, but recommends no value. It does not mention a signature expiration skew. It would be good to treat this subject in the document. Personally, I would prefer a fixed value (~ 5 to 10 minutes) rather than a percentage. Otherwise, the validator may be using a possibly unacceptably small or large skew values depending on the validity interval. > However, a DNSSEC validator is not able to determine other than by > > trying whether a signature scheme is supported by the authoritative > > server. > > This one is unclear. First, the signer is not always an authoritative > server, signature can be done offline. Second, querying the DNSKEY is > enough, no? (Or querying the signatures, but I assume a zone won't > publish a DNSKEY without being able to sign with this algorithm.) > As the spec is currently written, yes, the DNSKEY RRset will give this information. Shumon --00000000000051258705a50e1a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 6, 2020 at 4:49 AM Stephane B= ortzmeyer <bortzmeyer@nic.fr>= ; wrote:
On Mon, May 04, 2020 at 03:08:20PM -0400,
=C2=A0Tim Wicinski <tjw.ietf@gmail.com> wrote
=C2=A0a message of 64 lines which said:

> This starts a Call for Adoption for
> draft-mglt-dnsop-dnssec-validator-requirements

I think it is important to have such a document, because DNSSEC
failures may seriously endanger the deployment of DNSSEC (which is
already too low). The current draft seems a good starting point and I
support its adoption.

I also support ad= option and will review/contribute etc.

I'm willing to review. Let's start immediately with -09:

draft-ietf-dnsop-extended-error (recently approved by the IESG) should
be mentioned, since one of the biggest operational problem with DNSSEC
is the difficulty to understand why a resolver returns a SERVFAIL to
you.

Yup.

> More often, to date, failed validation is due to operator error and > not an attempt to forge data.

It can be a bug in software, too. Specially with complicated things
like NSEC3+optout+ENT+dynupdate :-{

Yes= , unfortunately I concur. My experience recently deploying DNSSEC
for a large organization made it clear to me that even recent versions of= =C2=A0
mature DNS implementations often have a variety of operati= onally
impacting DNSSEC bugs.

The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception<= br> and expiration dates are allowed to be off by 10% of the signature
lifetime"?

RFC 6781 Section 4.4.2 = (Signature Validity Periods) does mention having
a reasonable sig= nature inception offset, but recommends no value. It does
not men= tion a signature expiration skew. It would be good to treat this
= subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may= be using
a possibly unacceptably small or large skew values depe= nding on the validity
interval.

> However, a DNSSEC validator is not able to determine other than by
> trying whether a signature scheme is supported by the authoritative > server.

This one is unclear. First, the signer is not always an authoritative
server, signature can be done offline. Second, querying the DNSKEY is
enough, no? (Or querying the signatures, but I assume a zone won't
publish a DNSKEY without being able to sign with this algorithm.)

As the spec is currently written, yes, the DNSKE= Y RRset will give this
information.

Shum= on

--00000000000051258705a50e1a72-- From nobody Thu May 7 05:50:38 2020 Return-Path: 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 335073A05E2; Thu, 7 May 2020 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 2nBEKouMli6Y; Thu, 7 May 2020 05:50:34 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 843573A053F; Thu, 7 May 2020 05:50:34 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id k22so5262095eds.6; Thu, 07 May 2020 05:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CBhiLZVYwKeV/gc6sh07LG24XpNZq+drUK+zGmqND2k=; b=eDInlgI4sAjoW1EM0/U1C4iZYPMX94/oaD7DWDYIUoRhNuJMSGBCvLD+6j2oxpZrdJ QdTpHE8Jdn0vCh2rXIhALo0vM0nVsNa0Lcf7Bi+cOsGVcwj1IPIwtl3aq2E0P1T2+LXz zAI0GEYhUn1WDTE+Wi6TlHXLdIKJAkv74jAwwmLFAKbDxQCcmxRbAvEC9UeSM3QasMDv zlz8HZ38UdrkHpsGUKDIZ/WMnlndJMFgDNLcta7IWbFiQxQQOZrk86vCKJ0EHVRZOMmR /num/xD2SMeAsWC2FUcnNRaaZUck+6AUHIbZIFyKBONk3Rcv5PxxkHl3/2UAaRM4hBe5 76ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CBhiLZVYwKeV/gc6sh07LG24XpNZq+drUK+zGmqND2k=; b=H3t6Lk6dN4dYQg4AKzQiGWvfiTWqnSfQleijnLQPXopRPOg88t6fjgGmN9Brj5AmaL DP75h96Ud9L1vScaiGrSbNETlumkcdExyF/V0FXkhC3MmyefcLMfh1YtL0tDHMPPQVga kfFJbKEvD+LE+9YuFC146i/zrdFz2gyQw9aHcnEgynFU589PsMcbzw2x5pR77CkkLkfk G0q2eHoUrwhocy3mnyQ8p/d8eaNPk0AnEy+2uJ2n72iKd5W9ysWaLkQejmj6qKyDo4QF HJgVt6IhcAsI+NP1iydvwe2wOpXm7E5g+dEIDwVnnqleLKBDFBLqlFZ/MFrIVc2DrZQ3 vmTg== X-Gm-Message-State: AGi0PuaIKBDT0RvPZfOar56gvjmOYT/BMkA3gxcMpjN/NtxLIIjwMczK tGMyDRh0oAXuXUTnYpS1E6/gLisSoH9bG0VwWZU= X-Google-Smtp-Source: APiQypIsbP9zui0U5dv95yygiEy4MINYYE/8jscAvu0gqPjIZJKPbLBPASHoED/wN46AktAbMSFI7wIDJIEfCYU/A0s= X-Received: by 2002:a05:6402:129a:: with SMTP id w26mr11194354edv.254.1588855832987; Thu, 07 May 2020 05:50:32 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: From: Shumon Huque Date: Thu, 7 May 2020 08:50:21 -0400 Message-ID: To: Stephane Bortzmeyer Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000864b8f05a50e53e3" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:50:36 -0000 --000000000000864b8f05a50e53e3 Content-Type: text/plain; charset="UTF-8" On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer > wrote: > > The draft apparently do not mention advices on expiration slack (such >> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >> consensus on (I quote Unbound documentation) "The signature inception >> and expiration dates are allowed to be off by 10% of the signature >> lifetime"? >> > > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having > a reasonable signature inception offset, but recommends no value. It does > not mention a signature expiration skew. It would be good to treat this > subject in the document. Personally, I would prefer a fixed value (~ 5 to > 10 minutes) rather than a percentage. Otherwise, the validator may be using > a possibly unacceptably small or large skew values depending on the > validity > interval. > Just to quickly follow-up on my own post (sorry!), I realize this draft is only about validator requirements, but RFC6781 describers signer recommendations. Still, the skew issue has come up for me recently in signer implementations too. One commercial DNSSEC implementation we were using was generating on-the-fly signatures with _no_ inception offset - which means if the validator's clock was off even slightly, and supported no skew, it would fail. It required some vigorous arguing with this vendor to get them to use an inception offset. So, the skew issue ideally needs to be addressed on both sides (and it might be reasonable to mention that in this draft). Shumon. --000000000000864b8f05a50e53e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 7, 2020 at 8:34 AM Shumon Huq= ue <shuque@gmail.com> wrote:<= br>
On Wed, May 6, 2020 at 4:49 AM= Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
=
The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception<= br> and expiration dates are allowed to be off by 10% of the signature
lifetime"?

RFC 6781 Section 4.4.2 = (Signature Validity Periods) does mention having
a reasonable sig= nature inception offset, but recommends no value. It does
not men= tion a signature expiration skew. It would be good to treat this
= subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may= be using
a possibly unacceptably small or large skew values depe= nding on the validity
interval.

Just to quickly follow-up on my own post (sorry!), I reali= ze this draft is only
about=C2=A0 validator requirements, but RFC= 6781 describers signer recommendations.

Still, the= skew issue has come up for me recently in signer implementations
too. One commercial DNSSEC implementation we were using was generating
on-the-fly signatures with _no_ inception offset - which means if th= e validator's
clock was off even slightly, and supported no s= kew, it would fail. It required
some vigorous arguing with this v= endor to get them to use an inception offset.
So, the skew issue = ideally needs to be addressed on both sides (and it might
be reas= onable to mention that in this draft).

Shumon.

--000000000000864b8f05a50e53e3-- From nobody Thu May 7 06:04:58 2020 Return-Path: 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 18CB13A07AD for ; Thu, 7 May 2020 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 yrPlUx61IATv for ; Thu, 7 May 2020 06:04:53 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 11C873A07CB for ; Thu, 7 May 2020 06:04:44 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id j3so6193506ljg.8 for ; Thu, 07 May 2020 06:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w5cfHe58ZjPZyJ7AGeRx3mqhRl4pEkanDvouGsIWe/I=; b=BPgaK/hmWjYIdj3A8iXlAjUj0d/MaqMN5Ku4+mjRwY12DEYNpfSLUfEWSTXsrclhfq dvjUrbl7wyZr3aJnI3casbQnjKKuH0azE5qpaXQQjbKmUwX9pLwG2LXGW+eQXkGlv2vM aGO2MX7x0wWBfAIGq5RBQdjkiyNjhWv2PFYPPScu/GLd6c+4zr6KmyTQX5S90TvUHLAr brXhO5D+WUn4OLFDSlepILMqiRi2Bvvcr8pbqaoCIBE3pKna7UryrAI3Wwq2EcGUhxLO bfhP/x+tKczQOXMmQ/6qTahACV5CN6rPacb8V/eSM7Dwfh85ct4ZvaCxDSqxz5B+qSOD 8i2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w5cfHe58ZjPZyJ7AGeRx3mqhRl4pEkanDvouGsIWe/I=; b=qp4dMKGIRqRha0F/u/Xlr0XmFjdCm2G4HDZsXmNnUAhNrylYG/vJqvhttLR2+LJ99m soQmZsCrzQUcy68oPzuFL7xawSQGagNznZdrWTPT7gqsKXuTeKDmY6FARNeAKlgN5fnb yuJJr/W0BURcgXHHGVht6wHcE/XzdJgPM8icLaN4myaORpQKPY1WbJ0Rq9pyucTATqDB HDlTNtd1ntTqD39u5A6iHC8+uoB2JRLZBLtXsyaVfPhXWptdUaO1dZ6iWHuX+6/Fz3K9 XJvxoo0QdHkC+oFetnNyKKTqATUEseBKwOjh/rxZsweR+qfyBQ2+8wd+wMd6GzZ9iw8t zjDg== X-Gm-Message-State: AGi0PuaU5YBTLmWWa2Jg+noTNpsO9hLssifmet9OMA96KsLlpqtb+DRn CfSKPTvqzedV/0PPlVc7Ib+UmWkVBwX8B4n9BewsPcwT X-Google-Smtp-Source: APiQypL+KA/hS3iZIg6mZHCrhybJRa5pmVl9AsI379gFJzMuQNMeFfNLMlwZc00XFdEnegb0D/NWfIYt1T4AZbPQo48= X-Received: by 2002:a2e:8512:: with SMTP id j18mr8478320lji.201.1588856681947; Thu, 07 May 2020 06:04:41 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: From: Bob Harold Date: Thu, 7 May 2020 09:04:30 -0400 Message-ID: To: Shumon Huque Cc: Stephane Bortzmeyer , Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000208adc05a50e862f" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 13:04:56 -0000 --000000000000208adc05a50e862f Content-Type: text/plain; charset="UTF-8" On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer > wrote: > >> On Mon, May 04, 2020 at 03:08:20PM -0400, >> Tim Wicinski wrote >> a message of 64 lines which said: >> >> > This starts a Call for Adoption for >> > draft-mglt-dnsop-dnssec-validator-requirements >> >> I think it is important to have such a document, because DNSSEC >> failures may seriously endanger the deployment of DNSSEC (which is >> already too low). The current draft seems a good starting point and I >> support its adoption. >> > > I also support adoption and will review/contribute etc. > > I'm willing to review. Let's start immediately with -09: >> >> draft-ietf-dnsop-extended-error (recently approved by the IESG) should >> be mentioned, since one of the biggest operational problem with DNSSEC >> is the difficulty to understand why a resolver returns a SERVFAIL to >> you. >> > > Yup. > > > More often, to date, failed validation is due to operator error and >> > not an attempt to forge data. >> >> It can be a bug in software, too. Specially with complicated things >> like NSEC3+optout+ENT+dynupdate :-{ >> > > Yes, unfortunately I concur. My experience recently deploying DNSSEC > for a large organization made it clear to me that even recent versions of > mature DNS implementations often have a variety of operationally > impacting DNSSEC bugs. > > The draft apparently do not mention advices on expiration slack (such >> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >> consensus on (I quote Unbound documentation) "The signature inception >> and expiration dates are allowed to be off by 10% of the signature >> lifetime"? >> > > RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having > a reasonable signature inception offset, but recommends no value. It does > not mention a signature expiration skew. It would be good to treat this > subject in the document. Personally, I would prefer a fixed value (~ 5 to > 10 minutes) rather than a percentage. Otherwise, the validator may be using > a possibly unacceptably small or large skew values depending on the > validity > interval. > I agree. The amount a clock is likely to be out of sync is not related to the signature lifetime in any way. A fixed value based on likely clock skew or operational experience would be better. (Just my opinion, not meaning to sound like an authority on the subject.) -- Bob Harold > > > However, a DNSSEC validator is not able to determine other than by >> > trying whether a signature scheme is supported by the authoritative >> > server. >> >> This one is unclear. First, the signer is not always an authoritative >> server, signature can be done offline. Second, querying the DNSKEY is >> enough, no? (Or querying the signatures, but I assume a zone won't >> publish a DNSKEY without being able to sign with this algorithm.) >> > > As the spec is currently written, yes, the DNSKEY RRset will give this > information. > > Shumon > > --000000000000208adc05a50e862f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 7, 2020 at 8:34 = AM Shumon Huque <shuque@gmail.com> wrote:
On Mon, May 04, 2020 at 03:08:20PM -0400= ,
=C2=A0Tim Wicinski <tjw.ietf@gmail.com> wrote
=C2=A0a message of 64 lines which said:

> This starts a Call for Adoption for
> draft-mglt-dnsop-dnssec-validator-requirements

I think it is important to have such a document, because DNSSEC
failures may seriously endanger the deployment of DNSSEC (which is
already too low). The current draft seems a good starting point and I
support its adoption.

I also support ad= option and will review/contribute etc.

I'm willing to review. Let's start immediately with -09:

draft-ietf-dnsop-extended-error (recently approved by the IESG) should
be mentioned, since one of the biggest operational problem with DNSSEC
is the difficulty to understand why a resolver returns a SERVFAIL to
you.

Yup.

> More often, to date, failed validation is due to operator error and > not an attempt to forge data.

It can be a bug in software, too. Specially with complicated things
like NSEC3+optout+ENT+dynupdate :-{

Yes= , unfortunately I concur. My experience recently deploying DNSSEC
for a large organization made it clear to me that even recent versions of= =C2=A0
mature DNS implementations often have a variety of operati= onally
impacting DNSSEC bugs.

The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception<= br> and expiration dates are allowed to be off by 10% of the signature
lifetime"?

RFC 6781 Section 4.4.2 = (Signature Validity Periods) does mention having
a reasonable sig= nature inception offset, but recommends no value. It does
not men= tion a signature expiration skew. It would be good to treat this
= subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may= be using
a possibly unacceptably small or large skew values depe= nding on the validity
interval.

I agree.=C2=A0 The amount a clock is likely to be out of s= ync is not related to the signature lifetime in any way.=C2=A0 A fixed valu= e based on likely clock skew or operational experience would be better.
(Just my opinion, not meaning to sound like an authority on the subj= ect.)

--=C2=A0
Bob Harold

=
=C2=A0

> However, a DNSSEC validator is not able to determine other than by
> trying whether a signature scheme is supported by the authoritative > server.

This one is unclear. First, the signer is not always an authoritative
server, signature can be done offline. Second, querying the DNSKEY is
enough, no? (Or querying the signatures, but I assume a zone won't
publish a DNSKEY without being able to sign with this algorithm.)

As the spec is currently written, yes, the DNSKE= Y RRset will give this
information.

Shum= on

--000000000000208adc05a50e862f-- From nobody Thu May 7 10:55:40 2020 Return-Path: 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 34F103A0814; Thu, 7 May 2020 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=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 towBLl216Mr7; Thu, 7 May 2020 10:55:36 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 1322B3A080B; Thu, 7 May 2020 10:55:35 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id c24so2172527uap.13; Thu, 07 May 2020 10:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nRsRSym2M1FtFFfYpBidbaFscduOFa3XrNjHYeLqRVg=; b=DM9xa02+ZTouvAwH8MwNQp4XHpvHoy1LP+L1j63THSth4h0xWVf/knx2m5BmfqizE+ tjdafWIR3foEVvUPQH+uep+W3oJTWR9fyH2EA/ZSIC1TXtSAuIuapfxNwQDV5AtfMU3J oBt97CZzEecEZcOif3qxC4Ap4QVPk+S5cCyGK2SgD6rWVMEh4uC0/VTKKlJQceKDD6+S tD4GRKMBNdddX/H/I4fCTXphmnqTAhBagPijhi4+5m09ug9imx6lgFVxUD0x+OJtuZ+C ohdn48CWPLjayD6EQRyx+Gh+R9tsLZzlHMHwZuUVXT4eqQTDc313rT2NY2Zp4yGYlUfK 2XBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nRsRSym2M1FtFFfYpBidbaFscduOFa3XrNjHYeLqRVg=; b=SqoonViDY4ZXEB7bSFThf5iudSrAU/861NiMjsDXda1rWnyvK0pV2Lbse57/AHgrpN PxKjJd7/J/EO9w8z+vmHD6jRvzwCdQFLWHGIx+yMnc5QdaaFiTZ3AqBV3NC8GFAbKaV7 Z1QFNftY+PFM2DRL+cU9SxO24qQ08rMUdb/KVFez7l79S2iaNKE+KLwuZ63rRQXfb9/y p3brEYWNFMgwuKw174ask28NwACoEpUeX9lzKU/qnRoYSvoFDdiVJEAspwLZi5/nbypa IGVKVRaVI3UC8yzW7CsXCG7EI6Pm7rryLNBLhDSCZG9219rmputEFh9Fkv8Aafsw8o9x +3oA== X-Gm-Message-State: AGi0Pub0pa/Oeq3eNySag4/FyMWuGNxZbCBw3Cn7XU4mEF/r7oZ7wnPd nTsmeQIkaBGJqTHHqLNCfVZBs+OGRAUoOh28h0I= X-Google-Smtp-Source: APiQypK5Tbe7lfyVkS1acBcS2b44qxdCTPDlSZt8iYfK2unTPXyLl22fW4cOEpru0v+ufEHyOZi6XjQyH/b3dMwhCec= X-Received: by 2002:ab0:5586:: with SMTP id v6mr12436234uaa.87.1588874134959; Thu, 07 May 2020 10:55:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Thu, 7 May 2020 10:55:23 -0700 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000683bbd05a5129693" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:55:38 -0000 --000000000000683bbd05a5129693 Content-Type: text/plain; charset="UTF-8" On Mon, May 4, 2020 at 12:10 PM Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > I support adoption of this draft by DNSOP. I am willing to review. Brian > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 18 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000683bbd05a5129693 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 4, 2020 at 12:10 PM Tim W= icinski <tjw.ietf@gmail.com>= ; wrote:


All,

As we st= ated in the meeting and in our chairs actions, we're going to run
re= gular call for adoptions over next few months. =C2=A0
We are looking for= *explicit* support for adoption.


This starts a Call for Adoptio= n for draft-mglt-dnsop-dnssec-validator-requirements

The draft is av= ailable here: https://datatracker.ietf= .org/doc/draft-mglt-dnsop-dnssec-validator-requirements/


Ple= ase review this draft to see if you think it is suitable for adoption
by= DNSOP, and comments to the list, clearly stating your view.

I support adoption of this draft by DNSOP= . I am willing to review.

Brian

=C2=A0
Please also indicate if you= are willing to contribute text, review, etc.

This call for adoption= ends: 18 May 2020

Thanks,
tim wicinski
DNSOP co-chair

=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000683bbd05a5129693-- From nobody Thu May 7 11:00:30 2020 Return-Path: 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 5D3603A0949; Thu, 7 May 2020 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 c-r_0h2ceQeL; Thu, 7 May 2020 11:00:24 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 072673A0941; Thu, 7 May 2020 11:00:24 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id m24so3923457vsq.10; Thu, 07 May 2020 11:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Ydd+3eRgxFE9gk/IXR7tYrRNpZ0VJ9clUnn1CkA1ZM=; b=HSx2zIFVjQuQfh2JIpWTrREx0fJDOdv6LJRV8hcp18eH7kc+cxyj4UZ3e/uDX7EIhl ytnZoAiM+8nlcWN84eYUaMvOdg6PLN8GpVjDHLp+++Q3XsqGQCzQxeBNGyI/IiTeKcYC SSzvRCq0JZ5jqwKWrmTveAPhmbXFAKRHC6AjC2THWq9qiZYe8/Vz09TXIITuYGb0B2/e U0KIli0XWwe9s7IBZ33f30dYny9PMQEqPFXcHD2V8/XMbWSbm8xwUd7r7HNb+HGIpivM O/x14aNcwscfqmCifz80Q005jKZtuOG+e2/tmEQXOshGoKABLI/S3UMUNwB49yCME/wZ jC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Ydd+3eRgxFE9gk/IXR7tYrRNpZ0VJ9clUnn1CkA1ZM=; b=qg0K877shWbBmVCGvoZknXnnlBiAm3KbDWTfsMLx2YshPlD4rRNLOl3X8Lz8wLs/Bv g1Dq61YNP/wa8pDy351QXY+R66jIC93eyElvUSEkJ4qP09o3K7XOSWrognxhC24Y4MXD 1UOYzfZYY/AUTc7QknjvfuPh7o8ixTYk0MV3M9k92r5S+9AbzFND40cD1FqrV25IHEaW RSXWWcQlrg7znRP+zTulwDyLCvibVEQYCRBe2yqffcFTCZDpNa43A/87NcremXYz8efb Ge4UdGTDN8yz3rhVWCs6o5icpsc7B6gdf5xaYsYMotIzzWZnLTtqk8uIjmCx3CkofU5o ypiQ== X-Gm-Message-State: AGi0PubTaZY85HlL3oVv2u1KoHMqx3l8BszKAfqADXRCSb8m0SobSm++ V3n4B7bhbLbaOW7xmICC+ipUp1v8hgiHzSDT8dw= X-Google-Smtp-Source: APiQypIvGJx89fEiZmVuK6qDAcuHIbeXASJ0rrb5d5cI4smxS1dUN9q/I6KQ3ChfH8PtimJLo/DnH4th+eoibvhPwy8= X-Received: by 2002:a67:fc46:: with SMTP id p6mr14583740vsq.169.1588874423044; Thu, 07 May 2020 11:00:23 -0700 (PDT) MIME-Version: 1.0 References: <20200506084836.GA14813@nic.fr> In-Reply-To: From: Daniel Migault Date: Thu, 7 May 2020 14:00:11 -0400 Message-ID: To: Shumon Huque Cc: Stephane Bortzmeyer , Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000940f4405a512a7ee" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:00:28 -0000 --000000000000940f4405a512a7ee Content-Type: text/plain; charset="UTF-8" Thanks for the feed back Shumon, I agree that we should at least clarify where the responsibilities are so the mechanisms become more focused on smoothing the edges rather that compensating what the other party may not do. I also agree that fixed values might be more appropriated and the RDO should ensure time derivation will go beyond these values. Yours, Daniel On Thu, May 7, 2020 at 8:50 AM Shumon Huque wrote: > On Thu, May 7, 2020 at 8:34 AM Shumon Huque wrote: > >> On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer >> wrote: >> >> The draft apparently do not mention advices on expiration slack (such >>> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a >>> consensus on (I quote Unbound documentation) "The signature inception >>> and expiration dates are allowed to be off by 10% of the signature >>> lifetime"? >>> >> >> RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having >> a reasonable signature inception offset, but recommends no value. It does >> not mention a signature expiration skew. It would be good to treat this >> subject in the document. Personally, I would prefer a fixed value (~ 5 to >> 10 minutes) rather than a percentage. Otherwise, the validator may be >> using >> a possibly unacceptably small or large skew values depending on the >> validity >> interval. >> > > Just to quickly follow-up on my own post (sorry!), I realize this draft is > only > about validator requirements, but RFC6781 describers signer > recommendations. > > Still, the skew issue has come up for me recently in signer implementations > too. One commercial DNSSEC implementation we were using was generating > on-the-fly signatures with _no_ inception offset - which means if the > validator's > clock was off even slightly, and supported no skew, it would fail. It > required > some vigorous arguing with this vendor to get them to use an inception > offset. > So, the skew issue ideally needs to be addressed on both sides (and it > might > be reasonable to mention that in this draft). > > Shumon. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --000000000000940f4405a512a7ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feed back Shumon,=C2=A0

I agree that we should=C2=A0at least clarify where the re= sponsibilities are so the mechanisms become more focused on smoothing the e= dges rather that compensating what the other party may not do.=C2=A0
I = also agree that fixed values might be more appropriated and the RDO should = ensure time derivation will go beyond these values.=C2=A0

Yours,=C2=A0
Daniel

On Thu, May 7, 2020 at 8:50 AM Shumon Huqu= e <shuque@gmail.com> wrote:
=
On Thu, May 7, 2020 at 8:34 AM Shumon Huque <shuque@gmail.com> wrote:=
On Wed, May 6, 2020 at 4:49 A= M Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception<= br> and expiration dates are allowed to be off by 10% of the signature
lifetime"?

RFC 6781 Section 4.4.2 = (Signature Validity Periods) does mention having
a reasonable sig= nature inception offset, but recommends no value. It does
not men= tion a signature expiration skew. It would be good to treat this
= subject in the document. Personally, I would prefer a fixed value (~ 5 to
10 minutes) rather than a percentage. Otherwise, the validator may= be using
a possibly unacceptably small or large skew values depe= nding on the validity
interval.

Just to quickly follow-up on my own post (sorry!), I reali= ze this draft is only
about=C2=A0 validator requirements, but RFC= 6781 describers signer recommendations.

Still, the= skew issue has come up for me recently in signer implementations
too. One commercial DNSSEC implementation we were using was generating
on-the-fly signatures with _no_ inception offset - which means if th= e validator's
clock was off even slightly, and supported no s= kew, it would fail. It required
some vigorous arguing with this v= endor to get them to use an inception offset.
So, the skew issue = ideally needs to be addressed on both sides (and it might
be reas= onable to mention that in this draft).

Shumon.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--000000000000940f4405a512a7ee-- From nobody Thu May 7 11:17:04 2020 Return-Path: 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 98B503A0C31 for ; Thu, 7 May 2020 11:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 yj7yzuRAILB3 for ; Thu, 7 May 2020 11:16:56 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 52DB83A0C19 for ; Thu, 7 May 2020 11:16:56 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id r3so53745qvm.1 for ; Thu, 07 May 2020 11:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fOuB6bU6y09lCI0tB/7TKtj8HAPTS95v2x0V2uicXXs=; b=BPw5BqDyMxkr8lbGDbCgIXRicd3mP6QP+4i/bw/Y8C/xFV9mQpJIvbYfv3X6lAKJGE h7YJiSQlKOIgxQNNO3959p3aCSk/y3mJEa2iNlDHeEu9SVqjmuF8ntNId/JGIBpk89Ak lmO1CfwSP0nZpH3+5Sl6+Cp7OeQbxCBTxjFsA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fOuB6bU6y09lCI0tB/7TKtj8HAPTS95v2x0V2uicXXs=; b=lL7A0SzPBz+TBQ58IDBaqVqnurwHQrWbv9lKvktyIBb2vj0DtVYO6bg1C9hWdss78b vlx7G7fMI0hHNNfx0sdkLyOUKmKzDJZG4XW+BCoTDfMgrXCYfpu33XVMQFlhaepjyIX+ iKufPip9TUnj+QXDFxrbV1XYcHK7b5/VYb90qHDvdCNyH+EVJ59U2/C9spjpVQjxpuP3 YonyjuyzVfKYSjuydtfrys4yzxkyppiu5JOo4CHb+TSqUGzgK4xg80v5ZNy50TLP3RPg 55xO6GWpx6pXe/Z+uPNDv/bvwNF/0qYGodsFvPMkCsRmviuRgi84Xr0BpYvxCKxUozbG 6sGQ== X-Gm-Message-State: AGi0PuYxb5w93Uolu9g5Y1MZCv9YEpliLURZRAPD+5WIX0YreJeKeHgJ PguSxFc+7qSGUDK5aKTeOyEiuKlMNZJpI2Sf X-Google-Smtp-Source: APiQypKqQvOqiUIYk6yNgI7zpibYqFAjofJ6pZtlR8A8PbujTZM07wvo5VY1jLnzSK8jo2liDGEtsw== X-Received: by 2002:a0c:ed26:: with SMTP id u6mr14627715qvq.220.1588875414884; Thu, 07 May 2020 11:16:54 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:8c7c:d5c2:9fae:917b? ([2607:f2c0:e784:c7:8c7c:d5c2:9fae:917b]) by smtp.gmail.com with ESMTPSA id n13sm5012132qtf.15.2020.05.07.11.16.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 11:16:52 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A3B49332-C184-4049-A415-B2073250B8A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 7 May 2020 14:16:49 -0400 In-Reply-To: Cc: dnsop , dnsop-chairs To: Tim Wicinski References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:17:01 -0000 --Apple-Mail=_A3B49332-C184-4049-A415-B2073250B8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 4 May 2020, at 15:08, Tim Wicinski wrote: > This starts a Call for Adoption for = draft-mglt-dnsop-dnssec-validator-requirements >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-require= ments/ >=20 >=20 > Please review this draft to see if you think it is suitable for = adoption > by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. I have not looked at this draft far beyond the table of contents, but it = strikes me that this is very similar to an earlier draft that I recall = failing to persuade the working group to adopt: https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 If there is new-found enthusiasm for documenting these kinds of things = then I am overjoyed. Perhaps there is an opportunity to merge that = existing work from 2011 with this effort. Joe --Apple-Mail=_A3B49332-C184-4049-A415-B2073250B8A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXrRQkQAKCRA0jwy9hlI6 LDMqAKCsTbxikoDmhPsvlSKh36wnxcmDiwCgxMip3KLtTszLavL9WVpW/p9JCMg= =lRhQ -----END PGP SIGNATURE----- --Apple-Mail=_A3B49332-C184-4049-A415-B2073250B8A7-- From nobody Thu May 7 11:40:49 2020 Return-Path: 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 AB7173A087E for ; Thu, 7 May 2020 11:40:47 -0700 (PDT) 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=uniregistry.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 I5HWtDwQNOkm for ; Thu, 7 May 2020 11:40:46 -0700 (PDT) Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (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 8669E3A0877 for ; Thu, 7 May 2020 11:40:45 -0700 (PDT) Abuse: Forward to abuse@uniregistry.com with full headers X-Virus-Scanned: Content filter at a-mx.uniregistry.com Powered-By: https://www.uniregistry.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1588876844; bh=i7JuztzkDEGQDXhRCGgammlTtGWnpxBV3A51J3r3jOQ=; h=Subject:To:References:From:Date:In-Reply-To; b=ICG+4FsS+KkDIZ+IUpNTze5qw9WOCn22KwI/mWuPGuRhkoSKyzcBDrh8Y0QuaiKJL EIo3h1Giterz3NfK3p9hPib+46aF+ffZYiw0g6RkdDJ7O4vkJVfJtrKPokFzArOloi gjj58B0WXjF3YzmlIkPO708qoXhX1b6CD7ld9mWek0peib+lfxnJ17X3DVRs5jmNca jGEuvRYRJf2NiHI7Lp0SmoGopVhNRc5AEcxjpA6xJUz7VDCq+nw7mYxbvtzPauDuAC MxJjX7+Jk8N8ghMAbZTThePPPlcbSMDds7oh0n1pCsuqCWv62AUdO37gdWFceCfV1u y/7+1ZkknD/IA== Received: from EPPguy.local (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 047IehxP037971 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 7 May 2020 18:40:44 GMT To: dnsop@ietf.org References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> From: Patrick Mevzek Organization: Uniregistry Message-ID: <7df431dd-1f07-3817-dd40-27985a3d03fc@uniregistry.com> Date: Thu, 7 May 2020 13:40:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:40:48 -0000 On 02/05/2020 09:09, Roy Arends wrote: > Hi, > > Ed and I just submitted a new version of our private-use TLD draft. > > https://www.ietf.org/id/draft-arends-private-use-tld-01.txt While I do not have hard facts but just a gut feeling, I would feel safer if "xn" is excluded from the possible list of private labels to be used in the DNS, as it is used for prefix of IDNs. Some, probably buggy, software could match on "xn" instead of "xn--" as prefix to search for IDNs, and hence having "example.xn" could lead to problems. > This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace. > > It contains plenty of examples of how user-assigned code elements are used in the field, including other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself. > > This new version came about after fruitful discussions with peers inside and outside the IETF. Most discussions were productive. This has lead to the removal of the advice/example to use ZZ, as it was distracting from the point of the draft: these two-letter top level domains are available for private-use. Thanks for the new draft version, the new content is useful indeed. -- Patrick Mevzek From nobody Thu May 7 12:39:24 2020 Return-Path: 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 7A6933A0CB1; Thu, 7 May 2020 12:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 yHO_2AIfeEJH; Thu, 7 May 2020 12:39:20 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 9A2A53A0CAF; Thu, 7 May 2020 12:39:20 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id h30so4138993vsr.5; Thu, 07 May 2020 12:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/9EulrBSBUgW0eWpmNIRkrWGsOdF7rz1/ivaCeZt4II=; b=SnL52wtIbHarLJiWngnR+o9LzeVkMkl7F/nzaikv7rBfLeT+9PZmplxb1CejGXo+T5 +HRPwLWzqa+fH0gfEKk4992GpHX2cvUGMMWHM0jYGE7dRQl4K5d6YTXbj4N1jU/sm11F MrRw6xqXNGDOaDQ/N7BEtF+nLk8HgOHMtxVJkUk7XdIjeuODRP1zNP4jjBRg+lGI54ai HMT7jKy4wHXo2t28foXtg3NaLqWVCRouPVVYXvn7+nmIly6V6mCQzoBP6B6Mzb42jPST W1Q/KwyJpnjrK1LyHHGbg2nosMH2qX4WPIGCjoMtva329P/KY3LjhUthXFwObbCZ+qOe 1zuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/9EulrBSBUgW0eWpmNIRkrWGsOdF7rz1/ivaCeZt4II=; b=LEOMScLf8VoVI9eIqWNI3OGuujdWtBSejS8gZoDmWMNQWyZE3A6Cqw0xO6IYRZRe1W BhXHBezMtDlnxHncjbKTeRbCOfn6egL9WgeftxPBUTmdLO5MxCpgBzdnBIbsY5I0AFPh T7tWLWFJB8vLKAIS1mdRMMRNLtclSMvxQKKCdSJclZ63Pg8Pf7pggnUwpuB+b8/iPUAN FKDCtJ4dLTfBt3BVnq0Vf5JXShz51woDSdgoroS+gx4GQq9y4ZPq9ipbsEyRnWX1eUJF QWiZAVDX3/hzw6PZqO9rHZEsbc7ojo/5e4eS6cCTe9kKIx4+7v40MQspEF4OiN+hIoU5 Ws4g== X-Gm-Message-State: AGi0PuYmZNheGODoYZUkV7LuETLG09Ai6SU1bbwUvPdt4mVDJdCO/NRY ofgUfcE6nfmR4PYMEnDI2YQKt2AR67sh5irsvu4= X-Google-Smtp-Source: APiQypKXdzNHfQyuiD2QtHNheVEpNBQLbhOTE50Jn+LVZ51Ddni++64A8yJ+FJq5/0WiULRpmq1n8NqnyqISHXWFkko= X-Received: by 2002:a05:6102:3117:: with SMTP id e23mr13132409vsh.97.1588880359585; Thu, 07 May 2020 12:39:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Thu, 7 May 2020 15:39:08 -0400 Message-ID: To: Joe Abley Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000006c7ed305a514097c" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 19:39:23 -0000 --0000000000006c7ed305a514097c Content-Type: text/plain; charset="UTF-8" Hi Joe, Thanks for putting the reference of that draft. I have always thought that the draft you were mentioning was the one that became RFC7958. The current draft mentions that TA should be associated with bootstrapping mechanism and that boostrapping for the root zone should be extended to other TA. There are clearly some overlap between the two drafts and I also have the impression the drafts can be merged. the following issue has been opened: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 Yours, Daniel On Thu, May 7, 2020 at 2:17 PM Joe Abley wrote: > On 4 May 2020, at 15:08, Tim Wicinski wrote: > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > > > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > I have not looked at this draft far beyond the table of contents, but it > strikes me that this is very similar to an earlier draft that I recall > failing to persuade the working group to adopt: > > https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 > > If there is new-found enthusiasm for documenting these kinds of things > then I am overjoyed. Perhaps there is an opportunity to merge that existing > work from 2011 with this effort. > > > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --0000000000006c7ed305a514097c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,=C2=A0

Thanks for putting the re= ference of that draft. I have always thought that the draft you were mentio= ning=C2=A0was the one that became=C2=A0= RFC7958. The current draft mentions that TA should be associated with boots= trapping=C2=A0mechanism and that boostrapping=C2=A0for the root zone should= be extended to other TA.=C2=A0

There a= re clearly some overlap between the two drafts and I also have the impressi= on the drafts can be merged.=C2=A0=C2=A0
the following issue has been opened:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-re= quirements/issues/7<= br>

Yours,=C2=A0
Daniel

<= span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemF= ont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji= ","Segoe UI Emoji";font-size:16px">=C2=A0=C2=A0
=

= On Thu, May 7, 2020 at 2:17 PM Joe Abley <jabley@hopcount.ca> wrote:
On 4 May 2020, at 15:08, Tim Wicinski <tjw.ietf@gmail.com>= wrote:

> This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-= requirements
>
> The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-vali= dator-requirements/
>
>
> Please review this draft to see if you think it is suitable for adopti= on
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.

I have not looked at this draft far beyond the table of contents, but it st= rikes me that this is very similar to an earlier draft that I recall failin= g to persuade the working group to adopt:

https://tools.ietf.org/html/dra= ft-jabley-dnsop-validator-bootstrap-00

If there is new-found enthusiasm for documenting these kinds of things then= I am overjoyed. Perhaps there is an opportunity to merge that existing wor= k from 2011 with this effort.


Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--0000000000006c7ed305a514097c-- From nobody Thu May 7 12:42:55 2020 Return-Path: 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 D7B313A0CBB for ; Thu, 7 May 2020 12:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 k12-4EZ9bW0j for ; Thu, 7 May 2020 12:42:49 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 CF6133A0CD3 for ; Thu, 7 May 2020 12:42:48 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id a15so1330972qvt.9 for ; Thu, 07 May 2020 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=STijTRPmmzk7R/amtwQNVCJbIw3RaL14Y6HYoGS8puo=; b=QowLlcwFQy3OrDW6PS7YMH9n+JD5HRBpTLecVpLLh0Wo427AyciKV/3YUmJv6SFkYa 6/jwrlscS4Ylmle4tfCC6MwsvfSG5wmUC4dBNqslmDEfWoGHF796v8ZL8FsJwrsVws1K mUq/Vpafif51ZuDW30F5pNZ64pLL4H4hpkCCE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=STijTRPmmzk7R/amtwQNVCJbIw3RaL14Y6HYoGS8puo=; b=P23XbnpIl4SkyNe5P0rCrjzgRiAQiIGzJw1usn7HRTB443FZ/NM51Wx+82e+v5O2xp HbFyB90Scp4mRcNoIcnRBTzgNwZ00UXYZ1QMKnPfHx06WYc/8ZcMus2sT3kGICxPQBSl TYpiFESWNaJE1XuFfIR3P44z1uSYpMHfTifJe9MOnvxXg2mwIcw3Xvo84W350nCa+Mde j+nINzRhrSJbvq8LZq9uI01ZrVm7Ph/kTAfUcx+S7tqy4cvJ9kd5QLfIi4ZdO+w5HlVt 1EDfECDtxg9wOazyoMgFgKTq3+d2mvGjpHiUKJI6ZkgO61YFZWEhhaT0Lbr4/7MAsBQC 7sjA== X-Gm-Message-State: AGi0PuZjzEIYYgJNW5y+zL0JPa44EHzc3uHLoG0IQB5lTvoy0ETDiKbX VTcN1bLFujNzQgYyj5zAZu6yUQ== X-Google-Smtp-Source: APiQypLESKkhG5cA8kqY5xaNEQGLpX98RyYAoYtmRNrFeGYeiGtU5pKCO9VT8y0aBtf21jxs+pvUmw== X-Received: by 2002:a0c:ef50:: with SMTP id t16mr1777575qvs.16.1588880567415; Thu, 07 May 2020 12:42:47 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:8c7c:d5c2:9fae:917b? ([2607:f2c0:e784:c7:8c7c:d5c2:9fae:917b]) by smtp.gmail.com with ESMTPSA id b42sm5378425qta.29.2020.05.07.12.42.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 12:42:46 -0700 (PDT) From: Joe Abley Message-Id: <42A20E19-C43C-4093-8483-07B0A85386E3@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_0436A343-9403-40B2-A528-BB9F9BA72736"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 7 May 2020 15:42:44 -0400 In-Reply-To: Cc: Tim Wicinski , dnsop , dnsop-chairs To: Daniel Migault References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 19:42:52 -0000 --Apple-Mail=_0436A343-9403-40B2-A528-BB9F9BA72736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniel, On 7 May 2020, at 15:39, Daniel Migault wrote: > Thanks for putting the reference of that draft. I have always thought = that the draft you were mentioning was the one that became RFC7958. 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is = entirely reasonable! > The current draft mentions that TA should be associated with = bootstrapping mechanism and that boostrapping for the root zone should = be extended to other TA. Yep. > There are clearly some overlap between the two drafts and I also have = the impression the drafts can be merged. > the following issue has been opened: > = https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/iss= ues/7 Happy to help with that if it's something that the authors/working group = decide is useful. I support adoption of this draft, now that I've read it properly. Joe --Apple-Mail=_0436A343-9403-40B2-A528-BB9F9BA72736 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXrRktAAKCRA0jwy9hlI6 LHG2AKCNtaiN5ylum33pdtXfB3cH+s3/ggCfQhbNuXTJxvExUbQCvKbfaTj5Hx4= =q/Hw -----END PGP SIGNATURE----- --Apple-Mail=_0436A343-9403-40B2-A528-BB9F9BA72736-- From nobody Thu May 7 15:33:37 2020 Return-Path: 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 CEE553A0B85 for ; Thu, 7 May 2020 15:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 L-M2u8IW4U8P for ; Thu, 7 May 2020 15:33:31 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 649A03A0E1B for ; Thu, 7 May 2020 15:33:31 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id w2so6846199edx.4 for ; Thu, 07 May 2020 15:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JeKN8vfuCNcsN4QM6hpFQZIhj1SnodfvjuPWoZeVk98=; b=GQd4XMtXNKJz2P607/Y1Ev82wtngyBqzPhOzE9VSAL9EAh4zn4Zo3ozuZx7jDkhRC5 dCL/Y3+IwZlf92lX5lZZW8fmjEnmvBRNBMG1KZrywLv6jxbOEhSBFNx/IaYWtEdRK8E3 8F8vxHfA0j2LPKybeJyrcTVS6a0OXl0vF4XINITL/nWY0Rfhz0383gjTflnYkWNJInX4 z4Gba0EriVDLNWT+naRGgsqlbmoabDJIOG0oet9RuiLXOvyBjG7U+zOwzsT6V6BcwgRH pCzT0icEmaGtN05fH21ym6N3JV7hPUrbLAfnG+FW+Q2eSrOoSL7DifG/1bntPZa0MWJq 20/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JeKN8vfuCNcsN4QM6hpFQZIhj1SnodfvjuPWoZeVk98=; b=qYtOzm3i8NTlNf2nC0UP3i+6vqaKkHKxsdE/1Rb5HTB463nfTbjYE01AD173AfaDjG 9Gg0It/SJPO/51gaZfWBzP13al76Sdra4FYo86S5ampULaJrj4n3YyUM0KS9QFOZJt07 PgvviQVvanidwHCdbMbLScXVAVrkTMijvAJ4pzjjFjWJfH7COmOUbLmNre33TYG7E8He gXCM9Evrv4CuKulM0YWZus8xz/Tcy0yxpCmFl2O4aLL4Vq4iMYzos/NxZZYKFhIvdrwW 9GPHST36IR8vQGTARqYT3HQiQWmJE2KxSsAl7w2wkp34TOJwYh/sK9PuIWD1XR8pd7rG x8RA== X-Gm-Message-State: AGi0Pua1NKn2Cy0aFHEWfWhMf5rTQdJ31NwhkPY8RqfGPmzKcjQ4ocED 7lZ7vhdGcsu0WQB1J6ZsxPYoRvDCrs7GJL1+bIrR48ByCsQ= X-Google-Smtp-Source: APiQypJFOHI4ztZY1Uil1oVxPRcQh/2B0tAoO40Z9RNln4P2mq6bU7GKTjTTUFPQX2oV8amXENMmYWIw2qhGdhP94aU= X-Received: by 2002:a05:6402:30b4:: with SMTP id df20mr8236599edb.324.1588890809319; Thu, 07 May 2020 15:33:29 -0700 (PDT) MIME-Version: 1.0 From: Shumon Huque Date: Thu, 7 May 2020 18:33:18 -0400 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000046c41705a51678e4" Archived-At: Subject: [DNSOP] OARC Online 32a Workshop, June 9th, Call for contributions X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 22:33:36 -0000 --00000000000046c41705a51678e4 Content-Type: text/plain; charset="UTF-8" (Apologies to folks who may have already seen this announcement on other lists) Hi all, OARC is hosting an online meeting on June 9th, 17:00-19:00 UTC. The Programme Committee are seeking contributions from the community. All DNS-related subjects are welcome, but we're particularly interested in content which is timely and operationally relevant in light of the COVID-19 pandemic. Suggestions for discussion topics would also be good. As the session is limited to 2 hours we'd like to encourage brevity, presentations ought to be no longer than 20 minutes, not including time for questions. Subject areas we are looking for include the following, but not limited to: * data on traffic growth * operational scaling and availability challenges * infrastructure and skills bottlenecks * supply chain challenges * personnel & infrastructure protection * security/disinformation threats, public education * ideas that are helping * lessons learned * information from official channels * universal access inequities **Workshop Milestones:** * 7 May 2020 - Submissions open via Indico * 21 May 2020 - Deadline for submission (23:59 UTC) * 28 May 2020 - Initial Contribution list published * 02 Jun 2020 - Full agenda published * 04 Jun 2020 - Deadline for slideset submission * 09 Jun 2020 - OARC (online) 32a Workshop Details for presentation submission are published at: To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC (online) 32a: * your talk will be live broadcast and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Shumon Huque, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings. --00000000000046c41705a51678e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Apologies to folks who may have already seen this an= nouncement on other lists)

Hi all,

OARC is hosti= ng an online meeting on June 9th, 17:00-19:00 UTC. The Programme Committee = are seeking contributions from the community.

All DNS-related subjec= ts are welcome, but we're particularly interested in content which is t= imely and operationally relevant in light of the COVID-19 pandemic. Suggest= ions for discussion topics would also be good.

As the session is lim= ited to 2 hours we'd like to encourage brevity, presentations ought to = be no longer than 20 minutes, not including time for questions.

Subj= ect areas we are looking for include the following, but not limited to:
=
=C2=A0 * data on traffic growth
=C2=A0 * operational scaling and ava= ilability challenges
=C2=A0 * infrastructure and skills bottlenecks
= =C2=A0 * supply chain challenges
=C2=A0 * personnel & infrastructure= protection
=C2=A0 * security/disinformation threats, public education=C2=A0 * ideas that are helping
=C2=A0 * lessons learned
=C2=A0 * i= nformation from official channels
=C2=A0 * universal access inequities
**Workshop Milestones:**

* 7 May 2020 - Submissions open via I= ndico
* 21 May 2020 - Deadline for submission (23:59 UTC)
* 28 May 20= 20 - Initial Contribution list published
* 02 Jun 2020 - Full agenda pub= lished
* 04 Jun 2020 - Deadline for slideset submission
* 09 Jun 2020= - OARC (online) 32a Workshop

Details for presentation submission ar= e published at:

=C2=A0 =C2=A0 <https://www.dns-oarc.net/oa= rc32a>

To allow the Programme Committee to make objective ass= essments of submissions, so as to ensure the quality of the workshop, submi= ssions SHOULD include slides. Draft slides are acceptable on submission.
Additional information for speakers of OARC (online) 32a:

=C2= =A0 * your talk will be live broadcast and recorded for future reference=C2=A0 * your presentation slides will be available for delegates and othe= rs to download and refer to, before, during and after the meeting

If= you have questions or concerns you can contact the Programme Committee:
=C2=A0 =C2=A0=C2=A0https://www.dns-oarc.net/oarc/program= me

via

=C2=A0 =C2=A0 <submissions@dns-oarc.net>

= Shumon Huque, for the DNS-OARC Programme Committee


OARC depends = on sponsorship to fund its workshops and associated social events.
Pleas= e contact <spo= nsor@dns-oarc.net> if your organization is interested in becoming a = sponsor.

Please note that OARC is run on a non-profit basis, and is = not in a position to reimburse expenses or time for speakers at its meeting= s.
--00000000000046c41705a51678e4-- From nobody Thu May 7 17:16:50 2020 Return-Path: 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 91B553A09EE; Thu, 7 May 2020 17:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CPAiFjpIE15u; Thu, 7 May 2020 17:16:32 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 A53213A09C7; Thu, 7 May 2020 17:16:17 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id c124so6700425oib.13; Thu, 07 May 2020 17:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=15VAFp7DDUNk/S4KCmwPYy/hnnzQsJYHL19qWW4j8aw=; b=ay8cewsU/O3PG3ANMtRon3Uu23dNbXHIvjYCnRj5AnR3r4XUmzGgVgM+ZbIuglSmuL WLd7W+VNWYUQ/zbdLblPjcKq9ar4k868gvxZnMtcWuqoX3P7dVwHJNBwgvK+SwE00QQE +6yN7dLRQTw3udpytFXmows2lZuXa5O8s087sWrKbLfm6ekcGj6cMsMB9e8X9iI7OY51 ujmkvplsLpLQTdM6qIgQXDjpamJ2FPCvwvnP78FHoaXF7ahuJegpPopSTdAQeT7PY/1Q ilejnU2XUUZgNUJRZHeofNjxCQna+9HsViPdyVj69hGjRJzguhdbu0H3UiWZsfMDBlZS JjKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=15VAFp7DDUNk/S4KCmwPYy/hnnzQsJYHL19qWW4j8aw=; b=BIbec/qQCf5Xmz+r8RiEJ9C6jyo9Yv043QUxP/zzubC30uqNm3CxVMhDPfMzgLo4fr 1G9rJbShEjWy1FH7S91sbfsjniiuH2wVYoG3sslIO3tVYEtDxxMS5ut0QwcU7bWgzA7I vTw2ipCY3aWTG32fHT5lQ4mX8ZyjuRkGebAYTwUniAKhF+YHmclk5hATXSxgY7JgQ1mA S+RznREKh0JyvN3puNNV1AGpg7+RoPM5jSRU1YDoben5wo6ScFOP9fWKB81E3QDCPPbV M5AnPSQz4xM7S5G0tZHz2ViTScffJ/oPpE/oltg97m742KNo3VKvkKJpj3wjVjpPkZB1 smUg== X-Gm-Message-State: AGi0PuaFi7DqJYb0Wd3vIKaQM+onFHML9Jid2N+4Kwb9N16jWAODKhHN pR0MVCB3LRB3A0Es8KIjVKI8fMk7646YZnqHdJs= X-Google-Smtp-Source: APiQypKu3Vlo61AWAV/eXnmkJgPH28+oT/DZqAWZCWHAKWIcepaZwkAmynAGgUYzUHNTvaJeE+CqrcbYLU5RgNIG9hM= X-Received: by 2002:aca:ac84:: with SMTP id v126mr8922197oie.132.1588896976943; Thu, 07 May 2020 17:16:16 -0700 (PDT) MIME-Version: 1.0 References: <42A20E19-C43C-4093-8483-07B0A85386E3@hopcount.ca> In-Reply-To: <42A20E19-C43C-4093-8483-07B0A85386E3@hopcount.ca> From: Tim Wicinski Date: Thu, 7 May 2020 20:16:06 -0400 Message-ID: To: Joe Abley Cc: Daniel Migault , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000e5404805a517e7a3" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 00:16:46 -0000 --000000000000e5404805a517e7a3 Content-Type: text/plain; charset="UTF-8" Daniel Thanks for taking Joe's draft under advice and I agree there is work to be collaborated on. Tim (speaking as a chair) On Thu, May 7, 2020 at 3:42 PM Joe Abley wrote: > Hi Daniel, > > On 7 May 2020, at 15:39, Daniel Migault wrote: > > > Thanks for putting the reference of that draft. I have always thought > that the draft you were mentioning was the one that became RFC7958. > > 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is > entirely reasonable! > > > The current draft mentions that TA should be associated with > bootstrapping mechanism and that boostrapping for the root zone should be > extended to other TA. > > Yep. > > > There are clearly some overlap between the two drafts and I also have > the impression the drafts can be merged. > > the following issue has been opened: > > > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 > > Happy to help with that if it's something that the authors/working group > decide is useful. > > I support adoption of this draft, now that I've read it properly. > > > Joe > --000000000000e5404805a517e7a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

D= aniel
Thanks= =C2=A0for taking Joe's draft under advice and I agree there is work to = be collaborated on.

Tim
(speaking=C2=A0as a chair)

On Thu, May 7, 2020 at 3:42 PM Joe Abley = <jabley@hopcount.ca> wrote:=
Hi Daniel,

On 7 May 2020, at 15:39, Daniel Migault <mglt.ietf@gmail.com> wrote:

> Thanks for putting the reference of that draft. I have always thought = that the draft you were mentioning was the one that became RFC7958.

7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is entir= ely reasonable!

> The current draft mentions that TA should be associated with bootstrap= ping mechanism and that boostrapping for the root zone should be extended t= o other TA.

Yep.

> There are clearly some overlap between the two drafts and I also have = the impression the drafts can be merged.
> the following issue has been opened:
> https://github.c= om/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7

Happy to help with that if it's something that the authors/working grou= p decide is useful.

I support adoption of this draft, now that I've read it properly.


Joe
--000000000000e5404805a517e7a3-- From nobody Fri May 8 14:24:47 2020 Return-Path: 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 13A8B3A0F34 for ; Fri, 8 May 2020 14:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=verizon.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 64LSe72oOiVr for ; Fri, 8 May 2020 14:24:44 -0700 (PDT) Received: from smtpout2-tdc.verizon.com (smtpout2-tdc.verizon.com [137.188.104.134]) (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 899EB3A0F38 for ; Fri, 8 May 2020 14:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1588973084; x=1620509084; h=to:subject:date:message-id:mime-version:from; bh=J5qPPyPrANCqMSKqFQg54EOZI4zFLGEoSaNR6AiBImg=; b=qQ6P2yVeSk2eSmKUfervzCkOeU2S+3Ck/FKHXyYE7M74CVGa4WZ1WDuM +iSeYrGsnfHCenjaUz44aRei85wi9KatAJvXPTyKuQsETreN7/UFZUdim /IUjgHCOo37r0DucLDoNpmSOqnMsf2G+Nx6GdmnkYawwSnXDctyxOGSDL M=; From: sanjay.mishra@verizon.com Received: from tbwexch04apd.uswin.ad.vzwcorp.com ([153.114.162.28]) by smtpout2-tdc.verizon.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 08 May 2020 21:24:43 +0000 Received: from tbwexch11apd.uswin.ad.vzwcorp.com (153.114.162.35) by tbwexch04apd.uswin.ad.vzwcorp.com (153.114.162.28) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 17:24:42 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com (153.114.162.26) by tbwexch11apd.uswin.ad.vzwcorp.com (153.114.162.35) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 17:24:42 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) by tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) with mapi id 15.00.1497.006; Fri, 8 May 2020 17:24:42 -0400 To: "dnsop@ietf.org" Thread-Topic: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements Thread-Index: AdYlfd0BhIWh6qNBQn2YRmGJafHMng== Date: Fri, 8 May 2020 21:24:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_ffc1e4a712a243c0a44c35d6d7880370tbwexch02apduswinadvzwc_" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 21:24:47 -0000 --_000_ffc1e4a712a243c0a44c35d6d7880370tbwexch02apduswinadvzwc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. Agree with Stephane and support adoption of this draft. Thanks Sanjay Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requiremen= ts Stephane Bortzmeyer Wed, 06 May 2020 08:48 UTCShow head= er On Mon, May 04, 2020 at 03:08:20PM -0400, Tim Wicinski wrote a message of 64 lines which said: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements >I think it is important to have such a document, because DNSSEC failures may seriously endanger the deployment of DNSSEC (which is already too low). The current draft seems a good starting point and I support its adoption. --_000_ffc1e4a712a243c0a44c35d6d7880370tbwexch02apduswinadvzwc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+= ;1.

 

Agre= e with Stephane and support adoption of this draft.

 

Than= ks

Sanj= ay

 

 

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-vali= dator-requirements

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 06 May 202= 0 08:48 UTCShow header

On Mon, May 04, 2020 at 03:08:20P= M -0400,

Tim Wicinski <tjw.ietf@gmail.com> wrote

 a message of 64 lines which= said:

 

> This starts a Call for Adopt= ion for

> draft-mglt-dnsop-dnssec-vali= dator-requirements

 

>I think it is important to ha= ve such a document, because DNSSEC

failures may seriously endanger t= he deployment of DNSSEC (which is

already too low). The current dra= ft seems a good starting point and I

support its adoption.<= /span>

--_000_ffc1e4a712a243c0a44c35d6d7880370tbwexch02apduswinadvzwc_-- From nobody Sat May 9 18:52:07 2020 Return-Path: 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 59E833A0CF5 for ; Sat, 9 May 2020 18:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 m3GuACZOhPDq for ; Sat, 9 May 2020 18:51:58 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 7331E3A0CF3 for ; Sat, 9 May 2020 18:51:58 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id a2so11866000oia.11 for ; Sat, 09 May 2020 18:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xKDnAsys9FG3ZjHUvlUE13XPrwCUz5fsRzxHymdN6uw=; b=bfLZQP953mKfghlDTTa6LTzeQho2vJvEJ72jEqn90FhK+AZMu9hWmfthZKBVl05B0L 0LG0JYCyyKL4L3I7SGItMTvMBdhBkZRBWrgg+85pcOcxvzryhmmv3WcSdz+J2BczXLfM W+aE0ZNbOwMP4LKvnCa3WcwaIaJowIWk1rJyPiUZadRvZj+yUFHu58Rk5YXzByhvlfMz 4tQyZ6iVrdX7HXMs0Aw8teAamwari9+Q/Ae7tSYap44dnGnFKgCV1i73j8mhgz4MZj76 cwFsjfj5RzafD9cL09mKmdOQi9gnecobAxjtXDMZ2w1fomu/zNMeOoFHPwUHcLEExI/V L8kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xKDnAsys9FG3ZjHUvlUE13XPrwCUz5fsRzxHymdN6uw=; b=QECAJoGhR+lAsNPk/SBU4Na0qsAQOvgfp5sPiaEuRWkwTt6D13XHd6NjDV/xQMAG7b 0nptH1WpX91UMUXBGggPQ9xHcP6SZwa7PtCD/C3tRn9kkD4tMSzZx6xl3FFjhIJtEYL8 u85yG9TReQCwc47QqbL1iJko/ravONq/dl+wgcCmgPnFJDL4xQzx7xhh3BRW859mpU0p zfiwP21qWf4B55XR93ImdNBc4iyBN6XJrAOz5hT2gi6Mj2HawRyoHN8uE6hnYvm1UuNu GYF1dbKNa2lp63sV/BdNNphLbyiis6kfEf+H3QAkYwP0TthmEYVwj6pagrO845+OQS+G 3j6Q== X-Gm-Message-State: AGi0PuabF72nSnV2KmkOymGnS0E5YffNgNv1VIlBm/bLCA3TqmdMp7kv szS0A/R73hBCMIL3Io2r3WA0fC5pDrYVrnN0b0Y= X-Google-Smtp-Source: APiQypLygUDs40YI53pFhfTexZBPnvfSYAVj+pJFr6Y3hy/nHnQTcKWlqKTBIWHnG0lmKu89ikyKT0OENyg4zRnID2I= X-Received: by 2002:aca:ac84:: with SMTP id v126mr15840011oie.132.1589075517234; Sat, 09 May 2020 18:51:57 -0700 (PDT) MIME-Version: 1.0 References: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> In-Reply-To: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> From: Tim Wicinski Date: Sat, 9 May 2020 21:51:45 -0400 Message-ID: To: Stephen Morris Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000b9e36005a54179d2" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 01:52:06 -0000 --000000000000b9e36005a54179d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To follow up on Stephen's comments, a table was added to 2845bis to list all the algorithms that are currently in the IANA registry, along with suggestions for implementation. This was the first version: Requirement Name ----------- ------------------------ Optional HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hmac-sha384 Optional hmac-sha512 During the IESG review (I think it was the SECDIR review), there was a meltdown over implementing SHA-1. But SHA-1 is in use currently. My suggestion was to do a variation describing implementation use. This is what I came up with(so blame me): Name Implementation Use ------------------------ -------------- --------------- HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT gss-tsig MAY MAY hmac-sha1 MUST NOT RECOMMENDED hmac-sha224 MAY NOT RECOMMENDED hmac-sha256 MUST RECOMMENDED hmac-sha256-128 MAY MAY hmac-sha384 MAY MAY hmac-sha384-192 MAY MAY hmac-sha512 MAY MAY hmac-sha512-256 MAY MAY On the use side, these are mostly guesses. We would love to hear what the WG has to say about this. thanks tim On Mon, May 4, 2020 at 2:07 PM Stephen Morris wrote: > > > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Domain Name System Operations WG of th= e > IETF. > > > > Title : Secret Key Transaction Authentication for DNS > (TSIG) > > Authors : Francis Dupont > > Stephen Morris > > Paul Vixie > > Donald E. Eastlake 3rd > > Olafur Gudmundsson > > Brian Wellington > > Filename : draft-ietf-dnsop-rfc2845bis-08.txt > > Pages : 29 > > Date : 2020-05-04 > > > The update addresses to the draft comments made during the IESG review. > There were a fair number of these which led to a number of changes to the > document. These are listed below. > > One significant change is that the list of acceptable algorithms has been > extended, and WG approval for this is sought. > > Stephen > > > > > Comments from Roman Danyliw > --- > > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly follow= ing that > document (and the related [RFC4635]) were discovered to have security > problems related to this feature=E2=80=9D, consider providing a reference= to the > published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) > > I=E2=80=99ve added these (and one other related CVE) as informative refer= ences. > Using just the CVE number as a reference seemed a bit spartan, so I=E2=80= =99ve > added a title to each incident. As the description of the CVEs in Mitre= =E2=80=99s > database don=E2=80=99t contain a title (only a description, which can be = rather > long), I=E2=80=99ve taken the title from ISC=E2=80=99s KnowledgeBase (for= the BIND CVEs) > and from the Knot release notes (for the Knot CVE). > > > > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated so = the MD5 > security considerations apply to SHA-1 in a similar manner. Although > support for hmac-sha1 in TSIG is still mandatory for compatibility reason= s, > existing uses should be replaced with hmac-sha256 or other SHA-2 digest > algorithms [FIPS180-4], [RFC3874], [RFC6234]. > > > > -- It=E2=80=99s worth repeating those MD5 security considerations here > > I=E2=80=99m not really keen on doing this, since the security considerati= ons in > RFC 6151 cover two paragraphs and including them - or even a summary of > them - would detract from the flow of the document. However, I have > explicitly included a reference to RFC 6151 in the text. > > > > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth > including references to the recent SHA-1 cryptoanalysis provided in the > SECDIR review > > Added references to just one of these papers (=E2=80=9DSHA1 is a Shambles= =E2=80=9D). > We=E2=80=99re not doing a general analysis of the algorithms, so a simple= reference > to a paper than describes a SHA1 collision is all that is needed. (As an > aside, the paper doesn't give the date of publication, so I had to search > the Web looking for references to it. I think I=E2=80=99ve got the date = correct, > but I=E2=80=99d be grateful for a double-check.) > > > > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). > > Done - see Table 2 > > > > ** Section 10. Per =E2=80=9CFor all of the message authentication code > algorithms listed in this document, those producing longer values are > believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR rev= iew, this could be > misconstrued as the algorithm choice not the digest length provides the > security. Recommend rephrasing (or making some statement > > I=E2=80=99ve reworded this paragraph (in section 10). It now reads: > > "Although the strength of an algorithm determines its security, there > have been some arguments that mild truncation can strengthen a MAC by > reducing the information available to an attacker. However, excessive > truncation clearly weakens authentication by reducing the number of > bits an attacker has to try to break the authentication by brute > force [RFC2104]." > > > > ** Editorial > > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message, thi= s is the > message after the TSIG RR and been removed and the ARCOUNT field has been > decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (is missing a = word). > > > > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in wir= e > format.=E2=80=9D, this isn=E2=80=99t a sentence. > > Section 4.3.2 has been reworded to address these issues. > > > > Comments from Benjamin Kaduk > > > Thanks for putting together this update; it's good to see the security > > issue getting closed off in the udpated spec, and progression to full > > Internet Standard! I do have several substantive comments (as well as > > some minor/nit-level ones), many of which are listed here at the top bu= t > > a few of which are interspersed in the per-section comments. > > > > > > I considered making this a Discuss point, but it should be pretty > > uncontroversial and I trust that the right thing will happen even if I > > don't: there's a couple lingering remnants of SHA-1 being the > > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 and > > 10 (further detailed in the per-section comments). > > The document now mentions SHA1 collisions and notes that the MD5 security > considerations apply to SHA1. It also mentions that support for SHA1 is > mandatory for compatibility reasons but in existing uses it should be > replaced by a stronger one. > > > > I also initially had made the following point a Discuss-level point, bu= t > > decided to not do so since I don't remember any BCP-level guidance > > relating to cross-protocol attacks. Nevertheless, I strongly encourage > > the authors to consider that cryptographic best practice is to use any > > given key with exactly one cryptographic algorithm. The record format > > listed in Section 4.2 has the key name and algorithm as separately > > conveyed, which would allow for a given key to be used with all > > implemented algorithms. We should include some discussion that it's > > best to only use a single algorithm with any given key. > > The following text has been added to the Security Considerations section: > > "To prevent cross-algorithm attacks, there SHOULD only be one > algorithm associated with any given key name." > > > > We also have a 16-bit wide field for "Fudge", which (since it counts > > seconds) corresponds to a maximum window of something like +/- 18 hours= ; > > it's hard to believe that we really want to give people the rope to > > allow for that much time skew. (Yes, I understand that implementations > > will set something sane in practice but that doesn't necessarily mean > > that the protocol still has to allow it.) > > That was set in the original RFC 2845. Although I agree with the > comments, changing the size of that field would be a significant > undertaking. However, section 10 does state that the RECOMMENDED fudge > value in most circumstances is 300 seconds. > > > > Our authoritative list of algorithm names (Table 1) is rather divorced > > from the references to be consulted for the individual hash algorithms > > to be used with the HMAC procedure. The ones used here are sufficientl= y > > well-known that I'm not terribly concerned about it, though. > > The first paragraph of the IANA considerations section lists the > algorithms and references to where they are described, and I didn=E2=80= =99t want to > duplicate the information. > > > > Abstract > > > > The title says "DNS" but maybe the body of the abstract should as well? > > In the abstract, changed: > > "It can be used to authenticate dynamic updates as coming from an approve= d > client" > > to > > "It can be used to authenticate dynamic updates to a DNS zone as coming > from an approved client" > > > > Section 1.1 > > > > Some of this language feels like it might not age terribly well, e.g., > > "this can provide" or "[t]here was a need". > > > > addresses that need. The proposal is unsuitable for general server > > to server authentication for servers which speak with many other > > servers, since key management would become unwieldy with the number > > of shared keys going up quadratically. But it is suitable for many > > resolvers on hosts that only talk to a few recursive servers. > > Changed to: > > "The authentication mechanism proposed here provides a > simple and efficient authentication between clients and local > servers > by using shared secret keys to establish a trust relationship > between > two entities. Such keys must be protected in a manner similar to > private keys, lest a third party masquerade as one of the intende= d > parties (by forging the MAC). The proposal is unsuitable for > general > server to server authentication for servers which speak with many > other servers, since key management would become unwieldy with th= e > number of shared keys going up quadratically. But it is suitable > for > many resolvers on hosts that only talk to a few recursive servers= .=E2=80=9D > > > > Should zone transfers be mentioned here as well? > > Zone transfers are mentioned in the preceding paragraph. > > > > Section 1.2 > > > > I don't understand the motivation for changing terminology from MACs to > > "signatures"; they're still MACs even though they're transaction-based. > > The mention of signatures in section 1.2 is intended as a link between th= e > name of the RR (TSIG or Transaction Signature) and the term MAC used in t= he > rest of the document. > > > > MAC of the query as part of the calculation. Where a response > > comprises multiple packets, the calculation of the MAC associated > > with the second and subsequent packets includes in its inputs the MAC > > for the preceding packet. In this way it is possible to detect any > > interruption in the packet sequence. > > > > I suggest mentioning the lack of mechanism to detect truncation of the > > packet sequence. > > That is a fair point. I=E2=80=99ve modified the last sentence to read: > > "In this way it is possible to detect any interruption in the packet > sequence, > although not its premature termination." > > > > Section 4.2 > > > > NAME The name of the key used, in domain name syntax. The name > > should reflect the names of the hosts and uniquely identify the > > key among a set of keys these two hosts may share at any given > > time. For example, if hosts A.site.example and > > B.example.net > > > > share a key, possibilities for the key name include > > .A.site.example, .B.example.net, and > > .A.site.example.B.example.net. It should be possible for > > more than one key to be in simultaneous use among a set of > > interacting hosts. > > > > I'd suggest adding a note along the lines of "This allows for periodic > > key rotation per best operational practices, as well as algorithm > > agility as indicated by [BCP201].=E2=80=9D > > Added. > > > > The name may be used as a local index to the key involved and > > it is recommended that it be globally unique. Where a key is > > > > (nit?): this feels more like a "but" than an "and", to me. > > Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than =E2=80= =9Cand=E2=80=9D > > > > * MAC Size - an unsigned 16-bit integer giving the length of > > MAC field in octets. Truncation is indicated by a MAC size > > less than the size of the keyed hash produced by the > > algorithm specified by the Algorithm Name. > > > > nit: I would suggest "output size", as there are potentially a few > > different sizes involved (key size, block size, and output size, for > > starters, though I think the possibility of confusion here is low). > > I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference t= o this field, and > the other size mentioned - that of the keyed hash is, I think, also > unambiguous. > > > > * Other Len - an unsigned 16-bit integer specifying the length > > of the "Other Data" field in octets. > > > > * Other Data - this unsigned 48-bit integer field will be > > empty unless the content of the Error field is BADTIME, in > > which case it will contain the server's current time as the > > number of seconds since 00:00 on 1970-01-01 UTC, ignoring > > leap seconds (see Section 5.2.3). > > > > I'm slightly confused at the interplay between the explicit length fiel= d > > and the "empty unless" directive. Does this mean that the only allowed > > values in the "Other Len" are 0 and 6? Does "empty" mean "length-zero= =E2=80=9D? > > I=E2=80=99ve rewritten this slightly in a bid to make it clearer that =E2= =80=9COther Data=E2=80=9D > being empty means that =E2=80=9COther Len=E2=80=9D is zero. > > > > Section 4.3.1 > > > > Only included in the computation of a MAC for a response message (or > > the first message in a multi-message response), the validated request > > MAC MUST be included in the MAC computation. If the request MAC > > failed to validate, an unsigned error message MUST be returned > > instead. (Section 5.3.2). > > > > side note: while Section 5.3.2 specifies how to create an unsigned erro= r > > message, it looks like Section 5.2 (and subsections lists specific > > RCODEs that are to be used. > > That is the case. Section 4 is a description of the TSIG RR and its > fields. Section 5 describes the contents of the fields in various > situations (client transmission, server reception, server transmission, > client reception). > > > > Section 4.3.2 > > > > When verifying an incoming message, this is the message after the > > TSIG RR and been removed and the ARCOUNT field has been decremented. > > If the message ID differs from the original message ID, the original > > message ID is substituted for the message ID. (This could happen, > > for example, when forwarding a dynamic update request.) > > > > I trust (based on this text having survived while going for full IS) > > that there are no interesting record-keeping considerations with respec= t > > to knowing the message ID(s) to substitute, in the "forwarding a > > dynamic-update request" case, presumably since this is just the field > > from the TSIG RDATA and not some externally retained state. > > That is correct - the original ID is stored in the TSIG record=E2=80=99s = RDATA and > it is from there that the original ID is retrieved when a substitution is > made. > > > > Section 4.3.3 > > > > The RR RDLEN and RDATA MAC Length are not included in the input to > > MAC computation since they are not guaranteed to be knowable before > > the MAC is generated. > > > > I appreciate that this is explicitly noted; there are some security > > considerations regarding the non-inclusion of the (truncated) mac lengt= h > > as input, though. The local truncation policy helps here, but not 100%= . > > OK > > > > For each label type, there must be a defined "Canonical wire format" > > > > Just to check my understanding: label types only come into play for the > > two fields that are in domain name syntax, key name and algorithm name? > > There was actually an error in the text here: RFC 4034 section 6.1 is > concerned with Canonical Name Order. It is section 6.2 that details the > canonical wire format - I=E2=80=99ve changed the reference. > > Going back to the original point, yes, that is correct. Label type 00 is > uncompressed name. (11 is a compressed name, and label types 01 and 10 ar= e > discouraged - see RFC 6891 section 5). > > > > Section 5.1 > > > > the server. This TSIG record MUST be the only TSIG RR in the message > > and MUST be last record in the Additional Data section. The client > > > > (Is there anything else that tries to insist on being the last record i= n > > the additional data section? I guess it doesn't really make sense to > > try to Update: 1035 just to note this requirement.) > > Not to our knowledge. > > > > MUST store the MAC and the key name from the request while awaiting > > an answer. > > > > [This is going to end up alongside the request-ID that it has to store > > already, right?] > > Yes. The request MAC is included as one of the components used by the > server to generate the response - which should be encoded using the same > key as used in the request. > > > > Note that some older name servers will not accept requests with a > > nonempty additional data section. Clients SHOULD only attempt signed > > transactions with servers who are known to support TSIG and share > > some algorithm and secret key with the client -- so, this is not a > > problem in practice. > > > > (The context in which this "SHOULD" appears makes it feel like it's > > repeating an admontion from elsewhere and not the only instance of the > > requirement, in which case a reference might be appropriate.) > > I=E2=80=99ve removed this paragraph. The reference to older name servers= is now > completely out of date (it was a carry-over from the original 20-year old > text). The rest of the paragraph seems superfluous - rather like stating > that TCP clients should only connect to servers that support TCP. > > > > Section 5.2 > > > > If the TSIG RR cannot be understood, the server MUST regard the > > message as corrupt and return a FORMERR to the server. Otherwise the > > server is REQUIRED to return a TSIG RR in the response. > > > > As written, this could be read as an attempt to make a normative > > requirement of servers that do not implement this spec. Presumably it'= s > > just restating a requirement of the core protocol, though? > > It is the core protocol. > > I see your point though. However, by implication we are talking about a > server that implements TSIG. > > > > Section 5.2.2 > > > > Using the information in the TSIG, the server should verify the MAC > > by doing its own calculation and comparing the result with the MAC > > received. If the MAC fails to verify, the server MUST generate an > > > > Is there any other way to verify the MAC? (Should this be a "MUST > > verify=E2=80=9D?) > > Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. > > > > Section 5.2.2.1 > > > > When space is at a premium and the strength of the full length of a > > MAC is not needed, it is reasonable to truncate the keyed hash and > > use the truncated value for authentication. HMAC SHA-1 truncated to > > 96 bits is an option available in several IETF protocols, including > > IPsec and TLS. > > > > Also Kerberos, where it was the strongest option for a while and we had > > to define a new encryption type to provide a better option (RFC 8009). > > > > This text seems to be implying that HMAC SHA-1 truncated to 96 bits is = a > > recommendable option, which is ... far from clear. I'd prefer to have = a > > note that this specific truncation was appropriate when initially > > specified but may not provide a security level appropriate for all case= s > > in the modern environment, or preferrably to just change the reference > > to (e.g.) SHA-384-192 or SHA-256-128. > > Added the following an the end of the paragraph: > > However, while this option is kept for backwards compatibility, > it may not provide a security level appropriate for all cases > in the modern environment. In these cases, it is preferable to > use a hashing algorithm such as SHA-256-128, SHA-384-192 > or SHA-256-128 [RFC4868]. > > I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D,= =E2=80=9Chmac-sha384-192=E2=80=9D and > =E2=80=9Chmac-sha512-256=E2=80=9D as optional algorithms to the algorithm= table. > > > > This is sent when the signer has truncated the keyed hash output > > to an allowable length, as described in [RFC2104], taking initial > > octets and discarding trailing octets. TSIG truncation can only > > > > (Or when an on-path attacker has performed truncation.) > > True, but an on-path attacker can manipulate the message in any way > possible. I=E2=80=99m not sure whether adding this caveat will add anyth= ing to the > document. > > > > Section 5.2.3 > > > > (BADTIME). The server SHOULD also cache the most recent time signed > > value in a message generated by a key, and SHOULD return BADTIME if a > > message received later has an earlier time signed value. A response > > > > (But there's no fudge factor on this check, other than the inherent > > limit of seconds granularity, as alluded to by the last paragraph of > > this section?) > > The last paragraph in the section states that handling this issue should > be left up to implementations and that the exact method (and by > implication, the size of the fudge factor) be determined by the > implementation themselves. > > > > Section 5.3.1 > > > > A zone transfer over a DNS TCP session can include multiple DNS > > messages. Using TSIG on such a connection can protect the connection > > from hijacking and provide data integrity. The TSIG MUST be included > > > > (I assume that "hijacking TCP" means a sequence-number-guessing attack > > that would require the attacker to be winning the race against the > > legitimate sender to cause modified data to be introduced into the TCP > > stream? This is maybe not the best word to use for such a case.) > > I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D= . > > > > on all DNS messages in the response. For backward compatibility, a > > client which receives DNS messages and verifies TSIG MUST accept up > > to 99 intermediary messages without a TSIG. The first message is > > > > (side note: I'm kind of curious what such compatibility is needed with. > > Also, this gives an attacker some flexibility into which to incorporate > > a collision, though given the near-real-time constraints and the > > strength of the HMAC construction I don't expect any practical impact.) > > The original RFC 2845 did not require all packets in a message stream to > contain a TSIG, it just stated that there be no more than 99 intermediary > messages without a TSIG (presumably to cut down on the overhead required = in > message calculations - remember that RFC 2845 was published 20 years ago)= . > Although many DNS implementations now add a TSIG to every message, it is = by > no means certain that all do. (In fact, less than three years ago, a bug > was introduced into BIND, causing it to require that all packets in a zon= e > transfer would contain a TSIG. A fix allowing BIND to accept up to 99 > packets between signed ones was released shortly afterwards after reports > were received of zone transfers failing.) > > > > Section 5.3.2 > > > > Request MAC (if the request MAC validated) > > DNS Message (response) > > TSIG Variables (response) > > > > The reason that the request is not included in this MAC in some cases > > is to make it possible for the client to verify the error. If the > > error is not a TSIG error the response MUST be generated as specified > > in Section 5.3. > > > > This makes it sound like the server excludes the request MAC from the > > digest if it failed to validate (something the client cannot predict), > > so that the client must perform trial verification of both versions in > > order to validate the response. Is that correct? > > No. If the incoming MAC failed to validate, the server should send back > an unsigned response (MAC size =3D=3D 0 and empty MAC). > > > > Also, I think that the "in some cases" is not properly placed: as-is, i= t > > says that the request (not request MAC) is sometimes not included > > (implying that sometimes it is), which does not match up with the > > specification for the digest components. I presume that the intent is > > to say that in some cases the client could not verify the error, if the > > request itself was always included in the digest. > > Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. > > If the MAC could not be verified, it is possible that it was corrupted, > which would prevent the client verifying the response. But a major reason > is that an incorrect MAC included in a signed response led to the CVEs th= at > prompted this document update. > > > > Section 5.4.1 > > > > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG > > validates and the TSIG key recognised by the client but different > > from that used on the request, then this is a Key Error. The client > > > > nits: missing words "key is recognized" and "but is different=E2=80=9D > > It now reads =E2=80=9Ckey is recognized but different" > > > > Section 5.5 > > > > destination or the next forwarder. If no transaction security is > > available to the destination and the message is a query then, if the > > corresponding response has the AD flag (see [RFC4035]) set, the > > forwarder MUST clear the AD flag before adding the TSIG to the > > response and returning the result to the system from which it > > received the query. > > > > Is there anything to say about the CD bit? (It's independent crypto, s= o > > I don't expect so, but it seems worth checking.) > > No. CD is just a mechanism by which a client can request that the server > not do DNSSEC signature validation on the data and so allow the client to > receive the data instead of a SERVFAIL response. > > > > Section 6 > > > > The only message digest algorithm specified in the first version of > > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], > > [RFC2104]). Although a review of its security [RFC6151] concluded > > that "it may not be urgent to remove HMAC-MD5 from the existing > > protocols", with the availability of more secure alternatives the > > opportunity has been taken to make the implementation of this > > algorithm optional. > > > > It seems worth noting that the advice from RFC 6151 is already nine > > years old. > > I=E2=80=99ve use the phrasing "Although a review of its security some yea= rs ago=E2=80=9D. > > > > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], > > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 > > security considerations apply to SHA-1 in a similar manner. Although > > > > I'd consider referencing (e.g.) > > shattered.io > > for the "collisions have > > been demonstrated" claim, though it's pretty optional. > > A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D pap= er. > > > > support for hmac-sha1 in TSIG is still mandatory for compatibility > > reasons, existing uses should be replaced with hmac-sha256 or other > > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. > > > > Is this "sha1 mandatory for compatibility" going to age well? If we > > have two implementations that can operate with sha2 variants, is it > > required to keep this as mandatory (vs. optional with a note about > > deployed reality at time of publication) for progression to Internet > > Standard? > > This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2= =80=9D column in > RFC4635 (from which Table 2 was derived) into =E2=80=9CImplementation=E2= =80=9D and =E2=80=9CUse=E2=80=9D. > SHA1 is required to be implemented (for backwards compatibility) but its > use is not recommended. > > > > Optional hmac-sha224 > > > > It's not clear there's much reason to keep this around, or if we do, it > > could probably be "not recommended". (I assume that just dropping it > > entirely makes things annoying w.r.t. the IANA registry.) > > It has been left in for compatibility reasons, but its use is not > recommended. > > > > Section 9 > > > > Previous specifications [RFC2845] and [RFC4635] defined values for > > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an > > > > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where > > HMAC qualifies both hash algorithms is not terribly clear. > > Changed to > > Previous specifications [RFC2845] and [RFC4635] defined names for > the HMAC-MD5 and the various HMAC-SHA algorithms. > > > > Section 10 > > > > I suggest some discussion that the way truncation policy works, an > > attackers ability to forge messages accepted as valid is limited by the > > amount of truncation that the recipient is willing to accept, not the > > amount of truncation used to generate messages by the legitimate sender= . > > I think this is already taken care of by the reference to a local policy > in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.2= .4). > > > > There's also some fairly standard content to put in here about allowing > > for an unsigned error response to a signed request, so an attacker (eve= n > > off-path) can spoof such resposnes. (Section 5.4 indicates that the > > client should continue to wait if it gets such a thing, which helps a > > lot.) > > I=E2=80=99ve just added text that an unsigned response is not considered > acceptable because can be subject to spoofing and manipulation. > > > > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two > > entities. > > > > I suggest adding "; any such additional sharing would allow any party > > knowing the key to impersonate any other such party to members of the > > group=E2=80=9D. > > Added. > > > > A fudge value that is too large may leave the server open to replay > > attacks. A fudge value that is too small may cause failures if > > machines are not time synchronized or there are unexpected network > > delays. The RECOMMENDED value in most situations is 300 seconds. > > > > Our experience with kerberos in modern network environments has shown > > that 5 minutes is much larger than needed, though it's not clear there'= s > > a strong need to change this recommendation right now. > > The value is recommended (and even then, only in =E2=80=9Cmost situations= =E2=80=9D), so > implementations are free to set their own value. However, any guidance a= s > to typical time skews measured across a network would be useful in a numb= er > of protocols. > > > > Significant progress has been made recently in cryptanalysis of hash > > functions of the types used here. While the results so far should > > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are being > > made mandatory as a precaution. > > > > Please revise this note to not imply that SHA-1 is considered "strong= =E2=80=9D. > > Text revised to > > Significant progress has been made recently in cryptanalysis of > hash > functions of the types used here. While the results so far shoul= d > not > affect HMAC, the stronger SHA-256 algorithm is being made mandato= ry > as a precaution. > > > > Section 11.2 > > > > I'm not sure why RFC 2104 is listed as informative. > > RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a p= ossible downref > if the reference is placed in the =E2=80=9CNormative=E2=80=9D section. > > > > Comments from Mirja K=C3=BChlewind > > > I only had limited time for a quick review of this document, so I might > not be aware of all the needed background and details. Still I have two > quick questions on retries: > > > > 1) Sec 5.2.3: > > "Implementations should be aware > > of this possibility and be prepared to deal with it, e.g. by > > retransmitting the rejected request with a new TSIG once outstanding > > requests have completed or the time given by their time signed plus > > fudge value has passed." > > I might not be aware of all protocol details and maybe this is already > specified somewhere: While unlikely, it is possible that a request might = be > retransmitted multiple times, as that could cause president congestion ov= er > time, it's always good practice to define a maximum number of > retransmissions. If that is already defined somewhere, maybe adding a > note/pointer would be good as well. > > If someone can suggest a suitable number (and a reason for it), we can > consider doing this. In the meantime, I=E2=80=99ve merely stated that > implementation should limit the number of retransmissions and so leave th= e > choice up to the implementation. > > > > 2) Sec 5.3.1: > > " This allows the client to rapidly detect when the session has been > > altered; at which point it can close the connection and retry." > > When (immediately or after some waiting time) should the client retry > and how often? > > I think that should be down to the implementation to decide. > > > > You further say > > "The client SHOULD treat this the > > same way as they would any other interrupted transfer (although the > > exact behavior is not specified here)." > > Where is that specified? Can you provide a pointer in the text? > > That was a mistake in transcribing the original RFC2845 text. The final > word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads: > > The client SHOULD treat this the same way as they would any other > interrupted transfer (although the exact behavior is not > specified). > > > > 3) Sec 8. Shared Secrets: Would it be appropriate to use more normativ= e > language here? There are a bunch of lower case shoulds in this section; i= s > that on purpose? > > The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is v= ery general > security advice. Although this is something users ought to do, it is not > really a specific recommendation. > > > > Comments from Barry Leiba > > > =E2=80=94 Section 4.2 =E2=80=94 > > > > * Other Len - an unsigned 16-bit integer specifying the length > > of the "Other Data" field in octets. > > * Other Data - this unsigned 48-bit integer field will be > > > > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits? If= so, does that > mean tgat the value of =E2=80=9Cother len=E2=80=9D is always 6? If so, t= hen shouldn=E2=80=99t it > say that? If not, then what don=E2=80=99t I understand? > > Benjamin Kaduk also made the same comment, it has been addressed above. > > > > =E2=80=94 Section 5.1 =E2=80=94 > > > > Clients SHOULD only attempt signed > > transactions with servers who are known to support TSIG and share > > some algorithm and secret key with the client -- so, this is not a > > problem in practice. > > > > Why SHOULD and not MUST? > > Benjamin Kaduk also noted an issue here. The paragraph has been removed. > > > > =E2=80=94 Section 5.3.2 =E2=80=94 > > > > The server SHOULD also cache the most recent time signed > > value in a message generated by a key > > > > I tripped over this until I realized you mean =E2=80=9CTime Signed valu= e=E2=80=9D. You > capitalize it elsewhere, and it helps the parsing if it=E2=80=99s consist= ent. There > are four uncapitalized instances in this section. > > =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in the = description of > the field, =E2=80=9Ctims signed=E2=80=9D has been replaced with =E2=80=9C= time the message was > signed=E2=80=9D. > > Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9C= Fudge field=E2=80=9D (although > occurrences of =E2=80=9Cfudge value=E2=80=9D have not been capitalised, a= s the context of > that is that it is referring to the contents of the Fudge field). Also, > =E2=80=9Cother data=E2=80=9D and =E2=80=9Cother data length=E2=80=9D have= been replaced with the > (capitalised) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COthe= r Len=E2=80=9D. > > > > =E2=80=94 Section 9 =E2=80=94 > > > > There is no structure > > required other than names for different algorithms must be unique > > when compared as DNS names, i.e., comparison is case insensitive. > > > > I found this sentence to be really awkward and hard to parse. May I > suggest this?: > > > > NEW > > There is no structure to the names, and algorithm names are compared as > if they were DNS names (the comparison is case-insensitive). > > END > > > > I don=E2=80=99t think you really need to say that each name is differen= t/unique, > right? > > Agreed. The text has been changed to that suggested. > > > > other algorithm > > names are simple (i.e., single-component) names. > > > > Nitty thing that you can completely ignore, but I would avoid the Latin > abbreviation thus: =E2=80=9Cother algorithm names are simple, single-comp= onent > names.=E2=80=9D > > Changed. > > > > Comments from =C3=89ric Vyncke > > > Thank you for the work put into this document. It is clear and easy to > read. > > > > Please find below some non-blocking COMMENTs and NITs. An answer will b= e > appreciated. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -=C3=A9ric > > > > =3D=3D COMMENTS =3D=3D > > > > There are 6 authors while the usual procedure is to limit to 5 authors. > Personally, I do not care. > > > > -- Section 1.3 -- > > It is a little unclear to me whether the "two nameservers" were two > implementations or two actual DNS servers. > > Agreed, it was unclear. Changed to =E2=80=9Ctwo name server implementati= ons=E2=80=9D. > > > > -- Section 5.2 -- > > Suggest to provide some justifications about "copied to a safe > location": the DNS message was sent in the clear, why does the TSIG part = be > copied in a safe location? Please define what is meant by "safe location" > (Mainly for my own curiosity) > > It is a bit over-specified and has been changed. The text now reads: > > Upon receipt of > a message with exactly one correctly placed TSIG RR, a copy of the > TSIG RR is stored, and the TSIG RR is removed from the DNS Message= , > and decremented out of the DNS message header's ARCOUNT. > > > > "cannot be understood" is also quite vague. > > Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. > > > > -- Section 5.3 -- > > About rejecting request with a time signed value being earlier than the > last received value. I wonder what is the value of this behavior if there > is no 'fudge' as well... The last paragraph of this section describes thi= s > case and push the error handling to the request initiator. Any reason why > being flexible on the receiving site was not selected ? > > The fudge value is to cope with clock skew between the sender and > receiver. This won't impact on the order in which the packets are receiv= ed > by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-l= evel check. (It is > not fool-proof - a number of packets signed by the sender within a second > of one another may have the same =E2=80=9CTime Signed=E2=80=9D field.) > > Pushing the error handling to the initiation goes back to the original RF= C > 2845. > > > > =3D=3D NITS =3D=3D > > > > -- Section 4.3.2 -- > > Is " A whole and complete DNS message in wire format." a complete and > valid sentence? > > This was also pointed out by Roman Danyliw and has been addressed. > > > Other changes made during editing > > * There was no description of the contents of the =E2=80=9CError=E2=80=9D= and =E2=80=9COther Data=E2=80=9D > fields were in a request. This has now been corrected (Error is set to 0= . > The contents of =E2=80=9COther Data=E2=80=9D are stated to be undefined t= o allow for > extensions such as draft-andrews-dnsop-defeat-frag-attack.) > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000b9e36005a54179d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To follow up on Stephen's comments, a table was added to 2845bis to<= /div>
list all = the algorithms that are currently in the IANA registry,
along with=C2=A0suggestions= =C2=A0for implementation.=C2=A0 This was the first version:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirement Name
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0----------- --------= ----------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Optional =C2=A0 =C2=A0HMAC-MD5.SIG-ALG.REG.INT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0gss-tsig
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0= hmac-sha1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha224
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-sha256
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Option= al =C2=A0 =C2=A0hmac-sha384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha512

During the IESG review = (I think it was the SECDIR review), there was
a meltdown over implementing SHA-1. Bu= t SHA-1 is in use currently.=C2=A0
My suggestion was to do a variation describing i= mplementation use.=C2=A0
This is what I came up with(so blame me):=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Implementation Use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------= ----------------- -------------- ---------------
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 HMAC-MD5.SIG-ALG.= REG.INT MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 gss-tsig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECO= MMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha224 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0NOT RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256-128 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384-192 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512-256 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY

On the use side, these a= re mostly guesses.=C2=A0 =C2=A0We would love to hear
what the WG has to say about th= is.

<= /div>
thanks
tim

=
On Mon= , May 4, 2020 at 2:07 PM Stephen Morris <sa.morris8@gmail.com> wrote:

> On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain Name System Operations WG of t= he IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Secret Key Transaction Authentication for DNS (TSIG)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Francis Dupont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stephen Morris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Paul Vixie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Donald E. Eastlake 3rd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Olafur Gudmundsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Brian Wellington
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-rfc2845bis-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-05-04


The update addresses to the draft comments made during the IESG review.=C2= =A0 There were a fair number of these which led to a number of changes to t= he document.=C2=A0 These are listed below.

One significant change is that the list of acceptable algorithms has been e= xtended, and WG approval for this is sought.

Stephen




Comments from Roman Danyliw
---
> ** Section 1.3.=C2=A0 Per =E2=80=9CIn 2017, two nameservers=C2=A0 stri= ctly following that document (and the related [RFC4635]) were discovered to= have security problems related to this feature=E2=80=9D, consider providin= g a reference to the published vulnerabilities (i.e., CVE-2017-3142 and CVE= -2017-3143)

I=E2=80=99ve added these (and one other related CVE) as informative referen= ces.=C2=A0 Using just the CVE number as a reference seemed a bit spartan, s= o I=E2=80=99ve added a title to each incident. As the description of the CV= Es in Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descri= ption, which can be rather long), I=E2=80=99ve taken the title from ISC=E2= =80=99s KnowledgeBase (for the BIND CVEs) and from the Knot release notes (= for the Knot CVE).


> ** Section 6.=C2=A0 Per =E2=80=9CSHA-1 collisions have been demonstrat= ed so the MD5 security considerations apply to SHA-1 in a similar manner.= =C2=A0 Although support for hmac-sha1 in TSIG is still mandatory for compat= ibility reasons, existing uses should be replaced with hmac-sha256 or other= SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].
>
> -- It=E2=80=99s worth repeating those MD5 security considerations here=

I=E2=80=99m not really keen on doing this, since the security consideration= s in RFC 6151 cover two paragraphs and including them - or even a summary o= f them - would detract from the flow of the document.=C2=A0 However, I have= explicitly included a reference to RFC 6151 in the text.


> -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth including references to the recent SHA-1 cryptoanalysis provi= ded in the SECDIR review

Added references to just one of these papers (=E2=80=9DSHA1 is a Shambles= =E2=80=9D).=C2=A0 We=E2=80=99re not doing a general analysis of the algorit= hms, so a simple reference to a paper than describes a SHA1 collision is al= l that is needed.=C2=A0 (As an aside, the paper doesn't give the date o= f publication, so I had to search the Web looking for references to it.=C2= =A0 I think I=E2=80=99ve got the date correct, but I=E2=80=99d be grateful = for a double-check.)


> -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED).

Done - see Table 2


> ** Section 10.=C2=A0 Per =E2=80=9CFor all of the message authenticatio= n code algorithms listed in this document, those producing longer values ar= e believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR rev= iew, this could be misconstrued as the algorithm choice not the digest leng= th provides the security.=C2=A0 Recommend rephrasing (or making some statem= ent=C2=A0

I=E2=80=99ve reworded this paragraph (in section 10).=C2=A0 It now reads:
=C2=A0 "Although the strength of an algorithm determines its security,= there
=C2=A0 have been some arguments that mild truncation can strengthen a MAC b= y
=C2=A0 reducing the information available to an attacker.=C2=A0 However, ex= cessive
=C2=A0 truncation clearly weakens authentication by reducing the number of<= br> =C2=A0 bits an attacker has to try to break the authentication by brute
=C2=A0 force [RFC2104]."


> ** Editorial
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CWhen verifying an incoming messag= e, this is the message after the TSIG RR and been removed and the ARCOUNT f= ield has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (i= s missing a word).
>
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CA whole and complete DNS message = in wire format.=E2=80=9D, this isn=E2=80=99t a sentence.

Section 4.3.2 has been reworded to address these issues.



Comments from Benjamin Kaduk

> Thanks for putting together this update; it's good to see the secu= rity
> issue getting closed off in the udpated spec, and progression to full<= br> > Internet Standard!=C2=A0 I do have several substantive comments (as we= ll as
> some minor/nit-level ones), many of which are listed here at the top b= ut
> a few of which are interspersed in the per-section comments.
>
>
> I considered making this a Discuss point, but it should be pretty
> uncontroversial and I trust that the right thing will happen even if I=
> don't: there's a couple lingering remnants of SHA-1 being the<= br> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 an= d
> 10 (further detailed in the per-section comments).

The document now mentions SHA1 collisions and notes that the MD5 security c= onsiderations apply to SHA1.=C2=A0 It also mentions that support for SHA1 i= s mandatory for compatibility reasons but in existing uses it should be rep= laced by a stronger one.


> I also initially had made the following point a Discuss-level point, b= ut
> decided to not do so since I don't remember any BCP-level guidance=
> relating to cross-protocol attacks.=C2=A0 Nevertheless, I strongly enc= ourage
> the authors to consider that cryptographic best practice is to use any=
> given key with exactly one cryptographic algorithm.=C2=A0 The record f= ormat
> listed in Section 4.2 has the key name and algorithm as separately
> conveyed, which would allow for a given key to be used with all
> implemented algorithms.=C2=A0 We should include some discussion that i= t's
> best to only use a single algorithm with any given key.

The following text has been added to the Security Considerations section:
=C2=A0 "To prevent cross-algorithm attacks, there SHOULD only be one =C2=A0 =C2=A0 algorithm associated with any given key name."


> We also have a 16-bit wide field for "Fudge", which (since i= t counts
> seconds) corresponds to a maximum window of something like +/- 18 hour= s;
> it's hard to believe that we really want to give people the rope t= o
> allow for that much time skew.=C2=A0 (Yes, I understand that implement= ations
> will set something sane in practice but that doesn't necessarily m= ean
> that the protocol still has to allow it.)

That was set in the original RFC 2845.=C2=A0 Although I agree with the comm= ents, changing the size of that field would be a significant undertaking.= =C2=A0 However, section 10 does state that the RECOMMENDED fudge value in m= ost circumstances is 300 seconds.


> Our authoritative list of algorithm names (Table 1) is rather divorced=
> from the references to be consulted for the individual hash algorithms=
> to be used with the HMAC procedure.=C2=A0 The ones used here are suffi= ciently
> well-known that I'm not terribly concerned about it, though.

The first paragraph of the IANA considerations section lists the algorithms= and references to where they are described, and I didn=E2=80=99t want to d= uplicate the information.


> Abstract
>
> The title says "DNS" but maybe the body of the abstract shou= ld as well?

In the abstract, changed:

"It can be used to authenticate dynamic updates as coming from an appr= oved client"

to

"It can be used to authenticate dynamic updates to a DNS zone as comin= g from an approved client"


> Section 1.1
>
> Some of this language feels like it might not age terribly well, e.g.,=
> "this can provide" or "[t]here was a need".
>
>=C2=A0 =C2=A0addresses that need.=C2=A0 The proposal is unsuitable for = general server
>=C2=A0 =C2=A0to server authentication for servers which speak with many= other
>=C2=A0 =C2=A0servers, since key management would become unwieldy with t= he number
>=C2=A0 =C2=A0of shared keys going up quadratically.=C2=A0 But it is sui= table for many
>=C2=A0 =C2=A0resolvers on hosts that only talk to a few recursive serve= rs.

Changed to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The authentication mechanism proposed her= e provides a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple and efficient authentication between cli= ents and local servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by using shared secret keys to establish a trus= t relationship between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 two entities.=C2=A0 Such keys must be protected= in a manner similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private keys, lest a third party masquerade as = one of the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parties (by forging the MAC).=C2=A0 The proposa= l is unsuitable for general
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server to server authentication for servers whi= ch speak with many
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other servers, since key management would becom= e unwieldy with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number of shared keys going up quadratically. B= ut it is suitable for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 many resolvers on hosts that only talk to a few= recursive servers.=E2=80=9D


> Should zone transfers be mentioned here as well?

Zone transfers are mentioned in the preceding paragraph.


> Section 1.2
>
> I don't understand the motivation for changing terminology from MA= Cs to
> "signatures"; they're still MACs even though they're= transaction-based.

The mention of signatures in section 1.2 is intended as a link between the = name of the RR (TSIG or Transaction Signature) and the term MAC used in the= rest of the document.


>=C2=A0 =C2=A0MAC of the query as part of the calculation.=C2=A0 Where a= response
>=C2=A0 =C2=A0comprises multiple packets, the calculation of the MAC ass= ociated
>=C2=A0 =C2=A0with the second and subsequent packets includes in its inp= uts the MAC
>=C2=A0 =C2=A0for the preceding packet.=C2=A0 In this way it is possible= to detect any
>=C2=A0 =C2=A0interruption in the packet sequence.
>
> I suggest mentioning the lack of mechanism to detect truncation of the=
> packet sequence.

That is a fair point.=C2=A0 I=E2=80=99ve modified the last sentence to read= :

=C2=A0 =C2=A0"In this way it is possible to detect any interruption in= the packet sequence,
=C2=A0 =C2=A0although not its premature termination."


> Section 4.2
>
>=C2=A0 =C2=A0NAME=C2=A0 The name of the key used, in domain name syntax= .=C2=A0 The name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should reflect the names of the hosts= and uniquely identify the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key among a set of keys these two hos= ts may share at any given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time.=C2=A0 For example, if hosts A.s= ite.example and
> = B.example.net
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0share a key, possibilities for the ke= y name include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example, <id>= .B.ex= ample.net, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example.B= .example.net.=C2=A0 It should be possible for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than one key to be in simultaneo= us use among a set of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interacting hosts.
>
> I'd suggest adding a note along the lines of "This allows for= periodic
> key rotation per best operational practices, as well as algorithm
> agility as indicated by [BCP201].=E2=80=9D

Added.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The name may be used as a local index= to the key involved and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it is recommended that it be globally= unique.=C2=A0 Where a key is
>
> (nit?): this feels more like a "but" than an "and"= , to me.

Well spotted.=C2=A0 I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 MAC Size - an unsigned 16-bit= integer giving the length of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC field in octets.=C2=A0 Tr= uncation is indicated by a MAC size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 less than the size of the key= ed hash produced by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm specified by the Al= gorithm Name.
>
> nit: I would suggest "output size", as there are potentially= a few
> different sizes involved (key size, block size, and output size, for > starters, though I think the possibility of confusion here is low).
I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference to = this field, and the other size mentioned - that of the keyed hash is, I thi= nk, also unambiguous.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 empty unless the content of t= he Error field is BADTIME, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which case it will contain th= e server's current time as the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of seconds since 00:00= on 1970-01-01 UTC, ignoring
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leap seconds (see Section 5.2= .3).
>
> I'm slightly confused at the interplay between the explicit length= field
> and the "empty unless" directive.=C2=A0 Does this mean that = the only allowed
> values in the "Other Len" are 0 and 6?=C2=A0 Does "empt= y" mean "length-zero=E2=80=9D?

I=E2=80=99ve rewritten this slightly in a bid to make it clearer that =E2= =80=9COther Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80= =9D is zero.


> Section 4.3.1
>
>=C2=A0 =C2=A0Only included in the computation of a MAC for a response m= essage (or
>=C2=A0 =C2=A0the first message in a multi-message response), the valida= ted request
>=C2=A0 =C2=A0MAC MUST be included in the MAC computation.=C2=A0 If the = request MAC
>=C2=A0 =C2=A0failed to validate, an unsigned error message MUST be retu= rned
>=C2=A0 =C2=A0instead.=C2=A0 (Section 5.3.2).
>
> side note: while Section 5.3.2 specifies how to create an unsigned err= or
> message, it looks like Section 5.2 (and subsections lists specific
> RCODEs that are to be used.

That is the case.=C2=A0 Section 4 is a description of the TSIG RR and its f= ields.=C2=A0 Section 5 describes the contents of the fields in various situ= ations (client transmission, server reception, server transmission, client = reception).


> Section 4.3.2
>
>=C2=A0 =C2=A0When verifying an incoming message, this is the message af= ter the
>=C2=A0 =C2=A0TSIG RR and been removed and the ARCOUNT field has been de= cremented.
>=C2=A0 =C2=A0If the message ID differs from the original message ID, th= e original
>=C2=A0 =C2=A0message ID is substituted for the message ID.=C2=A0 (This = could happen,
>=C2=A0 =C2=A0for example, when forwarding a dynamic update request.) >
> I trust (based on this text having survived while going for full IS) > that there are no interesting record-keeping considerations with respe= ct
> to knowing the message ID(s) to substitute, in the "forwarding a<= br> > dynamic-update request" case, presumably since this is just the f= ield
> from the TSIG RDATA and not some externally retained state.

That is correct - the original ID is stored in the TSIG record=E2=80=99s RD= ATA and it is from there that the original ID is retrieved when a substitut= ion is made.


> Section 4.3.3
>
>=C2=A0 =C2=A0The RR RDLEN and RDATA MAC Length are not included in the = input to
>=C2=A0 =C2=A0MAC computation since they are not guaranteed to be knowab= le before
>=C2=A0 =C2=A0the MAC is generated.
>
> I appreciate that this is explicitly noted; there are some security > considerations regarding the non-inclusion of the (truncated) mac leng= th
> as input, though.=C2=A0 The local truncation policy helps here, but no= t 100%.

OK


>=C2=A0 =C2=A0For each label type, there must be a defined "Canonic= al wire format"
>
> Just to check my understanding: label types only come into play for th= e
> two fields that are in domain name syntax, key name and algorithm name= ?

There was actually an error in the text here: RFC 4034 section 6.1 is conce= rned with Canonical Name Order.=C2=A0 It is section 6.2 that details the ca= nonical wire format - I=E2=80=99ve changed the reference.

Going back to the original point, yes, that is correct.=C2=A0 Label type 00= is uncompressed name. (11 is a compressed name, and label types 01 and 10 = are discouraged - see RFC 6891 section 5).


> Section 5.1
>
>=C2=A0 =C2=A0the server.=C2=A0 This TSIG record MUST be the only TSIG R= R in the message
>=C2=A0 =C2=A0and MUST be last record in the Additional Data section.=C2= =A0 The client
>
> (Is there anything else that tries to insist on being the last record = in
> the additional data section?=C2=A0 I guess it doesn't really make = sense to
> try to Update: 1035 just to note this requirement.)

Not to our knowledge.


>=C2=A0 =C2=A0MUST store the MAC and the key name from the request while= awaiting
>=C2=A0 =C2=A0an answer.
>
> [This is going to end up alongside the request-ID that it has to store=
> already, right?]

Yes.=C2=A0 The request MAC is included as one of the components used by the= server to generate the response - which should be encoded using the same k= ey as used in the request.


>=C2=A0 =C2=A0Note that some older name servers will not accept requests= with a
>=C2=A0 =C2=A0nonempty additional data section.=C2=A0 Clients SHOULD onl= y attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> (The context in which this "SHOULD" appears makes it feel li= ke it's
> repeating an admontion from elsewhere and not the only instance of the=
> requirement, in which case a reference might be appropriate.)

I=E2=80=99ve removed this paragraph.=C2=A0 The reference to older name serv= ers is now completely out of date (it was a carry-over from the original 20= -year old text).=C2=A0 The rest of the paragraph seems superfluous - rather= like stating that TCP clients should only connect to servers that support = TCP.=C2=A0


> Section 5.2
>
>=C2=A0 =C2=A0If the TSIG RR cannot be understood, the server MUST regar= d the
>=C2=A0 =C2=A0message as corrupt and return a FORMERR to the server.=C2= =A0 Otherwise the
>=C2=A0 =C2=A0server is REQUIRED to return a TSIG RR in the response. >
> As written, this could be read as an attempt to make a normative
> requirement of servers that do not implement this spec.=C2=A0 Presumab= ly it's
> just restating a requirement of the core protocol, though?

It is the core protocol.

I see your point though.=C2=A0 However, by implication we are talking about= a server that implements TSIG.


> Section 5.2.2
>
>=C2=A0 =C2=A0Using the information in the TSIG, the server should verif= y the MAC
>=C2=A0 =C2=A0by doing its own calculation and comparing the result with= the MAC
>=C2=A0 =C2=A0received.=C2=A0 If the MAC fails to verify, the server MUS= T generate an
>
> Is there any other way to verify the MAC?=C2=A0 (Should this be a &quo= t;MUST
> verify=E2=80=9D?)

Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed.


> Section 5.2.2.1
>
>=C2=A0 =C2=A0When space is at a premium and the strength of the full le= ngth of a
>=C2=A0 =C2=A0MAC is not needed, it is reasonable to truncate the keyed = hash and
>=C2=A0 =C2=A0use the truncated value for authentication.=C2=A0 HMAC SHA= -1 truncated to
>=C2=A0 =C2=A096 bits is an option available in several IETF protocols, = including
>=C2=A0 =C2=A0IPsec and TLS.
>
> Also Kerberos, where it was the strongest option for a while and we ha= d
> to define a new encryption type to provide a better option (RFC 8009).=
>
> This text seems to be implying that HMAC SHA-1 truncated to 96 bits is= a
> recommendable option, which is ... far from clear.=C2=A0 I'd prefe= r to have a
> note that this specific truncation was appropriate when initially
> specified but may not provide a security level appropriate for all cas= es
> in the modern environment, or preferrably to just change the reference=
> to (e.g.) SHA-384-192 or SHA-256-128.

Added the following an the end of the paragraph:

=C2=A0 However, while this option is kept for backwards compatibility,
=C2=A0 it may not provide a security level appropriate for all cases
=C2=A0 in the modern environment. In these cases, it is preferable to
=C2=A0 use a hashing algorithm such as SHA-256-128, SHA-384-192
=C2=A0 or SHA-256-128 [RFC4868].

I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D, = =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80=9D as = optional algorithms to the algorithm table.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is sent when the signer has truncated t= he keyed hash output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to an allowable length, as described in [RFC= 2104], taking initial
>=C2=A0 =C2=A0 =C2=A0 =C2=A0octets and discarding trailing octets.=C2=A0= TSIG truncation can only
>
> (Or when an on-path attacker has performed truncation.)

True, but an on-path attacker can manipulate the message in any way possibl= e.=C2=A0 I=E2=80=99m not sure whether adding this caveat will add anything = to the document.


> Section 5.2.3
>
>=C2=A0 =C2=A0(BADTIME).=C2=A0 The server SHOULD also cache the most rec= ent time signed
>=C2=A0 =C2=A0value in a message generated by a key, and SHOULD return B= ADTIME if a
>=C2=A0 =C2=A0message received later has an earlier time signed value.= =C2=A0 A response
>
> (But there's no fudge factor on this check, other than the inheren= t
> limit of seconds granularity, as alluded to by the last paragraph of > this section?)

The last paragraph in the section states that handling this issue should be= left up to implementations and that the exact method (and by implication, = the size of the fudge factor) be determined by the implementation themselve= s.=C2=A0


> Section 5.3.1
>
>=C2=A0 =C2=A0A zone transfer over a DNS TCP session can include multipl= e DNS
>=C2=A0 =C2=A0messages.=C2=A0 Using TSIG on such a connection can protec= t the connection
>=C2=A0 =C2=A0from hijacking and provide data integrity.=C2=A0 The TSIG = MUST be included
>
> (I assume that "hijacking TCP" means a sequence-number-guess= ing attack
> that would require the attacker to be winning the race against the
> legitimate sender to cause modified data to be introduced into the TCP=
> stream?=C2=A0 This is maybe not the best word to use for such a case.)=

I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D.<= br>

>=C2=A0 =C2=A0on all DNS messages in the response.=C2=A0 For backward co= mpatibility, a
>=C2=A0 =C2=A0client which receives DNS messages and verifies TSIG MUST = accept up
>=C2=A0 =C2=A0to 99 intermediary messages without a TSIG.=C2=A0 The firs= t message is
>
> (side note: I'm kind of curious what such compatibility is needed = with.
> Also, this gives an attacker some flexibility into which to incorporat= e
> a collision, though given the near-real-time constraints and the
> strength of the HMAC construction I don't expect any practical imp= act.)

The original RFC 2845 did not require all packets in a message stream to co= ntain a TSIG, it just stated that there be no more than 99 intermediary mes= sages without a TSIG (presumably to cut down on the overhead required in me= ssage calculations - remember that RFC 2845 was published 20 years ago).=C2= =A0 Although many DNS implementations now add a TSIG to every message, it i= s by no means certain that all do. (In fact, less than three years ago, a b= ug was introduced into BIND, causing it to require that all packets in a zo= ne transfer would contain a TSIG.=C2=A0 A fix allowing BIND to accept up to= 99 packets between signed ones was released shortly afterwards after repor= ts were received of zone transfers failing.)


> Section 5.3.2
>
>=C2=A0 =C2=A0 =C2=A0 Request MAC (if the request MAC validated)
>=C2=A0 =C2=A0 =C2=A0 DNS Message (response)
>=C2=A0 =C2=A0 =C2=A0 TSIG Variables (response)
>
>=C2=A0 =C2=A0The reason that the request is not included in this MAC in= some cases
>=C2=A0 =C2=A0is to make it possible for the client to verify the error.= =C2=A0 If the
>=C2=A0 =C2=A0error is not a TSIG error the response MUST be generated a= s specified
>=C2=A0 =C2=A0in Section 5.3.
>
> This makes it sound like the server excludes the request MAC from the<= br> > digest if it failed to validate (something the client cannot predict),=
> so that the client must perform trial verification of both versions in=
> order to validate the response.=C2=A0 Is that correct?

No.=C2=A0 If the incoming MAC failed to validate, the server should send ba= ck an unsigned response (MAC size =3D=3D 0 and empty MAC).


> Also, I think that the "in some cases" is not properly place= d: as-is, it
> says that the request (not request MAC) is sometimes not included
> (implying that sometimes it is), which does not match up with the
> specification for the digest components.=C2=A0 I presume that the inte= nt is
> to say that in some cases the client could not verify the error, if th= e
> request itself was always included in the digest.

Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D.

If the MAC could not be verified, it is possible that it was corrupted, whi= ch would prevent the client verifying the response. But a major reason is t= hat an incorrect MAC included in a signed response led to the CVEs that pro= mpted this document update.


> Section 5.4.1
>
>=C2=A0 =C2=A0If an RCODE on a response is 9 (NOTAUTH), but the response= TSIG
>=C2=A0 =C2=A0validates and the TSIG key recognised by the client but di= fferent
>=C2=A0 =C2=A0from that used on the request, then this is a Key Error.= =C2=A0 The client
>
> nits: missing words "key is recognized" and "but is dif= ferent=E2=80=9D

It now reads =E2=80=9Ckey is recognized but different"


> Section 5.5
>
>=C2=A0 =C2=A0destination or the next forwarder.=C2=A0 If no transaction= security is
>=C2=A0 =C2=A0available to the destination and the message is a query th= en, if the
>=C2=A0 =C2=A0corresponding response has the AD flag (see [RFC4035]) set= , the
>=C2=A0 =C2=A0forwarder MUST clear the AD flag before adding the TSIG to= the
>=C2=A0 =C2=A0response and returning the result to the system from which= it
>=C2=A0 =C2=A0received the query.
>
> Is there anything to say about the CD bit?=C2=A0 (It's independent= crypto, so
> I don't expect so, but it seems worth checking.)

No.=C2=A0 CD is just a mechanism by which a client can request that the ser= ver not do DNSSEC signature validation on the data and so allow the client = to receive the data instead of a SERVFAIL response.


> Section 6
>
>=C2=A0 =C2=A0The only message digest algorithm specified in the first v= ersion of
>=C2=A0 =C2=A0these specifications [RFC2845] was "HMAC-MD5" (s= ee [RFC1321],
>=C2=A0 =C2=A0[RFC2104]).=C2=A0 Although a review of its security [RFC61= 51] concluded
>=C2=A0 =C2=A0that "it may not be urgent to remove HMAC-MD5 from th= e existing
>=C2=A0 =C2=A0protocols", with the availability of more secure alte= rnatives the
>=C2=A0 =C2=A0opportunity has been taken to make the implementation of t= his
>=C2=A0 =C2=A0algorithm optional.
>
> It seems worth noting that the advice from RFC 6151 is already nine > years old.

I=E2=80=99ve use the phrasing "Although a review of its security some = years ago=E2=80=9D.


>=C2=A0 =C2=A0[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS1= 80-4],
>=C2=A0 =C2=A0[RFC3174].=C2=A0 SHA-1 collisions have been demonstrated s= o the MD5
>=C2=A0 =C2=A0security considerations apply to SHA-1 in a similar manner= .=C2=A0 Although
>
> I'd consider referencing (e.g.)
> s= hattered.io
> for the "collisions have
> been demonstrated" claim, though it's pretty optional.

A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D paper= .


>=C2=A0 =C2=A0support for hmac-sha1 in TSIG is still mandatory for compa= tibility
>=C2=A0 =C2=A0reasons, existing uses should be replaced with hmac-sha256= or other
>=C2=A0 =C2=A0SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].=
>
> Is this "sha1 mandatory for compatibility" going to age well= ?=C2=A0 If we
> have two implementations that can operate with sha2 variants, is it > required to keep this as mandatory (vs. optional with a note about
> deployed reality at time of publication) for progression to Internet > Standard?

This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2=80= =9D column in RFC4635 (from which Table 2 was derived) into =E2=80=9CImplem= entation=E2=80=9D and =E2=80=9CUse=E2=80=9D.=C2=A0 SHA1 is required to be i= mplemented (for backwards compatibility) but its use is not recommended.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Op= tional=C2=A0 =C2=A0 hmac-sha224
>
> It's not clear there's much reason to keep this around, or if = we do, it
> could probably be "not recommended".=C2=A0 (I assume that ju= st dropping it
> entirely makes things annoying w.r.t. the IANA registry.)

It has been left in for compatibility reasons, but its use is not recommend= ed.


> Section 9
>
>=C2=A0 =C2=A0Previous specifications [RFC2845] and [RFC4635] defined va= lues for
>=C2=A0 =C2=A0HMAC MD5 and SHA.=C2=A0 IANA has also registered "gss= -tsig" as an
>
> I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied gr= ouping where
> HMAC qualifies both hash algorithms is not terribly clear.

Changed to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Previous specifications [RFC2845] and [RFC4635]= defined names for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the HMAC-MD5 and the various HMAC-SHA algorithm= s.


> Section 10
>
> I suggest some discussion that the way truncation policy works, an
> attackers ability to forge messages accepted as valid is limited by th= e
> amount of truncation that the recipient is willing to accept, not the<= br> > amount of truncation used to generate messages by the legitimate sende= r.

I think this is already taken care of by the reference to a local policy in= the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.2.4).=


> There's also some fairly standard content to put in here about all= owing
> for an unsigned error response to a signed request, so an attacker (ev= en
> off-path) can spoof such resposnes.=C2=A0 (Section 5.4 indicates that = the
> client should continue to wait if it gets such a thing, which helps a<= br> > lot.)

I=E2=80=99ve just added text that an unsigned response is not considered ac= ceptable because can be subject to spoofing and manipulation.


>=C2=A0 =C2=A0TKEY [RFC2930].=C2=A0 Secrets SHOULD NOT be shared by more= than two
>=C2=A0 =C2=A0entities.
>
> I suggest adding "; any such additional sharing would allow any p= arty
> knowing the key to impersonate any other such party to members of the<= br> > group=E2=80=9D.

Added.


>=C2=A0 =C2=A0A fudge value that is too large may leave the server open = to replay
>=C2=A0 =C2=A0attacks.=C2=A0 A fudge value that is too small may cause f= ailures if
>=C2=A0 =C2=A0machines are not time synchronized or there are unexpected= network
>=C2=A0 =C2=A0delays.=C2=A0 The RECOMMENDED value in most situations is = 300 seconds.
>
> Our experience with kerberos in modern network environments has shown<= br> > that 5 minutes is much larger than needed, though it's not clear t= here's
> a strong need to change this recommendation right now.

The value is recommended (and even then, only in =E2=80=9Cmost situations= =E2=80=9D), so implementations are free to set their own value.=C2=A0 Howev= er, any guidance as to typical time skews measured across a network would b= e useful in a number of protocols.


>=C2=A0 =C2=A0Significant progress has been made recently in cryptanalys= is of hash
>=C2=A0 =C2=A0functions of the types used here.=C2=A0 While the results = so far should
>=C2=A0 =C2=A0not affect HMAC, the stronger SHA-1 and SHA-256 algorithms= are being
>=C2=A0 =C2=A0made mandatory as a precaution.
>
> Please revise this note to not imply that SHA-1 is considered "st= rong=E2=80=9D.

Text revised to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Significant progress has been made recently in = cryptanalysis of hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 functions of the types used here.=C2=A0 While t= he results so far should not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affect HMAC, the stronger SHA-256 algorithm is = being made mandatory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a precaution.


> Section 11.2
>
> I'm not sure why RFC 2104 is listed as informative.

RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a pos= sible downref if the reference is placed in the =E2=80=9CNormative=E2=80=9D= section.



Comments from Mirja K=C3=BChlewind

> I only had limited time for a quick review of this document, so I migh= t not be aware of all the needed background and details. Still I have two q= uick questions on retries:
>
> 1) Sec 5.2.3:
> "Implementations should be aware
>=C2=A0 =C2=A0of this possibility and be prepared to deal with it, e.g. = by
>=C2=A0 =C2=A0retransmitting the rejected request with a new TSIG once o= utstanding
>=C2=A0 =C2=A0requests have completed or the time given by their time si= gned plus
>=C2=A0 =C2=A0fudge value has passed."
> I might not be aware of all protocol details and maybe this is already= specified somewhere: While unlikely, it is possible that a request might b= e retransmitted multiple times, as that could cause president congestion ov= er time, it's always good practice to define a maximum number of retran= smissions. If that is already defined somewhere, maybe adding a note/pointe= r would be good as well.

If someone can suggest a suitable number (and a reason for it), we can cons= ider doing this.=C2=A0 In the meantime, I=E2=80=99ve merely stated that imp= lementation should limit the number of retransmissions and so leave the cho= ice up to the implementation.


> 2) Sec 5.3.1:
> "=C2=A0 =C2=A0This allows the client to rapidly detect when the s= ession has been
>=C2=A0 =C2=A0altered; at which point it can close the connection and re= try."
> When (immediately or after some waiting time) should the client retry = and how often?

I think that should be down to the implementation to decide.


> You further say
> "The client SHOULD treat this the
>=C2=A0 =C2=A0same way as they would any other interrupted transfer (alt= hough the
>=C2=A0 =C2=A0exact behavior is not specified here)."
> Where is that specified? Can you provide a pointer in the text?

That was a mistake in transcribing the original RFC2845 text.=C2=A0 The fin= al word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client SHOULD treat this the same way as th= ey would any other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interrupted transfer (although the exact behavi= or is not specified).


> 3) Sec 8.=C2=A0 Shared Secrets: Would it be appropriate to use more no= rmative language here? There are a bunch of lower case shoulds in this sect= ion; is that on purpose?

The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is ver= y general security advice.=C2=A0 Although this is something users ought to = do, it is not really a specific recommendation.



Comments from Barry Leiba

> =E2=80=94 Section 4.2 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>
> Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits?=C2= =A0 If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is = always 6?=C2=A0 If so, then shouldn=E2=80=99t it say that?=C2=A0 If not, th= en what don=E2=80=99t I understand?

Benjamin Kaduk also made the same comment, it has been addressed above.


> =E2=80=94 Section 5.1 =E2=80=94
>
>=C2=A0 =C2=A0Clients SHOULD only attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> Why SHOULD and not MUST?

Benjamin Kaduk also noted an issue here.=C2=A0 The paragraph has been remov= ed.


> =E2=80=94 Section 5.3.2 =E2=80=94
>
>=C2=A0 =C2=A0The server SHOULD also cache the most recent time signed >=C2=A0 =C2=A0value in a message generated by a key
>
> I tripped over this until I realized you mean =E2=80=9CTime Signed val= ue=E2=80=9D.=C2=A0 You capitalize it elsewhere, and it helps the parsing if= it=E2=80=99s consistent. There are four uncapitalized instances in this se= ction.

=E2=80=9Ctime signed=E2=80=9D has been capitalised.=C2=A0 In addition, in t= he description of the field, =E2=80=9Ctims signed=E2=80=9D has been replace= d with =E2=80=9Ctime the message was signed=E2=80=9D.

Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9CFu= dge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2=80=9D h= ave not been capitalised, as the context of that is that it is referring to= the contents of the Fudge field). Also, =E2=80=9Cother data=E2=80=9D and = =E2=80=9Cother data length=E2=80=9D have been replaced with the (capitalise= d) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COther Len=E2=80= =9D.


> =E2=80=94 Section 9 =E2=80=94
>
>=C2=A0 =C2=A0There is no structure
>=C2=A0 =C2=A0required other than names for different algorithms must be= unique
>=C2=A0 =C2=A0when compared as DNS names, i.e., comparison is case insen= sitive.
>
> I found this sentence to be really awkward and hard to parse.=C2=A0 Ma= y I suggest this?:
>
> NEW
> There is no structure to the names, and algorithm names are compared a= s if they were DNS names (the comparison is case-insensitive).
> END
>
> I don=E2=80=99t think you really need to say that each name is differe= nt/unique, right?

Agreed.=C2=A0 The text has been changed to that suggested.


>=C2=A0 =C2=A0other algorithm
>=C2=A0 =C2=A0names are simple (i.e., single-component) names.
>
> Nitty thing that you can completely ignore, but I would avoid the Lati= n abbreviation thus: =E2=80=9Cother algorithm names are simple, single-comp= onent names.=E2=80=9D

Changed.



Comments from =C3=89ric Vyncke

> Thank you for the work put into this document. It is clear and easy to= read.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will = be appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -=C3=A9ric
>
> =3D=3D COMMENTS =3D=3D
>
> There are 6 authors while the usual procedure is to limit to 5 authors= . Personally, I do not care.
>
> -- Section 1.3 --
> It is a little unclear to me whether the "two nameservers" w= ere two implementations or two actual DNS servers.

Agreed, it was unclear.=C2=A0 Changed to =E2=80=9Ctwo name server implement= ations=E2=80=9D.


> -- Section 5.2 --
> Suggest to provide some justifications about "copied to a safe lo= cation": the DNS message was sent in the clear, why does the TSIG part= be copied in a safe location? Please define what is meant by "safe lo= cation" (Mainly for my own curiosity)

It is a bit over-specified and has been changed.=C2=A0 The text now reads:<= br>
=C2=A0 =C2=A0 =C2=A0 Upon receipt of
=C2=A0 =C2=A0 =C2=A0 =C2=A0a message with exactly one correctly placed TSIG= RR, a copy of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TSIG RR is stored, and the TSIG RR is removed fr= om the DNS Message,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and decremented out of the DNS message header= 9;s ARCOUNT.


> "cannot be understood" is also quite vague.

Changed to =E2=80=9Ccannot be interpreted=E2=80=9D.


> -- Section 5.3 --
> About rejecting request with a time signed value being earlier than th= e last received value. I wonder what is the value of this behavior if there= is no 'fudge' as well... The last paragraph of this section descri= bes this case and push the error handling to the request initiator. Any rea= son why being flexible on the receiving site was not selected ?

The fudge value is to cope with clock skew between the sender and receiver.= =C2=A0 This won't impact on the order in which the packets are received= by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-le= vel check. (It is not fool-proof - a number of packets signed by the sender= within a second of one another may have the same =E2=80=9CTime Signed=E2= =80=9D field.)

Pushing the error handling to the initiation goes back to the original RFC = 2845.


> =3D=3D NITS =3D=3D
>
> -- Section 4.3.2 --
> Is " A whole and complete DNS message in wire format." a com= plete and valid sentence?

This was also pointed out by Roman Danyliw and has been addressed.


Other changes made during editing

* There was no description of the contents of the =E2=80=9CError=E2=80=9D a= nd =E2=80=9COther Data=E2=80=9D fields were in a request.=C2=A0 This has no= w been corrected (Error is set to 0. The contents of =E2=80=9COther Data=E2= =80=9D are stated to be undefined to allow for extensions such as draft-and= rews-dnsop-defeat-frag-attack.)



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000b9e36005a54179d2-- From nobody Sat May 9 18:58:16 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E43C13A0D00; Sat, 9 May 2020 18:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158907589383.25416.1678100657116602252@ietfa.amsl.com> Date: Sat, 09 May 2020 18:58:13 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-pusateri-dnsop-update-timeout-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 01:58:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS TIMEOUT Resource Record Authors : Tom Pusateri Tim Wattenberg Filename : draft-pusateri-dnsop-update-timeout-05.txt Pages : 18 Date : 2020-05-09 Abstract: This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records. It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-05 https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 10 00:50:36 2020 Return-Path: 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 C14523A0598; Sun, 10 May 2020 00:50:33 -0700 (PDT) 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 THjoh-0HyiPT; Sun, 10 May 2020 00:50:30 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id CFE8D3A0791; Sun, 10 May 2020 00:50:28 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 040285F40778; Sun, 10 May 2020 07:50:26 +0000 (UTC) Received: from [172.19.191.18] (p4FC211E0.dip0.t-ipconnect.de [79.194.17.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id A5EA85F40389; Sun, 10 May 2020 07:50:25 +0000 (UTC) From: "Ralf Weber" To: dnsop Cc: dnsop-chairs Date: Sun, 10 May 2020 09:50:24 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <1E69C775-0D43-48D6-A57D-5865C4A046B7@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 07:50:34 -0000 Moin! On 4 May 2020, at 21:08, Tim Wicinski wrote: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requ= irements/ > > > Please review this draft to see if you think it is suitable for = > adoption > by DNSOP, and comments to the list, clearly stating your view. I support adaption, will review and may contribute text. So long -Ralf =E2=80=94-- Ralf Weber From nobody Sun May 10 21:29:10 2020 Return-Path: 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 1C6573A074B for ; Sun, 10 May 2020 21:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 HLuGFHxoRYXs for ; Sun, 10 May 2020 21:29:03 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 B328B3A005F for ; Sun, 10 May 2020 21:29:02 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id b71so328215ilg.8 for ; Sun, 10 May 2020 21:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zwf4G4cly/V/Y3urw26FRvSKz42RWXffh7B4ZTo3Rgs=; b=cJsY44APBG3Dt0uDqmT3cs2DywyX7vIjkqsvKnhylBFUG4m474E0SJ5Ahha62xltW7 XY72G/na6hy/f7WHyQIEBBJSkMbyYWw5wOGBQyYxkgidvx3a1SIOLx4c6DathbYfhhkc fKhDpa62hhxzds/TG+BrDiwSzsSlziTSBWvZmDCPtxQhovA6VzGchc5fRApUjyFMooWL OP4q4r+TNceeHiOllvWqoto2yYUGx5nxt5lKbuDeSvsHiedEu2mzr8Tkdh+hUoBgmr61 ZwckNDoTGKhXcXYJM61KFBhxj9p5AarRPl1OPJN6/3ncRGAOD0cCaMjn4rVqGLK0F7UC MJ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zwf4G4cly/V/Y3urw26FRvSKz42RWXffh7B4ZTo3Rgs=; b=SjeLUDyAprX4W6jw0OMNCunq6keVbIjEA8GqnpAjY+0c3ZpyrMxpbxTGPswtxlc1T7 H2CGLHQmChsRsvZvbWi8QCdXpBzmZjI/h5jM8/LbGppIYf1yYMT5eLQSRflm6qqKO1Hy tenVaW14Q8X9hPSaA4guJNohdiPjeCNWXXewvXxSwv/H2hGOnI51eJhLpSwNdbzANi+5 8C44nJxL6U4zc4BTl7+6OeIqzFCBt37hHRfWHxp2fSAE+A08fqNFn+TYLLuysSvu901/ dhs5dy4c3kiOPF5EvhN4dMitWP7PyLP/QnO4IQ548trJE1oT/bNk0/KvhKQYm2vV5Qy3 JZhQ== X-Gm-Message-State: AGi0PuYyNaQyxrhgb/5mqbiNhoKrbKPXF6PNdnTsFEHK3Jzt4n7fAOuU Qq6y0TkN1IKoQUBkRPfW/qcn+ywpXwoXwXXD0Hs= X-Google-Smtp-Source: APiQypLoONzKhaep+KdUM4Jxgb9yJnNJ1mvsM4N7eWzS48tfgRF6jvmJeXyp/PAYicgfbDf3ztNji2ghMZN5UBz5VJk= X-Received: by 2002:a92:c7d2:: with SMTP id g18mr4149776ilk.168.1589171341769; Sun, 10 May 2020 21:29:01 -0700 (PDT) MIME-Version: 1.0 References: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> In-Reply-To: From: Donald Eastlake Date: Mon, 11 May 2020 00:28:50 -0400 Message-ID: To: Tim Wicinski Cc: Stephen Morris , dnsop Content-Type: multipart/alternative; boundary="00000000000050413405a557c9e1" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 04:29:09 -0000 --00000000000050413405a557c9e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The incremental effort to implement SHA-224 if you are implementing SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use and you can use SHA-256 with truncation to 224 or even fewer bits. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sat, May 9, 2020 at 9:52 PM Tim Wicinski wrote: > To follow up on Stephen's comments, a table was added to 2845bis to > list all the algorithms that are currently in the IANA registry, > along with suggestions for implementation. This was the first version: > > Requirement Name > ----------- ------------------------ > Optional HMAC-MD5.SIG-ALG.REG.INT > Optional gss-tsig > Mandatory hmac-sha1 > Optional hmac-sha224 > Mandatory hmac-sha256 > Optional hmac-sha384 > Optional hmac-sha512 > > During the IESG review (I think it was the SECDIR review), there was > a meltdown over implementing SHA-1. But SHA-1 is in use currently. > My suggestion was to do a variation describing implementation use. > This is what I came up with(so blame me): > > Name Implementation Use > ------------------------ -------------- --------------- > HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT > gss-tsig MAY MAY > hmac-sha1 MUST NOT RECOMMENDED > hmac-sha224 MAY NOT RECOMMENDED > hmac-sha256 MUST RECOMMENDED > hmac-sha256-128 MAY MAY > hmac-sha384 MAY MAY > hmac-sha384-192 MAY MAY > hmac-sha512 MAY MAY > hmac-sha512-256 MAY MAY > > On the use side, these are mostly guesses. We would love to hear > what the WG has to say about this. > > thanks > tim > > > On Mon, May 4, 2020 at 2:07 PM Stephen Morris > wrote: > >> >> > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Domain Name System Operations WG of >> the IETF. >> > >> > Title : Secret Key Transaction Authentication for DNS >> (TSIG) >> > Authors : Francis Dupont >> > Stephen Morris >> > Paul Vixie >> > Donald E. Eastlake 3rd >> > Olafur Gudmundsson >> > Brian Wellington >> > Filename : draft-ietf-dnsop-rfc2845bis-08.txt >> > Pages : 29 >> > Date : 2020-05-04 >> >> >> The update addresses to the draft comments made during the IESG review. >> There were a fair number of these which led to a number of changes to th= e >> document. These are listed below. >> >> One significant change is that the list of acceptable algorithms has bee= n >> extended, and WG approval for this is sought. >> >> Stephen >> >> >> >> >> Comments from Roman Danyliw >> --- >> > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly follo= wing that >> document (and the related [RFC4635]) were discovered to have security >> problems related to this feature=E2=80=9D, consider providing a referenc= e to the >> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) >> >> I=E2=80=99ve added these (and one other related CVE) as informative refe= rences. >> Using just the CVE number as a reference seemed a bit spartan, so I=E2= =80=99ve >> added a title to each incident. As the description of the CVEs in Mitre= =E2=80=99s >> database don=E2=80=99t contain a title (only a description, which can be= rather >> long), I=E2=80=99ve taken the title from ISC=E2=80=99s KnowledgeBase (fo= r the BIND CVEs) >> and from the Knot release notes (for the Knot CVE). >> >> >> > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated so= the MD5 >> security considerations apply to SHA-1 in a similar manner. Although >> support for hmac-sha1 in TSIG is still mandatory for compatibility reaso= ns, >> existing uses should be replaced with hmac-sha256 or other SHA-2 digest >> algorithms [FIPS180-4], [RFC3874], [RFC6234]. >> > >> > -- It=E2=80=99s worth repeating those MD5 security considerations here >> >> I=E2=80=99m not really keen on doing this, since the security considerat= ions in >> RFC 6151 cover two paragraphs and including them - or even a summary of >> them - would detract from the flow of the document. However, I have >> explicitly included a reference to RFC 6151 in the text. >> >> >> > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth >> including references to the recent SHA-1 cryptoanalysis provided in the >> SECDIR review >> >> Added references to just one of these papers (=E2=80=9DSHA1 is a Shamble= s=E2=80=9D). >> We=E2=80=99re not doing a general analysis of the algorithms, so a simpl= e reference >> to a paper than describes a SHA1 collision is all that is needed. (As a= n >> aside, the paper doesn't give the date of publication, so I had to searc= h >> the Web looking for references to it. I think I=E2=80=99ve got the date= correct, >> but I=E2=80=99d be grateful for a double-check.) >> >> >> > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). >> >> Done - see Table 2 >> >> >> > ** Section 10. Per =E2=80=9CFor all of the message authentication cod= e >> algorithms listed in this document, those producing longer values are >> believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR re= view, this could be >> misconstrued as the algorithm choice not the digest length provides the >> security. Recommend rephrasing (or making some statement >> >> I=E2=80=99ve reworded this paragraph (in section 10). It now reads: >> >> "Although the strength of an algorithm determines its security, there >> have been some arguments that mild truncation can strengthen a MAC by >> reducing the information available to an attacker. However, excessive >> truncation clearly weakens authentication by reducing the number of >> bits an attacker has to try to break the authentication by brute >> force [RFC2104]." >> >> >> > ** Editorial >> > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message, th= is is the >> message after the TSIG RR and been removed and the ARCOUNT field has bee= n >> decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (is missing a= word). >> > >> > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in wi= re >> format.=E2=80=9D, this isn=E2=80=99t a sentence. >> >> Section 4.3.2 has been reworded to address these issues. >> >> >> >> Comments from Benjamin Kaduk >> >> > Thanks for putting together this update; it's good to see the security >> > issue getting closed off in the udpated spec, and progression to full >> > Internet Standard! I do have several substantive comments (as well as >> > some minor/nit-level ones), many of which are listed here at the top b= ut >> > a few of which are interspersed in the per-section comments. >> > >> > >> > I considered making this a Discuss point, but it should be pretty >> > uncontroversial and I trust that the right thing will happen even if I >> > don't: there's a couple lingering remnants of SHA-1 being the >> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 an= d >> > 10 (further detailed in the per-section comments). >> >> The document now mentions SHA1 collisions and notes that the MD5 securit= y >> considerations apply to SHA1. It also mentions that support for SHA1 is >> mandatory for compatibility reasons but in existing uses it should be >> replaced by a stronger one. >> >> >> > I also initially had made the following point a Discuss-level point, b= ut >> > decided to not do so since I don't remember any BCP-level guidance >> > relating to cross-protocol attacks. Nevertheless, I strongly encourag= e >> > the authors to consider that cryptographic best practice is to use any >> > given key with exactly one cryptographic algorithm. The record format >> > listed in Section 4.2 has the key name and algorithm as separately >> > conveyed, which would allow for a given key to be used with all >> > implemented algorithms. We should include some discussion that it's >> > best to only use a single algorithm with any given key. >> >> The following text has been added to the Security Considerations section= : >> >> "To prevent cross-algorithm attacks, there SHOULD only be one >> algorithm associated with any given key name." >> >> >> > We also have a 16-bit wide field for "Fudge", which (since it counts >> > seconds) corresponds to a maximum window of something like +/- 18 hour= s; >> > it's hard to believe that we really want to give people the rope to >> > allow for that much time skew. (Yes, I understand that implementation= s >> > will set something sane in practice but that doesn't necessarily mean >> > that the protocol still has to allow it.) >> >> That was set in the original RFC 2845. Although I agree with the >> comments, changing the size of that field would be a significant >> undertaking. However, section 10 does state that the RECOMMENDED fudge >> value in most circumstances is 300 seconds. >> >> >> > Our authoritative list of algorithm names (Table 1) is rather divorced >> > from the references to be consulted for the individual hash algorithms >> > to be used with the HMAC procedure. The ones used here are sufficient= ly >> > well-known that I'm not terribly concerned about it, though. >> >> The first paragraph of the IANA considerations section lists the >> algorithms and references to where they are described, and I didn=E2=80= =99t want to >> duplicate the information. >> >> >> > Abstract >> > >> > The title says "DNS" but maybe the body of the abstract should as well= ? >> >> In the abstract, changed: >> >> "It can be used to authenticate dynamic updates as coming from an >> approved client" >> >> to >> >> "It can be used to authenticate dynamic updates to a DNS zone as coming >> from an approved client" >> >> >> > Section 1.1 >> > >> > Some of this language feels like it might not age terribly well, e.g., >> > "this can provide" or "[t]here was a need". >> > >> > addresses that need. The proposal is unsuitable for general server >> > to server authentication for servers which speak with many other >> > servers, since key management would become unwieldy with the number >> > of shared keys going up quadratically. But it is suitable for many >> > resolvers on hosts that only talk to a few recursive servers. >> >> Changed to: >> >> "The authentication mechanism proposed here provides a >> simple and efficient authentication between clients and local >> servers >> by using shared secret keys to establish a trust relationship >> between >> two entities. Such keys must be protected in a manner similar t= o >> private keys, lest a third party masquerade as one of the intend= ed >> parties (by forging the MAC). The proposal is unsuitable for >> general >> server to server authentication for servers which speak with man= y >> other servers, since key management would become unwieldy with t= he >> number of shared keys going up quadratically. But it is suitable >> for >> many resolvers on hosts that only talk to a few recursive >> servers.=E2=80=9D >> >> >> > Should zone transfers be mentioned here as well? >> >> Zone transfers are mentioned in the preceding paragraph. >> >> >> > Section 1.2 >> > >> > I don't understand the motivation for changing terminology from MACs t= o >> > "signatures"; they're still MACs even though they're transaction-based= . >> >> The mention of signatures in section 1.2 is intended as a link between >> the name of the RR (TSIG or Transaction Signature) and the term MAC used= in >> the rest of the document. >> >> >> > MAC of the query as part of the calculation. Where a response >> > comprises multiple packets, the calculation of the MAC associated >> > with the second and subsequent packets includes in its inputs the MA= C >> > for the preceding packet. In this way it is possible to detect any >> > interruption in the packet sequence. >> > >> > I suggest mentioning the lack of mechanism to detect truncation of the >> > packet sequence. >> >> That is a fair point. I=E2=80=99ve modified the last sentence to read: >> >> "In this way it is possible to detect any interruption in the packet >> sequence, >> although not its premature termination." >> >> >> > Section 4.2 >> > >> > NAME The name of the key used, in domain name syntax.. The name >> > should reflect the names of the hosts and uniquely identify th= e >> > key among a set of keys these two hosts may share at any given >> > time. For example, if hosts A.site.example and >> > B.example.net >> > >> > share a key, possibilities for the key name include >> > .A.site.example, ..B.example.net, and >> > .A.site.example.B..example.net >> . It should be possible for >> > more than one key to be in simultaneous use among a set of >> > interacting hosts. >> > >> > I'd suggest adding a note along the lines of "This allows for periodic >> > key rotation per best operational practices, as well as algorithm >> > agility as indicated by [BCP201].=E2=80=9D >> >> Added. >> >> >> > The name may be used as a local index to the key involved and >> > it is recommended that it be globally unique. Where a key is >> > >> > (nit?): this feels more like a "but" than an "and", to me. >> >> Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than =E2=80= =9Cand=E2=80=9D >> >> >> > * MAC Size - an unsigned 16-bit integer giving the length of >> > MAC field in octets. Truncation is indicated by a MAC size >> > less than the size of the keyed hash produced by the >> > algorithm specified by the Algorithm Name. >> > >> > nit: I would suggest "output size", as there are potentially a few >> > different sizes involved (key size, block size, and output size, for >> > starters, though I think the possibility of confusion here is low). >> >> I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference = to this field, >> and the other size mentioned - that of the keyed hash is, I think, also >> unambiguous. >> >> >> > * Other Len - an unsigned 16-bit integer specifying the lengt= h >> > of the "Other Data" field in octets. >> > >> > * Other Data - this unsigned 48-bit integer field will be >> > empty unless the content of the Error field is BADTIME, in >> > which case it will contain the server's current time as the >> > number of seconds since 00:00 on 1970-01-01 UTC, ignoring >> > leap seconds (see Section 5.2..3). >> > >> > I'm slightly confused at the interplay between the explicit length fie= ld >> > and the "empty unless" directive. Does this mean that the only allowe= d >> > values in the "Other Len" are 0 and 6? Does "empty" mean "length-zero= =E2=80=9D? >> >> I=E2=80=99ve rewritten this slightly in a bid to make it clearer that = =E2=80=9COther >> Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80=9D is zero= . >> >> >> > Section 4.3.1 >> > >> > Only included in the computation of a MAC for a response message (or >> > the first message in a multi-message response), the validated reques= t >> > MAC MUST be included in the MAC computation. If the request MAC >> > failed to validate, an unsigned error message MUST be returned >> > instead. (Section 5.3.2). >> > >> > side note: while Section 5.3.2 specifies how to create an unsigned err= or >> > message, it looks like Section 5.2 (and subsections lists specific >> > RCODEs that are to be used. >> >> That is the case. Section 4 is a description of the TSIG RR and its >> fields. Section 5 describes the contents of the fields in various >> situations (client transmission, server reception, server transmission, >> client reception). >> >> >> > Section 4.3.2 >> > >> > When verifying an incoming message, this is the message after the >> > TSIG RR and been removed and the ARCOUNT field has been decremented. >> > If the message ID differs from the original message ID, the original >> > message ID is substituted for the message ID. (This could happen, >> > for example, when forwarding a dynamic update request.) >> > >> > I trust (based on this text having survived while going for full IS) >> > that there are no interesting record-keeping considerations with respe= ct >> > to knowing the message ID(s) to substitute, in the "forwarding a >> > dynamic-update request" case, presumably since this is just the field >> > from the TSIG RDATA and not some externally retained state. >> >> That is correct - the original ID is stored in the TSIG record=E2=80=99s= RDATA >> and it is from there that the original ID is retrieved when a substituti= on >> is made. >> >> >> > Section 4.3.3 >> > >> > The RR RDLEN and RDATA MAC Length are not included in the input to >> > MAC computation since they are not guaranteed to be knowable before >> > the MAC is generated. >> > >> > I appreciate that this is explicitly noted; there are some security >> > considerations regarding the non-inclusion of the (truncated) mac leng= th >> > as input, though. The local truncation policy helps here, but not 100= %. >> >> OK >> >> >> > For each label type, there must be a defined "Canonical wire format" >> > >> > Just to check my understanding: label types only come into play for th= e >> > two fields that are in domain name syntax, key name and algorithm name= ? >> >> There was actually an error in the text here: RFC 4034 section 6.1 is >> concerned with Canonical Name Order. It is section 6.2 that details the >> canonical wire format - I=E2=80=99ve changed the reference. >> >> Going back to the original point, yes, that is correct. Label type 00 i= s >> uncompressed name. (11 is a compressed name, and label types 01 and 10 a= re >> discouraged - see RFC 6891 section 5). >> >> >> > Section 5.1 >> > >> > the server. This TSIG record MUST be the only TSIG RR in the messag= e >> > and MUST be last record in the Additional Data section. The client >> > >> > (Is there anything else that tries to insist on being the last record = in >> > the additional data section? I guess it doesn't really make sense to >> > try to Update: 1035 just to note this requirement.) >> >> Not to our knowledge. >> >> >> > MUST store the MAC and the key name from the request while awaiting >> > an answer. >> > >> > [This is going to end up alongside the request-ID that it has to store >> > already, right?] >> >> Yes. The request MAC is included as one of the components used by the >> server to generate the response - which should be encoded using the same >> key as used in the request. >> >> >> > Note that some older name servers will not accept requests with a >> > nonempty additional data section. Clients SHOULD only attempt signe= d >> > transactions with servers who are known to support TSIG and share >> > some algorithm and secret key with the client -- so, this is not a >> > problem in practice. >> > >> > (The context in which this "SHOULD" appears makes it feel like it's >> > repeating an admontion from elsewhere and not the only instance of the >> > requirement, in which case a reference might be appropriate.) >> >> I=E2=80=99ve removed this paragraph. The reference to older name server= s is now >> completely out of date (it was a carry-over from the original 20-year ol= d >> text). The rest of the paragraph seems superfluous - rather like statin= g >> that TCP clients should only connect to servers that support TCP. >> >> >> > Section 5.2 >> > >> > If the TSIG RR cannot be understood, the server MUST regard the >> > message as corrupt and return a FORMERR to the server. Otherwise th= e >> > server is REQUIRED to return a TSIG RR in the response. >> > >> > As written, this could be read as an attempt to make a normative >> > requirement of servers that do not implement this spec. Presumably it= 's >> > just restating a requirement of the core protocol, though? >> >> It is the core protocol. >> >> I see your point though. However, by implication we are talking about a >> server that implements TSIG. >> >> >> > Section 5.2.2 >> > >> > Using the information in the TSIG, the server should verify the MAC >> > by doing its own calculation and comparing the result with the MAC >> > received. If the MAC fails to verify, the server MUST generate an >> > >> > Is there any other way to verify the MAC? (Should this be a "MUST >> > verify=E2=80=9D?) >> >> Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. >> >> >> > Section 5.2.2.1 >> > >> > When space is at a premium and the strength of the full length of a >> > MAC is not needed, it is reasonable to truncate the keyed hash and >> > use the truncated value for authentication. HMAC SHA-1 truncated to >> > 96 bits is an option available in several IETF protocols, including >> > IPsec and TLS. >> > >> > Also Kerberos, where it was the strongest option for a while and we ha= d >> > to define a new encryption type to provide a better option (RFC 8009). >> > >> > This text seems to be implying that HMAC SHA-1 truncated to 96 bits is= a >> > recommendable option, which is ... far from clear. I'd prefer to have= a >> > note that this specific truncation was appropriate when initially >> > specified but may not provide a security level appropriate for all cas= es >> > in the modern environment, or preferrably to just change the reference >> > to (e.g.) SHA-384-192 or SHA-256-128. >> >> Added the following an the end of the paragraph: >> >> However, while this option is kept for backwards compatibility, >> it may not provide a security level appropriate for all cases >> in the modern environment. In these cases, it is preferable to >> use a hashing algorithm such as SHA-256-128, SHA-384-192 >> or SHA-256-128 [RFC4868]. >> >> I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D= , =E2=80=9Chmac-sha384-192=E2=80=9D and >> =E2=80=9Chmac-sha512-256=E2=80=9D as optional algorithms to the algorith= m table. >> >> >> > This is sent when the signer has truncated the keyed hash output >> > to an allowable length, as described in [RFC2104], taking initia= l >> > octets and discarding trailing octets. TSIG truncation can only >> > >> > (Or when an on-path attacker has performed truncation.) >> >> True, but an on-path attacker can manipulate the message in any way >> possible. I=E2=80=99m not sure whether adding this caveat will add anyt= hing to the >> document. >> >> >> > Section 5.2.3 >> > >> > (BADTIME). The server SHOULD also cache the most recent time signed >> > value in a message generated by a key, and SHOULD return BADTIME if = a >> > message received later has an earlier time signed value. A response >> > >> > (But there's no fudge factor on this check, other than the inherent >> > limit of seconds granularity, as alluded to by the last paragraph of >> > this section?) >> >> The last paragraph in the section states that handling this issue should >> be left up to implementations and that the exact method (and by >> implication, the size of the fudge factor) be determined by the >> implementation themselves. >> >> >> > Section 5.3.1 >> > >> > A zone transfer over a DNS TCP session can include multiple DNS >> > messages. Using TSIG on such a connection can protect the connectio= n >> > from hijacking and provide data integrity. The TSIG MUST be include= d >> > >> > (I assume that "hijacking TCP" means a sequence-number-guessing attack >> > that would require the attacker to be winning the race against the >> > legitimate sender to cause modified data to be introduced into the TCP >> > stream? This is maybe not the best word to use for such a case.) >> >> I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80= =9D. >> >> >> > on all DNS messages in the response. For backward compatibility, a >> > client which receives DNS messages and verifies TSIG MUST accept up >> > to 99 intermediary messages without a TSIG. The first message is >> > >> > (side note: I'm kind of curious what such compatibility is needed with= . >> > Also, this gives an attacker some flexibility into which to incorporat= e >> > a collision, though given the near-real-time constraints and the >> > strength of the HMAC construction I don't expect any practical impact.= ) >> >> The original RFC 2845 did not require all packets in a message stream to >> contain a TSIG, it just stated that there be no more than 99 intermediar= y >> messages without a TSIG (presumably to cut down on the overhead required= in >> message calculations - remember that RFC 2845 was published 20 years ago= ). >> Although many DNS implementations now add a TSIG to every message, it is= by >> no means certain that all do. (In fact, less than three years ago, a bug >> was introduced into BIND, causing it to require that all packets in a zo= ne >> transfer would contain a TSIG. A fix allowing BIND to accept up to 99 >> packets between signed ones was released shortly afterwards after report= s >> were received of zone transfers failing.) >> >> >> > Section 5.3.2 >> > >> > Request MAC (if the request MAC validated) >> > DNS Message (response) >> > TSIG Variables (response) >> > >> > The reason that the request is not included in this MAC in some case= s >> > is to make it possible for the client to verify the error. If the >> > error is not a TSIG error the response MUST be generated as specifie= d >> > in Section 5.3. >> > >> > This makes it sound like the server excludes the request MAC from the >> > digest if it failed to validate (something the client cannot predict), >> > so that the client must perform trial verification of both versions in >> > order to validate the response. Is that correct? >> >> No. If the incoming MAC failed to validate, the server should send back >> an unsigned response (MAC size =3D=3D 0 and empty MAC). >> >> >> > Also, I think that the "in some cases" is not properly placed: as-is, = it >> > says that the request (not request MAC) is sometimes not included >> > (implying that sometimes it is), which does not match up with the >> > specification for the digest components. I presume that the intent is >> > to say that in some cases the client could not verify the error, if th= e >> > request itself was always included in the digest. >> >> Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. >> >> If the MAC could not be verified, it is possible that it was corrupted, >> which would prevent the client verifying the response. But a major reaso= n >> is that an incorrect MAC included in a signed response led to the CVEs t= hat >> prompted this document update. >> >> >> > Section 5.4.1 >> > >> > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG >> > validates and the TSIG key recognised by the client but different >> > from that used on the request, then this is a Key Error. The client >> > >> > nits: missing words "key is recognized" and "but is different=E2=80=9D >> >> It now reads =E2=80=9Ckey is recognized but different" >> >> >> > Section 5.5 >> > >> > destination or the next forwarder. If no transaction security is >> > available to the destination and the message is a query then, if the >> > corresponding response has the AD flag (see [RFC4035]) set, the >> > forwarder MUST clear the AD flag before adding the TSIG to the >> > response and returning the result to the system from which it >> > received the query. >> > >> > Is there anything to say about the CD bit? (It's independent crypto, = so >> > I don't expect so, but it seems worth checking.) >> >> No. CD is just a mechanism by which a client can request that the serve= r >> not do DNSSEC signature validation on the data and so allow the client t= o >> receive the data instead of a SERVFAIL response. >> >> >> > Section 6 >> > >> > The only message digest algorithm specified in the first version of >> > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], >> > [RFC2104]). Although a review of its security [RFC6151] concluded >> > that "it may not be urgent to remove HMAC-MD5 from the existing >> > protocols", with the availability of more secure alternatives the >> > opportunity has been taken to make the implementation of this >> > algorithm optional. >> > >> > It seems worth noting that the advice from RFC 6151 is already nine >> > years old. >> >> I=E2=80=99ve use the phrasing "Although a review of its security some ye= ars ago=E2=80=9D. >> >> >> > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], >> > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 >> > security considerations apply to SHA-1 in a similar manner.. Althou= gh >> > >> > I'd consider referencing (e.g.) >> > shattered.io >> > for the "collisions have >> > been demonstrated" claim, though it's pretty optional. >> >> A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D pa= per.. >> >> >> > support for hmac-sha1 in TSIG is still mandatory for compatibility >> > reasons, existing uses should be replaced with hmac-sha256 or other >> > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >> > >> > Is this "sha1 mandatory for compatibility" going to age well? If we >> > have two implementations that can operate with sha2 variants, is it >> > required to keep this as mandatory (vs. optional with a note about >> > deployed reality at time of publication) for progression to Internet >> > Standard? >> >> This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2= =80=9D column in >> RFC4635 (from which Table 2 was derived) into =E2=80=9CImplementation=E2= =80=9D and =E2=80=9CUse=E2=80=9D. >> SHA1 is required to be implemented (for backwards compatibility) but its >> use is not recommended. >> >> >> > Optional hmac-sha224 >> > >> > It's not clear there's much reason to keep this around, or if we do, i= t >> > could probably be "not recommended". (I assume that just dropping it >> > entirely makes things annoying w.r.t. the IANA registry.) >> >> It has been left in for compatibility reasons, but its use is not >> recommended. >> >> >> > Section 9 >> > >> > Previous specifications [RFC2845] and [RFC4635] defined values for >> > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >> > >> > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where >> > HMAC qualifies both hash algorithms is not terribly clear. >> >> Changed to >> >> Previous specifications [RFC2845] and [RFC4635] defined names fo= r >> the HMAC-MD5 and the various HMAC-SHA algorithms. >> >> >> > Section 10 >> > >> > I suggest some discussion that the way truncation policy works, an >> > attackers ability to forge messages accepted as valid is limited by th= e >> > amount of truncation that the recipient is willing to accept, not the >> > amount of truncation used to generate messages by the legitimate sende= r. >> >> I think this is already taken care of by the reference to a local policy >> in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.= 2.4). >> >> >> > There's also some fairly standard content to put in here about allowin= g >> > for an unsigned error response to a signed request, so an attacker (ev= en >> > off-path) can spoof such resposnes. (Section 5.4 indicates that the >> > client should continue to wait if it gets such a thing, which helps a >> > lot.) >> >> I=E2=80=99ve just added text that an unsigned response is not considered >> acceptable because can be subject to spoofing and manipulation. >> >> >> > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two >> > entities. >> > >> > I suggest adding "; any such additional sharing would allow any party >> > knowing the key to impersonate any other such party to members of the >> > group=E2=80=9D. >> >> Added. >> >> >> > A fudge value that is too large may leave the server open to replay >> > attacks. A fudge value that is too small may cause failures if >> > machines are not time synchronized or there are unexpected network >> > delays. The RECOMMENDED value in most situations is 300 seconds. >> > >> > Our experience with kerberos in modern network environments has shown >> > that 5 minutes is much larger than needed, though it's not clear there= 's >> > a strong need to change this recommendation right now. >> >> The value is recommended (and even then, only in =E2=80=9Cmost situation= s=E2=80=9D), so >> implementations are free to set their own value. However, any guidance = as >> to typical time skews measured across a network would be useful in a num= ber >> of protocols. >> >> >> > Significant progress has been made recently in cryptanalysis of hash >> > functions of the types used here. While the results so far should >> > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are being >> > made mandatory as a precaution. >> > >> > Please revise this note to not imply that SHA-1 is considered "strong= =E2=80=9D. >> >> Text revised to >> >> Significant progress has been made recently in cryptanalysis of >> hash >> functions of the types used here. While the results so far >> should not >> affect HMAC, the stronger SHA-256 algorithm is being made >> mandatory >> as a precaution. >> >> >> > Section 11.2 >> > >> > I'm not sure why RFC 2104 is listed as informative. >> >> RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a = possible downref >> if the reference is placed in the =E2=80=9CNormative=E2=80=9D section. >> >> >> >> Comments from Mirja K=C3=BChlewind >> >> > I only had limited time for a quick review of this document, so I migh= t >> not be aware of all the needed background and details. Still I have two >> quick questions on retries: >> > >> > 1) Sec 5.2.3: >> > "Implementations should be aware >> > of this possibility and be prepared to deal with it, e.g. by >> > retransmitting the rejected request with a new TSIG once outstanding >> > requests have completed or the time given by their time signed plus >> > fudge value has passed." >> > I might not be aware of all protocol details and maybe this is already >> specified somewhere: While unlikely, it is possible that a request might= be >> retransmitted multiple times, as that could cause president congestion o= ver >> time, it's always good practice to define a maximum number of >> retransmissions. If that is already defined somewhere, maybe adding a >> note/pointer would be good as well. >> >> If someone can suggest a suitable number (and a reason for it), we can >> consider doing this. In the meantime, I=E2=80=99ve merely stated that >> implementation should limit the number of retransmissions and so leave t= he >> choice up to the implementation. >> >> >> > 2) Sec 5.3.1: >> > " This allows the client to rapidly detect when the session has been >> > altered; at which point it can close the connection and retry." >> > When (immediately or after some waiting time) should the client retry >> and how often? >> >> I think that should be down to the implementation to decide. >> >> >> > You further say >> > "The client SHOULD treat this the >> > same way as they would any other interrupted transfer (although the >> > exact behavior is not specified here)." >> > Where is that specified? Can you provide a pointer in the text? >> >> That was a mistake in transcribing the original RFC2845 text. The final >> word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads: >> >> The client SHOULD treat this the same way as they would any othe= r >> interrupted transfer (although the exact behavior is not >> specified). >> >> >> > 3) Sec 8. Shared Secrets: Would it be appropriate to use more >> normative language here? There are a bunch of lower case shoulds in this >> section; is that on purpose? >> >> The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is = very general >> security advice. Although this is something users ought to do, it is no= t >> really a specific recommendation. >> >> >> >> Comments from Barry Leiba >> >> > =E2=80=94 Section 4.2 =E2=80=94 >> > >> > * Other Len - an unsigned 16-bit integer specifying the lengt= h >> > of the "Other Data" field in octets. >> > * Other Data - this unsigned 48-bit integer field will be >> > >> > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits? I= f so, does that >> mean tgat the value of =E2=80=9Cother len=E2=80=9D is always 6? If so, = then shouldn=E2=80=99t it >> say that? If not, then what don=E2=80=99t I understand? >> >> Benjamin Kaduk also made the same comment, it has been addressed above. >> >> >> > =E2=80=94 Section 5.1 =E2=80=94 >> > >> > Clients SHOULD only attempt signed >> > transactions with servers who are known to support TSIG and share >> > some algorithm and secret key with the client -- so, this is not a >> > problem in practice. >> > >> > Why SHOULD and not MUST? >> >> Benjamin Kaduk also noted an issue here. The paragraph has been removed= . >> >> >> > =E2=80=94 Section 5.3.2 =E2=80=94 >> > >> > The server SHOULD also cache the most recent time signed >> > value in a message generated by a key >> > >> > I tripped over this until I realized you mean =E2=80=9CTime Signed val= ue=E2=80=9D. You >> capitalize it elsewhere, and it helps the parsing if it=E2=80=99s consis= tent. There >> are four uncapitalized instances in this section. >> >> =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in the= description of >> the field, =E2=80=9Ctims signed=E2=80=9D has been replaced with =E2=80= =9Ctime the message was >> signed=E2=80=9D. >> >> Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80= =9CFudge field=E2=80=9D (although >> occurrences of =E2=80=9Cfudge value=E2=80=9D have not been capitalised, = as the context of >> that is that it is referring to the contents of the Fudge field). Also, >> =E2=80=9Cother data=E2=80=9D and =E2=80=9Cother data length=E2=80=9D hav= e been replaced with the >> (capitalised) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COth= er Len=E2=80=9D. >> >> >> > =E2=80=94 Section 9 =E2=80=94 >> > >> > There is no structure >> > required other than names for different algorithms must be unique >> > when compared as DNS names, i.e., comparison is case insensitive. >> > >> > I found this sentence to be really awkward and hard to parse. May I >> suggest this?: >> > >> > NEW >> > There is no structure to the names, and algorithm names are compared a= s >> if they were DNS names (the comparison is case-insensitive). >> > END >> > >> > I don=E2=80=99t think you really need to say that each name is >> different/unique, right? >> >> Agreed. The text has been changed to that suggested. >> >> >> > other algorithm >> > names are simple (i.e., single-component) names. >> > >> > Nitty thing that you can completely ignore, but I would avoid the Lati= n >> abbreviation thus: =E2=80=9Cother algorithm names are simple, single-com= ponent >> names.=E2=80=9D >> >> Changed. >> >> >> >> Comments from =C3=89ric Vyncke >> >> > Thank you for the work put into this document. It is clear and easy to >> read. >> > >> > Please find below some non-blocking COMMENTs and NITs. An answer will >> be appreciated. >> > >> > I hope that this helps to improve the document, >> > >> > Regards, >> > >> > -=C3=A9ric >> > >> > =3D=3D COMMENTS =3D=3D >> > >> > There are 6 authors while the usual procedure is to limit to 5 >> authors.. Personally, I do not care. >> > >> > -- Section 1.3 -- >> > It is a little unclear to me whether the "two nameservers" were two >> implementations or two actual DNS servers. >> >> Agreed, it was unclear. Changed to =E2=80=9Ctwo name server implementat= ions=E2=80=9D. >> >> >> > -- Section 5.2 -- >> > Suggest to provide some justifications about "copied to a safe >> location": the DNS message was sent in the clear, why does the TSIG part= be >> copied in a safe location? Please define what is meant by "safe location= " >> (Mainly for my own curiosity) >> >> It is a bit over-specified and has been changed. The text now reads: >> >> Upon receipt of >> a message with exactly one correctly placed TSIG RR, a copy of th= e >> TSIG RR is stored, and the TSIG RR is removed from the DNS Messag= e, >> and decremented out of the DNS message header's ARCOUNT. >> >> >> > "cannot be understood" is also quite vague. >> >> Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. >> >> >> > -- Section 5.3 -- >> > About rejecting request with a time signed value being earlier than th= e >> last received value. I wonder what is the value of this behavior if ther= e >> is no 'fudge' as well... The last paragraph of this section describes th= is >> case and push the error handling to the request initiator. Any reason wh= y >> being flexible on the receiving site was not selected ? >> >> The fudge value is to cope with clock skew between the sender and >> receiver. This won't impact on the order in which the packets are recei= ved >> by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-= level check. (It is >> not fool-proof - a number of packets signed by the sender within a secon= d >> of one another may have the same =E2=80=9CTime Signed=E2=80=9D field.) >> >> Pushing the error handling to the initiation goes back to the original >> RFC 2845. >> >> >> > =3D=3D NITS =3D=3D >> > >> > -- Section 4.3.2 -- >> > Is " A whole and complete DNS message in wire format." a complete and >> valid sentence? >> >> This was also pointed out by Roman Danyliw and has been addressed. >> >> >> Other changes made during editing >> >> * There was no description of the contents of the =E2=80=9CError=E2=80= =9D and =E2=80=9COther >> Data=E2=80=9D fields were in a request. This has now been corrected (Er= ror is set >> to 0. The contents of =E2=80=9COther Data=E2=80=9D are stated to be unde= fined to allow for >> extensions such as draft-andrews-dnsop-defeat-frag-attack.) >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000050413405a557c9e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The incremental effort to implement SHA-224 if you are imp= lementing SHA-256 is miniscule. It makes no sense to me for SHA-224 to be N= OT RECOMMENDED to use when=C2=A0SHA-256 is MUST implement=C2=A0and=C2=A0REC= OMMENDED to use and you can use SHA-256 with truncation to 224 or even fewe= r bits.
=C2=A0
Thanks,
Donald
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
= =C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com

<= /div>

On Sat, May 9, 2020 at 9:52 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
To follow up on Stephen's comments= , a table was added to 2845bis to
list all the algorithms that are currently in th= e IANA registry,
along with=C2=A0suggestions=C2=A0for implementation.=C2=A0 This was= the first version:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Requirement Name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0----------- ------------------------
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0<= a href=3D"http://HMAC-MD5.SIG-ALG.REG.INT" target=3D"_blank">HMAC-MD5.SIG-A= LG.REG.INT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Optional =C2=A0 =C2=A0gss-tsig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-sha1
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional = =C2=A0 =C2=A0hmac-sha224
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-sha256
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0h= mac-sha384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha512

During the IESG review (I think it was t= he SECDIR review), there was
a meltdown over implementing SHA-1. But SHA-1 is in use= currently.=C2=A0
My suggestion was to do a variation describing implementation use.= =C2=A0
Th= is is what I came up with(so blame me):=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Imple= mentation Use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------= - -------------- ---------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HMAC-MD5.SIG-ALG.= REG.INT MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 gss-tsig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECO= MMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha224 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0NOT RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256-128 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384-192 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512-256 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY

On the use side, these a= re mostly guesses.=C2=A0 =C2=A0We would love to hear
what the WG has to say about th= is.

<= /div>
thanks
tim

=
On Mon= , May 4, 2020 at 2:07 PM Stephen Morris <sa.morris8@gmail.com> wrote:

> On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain Name System Operations WG of t= he IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Secret Key Transaction Authentication for DNS (TSIG)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Francis Dupont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stephen Morris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Paul Vixie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Donald E. Eastlake 3rd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Olafur Gudmundsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Brian Wellington
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-rfc2845bis-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-05-04


The update addresses to the draft comments made during the IESG review.=C2= =A0 There were a fair number of these which led to a number of changes to t= he document.=C2=A0 These are listed below.

One significant change is that the list of acceptable algorithms has been e= xtended, and WG approval for this is sought.

Stephen




Comments from Roman Danyliw
---
> ** Section 1.3.=C2=A0 Per =E2=80=9CIn 2017, two nameservers=C2=A0 stri= ctly following that document (and the related [RFC4635]) were discovered to= have security problems related to this feature=E2=80=9D, consider providin= g a reference to the published vulnerabilities (i.e., CVE-2017-3142 and CVE= -2017-3143)

I=E2=80=99ve added these (and one other related CVE) as informative referen= ces.=C2=A0 Using just the CVE number as a reference seemed a bit spartan, s= o I=E2=80=99ve added a title to each incident. As the description of the CV= Es in Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descri= ption, which can be rather long), I=E2=80=99ve taken the title from ISC=E2= =80=99s KnowledgeBase (for the BIND CVEs) and from the Knot release notes (= for the Knot CVE).


> ** Section 6.=C2=A0 Per =E2=80=9CSHA-1 collisions have been demonstrat= ed so the MD5 security considerations apply to SHA-1 in a similar manner.= =C2=A0 Although support for hmac-sha1 in TSIG is still mandatory for compat= ibility reasons, existing uses should be replaced with hmac-sha256 or other= SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].
>
> -- It=E2=80=99s worth repeating those MD5 security considerations here=

I=E2=80=99m not really keen on doing this, since the security consideration= s in RFC 6151 cover two paragraphs and including them - or even a summary o= f them - would detract from the flow of the document.=C2=A0 However, I have= explicitly included a reference to RFC 6151 in the text.


> -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth including references to the recent SHA-1 cryptoanalysis provi= ded in the SECDIR review

Added references to just one of these papers (=E2=80=9DSHA1 is a Shambles= =E2=80=9D).=C2=A0 We=E2=80=99re not doing a general analysis of the algorit= hms, so a simple reference to a paper than describes a SHA1 collision is al= l that is needed.=C2=A0 (As an aside, the paper doesn't give the date o= f publication, so I had to search the Web looking for references to it.=C2= =A0 I think I=E2=80=99ve got the date correct, but I=E2=80=99d be grateful = for a double-check.)


> -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED).

Done - see Table 2


> ** Section 10.=C2=A0 Per =E2=80=9CFor all of the message authenticatio= n code algorithms listed in this document, those producing longer values ar= e believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR rev= iew, this could be misconstrued as the algorithm choice not the digest leng= th provides the security.=C2=A0 Recommend rephrasing (or making some statem= ent=C2=A0

I=E2=80=99ve reworded this paragraph (in section 10).=C2=A0 It now reads:
=C2=A0 "Although the strength of an algorithm determines its security,= there
=C2=A0 have been some arguments that mild truncation can strengthen a MAC b= y
=C2=A0 reducing the information available to an attacker.=C2=A0 However, ex= cessive
=C2=A0 truncation clearly weakens authentication by reducing the number of<= br> =C2=A0 bits an attacker has to try to break the authentication by brute
=C2=A0 force [RFC2104]."


> ** Editorial
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CWhen verifying an incoming messag= e, this is the message after the TSIG RR and been removed and the ARCOUNT f= ield has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (i= s missing a word).
>
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CA whole and complete DNS message = in wire format.=E2=80=9D, this isn=E2=80=99t a sentence.

Section 4.3.2 has been reworded to address these issues.



Comments from Benjamin Kaduk

> Thanks for putting together this update; it's good to see the secu= rity
> issue getting closed off in the udpated spec, and progression to full<= br> > Internet Standard!=C2=A0 I do have several substantive comments (as we= ll as
> some minor/nit-level ones), many of which are listed here at the top b= ut
> a few of which are interspersed in the per-section comments.
>
>
> I considered making this a Discuss point, but it should be pretty
> uncontroversial and I trust that the right thing will happen even if I=
> don't: there's a couple lingering remnants of SHA-1 being the<= br> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 an= d
> 10 (further detailed in the per-section comments).

The document now mentions SHA1 collisions and notes that the MD5 security c= onsiderations apply to SHA1.=C2=A0 It also mentions that support for SHA1 i= s mandatory for compatibility reasons but in existing uses it should be rep= laced by a stronger one.


> I also initially had made the following point a Discuss-level point, b= ut
> decided to not do so since I don't remember any BCP-level guidance=
> relating to cross-protocol attacks.=C2=A0 Nevertheless, I strongly enc= ourage
> the authors to consider that cryptographic best practice is to use any=
> given key with exactly one cryptographic algorithm.=C2=A0 The record f= ormat
> listed in Section 4.2 has the key name and algorithm as separately
> conveyed, which would allow for a given key to be used with all
> implemented algorithms.=C2=A0 We should include some discussion that i= t's
> best to only use a single algorithm with any given key.

The following text has been added to the Security Considerations section:
=C2=A0 "To prevent cross-algorithm attacks, there SHOULD only be one =C2=A0 =C2=A0 algorithm associated with any given key name."


> We also have a 16-bit wide field for "Fudge", which (since i= t counts
> seconds) corresponds to a maximum window of something like +/- 18 hour= s;
> it's hard to believe that we really want to give people the rope t= o
> allow for that much time skew.=C2=A0 (Yes, I understand that implement= ations
> will set something sane in practice but that doesn't necessarily m= ean
> that the protocol still has to allow it.)

That was set in the original RFC 2845.=C2=A0 Although I agree with the comm= ents, changing the size of that field would be a significant undertaking.= =C2=A0 However, section 10 does state that the RECOMMENDED fudge value in m= ost circumstances is 300 seconds.


> Our authoritative list of algorithm names (Table 1) is rather divorced=
> from the references to be consulted for the individual hash algorithms=
> to be used with the HMAC procedure.=C2=A0 The ones used here are suffi= ciently
> well-known that I'm not terribly concerned about it, though.

The first paragraph of the IANA considerations section lists the algorithms= and references to where they are described, and I didn=E2=80=99t want to d= uplicate the information.


> Abstract
>
> The title says "DNS" but maybe the body of the abstract shou= ld as well?

In the abstract, changed:

"It can be used to authenticate dynamic updates as coming from an appr= oved client"

to

"It can be used to authenticate dynamic updates to a DNS zone as comin= g from an approved client"


> Section 1.1
>
> Some of this language feels like it might not age terribly well, e.g.,=
> "this can provide" or "[t]here was a need".
>
>=C2=A0 =C2=A0addresses that need.=C2=A0 The proposal is unsuitable for = general server
>=C2=A0 =C2=A0to server authentication for servers which speak with many= other
>=C2=A0 =C2=A0servers, since key management would become unwieldy with t= he number
>=C2=A0 =C2=A0of shared keys going up quadratically.=C2=A0 But it is sui= table for many
>=C2=A0 =C2=A0resolvers on hosts that only talk to a few recursive serve= rs.

Changed to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The authentication mechanism proposed her= e provides a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple and efficient authentication between cli= ents and local servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by using shared secret keys to establish a trus= t relationship between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 two entities.=C2=A0 Such keys must be protected= in a manner similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private keys, lest a third party masquerade as = one of the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parties (by forging the MAC).=C2=A0 The proposa= l is unsuitable for general
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server to server authentication for servers whi= ch speak with many
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other servers, since key management would becom= e unwieldy with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number of shared keys going up quadratically. B= ut it is suitable for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 many resolvers on hosts that only talk to a few= recursive servers.=E2=80=9D


> Should zone transfers be mentioned here as well?

Zone transfers are mentioned in the preceding paragraph.


> Section 1.2
>
> I don't understand the motivation for changing terminology from MA= Cs to
> "signatures"; they're still MACs even though they're= transaction-based.

The mention of signatures in section 1.2 is intended as a link between the = name of the RR (TSIG or Transaction Signature) and the term MAC used in the= rest of the document.


>=C2=A0 =C2=A0MAC of the query as part of the calculation.=C2=A0 Where a= response
>=C2=A0 =C2=A0comprises multiple packets, the calculation of the MAC ass= ociated
>=C2=A0 =C2=A0with the second and subsequent packets includes in its inp= uts the MAC
>=C2=A0 =C2=A0for the preceding packet.=C2=A0 In this way it is possible= to detect any
>=C2=A0 =C2=A0interruption in the packet sequence.
>
> I suggest mentioning the lack of mechanism to detect truncation of the=
> packet sequence.

That is a fair point.=C2=A0 I=E2=80=99ve modified the last sentence to read= :

=C2=A0 =C2=A0"In this way it is possible to detect any interruption in= the packet sequence,
=C2=A0 =C2=A0although not its premature termination."


> Section 4.2
>
>=C2=A0 =C2=A0NAME=C2=A0 The name of the key used, in domain name syntax= ..=C2=A0 The name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should reflect the names of the hosts= and uniquely identify the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key among a set of keys these two hos= ts may share at any given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time.=C2=A0 For example, if hosts A.s= ite.example and
> = B.example.net
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0share a key, possibilities for the ke= y name include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example, <id>= ..B.e= xample.net, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example.B= ..example.net.=C2=A0 It should be possible for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than one key to be in simultaneo= us use among a set of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interacting hosts.
>
> I'd suggest adding a note along the lines of "This allows for= periodic
> key rotation per best operational practices, as well as algorithm
> agility as indicated by [BCP201].=E2=80=9D

Added.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The name may be used as a local index= to the key involved and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it is recommended that it be globally= unique.=C2=A0 Where a key is
>
> (nit?): this feels more like a "but" than an "and"= , to me.

Well spotted.=C2=A0 I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 MAC Size - an unsigned 16-bit= integer giving the length of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC field in octets.=C2=A0 Tr= uncation is indicated by a MAC size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 less than the size of the key= ed hash produced by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm specified by the Al= gorithm Name.
>
> nit: I would suggest "output size", as there are potentially= a few
> different sizes involved (key size, block size, and output size, for > starters, though I think the possibility of confusion here is low).
I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference to = this field, and the other size mentioned - that of the keyed hash is, I thi= nk, also unambiguous.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 empty unless the content of t= he Error field is BADTIME, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which case it will contain th= e server's current time as the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of seconds since 00:00= on 1970-01-01 UTC, ignoring
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leap seconds (see Section 5.2= ..3).
>
> I'm slightly confused at the interplay between the explicit length= field
> and the "empty unless" directive.=C2=A0 Does this mean that = the only allowed
> values in the "Other Len" are 0 and 6?=C2=A0 Does "empt= y" mean "length-zero=E2=80=9D?

I=E2=80=99ve rewritten this slightly in a bid to make it clearer that =E2= =80=9COther Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80= =9D is zero.


> Section 4.3.1
>
>=C2=A0 =C2=A0Only included in the computation of a MAC for a response m= essage (or
>=C2=A0 =C2=A0the first message in a multi-message response), the valida= ted request
>=C2=A0 =C2=A0MAC MUST be included in the MAC computation.=C2=A0 If the = request MAC
>=C2=A0 =C2=A0failed to validate, an unsigned error message MUST be retu= rned
>=C2=A0 =C2=A0instead.=C2=A0 (Section 5.3.2).
>
> side note: while Section 5.3.2 specifies how to create an unsigned err= or
> message, it looks like Section 5.2 (and subsections lists specific
> RCODEs that are to be used.

That is the case.=C2=A0 Section 4 is a description of the TSIG RR and its f= ields.=C2=A0 Section 5 describes the contents of the fields in various situ= ations (client transmission, server reception, server transmission, client = reception).


> Section 4.3.2
>
>=C2=A0 =C2=A0When verifying an incoming message, this is the message af= ter the
>=C2=A0 =C2=A0TSIG RR and been removed and the ARCOUNT field has been de= cremented.
>=C2=A0 =C2=A0If the message ID differs from the original message ID, th= e original
>=C2=A0 =C2=A0message ID is substituted for the message ID.=C2=A0 (This = could happen,
>=C2=A0 =C2=A0for example, when forwarding a dynamic update request.) >
> I trust (based on this text having survived while going for full IS) > that there are no interesting record-keeping considerations with respe= ct
> to knowing the message ID(s) to substitute, in the "forwarding a<= br> > dynamic-update request" case, presumably since this is just the f= ield
> from the TSIG RDATA and not some externally retained state.

That is correct - the original ID is stored in the TSIG record=E2=80=99s RD= ATA and it is from there that the original ID is retrieved when a substitut= ion is made.


> Section 4.3.3
>
>=C2=A0 =C2=A0The RR RDLEN and RDATA MAC Length are not included in the = input to
>=C2=A0 =C2=A0MAC computation since they are not guaranteed to be knowab= le before
>=C2=A0 =C2=A0the MAC is generated.
>
> I appreciate that this is explicitly noted; there are some security > considerations regarding the non-inclusion of the (truncated) mac leng= th
> as input, though.=C2=A0 The local truncation policy helps here, but no= t 100%.

OK


>=C2=A0 =C2=A0For each label type, there must be a defined "Canonic= al wire format"
>
> Just to check my understanding: label types only come into play for th= e
> two fields that are in domain name syntax, key name and algorithm name= ?

There was actually an error in the text here: RFC 4034 section 6.1 is conce= rned with Canonical Name Order.=C2=A0 It is section 6.2 that details the ca= nonical wire format - I=E2=80=99ve changed the reference.

Going back to the original point, yes, that is correct.=C2=A0 Label type 00= is uncompressed name. (11 is a compressed name, and label types 01 and 10 = are discouraged - see RFC 6891 section 5).


> Section 5.1
>
>=C2=A0 =C2=A0the server.=C2=A0 This TSIG record MUST be the only TSIG R= R in the message
>=C2=A0 =C2=A0and MUST be last record in the Additional Data section.=C2= =A0 The client
>
> (Is there anything else that tries to insist on being the last record = in
> the additional data section?=C2=A0 I guess it doesn't really make = sense to
> try to Update: 1035 just to note this requirement.)

Not to our knowledge.


>=C2=A0 =C2=A0MUST store the MAC and the key name from the request while= awaiting
>=C2=A0 =C2=A0an answer.
>
> [This is going to end up alongside the request-ID that it has to store=
> already, right?]

Yes.=C2=A0 The request MAC is included as one of the components used by the= server to generate the response - which should be encoded using the same k= ey as used in the request.


>=C2=A0 =C2=A0Note that some older name servers will not accept requests= with a
>=C2=A0 =C2=A0nonempty additional data section.=C2=A0 Clients SHOULD onl= y attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> (The context in which this "SHOULD" appears makes it feel li= ke it's
> repeating an admontion from elsewhere and not the only instance of the=
> requirement, in which case a reference might be appropriate.)

I=E2=80=99ve removed this paragraph.=C2=A0 The reference to older name serv= ers is now completely out of date (it was a carry-over from the original 20= -year old text).=C2=A0 The rest of the paragraph seems superfluous - rather= like stating that TCP clients should only connect to servers that support = TCP.=C2=A0


> Section 5.2
>
>=C2=A0 =C2=A0If the TSIG RR cannot be understood, the server MUST regar= d the
>=C2=A0 =C2=A0message as corrupt and return a FORMERR to the server.=C2= =A0 Otherwise the
>=C2=A0 =C2=A0server is REQUIRED to return a TSIG RR in the response. >
> As written, this could be read as an attempt to make a normative
> requirement of servers that do not implement this spec.=C2=A0 Presumab= ly it's
> just restating a requirement of the core protocol, though?

It is the core protocol.

I see your point though.=C2=A0 However, by implication we are talking about= a server that implements TSIG.


> Section 5.2.2
>
>=C2=A0 =C2=A0Using the information in the TSIG, the server should verif= y the MAC
>=C2=A0 =C2=A0by doing its own calculation and comparing the result with= the MAC
>=C2=A0 =C2=A0received.=C2=A0 If the MAC fails to verify, the server MUS= T generate an
>
> Is there any other way to verify the MAC?=C2=A0 (Should this be a &quo= t;MUST
> verify=E2=80=9D?)

Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed.


> Section 5.2.2.1
>
>=C2=A0 =C2=A0When space is at a premium and the strength of the full le= ngth of a
>=C2=A0 =C2=A0MAC is not needed, it is reasonable to truncate the keyed = hash and
>=C2=A0 =C2=A0use the truncated value for authentication.=C2=A0 HMAC SHA= -1 truncated to
>=C2=A0 =C2=A096 bits is an option available in several IETF protocols, = including
>=C2=A0 =C2=A0IPsec and TLS.
>
> Also Kerberos, where it was the strongest option for a while and we ha= d
> to define a new encryption type to provide a better option (RFC 8009).=
>
> This text seems to be implying that HMAC SHA-1 truncated to 96 bits is= a
> recommendable option, which is ... far from clear.=C2=A0 I'd prefe= r to have a
> note that this specific truncation was appropriate when initially
> specified but may not provide a security level appropriate for all cas= es
> in the modern environment, or preferrably to just change the reference=
> to (e.g.) SHA-384-192 or SHA-256-128.

Added the following an the end of the paragraph:

=C2=A0 However, while this option is kept for backwards compatibility,
=C2=A0 it may not provide a security level appropriate for all cases
=C2=A0 in the modern environment. In these cases, it is preferable to
=C2=A0 use a hashing algorithm such as SHA-256-128, SHA-384-192
=C2=A0 or SHA-256-128 [RFC4868].

I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D, = =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80=9D as = optional algorithms to the algorithm table.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is sent when the signer has truncated t= he keyed hash output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to an allowable length, as described in [RFC= 2104], taking initial
>=C2=A0 =C2=A0 =C2=A0 =C2=A0octets and discarding trailing octets.=C2=A0= TSIG truncation can only
>
> (Or when an on-path attacker has performed truncation.)

True, but an on-path attacker can manipulate the message in any way possibl= e.=C2=A0 I=E2=80=99m not sure whether adding this caveat will add anything = to the document.


> Section 5.2.3
>
>=C2=A0 =C2=A0(BADTIME).=C2=A0 The server SHOULD also cache the most rec= ent time signed
>=C2=A0 =C2=A0value in a message generated by a key, and SHOULD return B= ADTIME if a
>=C2=A0 =C2=A0message received later has an earlier time signed value.= =C2=A0 A response
>
> (But there's no fudge factor on this check, other than the inheren= t
> limit of seconds granularity, as alluded to by the last paragraph of > this section?)

The last paragraph in the section states that handling this issue should be= left up to implementations and that the exact method (and by implication, = the size of the fudge factor) be determined by the implementation themselve= s.=C2=A0


> Section 5.3.1
>
>=C2=A0 =C2=A0A zone transfer over a DNS TCP session can include multipl= e DNS
>=C2=A0 =C2=A0messages.=C2=A0 Using TSIG on such a connection can protec= t the connection
>=C2=A0 =C2=A0from hijacking and provide data integrity.=C2=A0 The TSIG = MUST be included
>
> (I assume that "hijacking TCP" means a sequence-number-guess= ing attack
> that would require the attacker to be winning the race against the
> legitimate sender to cause modified data to be introduced into the TCP=
> stream?=C2=A0 This is maybe not the best word to use for such a case.)=

I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D.<= br>

>=C2=A0 =C2=A0on all DNS messages in the response.=C2=A0 For backward co= mpatibility, a
>=C2=A0 =C2=A0client which receives DNS messages and verifies TSIG MUST = accept up
>=C2=A0 =C2=A0to 99 intermediary messages without a TSIG.=C2=A0 The firs= t message is
>
> (side note: I'm kind of curious what such compatibility is needed = with.
> Also, this gives an attacker some flexibility into which to incorporat= e
> a collision, though given the near-real-time constraints and the
> strength of the HMAC construction I don't expect any practical imp= act.)

The original RFC 2845 did not require all packets in a message stream to co= ntain a TSIG, it just stated that there be no more than 99 intermediary mes= sages without a TSIG (presumably to cut down on the overhead required in me= ssage calculations - remember that RFC 2845 was published 20 years ago).=C2= =A0 Although many DNS implementations now add a TSIG to every message, it i= s by no means certain that all do. (In fact, less than three years ago, a b= ug was introduced into BIND, causing it to require that all packets in a zo= ne transfer would contain a TSIG.=C2=A0 A fix allowing BIND to accept up to= 99 packets between signed ones was released shortly afterwards after repor= ts were received of zone transfers failing.)


> Section 5.3.2
>
>=C2=A0 =C2=A0 =C2=A0 Request MAC (if the request MAC validated)
>=C2=A0 =C2=A0 =C2=A0 DNS Message (response)
>=C2=A0 =C2=A0 =C2=A0 TSIG Variables (response)
>
>=C2=A0 =C2=A0The reason that the request is not included in this MAC in= some cases
>=C2=A0 =C2=A0is to make it possible for the client to verify the error.= =C2=A0 If the
>=C2=A0 =C2=A0error is not a TSIG error the response MUST be generated a= s specified
>=C2=A0 =C2=A0in Section 5.3.
>
> This makes it sound like the server excludes the request MAC from the<= br> > digest if it failed to validate (something the client cannot predict),=
> so that the client must perform trial verification of both versions in=
> order to validate the response.=C2=A0 Is that correct?

No.=C2=A0 If the incoming MAC failed to validate, the server should send ba= ck an unsigned response (MAC size =3D=3D 0 and empty MAC).


> Also, I think that the "in some cases" is not properly place= d: as-is, it
> says that the request (not request MAC) is sometimes not included
> (implying that sometimes it is), which does not match up with the
> specification for the digest components.=C2=A0 I presume that the inte= nt is
> to say that in some cases the client could not verify the error, if th= e
> request itself was always included in the digest.

Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D.

If the MAC could not be verified, it is possible that it was corrupted, whi= ch would prevent the client verifying the response. But a major reason is t= hat an incorrect MAC included in a signed response led to the CVEs that pro= mpted this document update.


> Section 5.4.1
>
>=C2=A0 =C2=A0If an RCODE on a response is 9 (NOTAUTH), but the response= TSIG
>=C2=A0 =C2=A0validates and the TSIG key recognised by the client but di= fferent
>=C2=A0 =C2=A0from that used on the request, then this is a Key Error.= =C2=A0 The client
>
> nits: missing words "key is recognized" and "but is dif= ferent=E2=80=9D

It now reads =E2=80=9Ckey is recognized but different"


> Section 5.5
>
>=C2=A0 =C2=A0destination or the next forwarder.=C2=A0 If no transaction= security is
>=C2=A0 =C2=A0available to the destination and the message is a query th= en, if the
>=C2=A0 =C2=A0corresponding response has the AD flag (see [RFC4035]) set= , the
>=C2=A0 =C2=A0forwarder MUST clear the AD flag before adding the TSIG to= the
>=C2=A0 =C2=A0response and returning the result to the system from which= it
>=C2=A0 =C2=A0received the query.
>
> Is there anything to say about the CD bit?=C2=A0 (It's independent= crypto, so
> I don't expect so, but it seems worth checking.)

No.=C2=A0 CD is just a mechanism by which a client can request that the ser= ver not do DNSSEC signature validation on the data and so allow the client = to receive the data instead of a SERVFAIL response.


> Section 6
>
>=C2=A0 =C2=A0The only message digest algorithm specified in the first v= ersion of
>=C2=A0 =C2=A0these specifications [RFC2845] was "HMAC-MD5" (s= ee [RFC1321],
>=C2=A0 =C2=A0[RFC2104]).=C2=A0 Although a review of its security [RFC61= 51] concluded
>=C2=A0 =C2=A0that "it may not be urgent to remove HMAC-MD5 from th= e existing
>=C2=A0 =C2=A0protocols", with the availability of more secure alte= rnatives the
>=C2=A0 =C2=A0opportunity has been taken to make the implementation of t= his
>=C2=A0 =C2=A0algorithm optional.
>
> It seems worth noting that the advice from RFC 6151 is already nine > years old.

I=E2=80=99ve use the phrasing "Although a review of its security some = years ago=E2=80=9D.


>=C2=A0 =C2=A0[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS1= 80-4],
>=C2=A0 =C2=A0[RFC3174].=C2=A0 SHA-1 collisions have been demonstrated s= o the MD5
>=C2=A0 =C2=A0security considerations apply to SHA-1 in a similar manner= ..=C2=A0 Although
>
> I'd consider referencing (e.g.)
> s= hattered.io
> for the "collisions have
> been demonstrated" claim, though it's pretty optional.

A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D paper= ..


>=C2=A0 =C2=A0support for hmac-sha1 in TSIG is still mandatory for compa= tibility
>=C2=A0 =C2=A0reasons, existing uses should be replaced with hmac-sha256= or other
>=C2=A0 =C2=A0SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].=
>
> Is this "sha1 mandatory for compatibility" going to age well= ?=C2=A0 If we
> have two implementations that can operate with sha2 variants, is it > required to keep this as mandatory (vs. optional with a note about
> deployed reality at time of publication) for progression to Internet > Standard?

This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2=80= =9D column in RFC4635 (from which Table 2 was derived) into =E2=80=9CImplem= entation=E2=80=9D and =E2=80=9CUse=E2=80=9D.=C2=A0 SHA1 is required to be i= mplemented (for backwards compatibility) but its use is not recommended.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Op= tional=C2=A0 =C2=A0 hmac-sha224
>
> It's not clear there's much reason to keep this around, or if = we do, it
> could probably be "not recommended".=C2=A0 (I assume that ju= st dropping it
> entirely makes things annoying w.r.t. the IANA registry.)

It has been left in for compatibility reasons, but its use is not recommend= ed.


> Section 9
>
>=C2=A0 =C2=A0Previous specifications [RFC2845] and [RFC4635] defined va= lues for
>=C2=A0 =C2=A0HMAC MD5 and SHA.=C2=A0 IANA has also registered "gss= -tsig" as an
>
> I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied gr= ouping where
> HMAC qualifies both hash algorithms is not terribly clear.

Changed to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Previous specifications [RFC2845] and [RFC4635]= defined names for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the HMAC-MD5 and the various HMAC-SHA algorithm= s.


> Section 10
>
> I suggest some discussion that the way truncation policy works, an
> attackers ability to forge messages accepted as valid is limited by th= e
> amount of truncation that the recipient is willing to accept, not the<= br> > amount of truncation used to generate messages by the legitimate sende= r.

I think this is already taken care of by the reference to a local policy in= the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.2.4).=


> There's also some fairly standard content to put in here about all= owing
> for an unsigned error response to a signed request, so an attacker (ev= en
> off-path) can spoof such resposnes.=C2=A0 (Section 5.4 indicates that = the
> client should continue to wait if it gets such a thing, which helps a<= br> > lot.)

I=E2=80=99ve just added text that an unsigned response is not considered ac= ceptable because can be subject to spoofing and manipulation.


>=C2=A0 =C2=A0TKEY [RFC2930].=C2=A0 Secrets SHOULD NOT be shared by more= than two
>=C2=A0 =C2=A0entities.
>
> I suggest adding "; any such additional sharing would allow any p= arty
> knowing the key to impersonate any other such party to members of the<= br> > group=E2=80=9D.

Added.


>=C2=A0 =C2=A0A fudge value that is too large may leave the server open = to replay
>=C2=A0 =C2=A0attacks.=C2=A0 A fudge value that is too small may cause f= ailures if
>=C2=A0 =C2=A0machines are not time synchronized or there are unexpected= network
>=C2=A0 =C2=A0delays.=C2=A0 The RECOMMENDED value in most situations is = 300 seconds.
>
> Our experience with kerberos in modern network environments has shown<= br> > that 5 minutes is much larger than needed, though it's not clear t= here's
> a strong need to change this recommendation right now.

The value is recommended (and even then, only in =E2=80=9Cmost situations= =E2=80=9D), so implementations are free to set their own value.=C2=A0 Howev= er, any guidance as to typical time skews measured across a network would b= e useful in a number of protocols.


>=C2=A0 =C2=A0Significant progress has been made recently in cryptanalys= is of hash
>=C2=A0 =C2=A0functions of the types used here.=C2=A0 While the results = so far should
>=C2=A0 =C2=A0not affect HMAC, the stronger SHA-1 and SHA-256 algorithms= are being
>=C2=A0 =C2=A0made mandatory as a precaution.
>
> Please revise this note to not imply that SHA-1 is considered "st= rong=E2=80=9D.

Text revised to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Significant progress has been made recently in = cryptanalysis of hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 functions of the types used here.=C2=A0 While t= he results so far should not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affect HMAC, the stronger SHA-256 algorithm is = being made mandatory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a precaution.


> Section 11.2
>
> I'm not sure why RFC 2104 is listed as informative.

RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a pos= sible downref if the reference is placed in the =E2=80=9CNormative=E2=80=9D= section.



Comments from Mirja K=C3=BChlewind

> I only had limited time for a quick review of this document, so I migh= t not be aware of all the needed background and details. Still I have two q= uick questions on retries:
>
> 1) Sec 5.2.3:
> "Implementations should be aware
>=C2=A0 =C2=A0of this possibility and be prepared to deal with it, e.g. = by
>=C2=A0 =C2=A0retransmitting the rejected request with a new TSIG once o= utstanding
>=C2=A0 =C2=A0requests have completed or the time given by their time si= gned plus
>=C2=A0 =C2=A0fudge value has passed."
> I might not be aware of all protocol details and maybe this is already= specified somewhere: While unlikely, it is possible that a request might b= e retransmitted multiple times, as that could cause president congestion ov= er time, it's always good practice to define a maximum number of retran= smissions. If that is already defined somewhere, maybe adding a note/pointe= r would be good as well.

If someone can suggest a suitable number (and a reason for it), we can cons= ider doing this.=C2=A0 In the meantime, I=E2=80=99ve merely stated that imp= lementation should limit the number of retransmissions and so leave the cho= ice up to the implementation.


> 2) Sec 5.3.1:
> "=C2=A0 =C2=A0This allows the client to rapidly detect when the s= ession has been
>=C2=A0 =C2=A0altered; at which point it can close the connection and re= try."
> When (immediately or after some waiting time) should the client retry = and how often?

I think that should be down to the implementation to decide.


> You further say
> "The client SHOULD treat this the
>=C2=A0 =C2=A0same way as they would any other interrupted transfer (alt= hough the
>=C2=A0 =C2=A0exact behavior is not specified here)."
> Where is that specified? Can you provide a pointer in the text?

That was a mistake in transcribing the original RFC2845 text.=C2=A0 The fin= al word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client SHOULD treat this the same way as th= ey would any other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interrupted transfer (although the exact behavi= or is not specified).


> 3) Sec 8.=C2=A0 Shared Secrets: Would it be appropriate to use more no= rmative language here? There are a bunch of lower case shoulds in this sect= ion; is that on purpose?

The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is ver= y general security advice.=C2=A0 Although this is something users ought to = do, it is not really a specific recommendation.



Comments from Barry Leiba

> =E2=80=94 Section 4.2 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>
> Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits?=C2= =A0 If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is = always 6?=C2=A0 If so, then shouldn=E2=80=99t it say that?=C2=A0 If not, th= en what don=E2=80=99t I understand?

Benjamin Kaduk also made the same comment, it has been addressed above.


> =E2=80=94 Section 5.1 =E2=80=94
>
>=C2=A0 =C2=A0Clients SHOULD only attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> Why SHOULD and not MUST?

Benjamin Kaduk also noted an issue here.=C2=A0 The paragraph has been remov= ed.


> =E2=80=94 Section 5.3.2 =E2=80=94
>
>=C2=A0 =C2=A0The server SHOULD also cache the most recent time signed >=C2=A0 =C2=A0value in a message generated by a key
>
> I tripped over this until I realized you mean =E2=80=9CTime Signed val= ue=E2=80=9D.=C2=A0 You capitalize it elsewhere, and it helps the parsing if= it=E2=80=99s consistent. There are four uncapitalized instances in this se= ction.

=E2=80=9Ctime signed=E2=80=9D has been capitalised.=C2=A0 In addition, in t= he description of the field, =E2=80=9Ctims signed=E2=80=9D has been replace= d with =E2=80=9Ctime the message was signed=E2=80=9D.

Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9CFu= dge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2=80=9D h= ave not been capitalised, as the context of that is that it is referring to= the contents of the Fudge field). Also, =E2=80=9Cother data=E2=80=9D and = =E2=80=9Cother data length=E2=80=9D have been replaced with the (capitalise= d) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COther Len=E2=80= =9D.


> =E2=80=94 Section 9 =E2=80=94
>
>=C2=A0 =C2=A0There is no structure
>=C2=A0 =C2=A0required other than names for different algorithms must be= unique
>=C2=A0 =C2=A0when compared as DNS names, i.e., comparison is case insen= sitive.
>
> I found this sentence to be really awkward and hard to parse.=C2=A0 Ma= y I suggest this?:
>
> NEW
> There is no structure to the names, and algorithm names are compared a= s if they were DNS names (the comparison is case-insensitive).
> END
>
> I don=E2=80=99t think you really need to say that each name is differe= nt/unique, right?

Agreed.=C2=A0 The text has been changed to that suggested.


>=C2=A0 =C2=A0other algorithm
>=C2=A0 =C2=A0names are simple (i.e., single-component) names.
>
> Nitty thing that you can completely ignore, but I would avoid the Lati= n abbreviation thus: =E2=80=9Cother algorithm names are simple, single-comp= onent names.=E2=80=9D

Changed.



Comments from =C3=89ric Vyncke

> Thank you for the work put into this document. It is clear and easy to= read.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will = be appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -=C3=A9ric
>
> =3D=3D COMMENTS =3D=3D
>
> There are 6 authors while the usual procedure is to limit to 5 authors= .. Personally, I do not care.
>
> -- Section 1.3 --
> It is a little unclear to me whether the "two nameservers" w= ere two implementations or two actual DNS servers.

Agreed, it was unclear.=C2=A0 Changed to =E2=80=9Ctwo name server implement= ations=E2=80=9D.


> -- Section 5.2 --
> Suggest to provide some justifications about "copied to a safe lo= cation": the DNS message was sent in the clear, why does the TSIG part= be copied in a safe location? Please define what is meant by "safe lo= cation" (Mainly for my own curiosity)

It is a bit over-specified and has been changed.=C2=A0 The text now reads:<= br>
=C2=A0 =C2=A0 =C2=A0 Upon receipt of
=C2=A0 =C2=A0 =C2=A0 =C2=A0a message with exactly one correctly placed TSIG= RR, a copy of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TSIG RR is stored, and the TSIG RR is removed fr= om the DNS Message,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and decremented out of the DNS message header= 9;s ARCOUNT.


> "cannot be understood" is also quite vague.

Changed to =E2=80=9Ccannot be interpreted=E2=80=9D.


> -- Section 5.3 --
> About rejecting request with a time signed value being earlier than th= e last received value. I wonder what is the value of this behavior if there= is no 'fudge' as well... The last paragraph of this section descri= bes this case and push the error handling to the request initiator. Any rea= son why being flexible on the receiving site was not selected ?

The fudge value is to cope with clock skew between the sender and receiver.= =C2=A0 This won't impact on the order in which the packets are received= by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-le= vel check. (It is not fool-proof - a number of packets signed by the sender= within a second of one another may have the same =E2=80=9CTime Signed=E2= =80=9D field.)

Pushing the error handling to the initiation goes back to the original RFC = 2845.


> =3D=3D NITS =3D=3D
>
> -- Section 4.3.2 --
> Is " A whole and complete DNS message in wire format." a com= plete and valid sentence?

This was also pointed out by Roman Danyliw and has been addressed.


Other changes made during editing

* There was no description of the contents of the =E2=80=9CError=E2=80=9D a= nd =E2=80=9COther Data=E2=80=9D fields were in a request.=C2=A0 This has no= w been corrected (Error is set to 0. The contents of =E2=80=9COther Data=E2= =80=9D are stated to be undefined to allow for extensions such as draft-and= rews-dnsop-defeat-frag-attack.)



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000050413405a557c9e1-- From nobody Mon May 11 01:51:20 2020 Return-Path: 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 F378A3A092D for ; Mon, 11 May 2020 01:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 dppHqEhtyZNg for ; Mon, 11 May 2020 01:51:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 25FE93A092C for ; Mon, 11 May 2020 01:51:13 -0700 (PDT) Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id 16B4A140C67; Mon, 11 May 2020 10:51:10 +0200 (CEST) To: Paul Wouters , dnsop@ietf.org References: <158828214716.7748.7938281376930754647@ietfa.amsl.com> <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <48259e06-2a5b-6629-8eb5-87955c31e03a@nic.cz> Date: Mon, 11 May 2020 10:51:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 08:51:19 -0000 On 5/7/20 6:06 AM, Paul Wouters wrote: > On Tue, 5 May 2020, Vladimír Čunát wrote: >> 1. Validation without logging. >> At the end of 3.1 you claim that mode is still useful.  When I focus on >> intentional attacks, signing a malicious DS seems among the easiest >> ones, and that can't be detected without the attacked machine doing >> logging (the DS might be served to specific targets only). > > Serving to specific targets is getting harder and harder, because we > see more and more people defaulting to not use their DHCP obtained DNS > server. And when picking another non-local server, DoH or DoT is > preventing man in the middles from replacing DS records in responses. > > So they would either have to publicly replace the DS for everyone, or > add a DS for everyone. That becomes a very visible event. If they lie to your resolver, they replace it for everyone sharing the same cache (for TTL duration).  So you say that people should hope that someone else will also obtain the same "forged" DS by chance (say, thanks to caching) and log it?  Perhaps it is an improvement... but in me personally such a setup would not inspire confidence. Speaking of non-DHCP DNS servers, if their provider promises to do all the DELEGATION_ONLY validation *and* logging (and we authenticate their servers, e.g. via TLS), that mode would actually make sense to me.  It's a bit similar to trusting your DNS provider with DNSSEC validation and not repeating it locally (though I personally prefer to do it again when forwarding), but the tradeoff seems better here: security severity is lower than bogus records and the logging surely won't be as cheap and simple to deploy. >>   Consequently >> I'm doubtful about implementing and deploying such a "half-secure" >> approach in validators, especially as the RFC draft feels very hazy >> about the way logging might be done. > > This draft is not trying to specify the DNSSEC logging. But I described > things in earlier messages already. The way we had our experimental > logging done with Linus Nordberg, is that we used dnssec-chains (RFC > 7901) as the record format for the DNS data, wrapped in the regular > append-only style transparency log using merckle trees. Perhaps it's just me, but I'd expect the RFC to contain a plan on *what* would be logged, in connection to the security assurances this should get us (without most of the technical details on how to do the logging exactly).  I think you mostly confirmed what would be logged below. >> 2. Amount of logging. >> The draft implies it would allow to very significantly decrease the >> amount of data that needs to be logged.  Zones without the bit perhaps >> won't be logged, but I hope that wasn't a significant point. > > Right. Anything without DNSSEC cannot be helped. To be clear, I meant the proposed DELEGATION_ONLY flag, but that sentence doesn't seem important. >>   The draft >> doesn't explicitly say what would be logged; my conclusion for zones >> using this bit is that "we" would need basically any authoritative (i.e. >> signed) data except for NSEC* records that have DS bit and miss opt-out >> bit.  Am I missing something? > > You would need to log the DS, and possibly log the denial of existence > of the DS record. If the delegation-only bit it set, you can further log > anything that should not have been signed but was signed, so any records > outside of the apex that are signed. But this data is already dropped > by supporting validators as BOGUS, so those hooks could be used for > logging it. It should not be common. As soon as you see any of this, > the zone is basically malicious and a public inquery should be started. > > As for opt-out, again zones without DNSSEC cannot be helped. Zones with > DNSSEC, you log the DS and the denial of existence of DS. > > When to log this is a bit similar to the CT gossip protocol that was > proposed. You log things when you see a modification (no-DS to DS or > visa versa, or old-DS to new-DS). But that is outside the scope of > this draft. OK.  Nit: I'd expect that in practice most breakages would be unintentional non-malicious errors, but they should still be only a tiny fraction of all logged data (I hope). >>   As for large TLD zones, even in best >> currently practical case the reduction seems by less than a half?  > > You are missing the point that currently resolvers cannot determine if > a TLD is delegation-only. For example, if you assume all TLDs are > delegation-only, you break things, such as .de where registrations can > be done without NS record, straight signed by the .de key. The point of > the DNSKEY DELEGATION_ONLY flag is to indicate that yes this zone does > not do this and THUS you can log these things when you see them. I was aware of that (the "zones without the bit" sentence).  I just somehow thought the plan was to significantly reduce the amount of logging *in* the DELEGATION_ONLY zones (in some "realistic" cases).  It seems that I haven't missed any substantial savings in your plans - thanks for confirmation, though I am a little disappointed, as it doesn't seem easy to pull off to publicly log roughly the whole history of most of signed records in DELEGATION_ONLY zones. Still, perhaps it's not an issue.  Adding the flag on authoritative side sounds trivial (except for initial rollover).  After it gets deployed there in some notable zones, on resolver side the logging will bring some security assurances to their clients, so I do see a chance that a part of resolvers would be willing to do the work even if it's not so little. --Vladimir (Knot Resolver) From nobody Mon May 11 05:59:33 2020 Return-Path: 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 5AD493A0A94 for ; Mon, 11 May 2020 05:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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, MSGID_FROM_MTA_HEADER=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 9zJMKOF6qzJt for ; Mon, 11 May 2020 05:59:28 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2047.outbound.protection.outlook.com [40.107.20.47]) (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 36A7A3A0A99 for ; Mon, 11 May 2020 05:59:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DIcVU9Owh79if3ZiIyHkFORRT/i+Glfs2apDnWc1AiMmmDhOnihvqjGYVfBcSGyTDc7OPd/y4NWXCIh2xHHO64/5v+2DMBJFc6B4Qxopt3I7F91rQy+2469TKnc9wW2rxArRWuumJWjCTnfBSDknjnGS6pOzj/G6i3yxAylVasBFpU7g4tjKZU2Nd2gttJkV62RqkpZfTwdsCwa9GOdgPQAg0Pe0Uu/a1aK3/Yeey5FMx+1hyo/qEqAmtAQc0ZhEVC09D/Wu1Hn+6FCeQI3VOGy9m8ZPJ2XaOoFWuiDqVuWWPsD32nkYp48PVPYklW4YWl9lCVVsKqMeeNh4dMhnLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6DEfVdN+WVI/NobOMzhijWDpZjQSuUfwzRWuhQG6n4Q=; b=i4foe1l+TkWaSdTnI8tDN4Eyg3K8ukKxi+FqURjNcuY0jHiCSSEkAR161Jvri0dtPCq2wlLcV/IZHsAbAMpwuUOQ0c8O5qa/TsgcqJvm5wGj8qV6Ec7fClUTD7c7HNVkmXuMEfCsn/JqV7kaa/hi2POLgQm8DHjDi9/pN+eVfEa4CmiyJuNNe8AIf1iqZGP++pgykpClfsWBfVkvnzZ3CmoFAFVWNs3s6YJtElF+RwrscL7jz1p22WpXVe+SnGCO7wN53/kzfJC5E2zqwz2RXNjgMIxOZFc1j/hs04Pp2ZBvXXirT9xUn5MxxwgbmgId43f3gJnqiClBMFRFYi5+qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6DEfVdN+WVI/NobOMzhijWDpZjQSuUfwzRWuhQG6n4Q=; b=GvJxrk5k7/itB/ymCMxU95k0mQPipBY1HSajOCYLAV3PXYxnmeSLenGtKEw5lfBrXIHtDh4T2qeysx5QCrNRDdR2SO6i1eI9AKpguNDVcFqF1esuq7hnlYa0LQo74PqwBH8ArI3trynM4DXIHLWD7z+ubTLv0Bd+tObp/EVXg+w= Authentication-Results: utwente.nl; dkim=none (message not signed) header.d=none;utwente.nl; dmarc=none action=none header.from=sidn.nl; Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM0P194MB0483.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:162::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30; Mon, 11 May 2020 12:59:25 +0000 Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::40dc:96f0:d873:6848]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::40dc:96f0:d873:6848%6]) with mapi id 15.20.2979.033; Mon, 11 May 2020 12:59:25 +0000 To: IETF DNSOP WG References: <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> From: "Giovane C. M. Moura" Autocrypt: addr=giovane.moura@sidn.nl; keydata= mQINBF14qwEBEAC7A6IGvwbFinLND4AFjFycPiM5Y3qudODE0kiYBPy5d4NIT4uAthSm2FPp 3kUNxMtlZI5NR0Ie/kI2NLdpS6MLpkKtO30D2GIQjaQ58emUnWAxkH94RDB5cJ69mmVxIUnv cpZEOrCvBcJU3SIhnXTfga8AFEct5Sb6XRYy8kblGXcH/6W1XTckcb4g/SejszC2oiiV3cZH HS3UCJvMfY1/6ojq6Cot6jgs/3M56PZI9odsYATu84JNaKqFv1rbD1lf7hYOM5sri6OqrPad qBOCT5DWbdxHvi6JzLNhuxxag/BtJPfLxMFDm+C6P0FKSjY78EzY6Ne2MKlLSDGQWyAHXZae X9RO/0t64LEWBLXmVS1KtIAPt0TgGodhr5d7jXP2maFmgO2+rWhGBBEeC9y9oRRJuBGFzl8w 0wMp1RDNipomtjWPZIIsuWiNKAF/iaPcTr6ZjaNOhnX+Kuqh3X7rr546RYtDDCVWVDpLKZmn 1scrRGKnhvPQsBiuICp5Up6sHNxh30c0n2PJeUZYlhLiZTuzG3rUSg7TLx7d39V4/XyjNr1p ordddIzM2zcGCNP0IgyjdMzjFljL01liMhENXmSagwDLQsOuExcZfawWviPEB2Rzz39obuxi L08RPrtnptcjkx0n6JFtkQUBOLGodtWWLs9cVF4Lic7aJswg6wARAQABtCtHaW92YW5lIEMu IE0uIE1vdXJhIDxnaW92YW5lLm1vdXJhQHNpZG4ubmw+iQJOBBMBCAA4FiEEkUlxD1iA/bYW 8LYoeMuqlaSXxY4FAl14qwECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeMuqlaSX xY7A/w/9FSp5N5rGcWe9bK8+k06e5dcxYRphMMHpC6hnrvyfgZgvepkhx9jK8HOevF1xk/Xa 8MR53fP0wo+2ZXSPJNgkzITFFypHfM2LLxh1/Lm2KnwR58OuX/E1juvOx5FseDrVjcmOL1s/ vtm0s4nlbzCSwrvBfnpsSXmQvseQHcm82Oto78p7YxgUNoxjPkaUkmekDMm8TWwctTummYfM vHzKgKSVCCBNJayRRR6+pw+UG5mnlvUgv96AwK7CUF2pjlwIFKx6cVDDD3M17ZUP6zsPQ+HB 8m0DtQFtAu1mU/OXeNk54jKm4b2A1gXwNnh11e7uPzS5hrjz9znwyTLLw1fJPySYUVMDhuu4 EI+L2Goi1DrhLunQ72YRIKHF3jVjDd6eHenk9Qq44WfuYOE1PSdIKjhS0DfOZgy/C4DWkot/ XfZ40dlaV1eLb/fjWw1/GY3FYZIxxPvFV5tg+Fjn4pqiqy2XvCBrIzMYG0X4u3A4Kvjnblh0 9G/bD8lzx6mUymDvZ/PHk8+mhp9obA+LcmLHt+lkNyR73vT1ZTrQWqrzMTlXN7guFWSOrCOm toWgVu63L9LsFKiUllkctXGhFzaERQT85h6ugovq7Bk0Qf0NBvHcwxgBdUa/uqp9Frcm4gT3 pZFepXY4Q63nL/y3Ay65rouurVPsSUTghuzgRaZ1ePq5Ag0EXXirAQEQANJeW4E1yFJ8RIdH /LUp7ZjLSQZjxLi0J6Jz8q60ZCFOEBh++i0nmYljEHG1HHqvMzv7x7EEg2ZaQmk6l8ZF4CuG oy8xjKLyM1v7k3i/GPwHEmWAKR6VxwBflE4ISL0bwecOuBubemSsQYaHBvydTg/sSkCz2YcF inec4o4Ertu4HCo0c+LlzcWWcb1/O6vUaOGCH0LBXT2btbDMzOgSBTeRCHP/aLIClkjNmvRc mQIszCCriuqlapNWTzIm8WVfD5Ho/ZyrtgeSbqk5I4by9eyAJNDKi05NgR1vY85tQ/hNIN90 8RcVK7OvGrQ9NgJpk3oFeaCkAXbhq5HfAI2tWnj3lrPLa7FP//YoYVY/Teqb+Ehp1CiVkeHf F2yGRsSWa+99Ii3nM3E8CpJu+SS/M1zbQlBgvGT+liXMfvJ/7wzAivTdIsy94uiWbLvrmF6V g6Iwq6d9O+/3j8gvcl0OXvUzNO9Qjb3+dL9hoKZ4GPUN9nYP34KcGLgdeyi0/DeKTLDODbXA scoQ+V96JmJzMW+UXkIyfq27MVyZLnJMtwD9On2/vSaNjXD2imfUbtHU0+7FvET8qzzJUBII IYz0dA5UmQx2/PKqDLh5DWdaWZa1cf6RqQ+FE10ePot+RjTU3ojiYqbzJ9Nm8WazV2ibAMg9 gozAb/oRmp7vzZURc21PABEBAAGJAjYEGAEIACAWIQSRSXEPWID9thbwtih4y6qVpJfFjgUC XXirAQIbDAAKCRB4y6qVpJfFjo9sD/9iqHO8MMaMBhefBJs5imU+TMarHto+OLfsnGTQarqH GfyvCB6LmY0ZP92jXtMe9hx0dt8SrlGOtwsFoqcvSk5L5yaFde1aG2o3a21mlcyMRhljzME9 RgnN61pB/rfg8yjbxNbhBgKjQCO/2fyJIcp9Er2qKmJYGV7UkP3Fl5SHMs6Z9IiDhRQjhpKZ iXRpQUofHggErvV7//j8ALLEReVjfEg049EZ1U5VQosroXzkbSPfpAHjW4d+MdCM38WYC3Ap fk7qY1vZV3YTj/eD7j4b772xMMlUdPm6Vl83sAY/OP5ZFCe/f8HUwaRYm6zwhnRug8tI2g05 N3/yBVbmc047gtXTFuW0ZhHkN26rSl6e+gtfhoh0CigfixHRFI6TWrtF5APVxW+WJ1N990w1 RXXHCn8ZGVJ9u8sglWPSWwK8vVhhbZQVtPUkUegN0Zj7nqHz+5nHtqsF6ddIN65akf+CqArU /iVwvA5gsvid2vyunM88MlUplJBmAXtMEyCpvTyfDTT7jYY15ZpaO3jlHyiagwVhVrxgsw+B N0RmT/zoqKN33zuhSmrxw0+vU+gq2BZLjpjZRnnjeoFwKo3qNWKx7BRTxzOG5eMoGzrvO7dF Xt5QjjOQ4cFtq4ryW8qDfmDd4mLYyMcRO/hOPPq30pW9emtiXFABb8JvwfEusod+mQ== Message-ID: Date: Mon, 11 May 2020 14:59:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR10CA0033.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::13) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.172] (31.21.111.111) by AM0PR10CA0033.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26 via Frontend Transport; Mon, 11 May 2020 12:59:25 +0000 X-Originating-IP: [31.21.111.111] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bbb9ef2f-dd25-4b18-cb81-08d7f5ab21f1 X-MS-TrafficTypeDiagnostic: AM0P194MB0483: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 04004D94E2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AyioIcuxojK5I9K8OWS+YwBTLpbNm3aHlUkLQS5BwG/XeUMBHFiTwoPFCnQ0ly3ECfIVPyQ94QDYwTZIu1IdhclVJ3Iv6dkla7znGANHbHGo6dQi22Ie7+yoLPTVLdcryotu+xwlk3S+yVFkrc35TmpIi2XZkc+j3RYCt3KLd+64S8TDR2Y+ey/WkWyDa5DPMEJK8KDQBynoqe5AXlz56nx5hR7dn7XSCoEw7Usu2tuDGscNQQ4NSjruDHT3z6R9RzavtG72TS/67WrdNYtQkgfvkko9IguXaVPexIAGsVqQ9z2gyijifniTycMHw5P80n0il8iPbQWzVoMwInicf33ajI4YNYWn+XDa14vmJp3OILESwSq+F02Hyg+uN60lEG6KlIM9tSuILUA2KdVlHi0YmLzL2ouuN5U8zbP6Cvx6Y0QZBO/EcHIJAf4JYB7xRVfuMWhsD5x18LTDJ6G+D2ZyUpXFKtN9BdFpPJIBcbW5i8aQme1SYxs0zAm0sEP9Q5c9OPihap31vqJpiraolZtV4YxP+STYMs4a0WTbPHSj+bo/kB2k5K5EyLU/QoJiLOKPv6N5J3Sg2uQwQLujivBSkuw9HvRDpTABnFXEUs68cPbUK0Y7SL2UNg9MwzK4 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(376002)(39840400004)(396003)(136003)(33430700001)(6486002)(186003)(16526019)(5660300002)(26005)(52116002)(16576012)(316002)(966005)(2616005)(956004)(33440700001)(31686004)(4744005)(83080400001)(31696002)(86362001)(478600001)(8936002)(36756003)(66556008)(6916009)(66476007)(66946007)(8676002)(2906002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: bbJ2QTb0lJq1e3VqFoMEdI/Yjml214G8aPmHjUmwL4t1N6ghn/SVTUFgQUFc8vfKcCTKTJkG0iUDimP3DUX7TaK14hfkNkjOJ2QI3e4/SyTiCdKiyMnKMpXnG7x1cRsumpDxRUqPazOjFNt4bHDw5MZkf9CT3uVuCBg/yuIoO/YUWH/rlklLabGT5K/lzt/qKC5Bf9cdpogvqyufsp564I5G8LcQdh1L3MKO0bc/XmCU4qiztLu4c1VTNVx64hPLF+sZkzQn+3x8FXFf8MvoF25qqgOxjcTATQQyxn9rFPROW4YWv2uGb7Y+GfCzjZTboHU0tRBh2e4YoPcf+vddBRdEtNMVxDiIAg4pyo08kTrFzSk6B6kFmZqxcl+7SLompE9c3N9HV1lyfY0dqSMsKZOrQVu8TyTfN+4AfXwlV2Cwq73cYEHQD9a/tgAIrSjLypMWrw+L9G6Yc1Hx57wl1ZJztVuv9F4mFSBpl+bD+mzRyS8mZkzB34VDvMaHH0Oe X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: bbb9ef2f-dd25-4b18-cb81-08d7f5ab21f1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2020 12:59:25.5470 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ydgK0QAJCve8V4hE4o5SJUUpfZeflqpMv+QgIedc02EPT0yvBN2FM7i1RV1HmjvHuciAwv1JbQsK4cvOl4g+fA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0483 Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:59:31 -0000 >> Do you plan to maintain the parent/child disjoint NS  >> domain (marigliano.xyz ) going forward? And what >> about the test >> domains for other types of misconfigurations? > > Great idea. Let me look into this, will get back to with that. Done. Check http://superdns.nl :) Marco and I (mostly Marco, I've got say) set up this website and all the delegations/records that replicates the setup of the paper. We did under a diff domain for sake of simplicity for us and differently from the paper, we create 4 delegations, each one corresponding to one of the scenarios (in the paper we change the NS configurations in between experiments, we want a static setup here for folks to test). Hope it helps and if you need any help, let me know. /giovane ps: Raffaele, the first author of our paper, will present the study on RIPE80 on Tuesday's plenary: https://ripe80.ripe.net/programme/meeting-plan/plenary/#tue4 , in case you want to check it out From nobody Mon May 11 06:00:33 2020 Return-Path: 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 8C8603A0A9A; Mon, 11 May 2020 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 pkiipC3NtroW; Mon, 11 May 2020 06:00:25 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 1934A3A0B83; Mon, 11 May 2020 06:00:06 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id h30so5490882vsr.5; Mon, 11 May 2020 06:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i+XBi6gIU9CRcceF/t3cD28/6jiEK7KZfICtZtHIrZc=; b=QtvNpRw16U/Ae5N2tgJaHz+g94+nUmwROXIWrzYKUbn/sdMO5fs3sNY31+ZqEH0sSF Dc3B7zyKc/zWBslystIhfXeCJswsTv13JR0//fBOB5oLuaJODnyg7bJXIVxjN3rtHZzH fxD++L9LIOAT61cLwok2mJFf+IhW5aFJ6ej1YPd8EW3Q/43Dgwz+HPEvvNjBz1RutsuZ fBB/5cYpjbQJmsizza1ovkcgh7TMBEiWDaLmRCYZEkSstbFjpbuoc/klku1l4/l8sY3y thtJzMiFPmgzLvw7MiDp7dWCnj6/ACDGT2EgcNUZpNddkdu6mtTc8gHuDR8x/vCRgPCw atFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i+XBi6gIU9CRcceF/t3cD28/6jiEK7KZfICtZtHIrZc=; b=LfkXSb9tMctqTPoK+5NdDwHCkyTM1COc3MdKaN0Tz132r4nbdWY4e0xn6NVpilOfIJ wEzhgITC4iVC4nelFOmXL/VJzz51oVBZJZTBGdfjfpDonizn8fbrnwSlJxa/kzvUjPOg qUvI5KvSoWrzD3EAuFKBnBRKJHeMd7Uji03NxdE+xKa6akqcmPh7GoP2nGKcte5NSEFp 1RJXqkFek1pYMYQ4zT0aH3/TevPhw734WDIPbc+updPMKQza0PYJcQsdjii7i5tUptl/ /J/BfhZd1T7BtbFwv3NcpjzYBa11IyMIEIZ1ETts4D3NkLPjxaXyr1EBDR3Ve877J+1z YdEw== X-Gm-Message-State: AOAM530P498Ttq5JC+uioPMID3lXxfHIvfZOgwwHd2hfJaN2dy5QUf98 FwD9Xt5+W+f0K4ftMY0h0ttsDnUXKsnTbaXYcB0= X-Google-Smtp-Source: ABdhPJwbef1pm6bJi1LWJPTlNYEnrh3fg2gjZJpnp8QCyOXsxvmp2C69H1bvt1ukieduAcyQ1I3M5vIPAoms1hx2LMQ= X-Received: by 2002:a67:ea45:: with SMTP id r5mr698940vso.69.1589202004936; Mon, 11 May 2020 06:00:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Mon, 11 May 2020 08:59:53 -0400 Message-ID: To: Brian Dickson Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000fb0dc405a55eecd9" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 13:00:31 -0000 --000000000000fb0dc405a55eecd9 Content-Type: text/plain; charset="UTF-8" Thanks Brian. That is really much appreciated! Yours, Daniel On Thu, May 7, 2020 at 1:56 PM Brian Dickson wrote: > > > On Mon, May 4, 2020 at 12:10 PM Tim Wicinski wrote: > >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for >> draft-mglt-dnsop-dnssec-validator-requirements >> >> The draft is available here: >> https://datatracker.ietf..org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> >> >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> > > I support adoption of this draft by DNSOP.. I am willing to review. > > Brian > > > >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 18 May 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --000000000000fb0dc405a55eecd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Brian. That is really much appreciated!
Yours,= =C2=A0

Daniel

On Thu, May 7, 2020 at 1:56 PM = Brian Dickson <brian.pe= ter.dickson@gmail.com> wrote:


On Mon, May 4, 2= 020 at 12:10 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:


All,

As we stated in the meeting and in our chai= rs actions, we're going to run
regular call for adoptions over next = few months. =C2=A0
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-mglt-dnsop-dnssec-valid= ator-requirements

The draft is available here: https://datatracker.ietf..org/doc/draft-mglt-dnsop-dnssec-v= alidator-requirements/


Please review this draft to see if yo= u think it is suitable for adoption
by DNSOP, and comments to the list, = clearly stating your view.

= I support adoption of this draft by DNSOP.. I am willing to review.

Brian

=C2=A0
Please also indicate if you are willing to contribute text, = review, etc.

This call for adoption ends: 18 May 2020

Thanks,=
tim wicinski
DNSOP co-chair

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--000000000000fb0dc405a55eecd9-- From nobody Mon May 11 06:04:34 2020 Return-Path: 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 8D2F63A0A03; Mon, 11 May 2020 06:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 VIixckCWHF3N; Mon, 11 May 2020 06:04:28 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 94A263A0AA0; Mon, 11 May 2020 06:04:28 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id g2so5513894vsb.4; Mon, 11 May 2020 06:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zH3d6jEQMkFYDcoSNt4MJ+R5K41YktvB4NzdcMt0HtA=; b=arWFm9yxCAVl6BNo6OlgGsjVvePHnbEwGPwhj4aEjCVtPLYPMyxZw8yzTRws54Swpf WQFgjotmmJdYc3Et1i1rbH6+6jS994jWowYwXbxHJURZvS1sF8rxg7w8m/AMoMeq8HFt tDr2zFr7NFf9997JTGdRau64YqdoKFZwORHVqC4U1eunBlBwdeH421eRxiOV0LgelB8d 6bHlU1jfGnXEdSfRGvSnyDv4V0QBXBJ6D30tjPAp8P2pu1kIindRrpyZgDE0W6wqOJ2b xCdVnChji11/nIfUbg+7orClTsEoYC2c+mJEnBOkjvlns7AauEQZcyH8ko9Uvr6O0wX9 IEoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zH3d6jEQMkFYDcoSNt4MJ+R5K41YktvB4NzdcMt0HtA=; b=FhYMhlmMIIDcFjoaR28odptU3gGSZHK8ZKA5nP3tSScJbOHiDcY+CSVZh9d//1M2ff MLcKNjvXLsIBrCHiGbXUpxt6e63aNMzAiE+VgCuJ74BfRJw/prRTM4huAECmBzf3vfyp 9UT9/Ab3mDLuPwuf4ob/UoQUVXNdbJflDBXryjSbex/6r7HrLTpWVhlMPiVYpdFBFYcI znqiuhgPNeSdM8EZITg8z3zRiFf+HXEDBdj6wJ9E0a7ZqGEMgLdVn4D+7JkvjCL7bnxG Eo8lLhb16dkGRZE69+VVAe61LbWA3hvVBqXyk4BQspVno0dtmaBdpLs9momVIOinaKTX undw== X-Gm-Message-State: AGi0PuYKYKxgxVVG3Fw6Ng5lL2IpsIJk8mdoHGVtaFUekUfmqQQxcnP2 au3+bEZ31wJwe4e00RfoRwH++y6B8hCqyZNKdsU= X-Google-Smtp-Source: APiQypK/izxaR72/GR4fS/3OtA43AEyIb/chkdnj39ZHLlvp02Tg8gAYv0pwxiOxFQksA544pB07IYpCvCdTqkrdtF8= X-Received: by 2002:a05:6102:3117:: with SMTP id e23mr10760055vsh.97.1589202267506; Mon, 11 May 2020 06:04:27 -0700 (PDT) MIME-Version: 1.0 References: <42A20E19-C43C-4093-8483-07B0A85386E3@hopcount.ca> In-Reply-To: From: Daniel Migault Date: Mon, 11 May 2020 09:04:16 -0400 Message-ID: To: Tim Wicinski Cc: Joe Abley , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000a1b18905a55efce4" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 13:04:32 -0000 --000000000000a1b18905a55efce4 Content-Type: text/plain; charset="UTF-8" Hi Tim, Just to clarify, I fully agree there is a lot of similarities and we will work on it with Joe. Yours, Daniel On Thu, May 7, 2020 at 8:16 PM Tim Wicinski wrote: > > Daniel > > Thanks for taking Joe's draft under advice and I agree there is work to be > collaborated on. > > Tim > (speaking as a chair) > > On Thu, May 7, 2020 at 3:42 PM Joe Abley wrote: > >> Hi Daniel, >> >> On 7 May 2020, at 15:39, Daniel Migault wrote: >> >> > Thanks for putting the reference of that draft. I have always thought >> that the draft you were mentioning was the one that became RFC7958. >> >> 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is >> entirely reasonable! >> >> > The current draft mentions that TA should be associated with >> bootstrapping mechanism and that boostrapping for the root zone should be >> extended to other TA. >> >> Yep. >> >> > There are clearly some overlap between the two drafts and I also have >> the impression the drafts can be merged. >> > the following issue has been opened: >> > >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7 >> >> Happy to help with that if it's something that the authors/working group >> decide is useful. >> >> I support adoption of this draft, now that I've read it properly. >> >> >> Joe >> > -- Daniel Migault Ericsson --000000000000a1b18905a55efce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim,=C2=A0

Just to clarify, I fully= =C2=A0agree there is=C2=A0a lot of similarities and we will work on it with= Joe.

Yours,=C2=A0
Daniel=C2=A0

On = Thu, May 7, 2020 at 8:16 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:

Daniel

Thanks=C2=A0for taking Joe's draft under advice = and I agree there is work to be collaborated on.

Tim
(speaking=C2=A0as a chair)

On Thu, May = 7, 2020 at 3:42 PM Joe Abley <jabley@hopcount.ca> wrote:
Hi Daniel,

On 7 May 2020, at 15:39, Daniel Migault <mglt.ietf@gmail.com> wrote:

> Thanks for putting the reference of that draft. I have always thought = that the draft you were mentioning was the one that became RFC7958.

7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is entir= ely reasonable!

> The current draft mentions that TA should be associated with bootstrap= ping mechanism and that boostrapping for the root zone should be extended t= o other TA.

Yep.

> There are clearly some overlap between the two drafts and I also have = the impression the drafts can be merged.
> the following issue has been opened:
> https://github.c= om/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7

Happy to help with that if it's something that the authors/working grou= p decide is useful.

I support adoption of this draft, now that I've read it properly.


Joe


--
Daniel Migault
Ericsson
--000000000000a1b18905a55efce4-- From nobody Mon May 11 10:44:07 2020 Return-Path: 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 80FEF3A0B4D; Mon, 11 May 2020 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 M2rNP55nLDQ0; Mon, 11 May 2020 10:41:33 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 007033A0AA4; Mon, 11 May 2020 10:41:31 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id x16so2118403oop.13; Mon, 11 May 2020 10:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=yKvTQevPWLHGXLlR0eKiGocy8CupDaN1uHbZ8OWeg38=; b=OPRkF4kJ+y5C1fRk/NOB9VMckBjnqHUDdmEBHTmLUGnmP7fk+2DUYFU3TshTYxIigp tJDHiW8e/37ac4WiGTKgGOo5LYeLhkmXsHg1vCU5C6EVSsRQDwG6TgJ01mL+ItEKdRzG 6UfBINueyuQHEWlOoRJu+ryhlWj9PPf4ac/S0KYm95yJkkKNUOtJZmSehTTLl2/UZm64 YL9WeNa+MKqNXz5xvMZdiBa6WcSSRWFsb7EbpiLkreOyOP9tovK4CZoJjqdgwI1udj/+ NEbvv6m7fwstASAr+xO6mRl94bpOsjUS24DMSSx6y7m7+iGPCUl6p0N8SVu6g7yJgOfl xFwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=yKvTQevPWLHGXLlR0eKiGocy8CupDaN1uHbZ8OWeg38=; b=YKV6ef2jkFcZvC+dt2OtLOuKyXfXtDQRV495trfL2BnFdpxn8mUfm1mOVvWuoYJPyg a5RNIzrjSQMpzISjZ/AoR7ExSAgA8PvFa33YLLtifkwf7uEKns6pHlseS+HOfFJe70Du Ek8S7Zp/cgiNMG+XQVqDTeNchxlsNjtII4kX/XuHB5LbB/e5hc7G4if6b98K4N5ZBMeM V51bHE36njy+5hc6/r5Ysu2B4Ljj6ZLHpGm3XzGRT97+3JXrzw2yEy/6yl9aavb+QrQ6 OlQfibes4Yk0MtW4aaY8wQ2hNvPpEAyVmAUiSyITCNVytCMquwtdIKTYR7zriRtZwxxp ZOJA== X-Gm-Message-State: AGi0PuaeTV81m0CyJ4eAkZ88p8+B7gZPohUD4ZKGNZwGqSa4+SFEZH/q CxpwVmpbd67GySlLOzs6PYYbtFMjBto3QvkRBD+LiVQLVWo= X-Google-Smtp-Source: APiQypLIuIgRvDo+VQ26tWMQySTCOHR14kdnOcfLSYgCZ2hTM5IyJ+JheZ8l4FiygMUo7bqaKS6NcxlscPbYSQA8ioc= X-Received: by 2002:a4a:a54a:: with SMTP id s10mr14922354oom.73.1589218889820; Mon, 11 May 2020 10:41:29 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Mon, 11 May 2020 13:41:19 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="00000000000065efa605a562dbf5" Archived-At: Subject: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 17:41:45 -0000 --00000000000065efa605a562dbf5 Content-Type: text/plain; charset="UTF-8" All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 25 May 2020 Thanks, tim wicinski DNSOP co-chair --00000000000065efa605a562dbf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,

As we stated in the meeting and in our chairs actions, w= e're going to run
regular call for adoptions over next few months. = =C2=A0
We are looking for *explicit* support for adoption.


Th= is starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
<= br>The draft is available here: https://datatracker.ietf.org/doc/dr= aft-toorop-dnsop-dns-catalog-zones/

Please review this draft to = see if you think it is suitable for adoption
by DNSOP, and comments to t= he list, clearly stating your view.

Please also indicate if you are = willing to contribute text, review, etc.

This call for adoption ends= : 25 May 2020

Thanks,
tim wicinski
DNSOP co-chair


<= br>
--00000000000065efa605a562dbf5-- From nobody Mon May 11 10:52:32 2020 Return-Path: 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 B5ED13A0ACF for ; Mon, 11 May 2020 10:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 muh05mA8eVhq for ; Mon, 11 May 2020 10:51:46 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 4BEB73A0854 for ; Mon, 11 May 2020 10:51:45 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id m18so8233816otq.9 for ; Mon, 11 May 2020 10:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GVH+ulxRJ3jQNLK6dJLMZnTN4Sj5jOYPnpyMHQ1F8vo=; b=Bpith+d4WyILNVHzDdHqiIsCJ8Aes3ZzuLwQoLWqCVwjUjSOGNM847VuFqY+2f82rU Nx967b+zoqDo+LlstB3zy/vMm6321BKMRKOdo2rDSaK/B1zPcUoSUEYTMnW6uVm+RXCe XML9k2actePnZ0GhXYFhYFOYobSHsbssb7Han+UBDjZJe9Mmtlc+kB6p36KtNYRTSNOd DBEM4ol3P81i6Xx5tG9VAQxdxKDFegNqOoMFCUnEf1Dl+vWnEwXuTGKl+SxJk2RX/79d qfa3N+rqEG7yn/UCY0Pi5WjANqcQdaOzuB4Is+Nh6++v5D/oNNkfZRMZAjGvNlpPNkKx h2JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GVH+ulxRJ3jQNLK6dJLMZnTN4Sj5jOYPnpyMHQ1F8vo=; b=M5PL+oovc5QrVG/sDeaiOdNU7DqWICKVdJZAMbyVCU2uwjz1poC1MNtUoTRlGq4cmi stEGKUfLBuk/HyC0/mO+jlEulSoIY67G568tgXNvnzjCxICsGopg+1GDuXiihd9hv8om t/Y77N8DNP+CqGntbbTqzMOLagU1sw9StXrLzsqmiQIkhq5vOX7rOMgPZ7k6zl1G1XUA HLLw4xe4hLUzaDSS33EVbV1EPoN2xRZhTxoJMpg95aU43+DlzAeQnTyz3bFtG+xXgdBD Gm7a9doJZDz1Q4XDX6WgrXbZVjvigJRUDN/IhKvAhEuGpgLzqgB+9zwt6TVdTrnKShgG E+2g== X-Gm-Message-State: AGi0PublGTOhKVGBfPC0VUEcSp6Yd/chhEfTJ+agTtTC24HZPp02kOwt dWJnCCuJ5avK0lffSYeg2me/2CXwdJz9VH0QUwI= X-Google-Smtp-Source: APiQypKYEG9ZdJCt6XWpwkCu50QXw25vpklsU4RfKnoYaFG7RsCm+zQA6sh/CCVdsCuSEgH1OwThwNj1DqrY3f6sY1o= X-Received: by 2002:a9d:620c:: with SMTP id g12mr13849593otj.158.1589219504300; Mon, 11 May 2020 10:51:44 -0700 (PDT) MIME-Version: 1.0 References: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> In-Reply-To: From: Tim Wicinski Date: Mon, 11 May 2020 13:51:32 -0400 Message-ID: To: Donald Eastlake Cc: Stephen Morris , dnsop Content-Type: multipart/alternative; boundary="00000000000006285005a5630063" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 17:51:58 -0000 --00000000000006285005a5630063 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Donald So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ? On Mon, May 11, 2020 at 12:29 AM Donald Eastlake wrote: > The incremental effort to implement SHA-224 if you are implementing > SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT > RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use > and you can use SHA-256 with truncation to 224 or even fewer bits. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > On Sat, May 9, 2020 at 9:52 PM Tim Wicinski wrote: > >> To follow up on Stephen's comments, a table was added to 2845bis to >> list all the algorithms that are currently in the IANA registry, >> along with suggestions for implementation. This was the first version: >> >> Requirement Name >> ----------- ------------------------ >> Optional HMAC-MD5.SIG-ALG.REG.INT >> Optional gss-tsig >> Mandatory hmac-sha1 >> Optional hmac-sha224 >> Mandatory hmac-sha256 >> Optional hmac-sha384 >> Optional hmac-sha512 >> >> During the IESG review (I think it was the SECDIR review), there was >> a meltdown over implementing SHA-1. But SHA-1 is in use currently. >> My suggestion was to do a variation describing implementation use. >> This is what I came up with(so blame me): >> >> Name Implementation Use >> ------------------------ -------------- --------------- >> HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT >> gss-tsig MAY MAY >> hmac-sha1 MUST NOT RECOMMENDED >> hmac-sha224 MAY NOT RECOMMENDED >> hmac-sha256 MUST RECOMMENDED >> hmac-sha256-128 MAY MAY >> hmac-sha384 MAY MAY >> hmac-sha384-192 MAY MAY >> hmac-sha512 MAY MAY >> hmac-sha512-256 MAY MAY >> >> On the use side, these are mostly guesses. We would love to hear >> what the WG has to say about this. >> >> thanks >> tim >> >> >> On Mon, May 4, 2020 at 2:07 PM Stephen Morris >> wrote: >> >>> >>> > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> > This draft is a work item of the Domain Name System Operations WG of >>> the IETF. >>> > >>> > Title : Secret Key Transaction Authentication for DN= S >>> (TSIG) >>> > Authors : Francis Dupont >>> > Stephen Morris >>> > Paul Vixie >>> > Donald E. Eastlake 3rd >>> > Olafur Gudmundsson >>> > Brian Wellington >>> > Filename : draft-ietf-dnsop-rfc2845bis-08.txt >>> > Pages : 29 >>> > Date : 2020-05-04 >>> >>> >>> The update addresses to the draft comments made during the IESG review. >>> There were a fair number of these which led to a number of changes to t= he >>> document. These are listed below. >>> >>> One significant change is that the list of acceptable algorithms has >>> been extended, and WG approval for this is sought. >>> >>> Stephen >>> >>> >>> >>> >>> Comments from Roman Danyliw >>> --- >>> > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly foll= owing >>> that document (and the related [RFC4635]) were discovered to have secur= ity >>> problems related to this feature=E2=80=9D, consider providing a referen= ce to the >>> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) >>> >>> I=E2=80=99ve added these (and one other related CVE) as informative ref= erences. >>> Using just the CVE number as a reference seemed a bit spartan, so I=E2= =80=99ve >>> added a title to each incident. As the description of the CVEs in Mitre= =E2=80=99s >>> database don=E2=80=99t contain a title (only a description, which can b= e rather >>> long), I=E2=80=99ve taken the title from ISC=E2=80=99s KnowledgeBase (f= or the BIND CVEs) >>> and from the Knot release notes (for the Knot CVE). >>> >>> >>> > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated s= o the MD5 >>> security considerations apply to SHA-1 in a similar manner. Although >>> support for hmac-sha1 in TSIG is still mandatory for compatibility reas= ons, >>> existing uses should be replaced with hmac-sha256 or other SHA-2 digest >>> algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>> > >>> > -- It=E2=80=99s worth repeating those MD5 security considerations her= e >>> >>> I=E2=80=99m not really keen on doing this, since the security considera= tions in >>> RFC 6151 cover two paragraphs and including them - or even a summary of >>> them - would detract from the flow of the document. However, I have >>> explicitly included a reference to RFC 6151 in the text. >>> >>> >>> > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it= =E2=80=99s worth >>> including references to the recent SHA-1 cryptoanalysis provided in the >>> SECDIR review >>> >>> Added references to just one of these papers (=E2=80=9DSHA1 is a Shambl= es=E2=80=9D). >>> We=E2=80=99re not doing a general analysis of the algorithms, so a simp= le reference >>> to a paper than describes a SHA1 collision is all that is needed. (As = an >>> aside, the paper doesn't give the date of publication, so I had to sear= ch >>> the Web looking for references to it. I think I=E2=80=99ve got the dat= e correct, >>> but I=E2=80=99d be grateful for a double-check.) >>> >>> >>> > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). >>> >>> Done - see Table 2 >>> >>> >>> > ** Section 10. Per =E2=80=9CFor all of the message authentication co= de >>> algorithms listed in this document, those producing longer values are >>> believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR r= eview, this could be >>> misconstrued as the algorithm choice not the digest length provides the >>> security. Recommend rephrasing (or making some statement >>> >>> I=E2=80=99ve reworded this paragraph (in section 10). It now reads: >>> >>> "Although the strength of an algorithm determines its security, there >>> have been some arguments that mild truncation can strengthen a MAC by >>> reducing the information available to an attacker. However, excessiv= e >>> truncation clearly weakens authentication by reducing the number of >>> bits an attacker has to try to break the authentication by brute >>> force [RFC2104]." >>> >>> >>> > ** Editorial >>> > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message, t= his is >>> the message after the TSIG RR and been removed and the ARCOUNT field ha= s >>> been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (is mis= sing a word). >>> > >>> > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in w= ire >>> format.=E2=80=9D, this isn=E2=80=99t a sentence. >>> >>> Section 4.3.2 has been reworded to address these issues. >>> >>> >>> >>> Comments from Benjamin Kaduk >>> >>> > Thanks for putting together this update; it's good to see the securit= y >>> > issue getting closed off in the udpated spec, and progression to full >>> > Internet Standard! I do have several substantive comments (as well a= s >>> > some minor/nit-level ones), many of which are listed here at the top >>> but >>> > a few of which are interspersed in the per-section comments. >>> > >>> > >>> > I considered making this a Discuss point, but it should be pretty >>> > uncontroversial and I trust that the right thing will happen even if = I >>> > don't: there's a couple lingering remnants of SHA-1 being the >>> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 a= nd >>> > 10 (further detailed in the per-section comments). >>> >>> The document now mentions SHA1 collisions and notes that the MD5 >>> security considerations apply to SHA1. It also mentions that support f= or >>> SHA1 is mandatory for compatibility reasons but in existing uses it sho= uld >>> be replaced by a stronger one. >>> >>> >>> > I also initially had made the following point a Discuss-level point, >>> but >>> > decided to not do so since I don't remember any BCP-level guidance >>> > relating to cross-protocol attacks. Nevertheless, I strongly encoura= ge >>> > the authors to consider that cryptographic best practice is to use an= y >>> > given key with exactly one cryptographic algorithm. The record forma= t >>> > listed in Section 4.2 has the key name and algorithm as separately >>> > conveyed, which would allow for a given key to be used with all >>> > implemented algorithms. We should include some discussion that it's >>> > best to only use a single algorithm with any given key. >>> >>> The following text has been added to the Security Considerations sectio= n: >>> >>> "To prevent cross-algorithm attacks, there SHOULD only be one >>> algorithm associated with any given key name." >>> >>> >>> > We also have a 16-bit wide field for "Fudge", which (since it counts >>> > seconds) corresponds to a maximum window of something like +/- 18 >>> hours; >>> > it's hard to believe that we really want to give people the rope to >>> > allow for that much time skew. (Yes, I understand that implementatio= ns >>> > will set something sane in practice but that doesn't necessarily mean >>> > that the protocol still has to allow it.) >>> >>> That was set in the original RFC 2845. Although I agree with the >>> comments, changing the size of that field would be a significant >>> undertaking. However, section 10 does state that the RECOMMENDED fudge >>> value in most circumstances is 300 seconds. >>> >>> >>> > Our authoritative list of algorithm names (Table 1) is rather divorce= d >>> > from the references to be consulted for the individual hash algorithm= s >>> > to be used with the HMAC procedure. The ones used here are >>> sufficiently >>> > well-known that I'm not terribly concerned about it, though. >>> >>> The first paragraph of the IANA considerations section lists the >>> algorithms and references to where they are described, and I didn=E2=80= =99t want to >>> duplicate the information. >>> >>> >>> > Abstract >>> > >>> > The title says "DNS" but maybe the body of the abstract should as wel= l? >>> >>> In the abstract, changed: >>> >>> "It can be used to authenticate dynamic updates as coming from an >>> approved client" >>> >>> to >>> >>> "It can be used to authenticate dynamic updates to a DNS zone as coming >>> from an approved client" >>> >>> >>> > Section 1.1 >>> > >>> > Some of this language feels like it might not age terribly well, e.g.= , >>> > "this can provide" or "[t]here was a need". >>> > >>> > addresses that need. The proposal is unsuitable for general server >>> > to server authentication for servers which speak with many other >>> > servers, since key management would become unwieldy with the number >>> > of shared keys going up quadratically. But it is suitable for many >>> > resolvers on hosts that only talk to a few recursive servers. >>> >>> Changed to: >>> >>> "The authentication mechanism proposed here provides a >>> simple and efficient authentication between clients and local >>> servers >>> by using shared secret keys to establish a trust relationship >>> between >>> two entities. Such keys must be protected in a manner similar = to >>> private keys, lest a third party masquerade as one of the >>> intended >>> parties (by forging the MAC). The proposal is unsuitable for >>> general >>> server to server authentication for servers which speak with ma= ny >>> other servers, since key management would become unwieldy with >>> the >>> number of shared keys going up quadratically. But it is suitabl= e >>> for >>> many resolvers on hosts that only talk to a few recursive >>> servers.=E2=80=9D >>> >>> >>> > Should zone transfers be mentioned here as well? >>> >>> Zone transfers are mentioned in the preceding paragraph. >>> >>> >>> > Section 1.2 >>> > >>> > I don't understand the motivation for changing terminology from MACs = to >>> > "signatures"; they're still MACs even though they're transaction-base= d. >>> >>> The mention of signatures in section 1.2 is intended as a link between >>> the name of the RR (TSIG or Transaction Signature) and the term MAC use= d in >>> the rest of the document. >>> >>> >>> > MAC of the query as part of the calculation. Where a response >>> > comprises multiple packets, the calculation of the MAC associated >>> > with the second and subsequent packets includes in its inputs the M= AC >>> > for the preceding packet. In this way it is possible to detect any >>> > interruption in the packet sequence. >>> > >>> > I suggest mentioning the lack of mechanism to detect truncation of th= e >>> > packet sequence. >>> >>> That is a fair point. I=E2=80=99ve modified the last sentence to read: >>> >>> "In this way it is possible to detect any interruption in the packet >>> sequence, >>> although not its premature termination." >>> >>> >>> > Section 4.2 >>> > >>> > NAME The name of the key used, in domain name syntax.. The name >>> > should reflect the names of the hosts and uniquely identify t= he >>> > key among a set of keys these two hosts may share at any give= n >>> > time. For example, if hosts A.site.example and >>> > B.example.net >>> > >>> > share a key, possibilities for the key name include >>> > .A.site.example, ..B.example.net, and >>> > .A.site.example.B..example.net >>> . It should be possible for >>> > more than one key to be in simultaneous use among a set of >>> > interacting hosts. >>> > >>> > I'd suggest adding a note along the lines of "This allows for periodi= c >>> > key rotation per best operational practices, as well as algorithm >>> > agility as indicated by [BCP201].=E2=80=9D >>> >>> Added. >>> >>> >>> > The name may be used as a local index to the key involved and >>> > it is recommended that it be globally unique. Where a key is >>> > >>> > (nit?): this feels more like a "but" than an "and", to me. >>> >>> Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D >>> >>> >>> > * MAC Size - an unsigned 16-bit integer giving the length of >>> > MAC field in octets. Truncation is indicated by a MAC siz= e >>> > less than the size of the keyed hash produced by the >>> > algorithm specified by the Algorithm Name. >>> > >>> > nit: I would suggest "output size", as there are potentially a few >>> > different sizes involved (key size, block size, and output size, for >>> > starters, though I think the possibility of confusion here is low). >>> >>> I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference= to this field, >>> and the other size mentioned - that of the keyed hash is, I think, also >>> unambiguous. >>> >>> >>> > * Other Len - an unsigned 16-bit integer specifying the leng= th >>> > of the "Other Data" field in octets. >>> > >>> > * Other Data - this unsigned 48-bit integer field will be >>> > empty unless the content of the Error field is BADTIME, in >>> > which case it will contain the server's current time as th= e >>> > number of seconds since 00:00 on 1970-01-01 UTC, ignoring >>> > leap seconds (see Section 5.2..3). >>> > >>> > I'm slightly confused at the interplay between the explicit length >>> field >>> > and the "empty unless" directive. Does this mean that the only allow= ed >>> > values in the "Other Len" are 0 and 6? Does "empty" mean >>> "length-zero=E2=80=9D? >>> >>> I=E2=80=99ve rewritten this slightly in a bid to make it clearer that = =E2=80=9COther >>> Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80=9D is zer= o. >>> >>> >>> > Section 4.3.1 >>> > >>> > Only included in the computation of a MAC for a response message (o= r >>> > the first message in a multi-message response), the validated reque= st >>> > MAC MUST be included in the MAC computation. If the request MAC >>> > failed to validate, an unsigned error message MUST be returned >>> > instead. (Section 5.3.2). >>> > >>> > side note: while Section 5.3.2 specifies how to create an unsigned >>> error >>> > message, it looks like Section 5.2 (and subsections lists specific >>> > RCODEs that are to be used. >>> >>> That is the case. Section 4 is a description of the TSIG RR and its >>> fields. Section 5 describes the contents of the fields in various >>> situations (client transmission, server reception, server transmission, >>> client reception). >>> >>> >>> > Section 4.3.2 >>> > >>> > When verifying an incoming message, this is the message after the >>> > TSIG RR and been removed and the ARCOUNT field has been decremented= . >>> > If the message ID differs from the original message ID, the origina= l >>> > message ID is substituted for the message ID. (This could happen, >>> > for example, when forwarding a dynamic update request.) >>> > >>> > I trust (based on this text having survived while going for full IS) >>> > that there are no interesting record-keeping considerations with >>> respect >>> > to knowing the message ID(s) to substitute, in the "forwarding a >>> > dynamic-update request" case, presumably since this is just the field >>> > from the TSIG RDATA and not some externally retained state. >>> >>> That is correct - the original ID is stored in the TSIG record=E2=80=99= s RDATA >>> and it is from there that the original ID is retrieved when a substitut= ion >>> is made. >>> >>> >>> > Section 4.3.3 >>> > >>> > The RR RDLEN and RDATA MAC Length are not included in the input to >>> > MAC computation since they are not guaranteed to be knowable before >>> > the MAC is generated. >>> > >>> > I appreciate that this is explicitly noted; there are some security >>> > considerations regarding the non-inclusion of the (truncated) mac >>> length >>> > as input, though. The local truncation policy helps here, but not >>> 100%. >>> >>> OK >>> >>> >>> > For each label type, there must be a defined "Canonical wire format= " >>> > >>> > Just to check my understanding: label types only come into play for t= he >>> > two fields that are in domain name syntax, key name and algorithm nam= e? >>> >>> There was actually an error in the text here: RFC 4034 section 6.1 is >>> concerned with Canonical Name Order. It is section 6.2 that details th= e >>> canonical wire format - I=E2=80=99ve changed the reference. >>> >>> Going back to the original point, yes, that is correct. Label type 00 >>> is uncompressed name. (11 is a compressed name, and label types 01 and = 10 >>> are discouraged - see RFC 6891 section 5). >>> >>> >>> > Section 5.1 >>> > >>> > the server. This TSIG record MUST be the only TSIG RR in the messa= ge >>> > and MUST be last record in the Additional Data section. The client >>> > >>> > (Is there anything else that tries to insist on being the last record >>> in >>> > the additional data section? I guess it doesn't really make sense to >>> > try to Update: 1035 just to note this requirement.) >>> >>> Not to our knowledge. >>> >>> >>> > MUST store the MAC and the key name from the request while awaiting >>> > an answer. >>> > >>> > [This is going to end up alongside the request-ID that it has to stor= e >>> > already, right?] >>> >>> Yes. The request MAC is included as one of the components used by the >>> server to generate the response - which should be encoded using the sam= e >>> key as used in the request. >>> >>> >>> > Note that some older name servers will not accept requests with a >>> > nonempty additional data section. Clients SHOULD only attempt sign= ed >>> > transactions with servers who are known to support TSIG and share >>> > some algorithm and secret key with the client -- so, this is not a >>> > problem in practice. >>> > >>> > (The context in which this "SHOULD" appears makes it feel like it's >>> > repeating an admontion from elsewhere and not the only instance of th= e >>> > requirement, in which case a reference might be appropriate.) >>> >>> I=E2=80=99ve removed this paragraph. The reference to older name serve= rs is now >>> completely out of date (it was a carry-over from the original 20-year o= ld >>> text). The rest of the paragraph seems superfluous - rather like stati= ng >>> that TCP clients should only connect to servers that support TCP. >>> >>> >>> > Section 5.2 >>> > >>> > If the TSIG RR cannot be understood, the server MUST regard the >>> > message as corrupt and return a FORMERR to the server. Otherwise t= he >>> > server is REQUIRED to return a TSIG RR in the response. >>> > >>> > As written, this could be read as an attempt to make a normative >>> > requirement of servers that do not implement this spec. Presumably >>> it's >>> > just restating a requirement of the core protocol, though? >>> >>> It is the core protocol. >>> >>> I see your point though. However, by implication we are talking about = a >>> server that implements TSIG. >>> >>> >>> > Section 5.2.2 >>> > >>> > Using the information in the TSIG, the server should verify the MAC >>> > by doing its own calculation and comparing the result with the MAC >>> > received. If the MAC fails to verify, the server MUST generate an >>> > >>> > Is there any other way to verify the MAC? (Should this be a "MUST >>> > verify=E2=80=9D?) >>> >>> Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. >>> >>> >>> > Section 5.2.2.1 >>> > >>> > When space is at a premium and the strength of the full length of a >>> > MAC is not needed, it is reasonable to truncate the keyed hash and >>> > use the truncated value for authentication. HMAC SHA-1 truncated t= o >>> > 96 bits is an option available in several IETF protocols, including >>> > IPsec and TLS. >>> > >>> > Also Kerberos, where it was the strongest option for a while and we h= ad >>> > to define a new encryption type to provide a better option (RFC 8009)= . >>> > >>> > This text seems to be implying that HMAC SHA-1 truncated to 96 bits i= s >>> a >>> > recommendable option, which is ... far from clear. I'd prefer to hav= e >>> a >>> > note that this specific truncation was appropriate when initially >>> > specified but may not provide a security level appropriate for all >>> cases >>> > in the modern environment, or preferrably to just change the referenc= e >>> > to (e.g.) SHA-384-192 or SHA-256-128. >>> >>> Added the following an the end of the paragraph: >>> >>> However, while this option is kept for backwards compatibility, >>> it may not provide a security level appropriate for all cases >>> in the modern environment. In these cases, it is preferable to >>> use a hashing algorithm such as SHA-256-128, SHA-384-192 >>> or SHA-256-128 [RFC4868]. >>> >>> I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80= =9D, =E2=80=9Chmac-sha384-192=E2=80=9D and >>> =E2=80=9Chmac-sha512-256=E2=80=9D as optional algorithms to the algorit= hm table. >>> >>> >>> > This is sent when the signer has truncated the keyed hash outpu= t >>> > to an allowable length, as described in [RFC2104], taking initi= al >>> > octets and discarding trailing octets. TSIG truncation can onl= y >>> > >>> > (Or when an on-path attacker has performed truncation.) >>> >>> True, but an on-path attacker can manipulate the message in any way >>> possible. I=E2=80=99m not sure whether adding this caveat will add any= thing to the >>> document. >>> >>> >>> > Section 5.2.3 >>> > >>> > (BADTIME). The server SHOULD also cache the most recent time signe= d >>> > value in a message generated by a key, and SHOULD return BADTIME if= a >>> > message received later has an earlier time signed value. A respons= e >>> > >>> > (But there's no fudge factor on this check, other than the inherent >>> > limit of seconds granularity, as alluded to by the last paragraph of >>> > this section?) >>> >>> The last paragraph in the section states that handling this issue shoul= d >>> be left up to implementations and that the exact method (and by >>> implication, the size of the fudge factor) be determined by the >>> implementation themselves. >>> >>> >>> > Section 5.3.1 >>> > >>> > A zone transfer over a DNS TCP session can include multiple DNS >>> > messages. Using TSIG on such a connection can protect the connecti= on >>> > from hijacking and provide data integrity. The TSIG MUST be includ= ed >>> > >>> > (I assume that "hijacking TCP" means a sequence-number-guessing attac= k >>> > that would require the attacker to be winning the race against the >>> > legitimate sender to cause modified data to be introduced into the TC= P >>> > stream? This is maybe not the best word to use for such a case.) >>> >>> I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80= =9D. >>> >>> >>> > on all DNS messages in the response. For backward compatibility, a >>> > client which receives DNS messages and verifies TSIG MUST accept up >>> > to 99 intermediary messages without a TSIG. The first message is >>> > >>> > (side note: I'm kind of curious what such compatibility is needed wit= h. >>> > Also, this gives an attacker some flexibility into which to incorpora= te >>> > a collision, though given the near-real-time constraints and the >>> > strength of the HMAC construction I don't expect any practical impact= .) >>> >>> The original RFC 2845 did not require all packets in a message stream t= o >>> contain a TSIG, it just stated that there be no more than 99 intermedia= ry >>> messages without a TSIG (presumably to cut down on the overhead require= d in >>> message calculations - remember that RFC 2845 was published 20 years ag= o). >>> Although many DNS implementations now add a TSIG to every message, it i= s by >>> no means certain that all do. (In fact, less than three years ago, a bu= g >>> was introduced into BIND, causing it to require that all packets in a z= one >>> transfer would contain a TSIG. A fix allowing BIND to accept up to 99 >>> packets between signed ones was released shortly afterwards after repor= ts >>> were received of zone transfers failing.) >>> >>> >>> > Section 5.3.2 >>> > >>> > Request MAC (if the request MAC validated) >>> > DNS Message (response) >>> > TSIG Variables (response) >>> > >>> > The reason that the request is not included in this MAC in some cas= es >>> > is to make it possible for the client to verify the error. If the >>> > error is not a TSIG error the response MUST be generated as specifi= ed >>> > in Section 5.3. >>> > >>> > This makes it sound like the server excludes the request MAC from the >>> > digest if it failed to validate (something the client cannot predict)= , >>> > so that the client must perform trial verification of both versions i= n >>> > order to validate the response. Is that correct? >>> >>> No. If the incoming MAC failed to validate, the server should send bac= k >>> an unsigned response (MAC size =3D=3D 0 and empty MAC). >>> >>> >>> > Also, I think that the "in some cases" is not properly placed: as-is, >>> it >>> > says that the request (not request MAC) is sometimes not included >>> > (implying that sometimes it is), which does not match up with the >>> > specification for the digest components. I presume that the intent i= s >>> > to say that in some cases the client could not verify the error, if t= he >>> > request itself was always included in the digest. >>> >>> Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. >>> >>> If the MAC could not be verified, it is possible that it was corrupted, >>> which would prevent the client verifying the response. But a major reas= on >>> is that an incorrect MAC included in a signed response led to the CVEs = that >>> prompted this document update. >>> >>> >>> > Section 5.4.1 >>> > >>> > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG >>> > validates and the TSIG key recognised by the client but different >>> > from that used on the request, then this is a Key Error. The clien= t >>> > >>> > nits: missing words "key is recognized" and "but is different=E2=80= =9D >>> >>> It now reads =E2=80=9Ckey is recognized but different" >>> >>> >>> > Section 5.5 >>> > >>> > destination or the next forwarder. If no transaction security is >>> > available to the destination and the message is a query then, if th= e >>> > corresponding response has the AD flag (see [RFC4035]) set, the >>> > forwarder MUST clear the AD flag before adding the TSIG to the >>> > response and returning the result to the system from which it >>> > received the query. >>> > >>> > Is there anything to say about the CD bit? (It's independent crypto, >>> so >>> > I don't expect so, but it seems worth checking.) >>> >>> No. CD is just a mechanism by which a client can request that the >>> server not do DNSSEC signature validation on the data and so allow the >>> client to receive the data instead of a SERVFAIL response. >>> >>> >>> > Section 6 >>> > >>> > The only message digest algorithm specified in the first version of >>> > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], >>> > [RFC2104]). Although a review of its security [RFC6151] concluded >>> > that "it may not be urgent to remove HMAC-MD5 from the existing >>> > protocols", with the availability of more secure alternatives the >>> > opportunity has been taken to make the implementation of this >>> > algorithm optional. >>> > >>> > It seems worth noting that the advice from RFC 6151 is already nine >>> > years old. >>> >>> I=E2=80=99ve use the phrasing "Although a review of its security some y= ears ago=E2=80=9D. >>> >>> >>> > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], >>> > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 >>> > security considerations apply to SHA-1 in a similar manner.. >>> Although >>> > >>> > I'd consider referencing (e.g.) >>> > shattered.io >>> > for the "collisions have >>> > been demonstrated" claim, though it's pretty optional. >>> >>> A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D p= aper.. >>> >>> >>> > support for hmac-sha1 in TSIG is still mandatory for compatibility >>> > reasons, existing uses should be replaced with hmac-sha256 or other >>> > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>> > >>> > Is this "sha1 mandatory for compatibility" going to age well? If we >>> > have two implementations that can operate with sha2 variants, is it >>> > required to keep this as mandatory (vs. optional with a note about >>> > deployed reality at time of publication) for progression to Internet >>> > Standard? >>> >>> This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2= =80=9D column in >>> RFC4635 (from which Table 2 was derived) into =E2=80=9CImplementation= =E2=80=9D and =E2=80=9CUse=E2=80=9D. >>> SHA1 is required to be implemented (for backwards compatibility) but it= s >>> use is not recommended. >>> >>> >>> > Optional hmac-sha224 >>> > >>> > It's not clear there's much reason to keep this around, or if we do, = it >>> > could probably be "not recommended". (I assume that just dropping it >>> > entirely makes things annoying w.r.t. the IANA registry.) >>> >>> It has been left in for compatibility reasons, but its use is not >>> recommended. >>> >>> >>> > Section 9 >>> > >>> > Previous specifications [RFC2845] and [RFC4635] defined values for >>> > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >>> > >>> > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where >>> > HMAC qualifies both hash algorithms is not terribly clear. >>> >>> Changed to >>> >>> Previous specifications [RFC2845] and [RFC4635] defined names f= or >>> the HMAC-MD5 and the various HMAC-SHA algorithms. >>> >>> >>> > Section 10 >>> > >>> > I suggest some discussion that the way truncation policy works, an >>> > attackers ability to forge messages accepted as valid is limited by t= he >>> > amount of truncation that the recipient is willing to accept, not the >>> > amount of truncation used to generate messages by the legitimate >>> sender. >>> >>> I think this is already taken care of by the reference to a local polic= y >>> in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5= .2.4). >>> >>> >>> > There's also some fairly standard content to put in here about allowi= ng >>> > for an unsigned error response to a signed request, so an attacker >>> (even >>> > off-path) can spoof such resposnes. (Section 5.4 indicates that the >>> > client should continue to wait if it gets such a thing, which helps a >>> > lot.) >>> >>> I=E2=80=99ve just added text that an unsigned response is not considere= d >>> acceptable because can be subject to spoofing and manipulation. >>> >>> >>> > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two >>> > entities. >>> > >>> > I suggest adding "; any such additional sharing would allow any party >>> > knowing the key to impersonate any other such party to members of the >>> > group=E2=80=9D. >>> >>> Added. >>> >>> >>> > A fudge value that is too large may leave the server open to replay >>> > attacks. A fudge value that is too small may cause failures if >>> > machines are not time synchronized or there are unexpected network >>> > delays. The RECOMMENDED value in most situations is 300 seconds. >>> > >>> > Our experience with kerberos in modern network environments has shown >>> > that 5 minutes is much larger than needed, though it's not clear >>> there's >>> > a strong need to change this recommendation right now. >>> >>> The value is recommended (and even then, only in =E2=80=9Cmost situatio= ns=E2=80=9D), so >>> implementations are free to set their own value. However, any guidance= as >>> to typical time skews measured across a network would be useful in a nu= mber >>> of protocols. >>> >>> >>> > Significant progress has been made recently in cryptanalysis of has= h >>> > functions of the types used here. While the results so far should >>> > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are bein= g >>> > made mandatory as a precaution. >>> > >>> > Please revise this note to not imply that SHA-1 is considered "strong= =E2=80=9D. >>> >>> Text revised to >>> >>> Significant progress has been made recently in cryptanalysis of >>> hash >>> functions of the types used here. While the results so far >>> should not >>> affect HMAC, the stronger SHA-256 algorithm is being made >>> mandatory >>> as a precaution. >>> >>> >>> > Section 11.2 >>> > >>> > I'm not sure why RFC 2104 is listed as informative. >>> >>> RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a= possible downref >>> if the reference is placed in the =E2=80=9CNormative=E2=80=9D section. >>> >>> >>> >>> Comments from Mirja K=C3=BChlewind >>> >>> > I only had limited time for a quick review of this document, so I >>> might not be aware of all the needed background and details. Still I ha= ve >>> two quick questions on retries: >>> > >>> > 1) Sec 5.2.3: >>> > "Implementations should be aware >>> > of this possibility and be prepared to deal with it, e.g. by >>> > retransmitting the rejected request with a new TSIG once outstandin= g >>> > requests have completed or the time given by their time signed plus >>> > fudge value has passed." >>> > I might not be aware of all protocol details and maybe this is alread= y >>> specified somewhere: While unlikely, it is possible that a request migh= t be >>> retransmitted multiple times, as that could cause president congestion = over >>> time, it's always good practice to define a maximum number of >>> retransmissions. If that is already defined somewhere, maybe adding a >>> note/pointer would be good as well. >>> >>> If someone can suggest a suitable number (and a reason for it), we can >>> consider doing this. In the meantime, I=E2=80=99ve merely stated that >>> implementation should limit the number of retransmissions and so leave = the >>> choice up to the implementation. >>> >>> >>> > 2) Sec 5.3.1: >>> > " This allows the client to rapidly detect when the session has bee= n >>> > altered; at which point it can close the connection and retry." >>> > When (immediately or after some waiting time) should the client retry >>> and how often? >>> >>> I think that should be down to the implementation to decide. >>> >>> >>> > You further say >>> > "The client SHOULD treat this the >>> > same way as they would any other interrupted transfer (although the >>> > exact behavior is not specified here)." >>> > Where is that specified? Can you provide a pointer in the text? >>> >>> That was a mistake in transcribing the original RFC2845 text. The fina= l >>> word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads: >>> >>> The client SHOULD treat this the same way as they would any oth= er >>> interrupted transfer (although the exact behavior is not >>> specified). >>> >>> >>> > 3) Sec 8. Shared Secrets: Would it be appropriate to use more >>> normative language here? There are a bunch of lower case shoulds in thi= s >>> section; is that on purpose? >>> >>> The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is= very general >>> security advice. Although this is something users ought to do, it is n= ot >>> really a specific recommendation. >>> >>> >>> >>> Comments from Barry Leiba >>> >>> > =E2=80=94 Section 4.2 =E2=80=94 >>> > >>> > * Other Len - an unsigned 16-bit integer specifying the leng= th >>> > of the "Other Data" field in octets. >>> > * Other Data - this unsigned 48-bit integer field will be >>> > >>> > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits? = If so, does that >>> mean tgat the value of =E2=80=9Cother len=E2=80=9D is always 6? If so,= then shouldn=E2=80=99t it >>> say that? If not, then what don=E2=80=99t I understand? >>> >>> Benjamin Kaduk also made the same comment, it has been addressed above. >>> >>> >>> > =E2=80=94 Section 5.1 =E2=80=94 >>> > >>> > Clients SHOULD only attempt signed >>> > transactions with servers who are known to support TSIG and share >>> > some algorithm and secret key with the client -- so, this is not a >>> > problem in practice. >>> > >>> > Why SHOULD and not MUST? >>> >>> Benjamin Kaduk also noted an issue here. The paragraph has been remove= d. >>> >>> >>> > =E2=80=94 Section 5.3.2 =E2=80=94 >>> > >>> > The server SHOULD also cache the most recent time signed >>> > value in a message generated by a key >>> > >>> > I tripped over this until I realized you mean =E2=80=9CTime Signed va= lue=E2=80=9D. >>> You capitalize it elsewhere, and it helps the parsing if it=E2=80=99s c= onsistent. >>> There are four uncapitalized instances in this section. >>> >>> =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in th= e description of >>> the field, =E2=80=9Ctims signed=E2=80=9D has been replaced with =E2=80= =9Ctime the message was >>> signed=E2=80=9D. >>> >>> Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80= =9CFudge field=E2=80=9D (although >>> occurrences of =E2=80=9Cfudge value=E2=80=9D have not been capitalised,= as the context of >>> that is that it is referring to the contents of the Fudge field). Also, >>> =E2=80=9Cother data=E2=80=9D and =E2=80=9Cother data length=E2=80=9D ha= ve been replaced with the >>> (capitalised) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COt= her Len=E2=80=9D. >>> >>> >>> > =E2=80=94 Section 9 =E2=80=94 >>> > >>> > There is no structure >>> > required other than names for different algorithms must be unique >>> > when compared as DNS names, i.e., comparison is case insensitive. >>> > >>> > I found this sentence to be really awkward and hard to parse. May I >>> suggest this?: >>> > >>> > NEW >>> > There is no structure to the names, and algorithm names are compared >>> as if they were DNS names (the comparison is case-insensitive). >>> > END >>> > >>> > I don=E2=80=99t think you really need to say that each name is >>> different/unique, right? >>> >>> Agreed. The text has been changed to that suggested. >>> >>> >>> > other algorithm >>> > names are simple (i.e., single-component) names. >>> > >>> > Nitty thing that you can completely ignore, but I would avoid the >>> Latin abbreviation thus: =E2=80=9Cother algorithm names are simple, >>> single-component names.=E2=80=9D >>> >>> Changed. >>> >>> >>> >>> Comments from =C3=89ric Vyncke >>> >>> > Thank you for the work put into this document. It is clear and easy t= o >>> read. >>> > >>> > Please find below some non-blocking COMMENTs and NITs. An answer will >>> be appreciated. >>> > >>> > I hope that this helps to improve the document, >>> > >>> > Regards, >>> > >>> > -=C3=A9ric >>> > >>> > =3D=3D COMMENTS =3D=3D >>> > >>> > There are 6 authors while the usual procedure is to limit to 5 >>> authors.. Personally, I do not care. >>> > >>> > -- Section 1.3 -- >>> > It is a little unclear to me whether the "two nameservers" were two >>> implementations or two actual DNS servers. >>> >>> Agreed, it was unclear. Changed to =E2=80=9Ctwo name server implementa= tions=E2=80=9D. >>> >>> >>> > -- Section 5.2 -- >>> > Suggest to provide some justifications about "copied to a safe >>> location": the DNS message was sent in the clear, why does the TSIG par= t be >>> copied in a safe location? Please define what is meant by "safe locatio= n" >>> (Mainly for my own curiosity) >>> >>> It is a bit over-specified and has been changed. The text now reads: >>> >>> Upon receipt of >>> a message with exactly one correctly placed TSIG RR, a copy of t= he >>> TSIG RR is stored, and the TSIG RR is removed from the DNS >>> Message, >>> and decremented out of the DNS message header's ARCOUNT. >>> >>> >>> > "cannot be understood" is also quite vague. >>> >>> Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. >>> >>> >>> > -- Section 5.3 -- >>> > About rejecting request with a time signed value being earlier than >>> the last received value. I wonder what is the value of this behavior if >>> there is no 'fudge' as well... The last paragraph of this section descr= ibes >>> this case and push the error handling to the request initiator. Any rea= son >>> why being flexible on the receiving site was not selected ? >>> >>> The fudge value is to cope with clock skew between the sender and >>> receiver. This won't impact on the order in which the packets are rece= ived >>> by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first= -level check. (It is >>> not fool-proof - a number of packets signed by the sender within a seco= nd >>> of one another may have the same =E2=80=9CTime Signed=E2=80=9D field.) >>> >>> Pushing the error handling to the initiation goes back to the original >>> RFC 2845. >>> >>> >>> > =3D=3D NITS =3D=3D >>> > >>> > -- Section 4.3.2 -- >>> > Is " A whole and complete DNS message in wire format." a complete and >>> valid sentence? >>> >>> This was also pointed out by Roman Danyliw and has been addressed. >>> >>> >>> Other changes made during editing >>> >>> * There was no description of the contents of the =E2=80=9CError=E2=80= =9D and =E2=80=9COther >>> Data=E2=80=9D fields were in a request. This has now been corrected (E= rror is set >>> to 0. The contents of =E2=80=9COther Data=E2=80=9D are stated to be und= efined to allow for >>> extensions such as draft-andrews-dnsop-defeat-frag-attack.) >>> >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > --00000000000006285005a5630063 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Donald

So = you're suggest=C2=A0hmac-sha224 is "MAY" for both Implementat= ion and Use ?=C2=A0

On Mon, May 11, 2020 at 12:29 AM Donald Eastlake &= lt;d3e3e3@gmail.com> wrote:
<= /div>
The= incremental effort to implement SHA-224 if you are implementing SHA-256 is= miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to us= e when=C2=A0SHA-256 is MUST implement=C2=A0and=C2=A0RECOMMENDED to use and = you can use SHA-256 with truncation to 224 or even fewer bits.
=C2=A0
Thanks,
Donald
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0= 2386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com

<= /div>
O= n Sat, May 9, 2020 at 9:52 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
To follow up on Stephen&= #39;s comments, a table was added to 2845bis to
list all the algorithms that are cur= rently in the IANA registry,
along with=C2=A0suggestions=C2=A0for implementation.=C2= =A0 This was the first version:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Requirement Name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0----------- ------------------------
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2= =A0 =C2=A0HMA= C-MD5.SIG-ALG.REG.INT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0gss-tsig
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-s= ha1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Optional =C2=A0 =C2=A0hmac-sha224
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-sha256
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2= =A0 =C2=A0hmac-sha384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha512

During the IESG review (I th= ink it was the SECDIR review), there was
a meltdown over implementing SHA-1. But SHA= -1 is in use currently.=C2=A0
My suggestion was to do a variation describing impleme= ntation use.=C2=A0
This is what I came up with(so blame me):=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Implementation Use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------= ------------- -------------- ---------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 HMAC-= MD5.SIG-ALG.REG.INT MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST N= OT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 gss-tsig =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha1 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = NOT RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha224 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0NOT RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha= 256 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sh= a256-128 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384-192 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512-256 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY

<= div class=3D"gmail_default" style=3D"font-family:monospace">On the use side= , these are mostly guesses.=C2=A0 =C2=A0We would love to hear
what the WG has to say= about this.

= thanks
ti= m


On Mon, May 4, 2020 at 2:07 PM Stephen Morris <sa.morris8@gmail.com> wrote:
=

> On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain Name System Operations WG of t= he IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Secret Key Transaction Authentication for DNS (TSIG)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Francis Dupont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stephen Morris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Paul Vixie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Donald E. Eastlake 3rd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Olafur Gudmundsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Brian Wellington
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-rfc2845bis-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-05-04


The update addresses to the draft comments made during the IESG review.=C2= =A0 There were a fair number of these which led to a number of changes to t= he document.=C2=A0 These are listed below.

One significant change is that the list of acceptable algorithms has been e= xtended, and WG approval for this is sought.

Stephen




Comments from Roman Danyliw
---
> ** Section 1.3.=C2=A0 Per =E2=80=9CIn 2017, two nameservers=C2=A0 stri= ctly following that document (and the related [RFC4635]) were discovered to= have security problems related to this feature=E2=80=9D, consider providin= g a reference to the published vulnerabilities (i.e., CVE-2017-3142 and CVE= -2017-3143)

I=E2=80=99ve added these (and one other related CVE) as informative referen= ces.=C2=A0 Using just the CVE number as a reference seemed a bit spartan, s= o I=E2=80=99ve added a title to each incident. As the description of the CV= Es in Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descri= ption, which can be rather long), I=E2=80=99ve taken the title from ISC=E2= =80=99s KnowledgeBase (for the BIND CVEs) and from the Knot release notes (= for the Knot CVE).


> ** Section 6.=C2=A0 Per =E2=80=9CSHA-1 collisions have been demonstrat= ed so the MD5 security considerations apply to SHA-1 in a similar manner.= =C2=A0 Although support for hmac-sha1 in TSIG is still mandatory for compat= ibility reasons, existing uses should be replaced with hmac-sha256 or other= SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].
>
> -- It=E2=80=99s worth repeating those MD5 security considerations here=

I=E2=80=99m not really keen on doing this, since the security consideration= s in RFC 6151 cover two paragraphs and including them - or even a summary o= f them - would detract from the flow of the document.=C2=A0 However, I have= explicitly included a reference to RFC 6151 in the text.


> -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth including references to the recent SHA-1 cryptoanalysis provi= ded in the SECDIR review

Added references to just one of these papers (=E2=80=9DSHA1 is a Shambles= =E2=80=9D).=C2=A0 We=E2=80=99re not doing a general analysis of the algorit= hms, so a simple reference to a paper than describes a SHA1 collision is al= l that is needed.=C2=A0 (As an aside, the paper doesn't give the date o= f publication, so I had to search the Web looking for references to it.=C2= =A0 I think I=E2=80=99ve got the date correct, but I=E2=80=99d be grateful = for a double-check.)


> -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED).

Done - see Table 2


> ** Section 10.=C2=A0 Per =E2=80=9CFor all of the message authenticatio= n code algorithms listed in this document, those producing longer values ar= e believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR rev= iew, this could be misconstrued as the algorithm choice not the digest leng= th provides the security.=C2=A0 Recommend rephrasing (or making some statem= ent=C2=A0

I=E2=80=99ve reworded this paragraph (in section 10).=C2=A0 It now reads:
=C2=A0 "Although the strength of an algorithm determines its security,= there
=C2=A0 have been some arguments that mild truncation can strengthen a MAC b= y
=C2=A0 reducing the information available to an attacker.=C2=A0 However, ex= cessive
=C2=A0 truncation clearly weakens authentication by reducing the number of<= br> =C2=A0 bits an attacker has to try to break the authentication by brute
=C2=A0 force [RFC2104]."


> ** Editorial
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CWhen verifying an incoming messag= e, this is the message after the TSIG RR and been removed and the ARCOUNT f= ield has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (i= s missing a word).
>
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CA whole and complete DNS message = in wire format.=E2=80=9D, this isn=E2=80=99t a sentence.

Section 4.3.2 has been reworded to address these issues.



Comments from Benjamin Kaduk

> Thanks for putting together this update; it's good to see the secu= rity
> issue getting closed off in the udpated spec, and progression to full<= br> > Internet Standard!=C2=A0 I do have several substantive comments (as we= ll as
> some minor/nit-level ones), many of which are listed here at the top b= ut
> a few of which are interspersed in the per-section comments.
>
>
> I considered making this a Discuss point, but it should be pretty
> uncontroversial and I trust that the right thing will happen even if I=
> don't: there's a couple lingering remnants of SHA-1 being the<= br> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 an= d
> 10 (further detailed in the per-section comments).

The document now mentions SHA1 collisions and notes that the MD5 security c= onsiderations apply to SHA1.=C2=A0 It also mentions that support for SHA1 i= s mandatory for compatibility reasons but in existing uses it should be rep= laced by a stronger one.


> I also initially had made the following point a Discuss-level point, b= ut
> decided to not do so since I don't remember any BCP-level guidance=
> relating to cross-protocol attacks.=C2=A0 Nevertheless, I strongly enc= ourage
> the authors to consider that cryptographic best practice is to use any=
> given key with exactly one cryptographic algorithm.=C2=A0 The record f= ormat
> listed in Section 4.2 has the key name and algorithm as separately
> conveyed, which would allow for a given key to be used with all
> implemented algorithms.=C2=A0 We should include some discussion that i= t's
> best to only use a single algorithm with any given key.

The following text has been added to the Security Considerations section:
=C2=A0 "To prevent cross-algorithm attacks, there SHOULD only be one =C2=A0 =C2=A0 algorithm associated with any given key name."


> We also have a 16-bit wide field for "Fudge", which (since i= t counts
> seconds) corresponds to a maximum window of something like +/- 18 hour= s;
> it's hard to believe that we really want to give people the rope t= o
> allow for that much time skew.=C2=A0 (Yes, I understand that implement= ations
> will set something sane in practice but that doesn't necessarily m= ean
> that the protocol still has to allow it.)

That was set in the original RFC 2845.=C2=A0 Although I agree with the comm= ents, changing the size of that field would be a significant undertaking.= =C2=A0 However, section 10 does state that the RECOMMENDED fudge value in m= ost circumstances is 300 seconds.


> Our authoritative list of algorithm names (Table 1) is rather divorced=
> from the references to be consulted for the individual hash algorithms=
> to be used with the HMAC procedure.=C2=A0 The ones used here are suffi= ciently
> well-known that I'm not terribly concerned about it, though.

The first paragraph of the IANA considerations section lists the algorithms= and references to where they are described, and I didn=E2=80=99t want to d= uplicate the information.


> Abstract
>
> The title says "DNS" but maybe the body of the abstract shou= ld as well?

In the abstract, changed:

"It can be used to authenticate dynamic updates as coming from an appr= oved client"

to

"It can be used to authenticate dynamic updates to a DNS zone as comin= g from an approved client"


> Section 1.1
>
> Some of this language feels like it might not age terribly well, e.g.,=
> "this can provide" or "[t]here was a need".
>
>=C2=A0 =C2=A0addresses that need.=C2=A0 The proposal is unsuitable for = general server
>=C2=A0 =C2=A0to server authentication for servers which speak with many= other
>=C2=A0 =C2=A0servers, since key management would become unwieldy with t= he number
>=C2=A0 =C2=A0of shared keys going up quadratically.=C2=A0 But it is sui= table for many
>=C2=A0 =C2=A0resolvers on hosts that only talk to a few recursive serve= rs.

Changed to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The authentication mechanism proposed her= e provides a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple and efficient authentication between cli= ents and local servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by using shared secret keys to establish a trus= t relationship between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 two entities.=C2=A0 Such keys must be protected= in a manner similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private keys, lest a third party masquerade as = one of the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parties (by forging the MAC).=C2=A0 The proposa= l is unsuitable for general
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server to server authentication for servers whi= ch speak with many
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other servers, since key management would becom= e unwieldy with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number of shared keys going up quadratically. B= ut it is suitable for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 many resolvers on hosts that only talk to a few= recursive servers.=E2=80=9D


> Should zone transfers be mentioned here as well?

Zone transfers are mentioned in the preceding paragraph.


> Section 1.2
>
> I don't understand the motivation for changing terminology from MA= Cs to
> "signatures"; they're still MACs even though they're= transaction-based.

The mention of signatures in section 1.2 is intended as a link between the = name of the RR (TSIG or Transaction Signature) and the term MAC used in the= rest of the document.


>=C2=A0 =C2=A0MAC of the query as part of the calculation.=C2=A0 Where a= response
>=C2=A0 =C2=A0comprises multiple packets, the calculation of the MAC ass= ociated
>=C2=A0 =C2=A0with the second and subsequent packets includes in its inp= uts the MAC
>=C2=A0 =C2=A0for the preceding packet.=C2=A0 In this way it is possible= to detect any
>=C2=A0 =C2=A0interruption in the packet sequence.
>
> I suggest mentioning the lack of mechanism to detect truncation of the=
> packet sequence.

That is a fair point.=C2=A0 I=E2=80=99ve modified the last sentence to read= :

=C2=A0 =C2=A0"In this way it is possible to detect any interruption in= the packet sequence,
=C2=A0 =C2=A0although not its premature termination."


> Section 4.2
>
>=C2=A0 =C2=A0NAME=C2=A0 The name of the key used, in domain name syntax= ..=C2=A0 The name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should reflect the names of the hosts= and uniquely identify the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key among a set of keys these two hos= ts may share at any given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time.=C2=A0 For example, if hosts A.s= ite.example and
> = B.example.net
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0share a key, possibilities for the ke= y name include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example, <id>= ..B.e= xample.net, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example.B= ..example.net.=C2=A0 It should be possible for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than one key to be in simultaneo= us use among a set of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interacting hosts.
>
> I'd suggest adding a note along the lines of "This allows for= periodic
> key rotation per best operational practices, as well as algorithm
> agility as indicated by [BCP201].=E2=80=9D

Added.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The name may be used as a local index= to the key involved and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it is recommended that it be globally= unique.=C2=A0 Where a key is
>
> (nit?): this feels more like a "but" than an "and"= , to me.

Well spotted.=C2=A0 I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 MAC Size - an unsigned 16-bit= integer giving the length of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC field in octets.=C2=A0 Tr= uncation is indicated by a MAC size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 less than the size of the key= ed hash produced by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm specified by the Al= gorithm Name.
>
> nit: I would suggest "output size", as there are potentially= a few
> different sizes involved (key size, block size, and output size, for > starters, though I think the possibility of confusion here is low).
I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference to = this field, and the other size mentioned - that of the keyed hash is, I thi= nk, also unambiguous.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 empty unless the content of t= he Error field is BADTIME, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which case it will contain th= e server's current time as the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of seconds since 00:00= on 1970-01-01 UTC, ignoring
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leap seconds (see Section 5.2= ..3).
>
> I'm slightly confused at the interplay between the explicit length= field
> and the "empty unless" directive.=C2=A0 Does this mean that = the only allowed
> values in the "Other Len" are 0 and 6?=C2=A0 Does "empt= y" mean "length-zero=E2=80=9D?

I=E2=80=99ve rewritten this slightly in a bid to make it clearer that =E2= =80=9COther Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80= =9D is zero.


> Section 4.3.1
>
>=C2=A0 =C2=A0Only included in the computation of a MAC for a response m= essage (or
>=C2=A0 =C2=A0the first message in a multi-message response), the valida= ted request
>=C2=A0 =C2=A0MAC MUST be included in the MAC computation.=C2=A0 If the = request MAC
>=C2=A0 =C2=A0failed to validate, an unsigned error message MUST be retu= rned
>=C2=A0 =C2=A0instead.=C2=A0 (Section 5.3.2).
>
> side note: while Section 5.3.2 specifies how to create an unsigned err= or
> message, it looks like Section 5.2 (and subsections lists specific
> RCODEs that are to be used.

That is the case.=C2=A0 Section 4 is a description of the TSIG RR and its f= ields.=C2=A0 Section 5 describes the contents of the fields in various situ= ations (client transmission, server reception, server transmission, client = reception).


> Section 4.3.2
>
>=C2=A0 =C2=A0When verifying an incoming message, this is the message af= ter the
>=C2=A0 =C2=A0TSIG RR and been removed and the ARCOUNT field has been de= cremented.
>=C2=A0 =C2=A0If the message ID differs from the original message ID, th= e original
>=C2=A0 =C2=A0message ID is substituted for the message ID.=C2=A0 (This = could happen,
>=C2=A0 =C2=A0for example, when forwarding a dynamic update request.) >
> I trust (based on this text having survived while going for full IS) > that there are no interesting record-keeping considerations with respe= ct
> to knowing the message ID(s) to substitute, in the "forwarding a<= br> > dynamic-update request" case, presumably since this is just the f= ield
> from the TSIG RDATA and not some externally retained state.

That is correct - the original ID is stored in the TSIG record=E2=80=99s RD= ATA and it is from there that the original ID is retrieved when a substitut= ion is made.


> Section 4.3.3
>
>=C2=A0 =C2=A0The RR RDLEN and RDATA MAC Length are not included in the = input to
>=C2=A0 =C2=A0MAC computation since they are not guaranteed to be knowab= le before
>=C2=A0 =C2=A0the MAC is generated.
>
> I appreciate that this is explicitly noted; there are some security > considerations regarding the non-inclusion of the (truncated) mac leng= th
> as input, though.=C2=A0 The local truncation policy helps here, but no= t 100%.

OK


>=C2=A0 =C2=A0For each label type, there must be a defined "Canonic= al wire format"
>
> Just to check my understanding: label types only come into play for th= e
> two fields that are in domain name syntax, key name and algorithm name= ?

There was actually an error in the text here: RFC 4034 section 6.1 is conce= rned with Canonical Name Order.=C2=A0 It is section 6.2 that details the ca= nonical wire format - I=E2=80=99ve changed the reference.

Going back to the original point, yes, that is correct.=C2=A0 Label type 00= is uncompressed name. (11 is a compressed name, and label types 01 and 10 = are discouraged - see RFC 6891 section 5).


> Section 5.1
>
>=C2=A0 =C2=A0the server.=C2=A0 This TSIG record MUST be the only TSIG R= R in the message
>=C2=A0 =C2=A0and MUST be last record in the Additional Data section.=C2= =A0 The client
>
> (Is there anything else that tries to insist on being the last record = in
> the additional data section?=C2=A0 I guess it doesn't really make = sense to
> try to Update: 1035 just to note this requirement.)

Not to our knowledge.


>=C2=A0 =C2=A0MUST store the MAC and the key name from the request while= awaiting
>=C2=A0 =C2=A0an answer.
>
> [This is going to end up alongside the request-ID that it has to store=
> already, right?]

Yes.=C2=A0 The request MAC is included as one of the components used by the= server to generate the response - which should be encoded using the same k= ey as used in the request.


>=C2=A0 =C2=A0Note that some older name servers will not accept requests= with a
>=C2=A0 =C2=A0nonempty additional data section.=C2=A0 Clients SHOULD onl= y attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> (The context in which this "SHOULD" appears makes it feel li= ke it's
> repeating an admontion from elsewhere and not the only instance of the=
> requirement, in which case a reference might be appropriate.)

I=E2=80=99ve removed this paragraph.=C2=A0 The reference to older name serv= ers is now completely out of date (it was a carry-over from the original 20= -year old text).=C2=A0 The rest of the paragraph seems superfluous - rather= like stating that TCP clients should only connect to servers that support = TCP.=C2=A0


> Section 5.2
>
>=C2=A0 =C2=A0If the TSIG RR cannot be understood, the server MUST regar= d the
>=C2=A0 =C2=A0message as corrupt and return a FORMERR to the server.=C2= =A0 Otherwise the
>=C2=A0 =C2=A0server is REQUIRED to return a TSIG RR in the response. >
> As written, this could be read as an attempt to make a normative
> requirement of servers that do not implement this spec.=C2=A0 Presumab= ly it's
> just restating a requirement of the core protocol, though?

It is the core protocol.

I see your point though.=C2=A0 However, by implication we are talking about= a server that implements TSIG.


> Section 5.2.2
>
>=C2=A0 =C2=A0Using the information in the TSIG, the server should verif= y the MAC
>=C2=A0 =C2=A0by doing its own calculation and comparing the result with= the MAC
>=C2=A0 =C2=A0received.=C2=A0 If the MAC fails to verify, the server MUS= T generate an
>
> Is there any other way to verify the MAC?=C2=A0 (Should this be a &quo= t;MUST
> verify=E2=80=9D?)

Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed.


> Section 5.2.2.1
>
>=C2=A0 =C2=A0When space is at a premium and the strength of the full le= ngth of a
>=C2=A0 =C2=A0MAC is not needed, it is reasonable to truncate the keyed = hash and
>=C2=A0 =C2=A0use the truncated value for authentication.=C2=A0 HMAC SHA= -1 truncated to
>=C2=A0 =C2=A096 bits is an option available in several IETF protocols, = including
>=C2=A0 =C2=A0IPsec and TLS.
>
> Also Kerberos, where it was the strongest option for a while and we ha= d
> to define a new encryption type to provide a better option (RFC 8009).=
>
> This text seems to be implying that HMAC SHA-1 truncated to 96 bits is= a
> recommendable option, which is ... far from clear.=C2=A0 I'd prefe= r to have a
> note that this specific truncation was appropriate when initially
> specified but may not provide a security level appropriate for all cas= es
> in the modern environment, or preferrably to just change the reference=
> to (e.g.) SHA-384-192 or SHA-256-128.

Added the following an the end of the paragraph:

=C2=A0 However, while this option is kept for backwards compatibility,
=C2=A0 it may not provide a security level appropriate for all cases
=C2=A0 in the modern environment. In these cases, it is preferable to
=C2=A0 use a hashing algorithm such as SHA-256-128, SHA-384-192
=C2=A0 or SHA-256-128 [RFC4868].

I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D, = =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80=9D as = optional algorithms to the algorithm table.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is sent when the signer has truncated t= he keyed hash output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to an allowable length, as described in [RFC= 2104], taking initial
>=C2=A0 =C2=A0 =C2=A0 =C2=A0octets and discarding trailing octets.=C2=A0= TSIG truncation can only
>
> (Or when an on-path attacker has performed truncation.)

True, but an on-path attacker can manipulate the message in any way possibl= e.=C2=A0 I=E2=80=99m not sure whether adding this caveat will add anything = to the document.


> Section 5.2.3
>
>=C2=A0 =C2=A0(BADTIME).=C2=A0 The server SHOULD also cache the most rec= ent time signed
>=C2=A0 =C2=A0value in a message generated by a key, and SHOULD return B= ADTIME if a
>=C2=A0 =C2=A0message received later has an earlier time signed value.= =C2=A0 A response
>
> (But there's no fudge factor on this check, other than the inheren= t
> limit of seconds granularity, as alluded to by the last paragraph of > this section?)

The last paragraph in the section states that handling this issue should be= left up to implementations and that the exact method (and by implication, = the size of the fudge factor) be determined by the implementation themselve= s.=C2=A0


> Section 5.3.1
>
>=C2=A0 =C2=A0A zone transfer over a DNS TCP session can include multipl= e DNS
>=C2=A0 =C2=A0messages.=C2=A0 Using TSIG on such a connection can protec= t the connection
>=C2=A0 =C2=A0from hijacking and provide data integrity.=C2=A0 The TSIG = MUST be included
>
> (I assume that "hijacking TCP" means a sequence-number-guess= ing attack
> that would require the attacker to be winning the race against the
> legitimate sender to cause modified data to be introduced into the TCP=
> stream?=C2=A0 This is maybe not the best word to use for such a case.)=

I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D.<= br>

>=C2=A0 =C2=A0on all DNS messages in the response.=C2=A0 For backward co= mpatibility, a
>=C2=A0 =C2=A0client which receives DNS messages and verifies TSIG MUST = accept up
>=C2=A0 =C2=A0to 99 intermediary messages without a TSIG.=C2=A0 The firs= t message is
>
> (side note: I'm kind of curious what such compatibility is needed = with.
> Also, this gives an attacker some flexibility into which to incorporat= e
> a collision, though given the near-real-time constraints and the
> strength of the HMAC construction I don't expect any practical imp= act.)

The original RFC 2845 did not require all packets in a message stream to co= ntain a TSIG, it just stated that there be no more than 99 intermediary mes= sages without a TSIG (presumably to cut down on the overhead required in me= ssage calculations - remember that RFC 2845 was published 20 years ago).=C2= =A0 Although many DNS implementations now add a TSIG to every message, it i= s by no means certain that all do. (In fact, less than three years ago, a b= ug was introduced into BIND, causing it to require that all packets in a zo= ne transfer would contain a TSIG.=C2=A0 A fix allowing BIND to accept up to= 99 packets between signed ones was released shortly afterwards after repor= ts were received of zone transfers failing.)


> Section 5.3.2
>
>=C2=A0 =C2=A0 =C2=A0 Request MAC (if the request MAC validated)
>=C2=A0 =C2=A0 =C2=A0 DNS Message (response)
>=C2=A0 =C2=A0 =C2=A0 TSIG Variables (response)
>
>=C2=A0 =C2=A0The reason that the request is not included in this MAC in= some cases
>=C2=A0 =C2=A0is to make it possible for the client to verify the error.= =C2=A0 If the
>=C2=A0 =C2=A0error is not a TSIG error the response MUST be generated a= s specified
>=C2=A0 =C2=A0in Section 5.3.
>
> This makes it sound like the server excludes the request MAC from the<= br> > digest if it failed to validate (something the client cannot predict),=
> so that the client must perform trial verification of both versions in=
> order to validate the response.=C2=A0 Is that correct?

No.=C2=A0 If the incoming MAC failed to validate, the server should send ba= ck an unsigned response (MAC size =3D=3D 0 and empty MAC).


> Also, I think that the "in some cases" is not properly place= d: as-is, it
> says that the request (not request MAC) is sometimes not included
> (implying that sometimes it is), which does not match up with the
> specification for the digest components.=C2=A0 I presume that the inte= nt is
> to say that in some cases the client could not verify the error, if th= e
> request itself was always included in the digest.

Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D.

If the MAC could not be verified, it is possible that it was corrupted, whi= ch would prevent the client verifying the response. But a major reason is t= hat an incorrect MAC included in a signed response led to the CVEs that pro= mpted this document update.


> Section 5.4.1
>
>=C2=A0 =C2=A0If an RCODE on a response is 9 (NOTAUTH), but the response= TSIG
>=C2=A0 =C2=A0validates and the TSIG key recognised by the client but di= fferent
>=C2=A0 =C2=A0from that used on the request, then this is a Key Error.= =C2=A0 The client
>
> nits: missing words "key is recognized" and "but is dif= ferent=E2=80=9D

It now reads =E2=80=9Ckey is recognized but different"


> Section 5.5
>
>=C2=A0 =C2=A0destination or the next forwarder.=C2=A0 If no transaction= security is
>=C2=A0 =C2=A0available to the destination and the message is a query th= en, if the
>=C2=A0 =C2=A0corresponding response has the AD flag (see [RFC4035]) set= , the
>=C2=A0 =C2=A0forwarder MUST clear the AD flag before adding the TSIG to= the
>=C2=A0 =C2=A0response and returning the result to the system from which= it
>=C2=A0 =C2=A0received the query.
>
> Is there anything to say about the CD bit?=C2=A0 (It's independent= crypto, so
> I don't expect so, but it seems worth checking.)

No.=C2=A0 CD is just a mechanism by which a client can request that the ser= ver not do DNSSEC signature validation on the data and so allow the client = to receive the data instead of a SERVFAIL response.


> Section 6
>
>=C2=A0 =C2=A0The only message digest algorithm specified in the first v= ersion of
>=C2=A0 =C2=A0these specifications [RFC2845] was "HMAC-MD5" (s= ee [RFC1321],
>=C2=A0 =C2=A0[RFC2104]).=C2=A0 Although a review of its security [RFC61= 51] concluded
>=C2=A0 =C2=A0that "it may not be urgent to remove HMAC-MD5 from th= e existing
>=C2=A0 =C2=A0protocols", with the availability of more secure alte= rnatives the
>=C2=A0 =C2=A0opportunity has been taken to make the implementation of t= his
>=C2=A0 =C2=A0algorithm optional.
>
> It seems worth noting that the advice from RFC 6151 is already nine > years old.

I=E2=80=99ve use the phrasing "Although a review of its security some = years ago=E2=80=9D.


>=C2=A0 =C2=A0[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS1= 80-4],
>=C2=A0 =C2=A0[RFC3174].=C2=A0 SHA-1 collisions have been demonstrated s= o the MD5
>=C2=A0 =C2=A0security considerations apply to SHA-1 in a similar manner= ..=C2=A0 Although
>
> I'd consider referencing (e.g.)
> s= hattered.io
> for the "collisions have
> been demonstrated" claim, though it's pretty optional.

A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D paper= ..


>=C2=A0 =C2=A0support for hmac-sha1 in TSIG is still mandatory for compa= tibility
>=C2=A0 =C2=A0reasons, existing uses should be replaced with hmac-sha256= or other
>=C2=A0 =C2=A0SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].=
>
> Is this "sha1 mandatory for compatibility" going to age well= ?=C2=A0 If we
> have two implementations that can operate with sha2 variants, is it > required to keep this as mandatory (vs. optional with a note about
> deployed reality at time of publication) for progression to Internet > Standard?

This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2=80= =9D column in RFC4635 (from which Table 2 was derived) into =E2=80=9CImplem= entation=E2=80=9D and =E2=80=9CUse=E2=80=9D.=C2=A0 SHA1 is required to be i= mplemented (for backwards compatibility) but its use is not recommended.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Op= tional=C2=A0 =C2=A0 hmac-sha224
>
> It's not clear there's much reason to keep this around, or if = we do, it
> could probably be "not recommended".=C2=A0 (I assume that ju= st dropping it
> entirely makes things annoying w.r.t. the IANA registry.)

It has been left in for compatibility reasons, but its use is not recommend= ed.


> Section 9
>
>=C2=A0 =C2=A0Previous specifications [RFC2845] and [RFC4635] defined va= lues for
>=C2=A0 =C2=A0HMAC MD5 and SHA.=C2=A0 IANA has also registered "gss= -tsig" as an
>
> I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied gr= ouping where
> HMAC qualifies both hash algorithms is not terribly clear.

Changed to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Previous specifications [RFC2845] and [RFC4635]= defined names for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the HMAC-MD5 and the various HMAC-SHA algorithm= s.


> Section 10
>
> I suggest some discussion that the way truncation policy works, an
> attackers ability to forge messages accepted as valid is limited by th= e
> amount of truncation that the recipient is willing to accept, not the<= br> > amount of truncation used to generate messages by the legitimate sende= r.

I think this is already taken care of by the reference to a local policy in= the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.2.4).=


> There's also some fairly standard content to put in here about all= owing
> for an unsigned error response to a signed request, so an attacker (ev= en
> off-path) can spoof such resposnes.=C2=A0 (Section 5.4 indicates that = the
> client should continue to wait if it gets such a thing, which helps a<= br> > lot.)

I=E2=80=99ve just added text that an unsigned response is not considered ac= ceptable because can be subject to spoofing and manipulation.


>=C2=A0 =C2=A0TKEY [RFC2930].=C2=A0 Secrets SHOULD NOT be shared by more= than two
>=C2=A0 =C2=A0entities.
>
> I suggest adding "; any such additional sharing would allow any p= arty
> knowing the key to impersonate any other such party to members of the<= br> > group=E2=80=9D.

Added.


>=C2=A0 =C2=A0A fudge value that is too large may leave the server open = to replay
>=C2=A0 =C2=A0attacks.=C2=A0 A fudge value that is too small may cause f= ailures if
>=C2=A0 =C2=A0machines are not time synchronized or there are unexpected= network
>=C2=A0 =C2=A0delays.=C2=A0 The RECOMMENDED value in most situations is = 300 seconds.
>
> Our experience with kerberos in modern network environments has shown<= br> > that 5 minutes is much larger than needed, though it's not clear t= here's
> a strong need to change this recommendation right now.

The value is recommended (and even then, only in =E2=80=9Cmost situations= =E2=80=9D), so implementations are free to set their own value.=C2=A0 Howev= er, any guidance as to typical time skews measured across a network would b= e useful in a number of protocols.


>=C2=A0 =C2=A0Significant progress has been made recently in cryptanalys= is of hash
>=C2=A0 =C2=A0functions of the types used here.=C2=A0 While the results = so far should
>=C2=A0 =C2=A0not affect HMAC, the stronger SHA-1 and SHA-256 algorithms= are being
>=C2=A0 =C2=A0made mandatory as a precaution.
>
> Please revise this note to not imply that SHA-1 is considered "st= rong=E2=80=9D.

Text revised to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Significant progress has been made recently in = cryptanalysis of hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 functions of the types used here.=C2=A0 While t= he results so far should not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affect HMAC, the stronger SHA-256 algorithm is = being made mandatory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a precaution.


> Section 11.2
>
> I'm not sure why RFC 2104 is listed as informative.

RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a pos= sible downref if the reference is placed in the =E2=80=9CNormative=E2=80=9D= section.



Comments from Mirja K=C3=BChlewind

> I only had limited time for a quick review of this document, so I migh= t not be aware of all the needed background and details. Still I have two q= uick questions on retries:
>
> 1) Sec 5.2.3:
> "Implementations should be aware
>=C2=A0 =C2=A0of this possibility and be prepared to deal with it, e.g. = by
>=C2=A0 =C2=A0retransmitting the rejected request with a new TSIG once o= utstanding
>=C2=A0 =C2=A0requests have completed or the time given by their time si= gned plus
>=C2=A0 =C2=A0fudge value has passed."
> I might not be aware of all protocol details and maybe this is already= specified somewhere: While unlikely, it is possible that a request might b= e retransmitted multiple times, as that could cause president congestion ov= er time, it's always good practice to define a maximum number of retran= smissions. If that is already defined somewhere, maybe adding a note/pointe= r would be good as well.

If someone can suggest a suitable number (and a reason for it), we can cons= ider doing this.=C2=A0 In the meantime, I=E2=80=99ve merely stated that imp= lementation should limit the number of retransmissions and so leave the cho= ice up to the implementation.


> 2) Sec 5.3.1:
> "=C2=A0 =C2=A0This allows the client to rapidly detect when the s= ession has been
>=C2=A0 =C2=A0altered; at which point it can close the connection and re= try."
> When (immediately or after some waiting time) should the client retry = and how often?

I think that should be down to the implementation to decide.


> You further say
> "The client SHOULD treat this the
>=C2=A0 =C2=A0same way as they would any other interrupted transfer (alt= hough the
>=C2=A0 =C2=A0exact behavior is not specified here)."
> Where is that specified? Can you provide a pointer in the text?

That was a mistake in transcribing the original RFC2845 text.=C2=A0 The fin= al word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client SHOULD treat this the same way as th= ey would any other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interrupted transfer (although the exact behavi= or is not specified).


> 3) Sec 8.=C2=A0 Shared Secrets: Would it be appropriate to use more no= rmative language here? There are a bunch of lower case shoulds in this sect= ion; is that on purpose?

The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is ver= y general security advice.=C2=A0 Although this is something users ought to = do, it is not really a specific recommendation.



Comments from Barry Leiba

> =E2=80=94 Section 4.2 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>
> Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits?=C2= =A0 If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is = always 6?=C2=A0 If so, then shouldn=E2=80=99t it say that?=C2=A0 If not, th= en what don=E2=80=99t I understand?

Benjamin Kaduk also made the same comment, it has been addressed above.


> =E2=80=94 Section 5.1 =E2=80=94
>
>=C2=A0 =C2=A0Clients SHOULD only attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> Why SHOULD and not MUST?

Benjamin Kaduk also noted an issue here.=C2=A0 The paragraph has been remov= ed.


> =E2=80=94 Section 5.3.2 =E2=80=94
>
>=C2=A0 =C2=A0The server SHOULD also cache the most recent time signed >=C2=A0 =C2=A0value in a message generated by a key
>
> I tripped over this until I realized you mean =E2=80=9CTime Signed val= ue=E2=80=9D.=C2=A0 You capitalize it elsewhere, and it helps the parsing if= it=E2=80=99s consistent. There are four uncapitalized instances in this se= ction.

=E2=80=9Ctime signed=E2=80=9D has been capitalised.=C2=A0 In addition, in t= he description of the field, =E2=80=9Ctims signed=E2=80=9D has been replace= d with =E2=80=9Ctime the message was signed=E2=80=9D.

Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9CFu= dge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2=80=9D h= ave not been capitalised, as the context of that is that it is referring to= the contents of the Fudge field). Also, =E2=80=9Cother data=E2=80=9D and = =E2=80=9Cother data length=E2=80=9D have been replaced with the (capitalise= d) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COther Len=E2=80= =9D.


> =E2=80=94 Section 9 =E2=80=94
>
>=C2=A0 =C2=A0There is no structure
>=C2=A0 =C2=A0required other than names for different algorithms must be= unique
>=C2=A0 =C2=A0when compared as DNS names, i.e., comparison is case insen= sitive.
>
> I found this sentence to be really awkward and hard to parse.=C2=A0 Ma= y I suggest this?:
>
> NEW
> There is no structure to the names, and algorithm names are compared a= s if they were DNS names (the comparison is case-insensitive).
> END
>
> I don=E2=80=99t think you really need to say that each name is differe= nt/unique, right?

Agreed.=C2=A0 The text has been changed to that suggested.


>=C2=A0 =C2=A0other algorithm
>=C2=A0 =C2=A0names are simple (i.e., single-component) names.
>
> Nitty thing that you can completely ignore, but I would avoid the Lati= n abbreviation thus: =E2=80=9Cother algorithm names are simple, single-comp= onent names.=E2=80=9D

Changed.



Comments from =C3=89ric Vyncke

> Thank you for the work put into this document. It is clear and easy to= read.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will = be appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -=C3=A9ric
>
> =3D=3D COMMENTS =3D=3D
>
> There are 6 authors while the usual procedure is to limit to 5 authors= .. Personally, I do not care.
>
> -- Section 1.3 --
> It is a little unclear to me whether the "two nameservers" w= ere two implementations or two actual DNS servers.

Agreed, it was unclear.=C2=A0 Changed to =E2=80=9Ctwo name server implement= ations=E2=80=9D.


> -- Section 5.2 --
> Suggest to provide some justifications about "copied to a safe lo= cation": the DNS message was sent in the clear, why does the TSIG part= be copied in a safe location? Please define what is meant by "safe lo= cation" (Mainly for my own curiosity)

It is a bit over-specified and has been changed.=C2=A0 The text now reads:<= br>
=C2=A0 =C2=A0 =C2=A0 Upon receipt of
=C2=A0 =C2=A0 =C2=A0 =C2=A0a message with exactly one correctly placed TSIG= RR, a copy of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TSIG RR is stored, and the TSIG RR is removed fr= om the DNS Message,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and decremented out of the DNS message header= 9;s ARCOUNT.


> "cannot be understood" is also quite vague.

Changed to =E2=80=9Ccannot be interpreted=E2=80=9D.


> -- Section 5.3 --
> About rejecting request with a time signed value being earlier than th= e last received value. I wonder what is the value of this behavior if there= is no 'fudge' as well... The last paragraph of this section descri= bes this case and push the error handling to the request initiator. Any rea= son why being flexible on the receiving site was not selected ?

The fudge value is to cope with clock skew between the sender and receiver.= =C2=A0 This won't impact on the order in which the packets are received= by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-le= vel check. (It is not fool-proof - a number of packets signed by the sender= within a second of one another may have the same =E2=80=9CTime Signed=E2= =80=9D field.)

Pushing the error handling to the initiation goes back to the original RFC = 2845.


> =3D=3D NITS =3D=3D
>
> -- Section 4.3.2 --
> Is " A whole and complete DNS message in wire format." a com= plete and valid sentence?

This was also pointed out by Roman Danyliw and has been addressed.


Other changes made during editing

* There was no description of the contents of the =E2=80=9CError=E2=80=9D a= nd =E2=80=9COther Data=E2=80=9D fields were in a request.=C2=A0 This has no= w been corrected (Error is set to 0. The contents of =E2=80=9COther Data=E2= =80=9D are stated to be undefined to allow for extensions such as draft-and= rews-dnsop-defeat-frag-attack.)



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000006285005a5630063-- From nobody Mon May 11 12:38:32 2020 Return-Path: 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 B1FD63A0C63 for ; Mon, 11 May 2020 12:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 qdlOzACIBjdx for ; Mon, 11 May 2020 12:38:29 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 C8AAB3A0C62 for ; Mon, 11 May 2020 12:38:28 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 188so8537599lfa.10 for ; Mon, 11 May 2020 12:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=znvD9oBTAn1i7y3nSg1dIfCinR0xlX4MbrAaq1W96sU=; b=R6gYRCwL4RP+lhEkP+h2GtAWLjqmD7wxDVN/44dHtrMs0S3dcu+31ZH62/h8vBE9ou u0M3CyTRXkDXsu5E5fmrH1NHYRmWG0ylNjo4Q+BSVzVVZGViiw53mA0cinPR6WBTG66X Pa2Ukt/M74lQdcPcNtRsbmfaj9NX/asHSTqIfsU9d9pelJ5VyQvXR6Y5YI4wurkNfTPe GJAPIt7tA+vm3QZutQna+VcBppTovAqtNc9QgNrRzGieNFoeeq7ufwSRXd5j0X84O9Tc dycZUrP2CBMK0M8zzxnfxrz7jLEUGk8fD/EufFdzkR7Rq6oBxGH4elQLkZodWMaefKft mdcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=znvD9oBTAn1i7y3nSg1dIfCinR0xlX4MbrAaq1W96sU=; b=rsgRUBunYWPk9kWbdsP757KlCwQ5zvbe608Rw62DkTZNZENuKfVFTDwVA4PEDVa15n GOhdGHK5yImWjWsHezXAkvh4qXGcULOuldvE8q4n7KQ1hHsrLYxmGX10pCFvLsDaUyXX TK1Dxu5BEKCZmxcF2rKrKgKFcjf4dZcXMH8uTRz+Z68OUghxH/ePUlqUtvIvNNponuWs jkq3Ex9Nkt/Vv72yuEAqaOpBcpqYbRT2AMEjBwmMXZXCYk3uxgCoaS2gaeRijcvXX3yk jhC74vAUY5T4ZSMJuwxLTXCxIhJLOgJ8F/8WCVizMV/qggERElasGrEuzswzDrP777i3 hnEQ== X-Gm-Message-State: AOAM531dWCHi7yrYUJhy3pa9gem8Y2gr1ZfYCYD/InF5HXZ7SUWwVxCs vL1l1naHS7nASDHdDVqYuOqdhS1cTCB5ktA+A+PNiw== X-Google-Smtp-Source: ABdhPJxga/Sx8+UsRS7axWw/nUIx81eZuVzRswQDzmhxaENoLn2L1c+vwL0pUfiGC4Pv8yqgguNuk5kRszSNDn9ULXM= X-Received: by 2002:a19:7909:: with SMTP id u9mr12135590lfc.130.1589225906921; Mon, 11 May 2020 12:38:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob Harold Date: Mon, 11 May 2020 15:38:15 -0400 Message-ID: To: Tim Wicinski Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000a67daf05a5647db0" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 19:38:31 -0000 --000000000000a67daf05a5647db0 Content-Type: text/plain; charset="UTF-8" On Mon, May 11, 2020 at 1:42 PM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > I support adoption and will review. "3. Description An implementation of catalog zones MAY allow the catalog to contain other catalog zones as member zones." It seems ok to me to allow catalog zones to include other catalog zones as future feature, although I cannot figure out yet how that would work, but it might conflict with: "6.1. Implementation Notes Catalog zones on secondary nameservers would have to be setup manually" -- Bob Harold --000000000000a67daf05a5647db0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 11, 2020 at 1:42 PM Tim Wicin= ski <tjw.ietf@gmail.com> wr= ote:

A= ll,

As we stated in the meeting and in our chairs actions, we're= going to run
regular call for adoptions over next few months. =C2=A0We are looking for *explicit* support for adoption.


This starts= a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones

The dr= aft is available here: https://datatracker.ietf.o= rg/doc/draft-toorop-dnsop-dns-catalog-zones/

Please review this = draft to see if you think it is suitable for adoption
by DNSOP, and comm= ents to the list, clearly stating your view.

Please also indicate if= you are willing to contribute text, review, etc.

This call for adop= tion ends: 25 May 2020

Thanks,
tim wicinski
DNSOP co-chair
=


I support adoption and wil= l review.

"3.=C2=A0 Description
An implementation of catalog zones MAY allow the catalog to contain
=C2= =A0 =C2=A0other catalog zones as member zones."

It seems ok to me to allow catalog zones to include other catalog zo= nes as future feature, although I cannot figure out yet how that would work= , but it might conflict with:

"6.1.=C2=A0 Imp= lementation Notes
=C2=A0 =C2=A0Catalog zones on secondary nameservers wo= uld have to be setup
=C2=A0 =C2=A0manually"

--=C2=A0
Bob Harold
=C2=A0
--000000000000a67daf05a5647db0-- From nobody Mon May 11 12:39:23 2020 Return-Path: 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 E36383A0B30 for ; Mon, 11 May 2020 12:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 UWr7dp--Po0Z for ; Mon, 11 May 2020 12:39:14 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 3613C3A0C7C for ; Mon, 11 May 2020 12:38:57 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id w11so11180393iov.8 for ; Mon, 11 May 2020 12:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gKbPY5uAp72WNRuGMM8Sue9baAkjxQAei2Lq8UOO98Y=; b=ZWIXNdUsPOEBVbAunaIq22crchnTWyTA+uyxp5uY9bEyouyEJWVA2yvKCsECqncXEI 9oXbiXwtlyJowsvjRxwMNwxUAemZ9XAQQw5O4rK6JbFSQ5D9X7Htx1/ZmH0FOtA9SBv3 GQD1hHWzoJrKAeE3wylATos9g77tk0qhk9ZwGxHOFtQ3ynyWfV+2Uk/WDcyJlkfedjNk WiJ75z23lu1EBFGf6k+38Hwku5rmEthJ7WrQ64msc3KVu2lA8OM13gQyq05F7so394tJ vR7HHkA66h8XEdtp508B9anzyI3zoZlrDqy2n8WyJ6lH4wDyJznhQHIZ28OTlJFl//6C cgNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gKbPY5uAp72WNRuGMM8Sue9baAkjxQAei2Lq8UOO98Y=; b=SckNAvdPpk69bH+KvD1lup3XFwnJZVO0aR4TomNGc3XAfQ4Xoc1em5BcDwFF64OF2E 5473UUp2qj6Xlll3KcpSWPrXVXCjoKx8WNatLob9ZydgFzMyNO1joqQCH+55Aztyp+GH iQ1opMRWBv+LXYkQzgNNTP7vqIxF1vBZ8Y2cZ6f+rKRmprZaK6OexIPfXR0m+IFbukoB 5OHvGckqz8X7GLAe7BPwmImD0SSpQrQ2TlJSytppzYH6lGLkEAXmtYGHp0c/oZZmpfXR lGCKWslUyUOvRfC1ympXJONzmORNDKyWN+TxtjqJT8+E016WrpUOf78lkOdzL3eC0J83 T7pA== X-Gm-Message-State: AGi0PuYiQD0aT8DpvwByLF7AvhZuDPYcnOs5fLUwvNmvrL4UJWLlHNUp NFOxgcAbvJJPmnlIJbWACkhKd3tjsUJHblQePaNQG6Ril1w= X-Google-Smtp-Source: APiQypJZycjlAL9/SsM4MQQDoFxY0FYg+zqoCRzz5mEynmLEFYdpVquQWxXh9N6SUB9R71F6zgfvR3QfpPFsifEcYus= X-Received: by 2002:a6b:6607:: with SMTP id a7mr9574084ioc.167.1589225935951; Mon, 11 May 2020 12:38:55 -0700 (PDT) MIME-Version: 1.0 References: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> In-Reply-To: From: Donald Eastlake Date: Mon, 11 May 2020 15:38:44 -0400 Message-ID: To: Tim Wicinski Cc: Stephen Morris , dnsop Content-Type: multipart/alternative; boundary="000000000000615d0f05a5647fdc" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 19:39:22 -0000 --000000000000615d0f05a5647fdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim, On Mon, May 11, 2020 at 1:51 PM Tim Wicinski wrote: > Donald > > So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ? > Yes, that would be fine. SHA-224 is just SHA-256 with some different initial vectors and the result truncated to 224 bits. So if you have implemented SHA-256, it takes like 0.1% more code to add SHA-224. And, while the value of SHA-224 would be different for a particular input from the value of SHA-256 truncated to 224 bits, I don't see any reason why it would be less secure. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, May 11, 2020 at 12:29 AM Donald Eastlake wrote: > >> The incremental effort to implement SHA-224 if you are implementing >> SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT >> RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use >> and you can use SHA-256 with truncation to 224 or even fewer bits. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com >> >> >> On Sat, May 9, 2020 at 9:52 PM Tim Wicinski wrote: >> >>> To follow up on Stephen's comments, a table was added to 2845bis to >>> list all the algorithms that are currently in the IANA registry, >>> along with suggestions for implementation. This was the first version: >>> >>> Requirement Name >>> ----------- ------------------------ >>> Optional HMAC-MD5.SIG-ALG.REG.INT >>> Optional gss-tsig >>> Mandatory hmac-sha1 >>> Optional hmac-sha224 >>> Mandatory hmac-sha256 >>> Optional hmac-sha384 >>> Optional hmac-sha512 >>> >>> During the IESG review (I think it was the SECDIR review), there was >>> a meltdown over implementing SHA-1. But SHA-1 is in use currently. >>> My suggestion was to do a variation describing implementation use. >>> This is what I came up with(so blame me): >>> >>> Name Implementation Use >>> ------------------------ -------------- --------------- >>> HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT >>> gss-tsig MAY MAY >>> hmac-sha1 MUST NOT RECOMMENDED >>> hmac-sha224 MAY NOT RECOMMENDED >>> hmac-sha256 MUST RECOMMENDED >>> hmac-sha256-128 MAY MAY >>> hmac-sha384 MAY MAY >>> hmac-sha384-192 MAY MAY >>> hmac-sha512 MAY MAY >>> hmac-sha512-256 MAY MAY >>> >>> On the use side, these are mostly guesses. We would love to hear >>> what the WG has to say about this. >>> >>> thanks >>> tim >>> >>> >>> On Mon, May 4, 2020 at 2:07 PM Stephen Morris >>> wrote: >>> >>>> >>>> > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> > This draft is a work item of the Domain Name System Operations WG of >>>> the IETF. >>>> > >>>> > Title : Secret Key Transaction Authentication for >>>> DNS (TSIG) >>>> > Authors : Francis Dupont >>>> > Stephen Morris >>>> > Paul Vixie >>>> > Donald E. Eastlake 3rd >>>> > Olafur Gudmundsson >>>> > Brian Wellington >>>> > Filename : draft-ietf-dnsop-rfc2845bis-08.txt >>>> > Pages : 29 >>>> > Date : 2020-05-04 >>>> >>>> >>>> The update addresses to the draft comments made during the IESG >>>> review. There were a fair number of these which led to a number of ch= anges >>>> to the document. These are listed below. >>>> >>>> One significant change is that the list of acceptable algorithms has >>>> been extended, and WG approval for this is sought. >>>> >>>> Stephen >>>> >>>> >>>> >>>> >>>> Comments from Roman Danyliw >>>> --- >>>> > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly fol= lowing >>>> that document (and the related [RFC4635]) were discovered to have secu= rity >>>> problems related to this feature=E2=80=9D, consider providing a refere= nce to the >>>> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143) >>>> >>>> I=E2=80=99ve added these (and one other related CVE) as informative >>>> references. Using just the CVE number as a reference seemed a bit spa= rtan, >>>> so I=E2=80=99ve added a title to each incident. As the description of = the CVEs in >>>> Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descrip= tion, which can be >>>> rather long), I=E2=80=99ve taken the title from ISC=E2=80=99s Knowledg= eBase (for the BIND >>>> CVEs) and from the Knot release notes (for the Knot CVE). >>>> >>>> >>>> > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated = so the >>>> MD5 security considerations apply to SHA-1 in a similar manner. Altho= ugh >>>> support for hmac-sha1 in TSIG is still mandatory for compatibility rea= sons, >>>> existing uses should be replaced with hmac-sha256 or other SHA-2 diges= t >>>> algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>>> > >>>> > -- It=E2=80=99s worth repeating those MD5 security considerations he= re >>>> >>>> I=E2=80=99m not really keen on doing this, since the security consider= ations in >>>> RFC 6151 cover two paragraphs and including them - or even a summary o= f >>>> them - would detract from the flow of the document. However, I have >>>> explicitly included a reference to RFC 6151 in the text. >>>> >>>> >>>> > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it= =E2=80=99s worth >>>> including references to the recent SHA-1 cryptoanalysis provided in th= e >>>> SECDIR review >>>> >>>> Added references to just one of these papers (=E2=80=9DSHA1 is a Shamb= les=E2=80=9D). >>>> We=E2=80=99re not doing a general analysis of the algorithms, so a sim= ple reference >>>> to a paper than describes a SHA1 collision is all that is needed. (As= an >>>> aside, the paper doesn't give the date of publication, so I had to sea= rch >>>> the Web looking for references to it. I think I=E2=80=99ve got the da= te correct, >>>> but I=E2=80=99d be grateful for a double-check.) >>>> >>>> >>>> > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). >>>> >>>> Done - see Table 2 >>>> >>>> >>>> > ** Section 10. Per =E2=80=9CFor all of the message authentication c= ode >>>> algorithms listed in this document, those producing longer values are >>>> believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR = review, this could be >>>> misconstrued as the algorithm choice not the digest length provides th= e >>>> security. Recommend rephrasing (or making some statement >>>> >>>> I=E2=80=99ve reworded this paragraph (in section 10). It now reads: >>>> >>>> "Although the strength of an algorithm determines its security, ther= e >>>> have been some arguments that mild truncation can strengthen a MAC b= y >>>> reducing the information available to an attacker. However, excessi= ve >>>> truncation clearly weakens authentication by reducing the number of >>>> bits an attacker has to try to break the authentication by brute >>>> force [RFC2104]." >>>> >>>> >>>> > ** Editorial >>>> > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message, = this is >>>> the message after the TSIG RR and been removed and the ARCOUNT field h= as >>>> been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (is mi= ssing a word). >>>> > >>>> > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in = wire >>>> format.=E2=80=9D, this isn=E2=80=99t a sentence. >>>> >>>> Section 4.3.2 has been reworded to address these issues. >>>> >>>> >>>> >>>> Comments from Benjamin Kaduk >>>> >>>> > Thanks for putting together this update; it's good to see the securi= ty >>>> > issue getting closed off in the udpated spec, and progression to ful= l >>>> > Internet Standard! I do have several substantive comments (as well = as >>>> > some minor/nit-level ones), many of which are listed here at the top >>>> but >>>> > a few of which are interspersed in the per-section comments. >>>> > >>>> > >>>> > I considered making this a Discuss point, but it should be pretty >>>> > uncontroversial and I trust that the right thing will happen even if= I >>>> > don't: there's a couple lingering remnants of SHA-1 being the >>>> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 >>>> and >>>> > 10 (further detailed in the per-section comments). >>>> >>>> The document now mentions SHA1 collisions and notes that the MD5 >>>> security considerations apply to SHA1. It also mentions that support = for >>>> SHA1 is mandatory for compatibility reasons but in existing uses it sh= ould >>>> be replaced by a stronger one. >>>> >>>> >>>> > I also initially had made the following point a Discuss-level point, >>>> but >>>> > decided to not do so since I don't remember any BCP-level guidance >>>> > relating to cross-protocol attacks. Nevertheless, I strongly >>>> encourage >>>> > the authors to consider that cryptographic best practice is to use a= ny >>>> > given key with exactly one cryptographic algorithm. The record form= at >>>> > listed in Section 4.2 has the key name and algorithm as separately >>>> > conveyed, which would allow for a given key to be used with all >>>> > implemented algorithms. We should include some discussion that it's >>>> > best to only use a single algorithm with any given key. >>>> >>>> The following text has been added to the Security Considerations >>>> section: >>>> >>>> "To prevent cross-algorithm attacks, there SHOULD only be one >>>> algorithm associated with any given key name." >>>> >>>> >>>> > We also have a 16-bit wide field for "Fudge", which (since it counts >>>> > seconds) corresponds to a maximum window of something like +/- 18 >>>> hours; >>>> > it's hard to believe that we really want to give people the rope to >>>> > allow for that much time skew. (Yes, I understand that >>>> implementations >>>> > will set something sane in practice but that doesn't necessarily mea= n >>>> > that the protocol still has to allow it.) >>>> >>>> That was set in the original RFC 2845. Although I agree with the >>>> comments, changing the size of that field would be a significant >>>> undertaking. However, section 10 does state that the RECOMMENDED fudg= e >>>> value in most circumstances is 300 seconds. >>>> >>>> >>>> > Our authoritative list of algorithm names (Table 1) is rather divorc= ed >>>> > from the references to be consulted for the individual hash algorith= ms >>>> > to be used with the HMAC procedure. The ones used here are >>>> sufficiently >>>> > well-known that I'm not terribly concerned about it, though. >>>> >>>> The first paragraph of the IANA considerations section lists the >>>> algorithms and references to where they are described, and I didn=E2= =80=99t want to >>>> duplicate the information. >>>> >>>> >>>> > Abstract >>>> > >>>> > The title says "DNS" but maybe the body of the abstract should as >>>> well? >>>> >>>> In the abstract, changed: >>>> >>>> "It can be used to authenticate dynamic updates as coming from an >>>> approved client" >>>> >>>> to >>>> >>>> "It can be used to authenticate dynamic updates to a DNS zone as comin= g >>>> from an approved client" >>>> >>>> >>>> > Section 1.1 >>>> > >>>> > Some of this language feels like it might not age terribly well, e.g= ., >>>> > "this can provide" or "[t]here was a need". >>>> > >>>> > addresses that need. The proposal is unsuitable for general serve= r >>>> > to server authentication for servers which speak with many other >>>> > servers, since key management would become unwieldy with the numbe= r >>>> > of shared keys going up quadratically. But it is suitable for man= y >>>> > resolvers on hosts that only talk to a few recursive servers. >>>> >>>> Changed to: >>>> >>>> "The authentication mechanism proposed here provides a >>>> simple and efficient authentication between clients and local >>>> servers >>>> by using shared secret keys to establish a trust relationship >>>> between >>>> two entities. Such keys must be protected in a manner similar >>>> to >>>> private keys, lest a third party masquerade as one of the >>>> intended >>>> parties (by forging the MAC). The proposal is unsuitable for >>>> general >>>> server to server authentication for servers which speak with >>>> many >>>> other servers, since key management would become unwieldy with >>>> the >>>> number of shared keys going up quadratically. But it is >>>> suitable for >>>> many resolvers on hosts that only talk to a few recursive >>>> servers.=E2=80=9D >>>> >>>> >>>> > Should zone transfers be mentioned here as well? >>>> >>>> Zone transfers are mentioned in the preceding paragraph. >>>> >>>> >>>> > Section 1.2 >>>> > >>>> > I don't understand the motivation for changing terminology from MACs >>>> to >>>> > "signatures"; they're still MACs even though they're >>>> transaction-based. >>>> >>>> The mention of signatures in section 1.2 is intended as a link between >>>> the name of the RR (TSIG or Transaction Signature) and the term MAC us= ed in >>>> the rest of the document. >>>> >>>> >>>> > MAC of the query as part of the calculation. Where a response >>>> > comprises multiple packets, the calculation of the MAC associated >>>> > with the second and subsequent packets includes in its inputs the >>>> MAC >>>> > for the preceding packet. In this way it is possible to detect an= y >>>> > interruption in the packet sequence. >>>> > >>>> > I suggest mentioning the lack of mechanism to detect truncation of t= he >>>> > packet sequence. >>>> >>>> That is a fair point. I=E2=80=99ve modified the last sentence to read= : >>>> >>>> "In this way it is possible to detect any interruption in the packe= t >>>> sequence, >>>> although not its premature termination." >>>> >>>> >>>> > Section 4.2 >>>> > >>>> > NAME The name of the key used, in domain name syntax.. The name >>>> > should reflect the names of the hosts and uniquely identify >>>> the >>>> > key among a set of keys these two hosts may share at any giv= en >>>> > time. For example, if hosts A.site.example and >>>> > B.example.net >>>> > >>>> > share a key, possibilities for the key name include >>>> > .A.site.example, ..B.example.net, and >>>> > .A.site.example.B..example.net >>>> . It should be possible for >>>> > more than one key to be in simultaneous use among a set of >>>> > interacting hosts. >>>> > >>>> > I'd suggest adding a note along the lines of "This allows for period= ic >>>> > key rotation per best operational practices, as well as algorithm >>>> > agility as indicated by [BCP201].=E2=80=9D >>>> >>>> Added. >>>> >>>> >>>> > The name may be used as a local index to the key involved an= d >>>> > it is recommended that it be globally unique. Where a key i= s >>>> > >>>> > (nit?): this feels more like a "but" than an "and", to me. >>>> >>>> Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D >>>> >>>> >>>> > * MAC Size - an unsigned 16-bit integer giving the length o= f >>>> > MAC field in octets. Truncation is indicated by a MAC si= ze >>>> > less than the size of the keyed hash produced by the >>>> > algorithm specified by the Algorithm Name. >>>> > >>>> > nit: I would suggest "output size", as there are potentially a few >>>> > different sizes involved (key size, block size, and output size, for >>>> > starters, though I think the possibility of confusion here is low). >>>> >>>> I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous referenc= e to this field, >>>> and the other size mentioned - that of the keyed hash is, I think, als= o >>>> unambiguous. >>>> >>>> >>>> > * Other Len - an unsigned 16-bit integer specifying the >>>> length >>>> > of the "Other Data" field in octets. >>>> > >>>> > * Other Data - this unsigned 48-bit integer field will be >>>> > empty unless the content of the Error field is BADTIME, i= n >>>> > which case it will contain the server's current time as t= he >>>> > number of seconds since 00:00 on 1970-01-01 UTC, ignoring >>>> > leap seconds (see Section 5.2..3). >>>> > >>>> > I'm slightly confused at the interplay between the explicit length >>>> field >>>> > and the "empty unless" directive. Does this mean that the only >>>> allowed >>>> > values in the "Other Len" are 0 and 6? Does "empty" mean >>>> "length-zero=E2=80=9D? >>>> >>>> I=E2=80=99ve rewritten this slightly in a bid to make it clearer that = =E2=80=9COther >>>> Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80=9D is ze= ro. >>>> >>>> >>>> > Section 4.3.1 >>>> > >>>> > Only included in the computation of a MAC for a response message (= or >>>> > the first message in a multi-message response), the validated >>>> request >>>> > MAC MUST be included in the MAC computation. If the request MAC >>>> > failed to validate, an unsigned error message MUST be returned >>>> > instead. (Section 5.3.2). >>>> > >>>> > side note: while Section 5.3.2 specifies how to create an unsigned >>>> error >>>> > message, it looks like Section 5.2 (and subsections lists specific >>>> > RCODEs that are to be used. >>>> >>>> That is the case. Section 4 is a description of the TSIG RR and its >>>> fields. Section 5 describes the contents of the fields in various >>>> situations (client transmission, server reception, server transmission= , >>>> client reception). >>>> >>>> >>>> > Section 4.3.2 >>>> > >>>> > When verifying an incoming message, this is the message after the >>>> > TSIG RR and been removed and the ARCOUNT field has been decremente= d. >>>> > If the message ID differs from the original message ID, the origin= al >>>> > message ID is substituted for the message ID. (This could happen, >>>> > for example, when forwarding a dynamic update request.) >>>> > >>>> > I trust (based on this text having survived while going for full IS) >>>> > that there are no interesting record-keeping considerations with >>>> respect >>>> > to knowing the message ID(s) to substitute, in the "forwarding a >>>> > dynamic-update request" case, presumably since this is just the fiel= d >>>> > from the TSIG RDATA and not some externally retained state. >>>> >>>> That is correct - the original ID is stored in the TSIG record=E2=80= =99s RDATA >>>> and it is from there that the original ID is retrieved when a substitu= tion >>>> is made. >>>> >>>> >>>> > Section 4.3.3 >>>> > >>>> > The RR RDLEN and RDATA MAC Length are not included in the input to >>>> > MAC computation since they are not guaranteed to be knowable befor= e >>>> > the MAC is generated. >>>> > >>>> > I appreciate that this is explicitly noted; there are some security >>>> > considerations regarding the non-inclusion of the (truncated) mac >>>> length >>>> > as input, though. The local truncation policy helps here, but not >>>> 100%. >>>> >>>> OK >>>> >>>> >>>> > For each label type, there must be a defined "Canonical wire forma= t" >>>> > >>>> > Just to check my understanding: label types only come into play for >>>> the >>>> > two fields that are in domain name syntax, key name and algorithm >>>> name? >>>> >>>> There was actually an error in the text here: RFC 4034 section 6.1 is >>>> concerned with Canonical Name Order. It is section 6.2 that details t= he >>>> canonical wire format - I=E2=80=99ve changed the reference. >>>> >>>> Going back to the original point, yes, that is correct. Label type 00 >>>> is uncompressed name. (11 is a compressed name, and label types 01 and= 10 >>>> are discouraged - see RFC 6891 section 5). >>>> >>>> >>>> > Section 5.1 >>>> > >>>> > the server. This TSIG record MUST be the only TSIG RR in the >>>> message >>>> > and MUST be last record in the Additional Data section. The clien= t >>>> > >>>> > (Is there anything else that tries to insist on being the last recor= d >>>> in >>>> > the additional data section? I guess it doesn't really make sense t= o >>>> > try to Update: 1035 just to note this requirement.) >>>> >>>> Not to our knowledge. >>>> >>>> >>>> > MUST store the MAC and the key name from the request while awaitin= g >>>> > an answer. >>>> > >>>> > [This is going to end up alongside the request-ID that it has to sto= re >>>> > already, right?] >>>> >>>> Yes. The request MAC is included as one of the components used by the >>>> server to generate the response - which should be encoded using the sa= me >>>> key as used in the request. >>>> >>>> >>>> > Note that some older name servers will not accept requests with a >>>> > nonempty additional data section. Clients SHOULD only attempt >>>> signed >>>> > transactions with servers who are known to support TSIG and share >>>> > some algorithm and secret key with the client -- so, this is not a >>>> > problem in practice. >>>> > >>>> > (The context in which this "SHOULD" appears makes it feel like it's >>>> > repeating an admontion from elsewhere and not the only instance of t= he >>>> > requirement, in which case a reference might be appropriate.) >>>> >>>> I=E2=80=99ve removed this paragraph. The reference to older name serv= ers is >>>> now completely out of date (it was a carry-over from the original 20-y= ear >>>> old text). The rest of the paragraph seems superfluous - rather like >>>> stating that TCP clients should only connect to servers that support T= CP. >>>> >>>> >>>> > Section 5.2 >>>> > >>>> > If the TSIG RR cannot be understood, the server MUST regard the >>>> > message as corrupt and return a FORMERR to the server. Otherwise >>>> the >>>> > server is REQUIRED to return a TSIG RR in the response. >>>> > >>>> > As written, this could be read as an attempt to make a normative >>>> > requirement of servers that do not implement this spec. Presumably >>>> it's >>>> > just restating a requirement of the core protocol, though? >>>> >>>> It is the core protocol. >>>> >>>> I see your point though. However, by implication we are talking about >>>> a server that implements TSIG. >>>> >>>> >>>> > Section 5.2.2 >>>> > >>>> > Using the information in the TSIG, the server should verify the MA= C >>>> > by doing its own calculation and comparing the result with the MAC >>>> > received. If the MAC fails to verify, the server MUST generate an >>>> > >>>> > Is there any other way to verify the MAC? (Should this be a "MUST >>>> > verify=E2=80=9D?) >>>> >>>> Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. >>>> >>>> >>>> > Section 5.2.2.1 >>>> > >>>> > When space is at a premium and the strength of the full length of = a >>>> > MAC is not needed, it is reasonable to truncate the keyed hash and >>>> > use the truncated value for authentication. HMAC SHA-1 truncated = to >>>> > 96 bits is an option available in several IETF protocols, includin= g >>>> > IPsec and TLS. >>>> > >>>> > Also Kerberos, where it was the strongest option for a while and we >>>> had >>>> > to define a new encryption type to provide a better option (RFC 8009= ). >>>> > >>>> > This text seems to be implying that HMAC SHA-1 truncated to 96 bits >>>> is a >>>> > recommendable option, which is ... far from clear. I'd prefer to >>>> have a >>>> > note that this specific truncation was appropriate when initially >>>> > specified but may not provide a security level appropriate for all >>>> cases >>>> > in the modern environment, or preferrably to just change the referen= ce >>>> > to (e.g.) SHA-384-192 or SHA-256-128. >>>> >>>> Added the following an the end of the paragraph: >>>> >>>> However, while this option is kept for backwards compatibility, >>>> it may not provide a security level appropriate for all cases >>>> in the modern environment. In these cases, it is preferable to >>>> use a hashing algorithm such as SHA-256-128, SHA-384-192 >>>> or SHA-256-128 [RFC4868]. >>>> >>>> I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80= =9D, =E2=80=9Chmac-sha384-192=E2=80=9D and >>>> =E2=80=9Chmac-sha512-256=E2=80=9D as optional algorithms to the algori= thm table. >>>> >>>> >>>> > This is sent when the signer has truncated the keyed hash outp= ut >>>> > to an allowable length, as described in [RFC2104], taking >>>> initial >>>> > octets and discarding trailing octets. TSIG truncation can on= ly >>>> > >>>> > (Or when an on-path attacker has performed truncation.) >>>> >>>> True, but an on-path attacker can manipulate the message in any way >>>> possible. I=E2=80=99m not sure whether adding this caveat will add an= ything to the >>>> document. >>>> >>>> >>>> > Section 5.2.3 >>>> > >>>> > (BADTIME). The server SHOULD also cache the most recent time sign= ed >>>> > value in a message generated by a key, and SHOULD return BADTIME i= f >>>> a >>>> > message received later has an earlier time signed value. A respon= se >>>> > >>>> > (But there's no fudge factor on this check, other than the inherent >>>> > limit of seconds granularity, as alluded to by the last paragraph of >>>> > this section?) >>>> >>>> The last paragraph in the section states that handling this issue >>>> should be left up to implementations and that the exact method (and by >>>> implication, the size of the fudge factor) be determined by the >>>> implementation themselves. >>>> >>>> >>>> > Section 5.3.1 >>>> > >>>> > A zone transfer over a DNS TCP session can include multiple DNS >>>> > messages. Using TSIG on such a connection can protect the >>>> connection >>>> > from hijacking and provide data integrity. The TSIG MUST be >>>> included >>>> > >>>> > (I assume that "hijacking TCP" means a sequence-number-guessing atta= ck >>>> > that would require the attacker to be winning the race against the >>>> > legitimate sender to cause modified data to be introduced into the T= CP >>>> > stream? This is maybe not the best word to use for such a case.) >>>> >>>> I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80= =9D. >>>> >>>> >>>> > on all DNS messages in the response. For backward compatibility, = a >>>> > client which receives DNS messages and verifies TSIG MUST accept u= p >>>> > to 99 intermediary messages without a TSIG. The first message is >>>> > >>>> > (side note: I'm kind of curious what such compatibility is needed >>>> with. >>>> > Also, this gives an attacker some flexibility into which to >>>> incorporate >>>> > a collision, though given the near-real-time constraints and the >>>> > strength of the HMAC construction I don't expect any practical >>>> impact.) >>>> >>>> The original RFC 2845 did not require all packets in a message stream >>>> to contain a TSIG, it just stated that there be no more than 99 >>>> intermediary messages without a TSIG (presumably to cut down on the >>>> overhead required in message calculations - remember that RFC 2845 was >>>> published 20 years ago). Although many DNS implementations now add a = TSIG >>>> to every message, it is by no means certain that all do. (In fact, les= s >>>> than three years ago, a bug was introduced into BIND, causing it to re= quire >>>> that all packets in a zone transfer would contain a TSIG. A fix allow= ing >>>> BIND to accept up to 99 packets between signed ones was released short= ly >>>> afterwards after reports were received of zone transfers failing.) >>>> >>>> >>>> > Section 5.3.2 >>>> > >>>> > Request MAC (if the request MAC validated) >>>> > DNS Message (response) >>>> > TSIG Variables (response) >>>> > >>>> > The reason that the request is not included in this MAC in some >>>> cases >>>> > is to make it possible for the client to verify the error. If the >>>> > error is not a TSIG error the response MUST be generated as >>>> specified >>>> > in Section 5.3. >>>> > >>>> > This makes it sound like the server excludes the request MAC from th= e >>>> > digest if it failed to validate (something the client cannot predict= ), >>>> > so that the client must perform trial verification of both versions = in >>>> > order to validate the response. Is that correct? >>>> >>>> No. If the incoming MAC failed to validate, the server should send >>>> back an unsigned response (MAC size =3D=3D 0 and empty MAC). >>>> >>>> >>>> > Also, I think that the "in some cases" is not properly placed: as-is= , >>>> it >>>> > says that the request (not request MAC) is sometimes not included >>>> > (implying that sometimes it is), which does not match up with the >>>> > specification for the digest components. I presume that the intent = is >>>> > to say that in some cases the client could not verify the error, if >>>> the >>>> > request itself was always included in the digest. >>>> >>>> Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. >>>> >>>> If the MAC could not be verified, it is possible that it was corrupted= , >>>> which would prevent the client verifying the response. But a major rea= son >>>> is that an incorrect MAC included in a signed response led to the CVEs= that >>>> prompted this document update. >>>> >>>> >>>> > Section 5.4.1 >>>> > >>>> > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG >>>> > validates and the TSIG key recognised by the client but different >>>> > from that used on the request, then this is a Key Error. The clie= nt >>>> > >>>> > nits: missing words "key is recognized" and "but is different=E2=80= =9D >>>> >>>> It now reads =E2=80=9Ckey is recognized but different" >>>> >>>> >>>> > Section 5.5 >>>> > >>>> > destination or the next forwarder. If no transaction security is >>>> > available to the destination and the message is a query then, if t= he >>>> > corresponding response has the AD flag (see [RFC4035]) set, the >>>> > forwarder MUST clear the AD flag before adding the TSIG to the >>>> > response and returning the result to the system from which it >>>> > received the query. >>>> > >>>> > Is there anything to say about the CD bit? (It's independent crypto= , >>>> so >>>> > I don't expect so, but it seems worth checking.) >>>> >>>> No. CD is just a mechanism by which a client can request that the >>>> server not do DNSSEC signature validation on the data and so allow the >>>> client to receive the data instead of a SERVFAIL response. >>>> >>>> >>>> > Section 6 >>>> > >>>> > The only message digest algorithm specified in the first version o= f >>>> > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], >>>> > [RFC2104]). Although a review of its security [RFC6151] concluded >>>> > that "it may not be urgent to remove HMAC-MD5 from the existing >>>> > protocols", with the availability of more secure alternatives the >>>> > opportunity has been taken to make the implementation of this >>>> > algorithm optional. >>>> > >>>> > It seems worth noting that the advice from RFC 6151 is already nine >>>> > years old. >>>> >>>> I=E2=80=99ve use the phrasing "Although a review of its security some = years >>>> ago=E2=80=9D. >>>> >>>> >>>> > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], >>>> > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 >>>> > security considerations apply to SHA-1 in a similar manner.. >>>> Although >>>> > >>>> > I'd consider referencing (e.g.) >>>> > shattered.io >>>> > for the "collisions have >>>> > been demonstrated" claim, though it's pretty optional. >>>> >>>> A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D = paper.. >>>> >>>> >>>> > support for hmac-sha1 in TSIG is still mandatory for compatibility >>>> > reasons, existing uses should be replaced with hmac-sha256 or othe= r >>>> > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>>> > >>>> > Is this "sha1 mandatory for compatibility" going to age well? If we >>>> > have two implementations that can operate with sha2 variants, is it >>>> > required to keep this as mandatory (vs. optional with a note about >>>> > deployed reality at time of publication) for progression to Internet >>>> > Standard? >>>> >>>> This has been addressed by splitting the =E2=80=9CMandatory/Optional= =E2=80=9D column in >>>> RFC4635 (from which Table 2 was derived) into =E2=80=9CImplementation= =E2=80=9D and =E2=80=9CUse=E2=80=9D. >>>> SHA1 is required to be implemented (for backwards compatibility) but i= ts >>>> use is not recommended. >>>> >>>> >>>> > Optional hmac-sha224 >>>> > >>>> > It's not clear there's much reason to keep this around, or if we do, >>>> it >>>> > could probably be "not recommended". (I assume that just dropping i= t >>>> > entirely makes things annoying w.r.t. the IANA registry.) >>>> >>>> It has been left in for compatibility reasons, but its use is not >>>> recommended. >>>> >>>> >>>> > Section 9 >>>> > >>>> > Previous specifications [RFC2845] and [RFC4635] defined values for >>>> > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >>>> > >>>> > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping where >>>> > HMAC qualifies both hash algorithms is not terribly clear. >>>> >>>> Changed to >>>> >>>> Previous specifications [RFC2845] and [RFC4635] defined names >>>> for >>>> the HMAC-MD5 and the various HMAC-SHA algorithms. >>>> >>>> >>>> > Section 10 >>>> > >>>> > I suggest some discussion that the way truncation policy works, an >>>> > attackers ability to forge messages accepted as valid is limited by >>>> the >>>> > amount of truncation that the recipient is willing to accept, not th= e >>>> > amount of truncation used to generate messages by the legitimate >>>> sender. >>>> >>>> I think this is already taken care of by the reference to a local >>>> policy in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D se= ction (5.2.4). >>>> >>>> >>>> > There's also some fairly standard content to put in here about >>>> allowing >>>> > for an unsigned error response to a signed request, so an attacker >>>> (even >>>> > off-path) can spoof such resposnes. (Section 5.4 indicates that the >>>> > client should continue to wait if it gets such a thing, which helps = a >>>> > lot.) >>>> >>>> I=E2=80=99ve just added text that an unsigned response is not consider= ed >>>> acceptable because can be subject to spoofing and manipulation. >>>> >>>> >>>> > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two >>>> > entities. >>>> > >>>> > I suggest adding "; any such additional sharing would allow any part= y >>>> > knowing the key to impersonate any other such party to members of th= e >>>> > group=E2=80=9D. >>>> >>>> Added. >>>> >>>> >>>> > A fudge value that is too large may leave the server open to repla= y >>>> > attacks. A fudge value that is too small may cause failures if >>>> > machines are not time synchronized or there are unexpected network >>>> > delays. The RECOMMENDED value in most situations is 300 seconds. >>>> > >>>> > Our experience with kerberos in modern network environments has show= n >>>> > that 5 minutes is much larger than needed, though it's not clear >>>> there's >>>> > a strong need to change this recommendation right now. >>>> >>>> The value is recommended (and even then, only in =E2=80=9Cmost situati= ons=E2=80=9D), so >>>> implementations are free to set their own value. However, any guidanc= e as >>>> to typical time skews measured across a network would be useful in a n= umber >>>> of protocols. >>>> >>>> >>>> > Significant progress has been made recently in cryptanalysis of ha= sh >>>> > functions of the types used here. While the results so far should >>>> > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are bei= ng >>>> > made mandatory as a precaution. >>>> > >>>> > Please revise this note to not imply that SHA-1 is considered >>>> "strong=E2=80=9D. >>>> >>>> Text revised to >>>> >>>> Significant progress has been made recently in cryptanalysis o= f >>>> hash >>>> functions of the types used here. While the results so far >>>> should not >>>> affect HMAC, the stronger SHA-256 algorithm is being made >>>> mandatory >>>> as a precaution. >>>> >>>> >>>> > Section 11.2 >>>> > >>>> > I'm not sure why RFC 2104 is listed as informative. >>>> >>>> RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of = a possible >>>> downref if the reference is placed in the =E2=80=9CNormative=E2=80=9D = section. >>>> >>>> >>>> >>>> Comments from Mirja K=C3=BChlewind >>>> >>>> > I only had limited time for a quick review of this document, so I >>>> might not be aware of all the needed background and details. Still I h= ave >>>> two quick questions on retries: >>>> > >>>> > 1) Sec 5.2.3: >>>> > "Implementations should be aware >>>> > of this possibility and be prepared to deal with it, e.g. by >>>> > retransmitting the rejected request with a new TSIG once outstandi= ng >>>> > requests have completed or the time given by their time signed plu= s >>>> > fudge value has passed." >>>> > I might not be aware of all protocol details and maybe this is >>>> already specified somewhere: While unlikely, it is possible that a req= uest >>>> might be retransmitted multiple times, as that could cause president >>>> congestion over time, it's always good practice to define a maximum nu= mber >>>> of retransmissions. If that is already defined somewhere, maybe adding= a >>>> note/pointer would be good as well. >>>> >>>> If someone can suggest a suitable number (and a reason for it), we can >>>> consider doing this. In the meantime, I=E2=80=99ve merely stated that >>>> implementation should limit the number of retransmissions and so leave= the >>>> choice up to the implementation. >>>> >>>> >>>> > 2) Sec 5.3.1: >>>> > " This allows the client to rapidly detect when the session has be= en >>>> > altered; at which point it can close the connection and retry." >>>> > When (immediately or after some waiting time) should the client retr= y >>>> and how often? >>>> >>>> I think that should be down to the implementation to decide. >>>> >>>> >>>> > You further say >>>> > "The client SHOULD treat this the >>>> > same way as they would any other interrupted transfer (although th= e >>>> > exact behavior is not specified here)." >>>> > Where is that specified? Can you provide a pointer in the text? >>>> >>>> That was a mistake in transcribing the original RFC2845 text. The >>>> final word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads= : >>>> >>>> The client SHOULD treat this the same way as they would any >>>> other >>>> interrupted transfer (although the exact behavior is not >>>> specified). >>>> >>>> >>>> > 3) Sec 8. Shared Secrets: Would it be appropriate to use more >>>> normative language here? There are a bunch of lower case shoulds in th= is >>>> section; is that on purpose? >>>> >>>> The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear i= s very general >>>> security advice. Although this is something users ought to do, it is = not >>>> really a specific recommendation. >>>> >>>> >>>> >>>> Comments from Barry Leiba >>>> >>>> > =E2=80=94 Section 4.2 =E2=80=94 >>>> > >>>> > * Other Len - an unsigned 16-bit integer specifying the >>>> length >>>> > of the "Other Data" field in octets. >>>> > * Other Data - this unsigned 48-bit integer field will be >>>> > >>>> > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits? = If so, does that >>>> mean tgat the value of =E2=80=9Cother len=E2=80=9D is always 6? If so= , then shouldn=E2=80=99t it >>>> say that? If not, then what don=E2=80=99t I understand? >>>> >>>> Benjamin Kaduk also made the same comment, it has been addressed above= . >>>> >>>> >>>> > =E2=80=94 Section 5.1 =E2=80=94 >>>> > >>>> > Clients SHOULD only attempt signed >>>> > transactions with servers who are known to support TSIG and share >>>> > some algorithm and secret key with the client -- so, this is not a >>>> > problem in practice. >>>> > >>>> > Why SHOULD and not MUST? >>>> >>>> Benjamin Kaduk also noted an issue here. The paragraph has been >>>> removed. >>>> >>>> >>>> > =E2=80=94 Section 5.3.2 =E2=80=94 >>>> > >>>> > The server SHOULD also cache the most recent time signed >>>> > value in a message generated by a key >>>> > >>>> > I tripped over this until I realized you mean =E2=80=9CTime Signed v= alue=E2=80=9D. >>>> You capitalize it elsewhere, and it helps the parsing if it=E2=80=99s = consistent. >>>> There are four uncapitalized instances in this section. >>>> >>>> =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in t= he description of >>>> the field, =E2=80=9Ctims signed=E2=80=9D has been replaced with =E2=80= =9Ctime the message was >>>> signed=E2=80=9D. >>>> >>>> Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80= =9CFudge field=E2=80=9D (although >>>> occurrences of =E2=80=9Cfudge value=E2=80=9D have not been capitalised= , as the context of >>>> that is that it is referring to the contents of the Fudge field). Also= , >>>> =E2=80=9Cother data=E2=80=9D and =E2=80=9Cother data length=E2=80=9D h= ave been replaced with the >>>> (capitalised) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9CO= ther Len=E2=80=9D. >>>> >>>> >>>> > =E2=80=94 Section 9 =E2=80=94 >>>> > >>>> > There is no structure >>>> > required other than names for different algorithms must be unique >>>> > when compared as DNS names, i.e., comparison is case insensitive. >>>> > >>>> > I found this sentence to be really awkward and hard to parse. May I >>>> suggest this?: >>>> > >>>> > NEW >>>> > There is no structure to the names, and algorithm names are compared >>>> as if they were DNS names (the comparison is case-insensitive). >>>> > END >>>> > >>>> > I don=E2=80=99t think you really need to say that each name is >>>> different/unique, right? >>>> >>>> Agreed. The text has been changed to that suggested. >>>> >>>> >>>> > other algorithm >>>> > names are simple (i.e., single-component) names. >>>> > >>>> > Nitty thing that you can completely ignore, but I would avoid the >>>> Latin abbreviation thus: =E2=80=9Cother algorithm names are simple, >>>> single-component names.=E2=80=9D >>>> >>>> Changed. >>>> >>>> >>>> >>>> Comments from =C3=89ric Vyncke >>>> >>>> > Thank you for the work put into this document. It is clear and easy >>>> to read. >>>> > >>>> > Please find below some non-blocking COMMENTs and NITs. An answer wil= l >>>> be appreciated. >>>> > >>>> > I hope that this helps to improve the document, >>>> > >>>> > Regards, >>>> > >>>> > -=C3=A9ric >>>> > >>>> > =3D=3D COMMENTS =3D=3D >>>> > >>>> > There are 6 authors while the usual procedure is to limit to 5 >>>> authors.. Personally, I do not care. >>>> > >>>> > -- Section 1.3 -- >>>> > It is a little unclear to me whether the "two nameservers" were two >>>> implementations or two actual DNS servers. >>>> >>>> Agreed, it was unclear. Changed to =E2=80=9Ctwo name server implement= ations=E2=80=9D. >>>> >>>> >>>> > -- Section 5.2 -- >>>> > Suggest to provide some justifications about "copied to a safe >>>> location": the DNS message was sent in the clear, why does the TSIG pa= rt be >>>> copied in a safe location? Please define what is meant by "safe locati= on" >>>> (Mainly for my own curiosity) >>>> >>>> It is a bit over-specified and has been changed. The text now reads: >>>> >>>> Upon receipt of >>>> a message with exactly one correctly placed TSIG RR, a copy of >>>> the >>>> TSIG RR is stored, and the TSIG RR is removed from the DNS >>>> Message, >>>> and decremented out of the DNS message header's ARCOUNT. >>>> >>>> >>>> > "cannot be understood" is also quite vague. >>>> >>>> Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. >>>> >>>> >>>> > -- Section 5.3 -- >>>> > About rejecting request with a time signed value being earlier than >>>> the last received value. I wonder what is the value of this behavior i= f >>>> there is no 'fudge' as well... The last paragraph of this section desc= ribes >>>> this case and push the error handling to the request initiator. Any re= ason >>>> why being flexible on the receiving site was not selected ? >>>> >>>> The fudge value is to cope with clock skew between the sender and >>>> receiver. This won't impact on the order in which the packets are rec= eived >>>> by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a firs= t-level check. (It is >>>> not fool-proof - a number of packets signed by the sender within a sec= ond >>>> of one another may have the same =E2=80=9CTime Signed=E2=80=9D field.) >>>> >>>> Pushing the error handling to the initiation goes back to the original >>>> RFC 2845. >>>> >>>> >>>> > =3D=3D NITS =3D=3D >>>> > >>>> > -- Section 4.3.2 -- >>>> > Is " A whole and complete DNS message in wire format." a complete an= d >>>> valid sentence? >>>> >>>> This was also pointed out by Roman Danyliw and has been addressed. >>>> >>>> >>>> Other changes made during editing >>>> >>>> * There was no description of the contents of the =E2=80=9CError=E2=80= =9D and =E2=80=9COther >>>> Data=E2=80=9D fields were in a request. This has now been corrected (= Error is set >>>> to 0. The contents of =E2=80=9COther Data=E2=80=9D are stated to be un= defined to allow for >>>> extensions such as draft-andrews-dnsop-defeat-frag-attack.) >>>> >>>> >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> --000000000000615d0f05a5647fdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim,

On Mon, May 11, 2020 at 1:51 PM Ti= m Wicinski <tjw.ietf@gmail.com= > wrote:
Donald

So y= ou're suggest=C2=A0hmac-sha224 is "MAY" for both Implementati= on and Use ?=C2=A0

Yes, that wo= uld be fine.

SHA-224 is just SHA-256 with some dif= ferent initial vectors and the result truncated to 224 bits. So if you have= implemented SHA-256, it takes like 0.1% more code to add SHA-224. And, whi= le the value of SHA-224 would be different for a particular input from the = value of SHA-256 truncated to 224 bits, I don't see any reason why it w= ould be less secure.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E= . Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle= , Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com

On Mon, May 1= 1, 2020 at 12:29 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
The incremental effort = to implement SHA-224 if you are implementing SHA-256 is miniscule. It makes= no sense to me for SHA-224 to be NOT RECOMMENDED to use when=C2=A0SHA-256 = is MUST implement=C2=A0and=C2=A0RECOMMENDED to use and you can use SHA-256 = with truncation to 224 or even fewer bits.
=C2=A0
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E= . Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle= , Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Sat, May 9, 2020 = at 9:52 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
To follow up on Stephen's comments, a table was added to 2845bis = to
list all the algorithms that a= re currently in the IANA registry,
along with=C2=A0suggestions=C2=A0for implementation.=C2=A0 This was the f= irst version:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Requirement Name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0----------- ------------------------<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Opt= ional =C2=A0 =C2=A0HMAC-MD5.SIG-ALG.REG.INT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0gss-tsig
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2= =A0 hmac-sha1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha224
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandatory =C2=A0 hmac-sha256=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Opti= onal =C2=A0 =C2=A0hmac-sha384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional =C2=A0 =C2=A0hmac-sha512

During the IESG review (I think it was the SECDIR review), there was
a meltdown over implementing SHA-1.= But SHA-1 is in use currently.=C2=A0
My suggestion was to do a variation describing implementation use.=C2= =A0
This is what I came up with(s= o blame me):=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Imple= mentation Use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------------------= - -------------- ---------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HMAC-MD5.SIG-ALG.= REG.INT MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 gss-tsig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECO= MMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha224 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0NOT RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha256-128 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha384-192 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hmac-sha512-256 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY

On the use side, these are mostly guesses.=C2=A0 =C2=A0We would love to h= ear
what the WG has to say about = this.

thanks
tim


On Mon, May 4, 2020 at 2:= 07 PM Stephen Morris <sa.morris8@gmail.com> wrote:

> On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain Name System Operations WG of t= he IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Secret Key Transaction Authentication for DNS (TSIG)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Francis Dupont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stephen Morris
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Paul Vixie
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Donald E. Eastlake 3rd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Olafur Gudmundsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Brian Wellington
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-rfc2845bis-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-05-04


The update addresses to the draft comments made during the IESG review.=C2= =A0 There were a fair number of these which led to a number of changes to t= he document.=C2=A0 These are listed below.

One significant change is that the list of acceptable algorithms has been e= xtended, and WG approval for this is sought.

Stephen




Comments from Roman Danyliw
---
> ** Section 1.3.=C2=A0 Per =E2=80=9CIn 2017, two nameservers=C2=A0 stri= ctly following that document (and the related [RFC4635]) were discovered to= have security problems related to this feature=E2=80=9D, consider providin= g a reference to the published vulnerabilities (i.e., CVE-2017-3142 and CVE= -2017-3143)

I=E2=80=99ve added these (and one other related CVE) as informative referen= ces.=C2=A0 Using just the CVE number as a reference seemed a bit spartan, s= o I=E2=80=99ve added a title to each incident. As the description of the CV= Es in Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descri= ption, which can be rather long), I=E2=80=99ve taken the title from ISC=E2= =80=99s KnowledgeBase (for the BIND CVEs) and from the Knot release notes (= for the Knot CVE).


> ** Section 6.=C2=A0 Per =E2=80=9CSHA-1 collisions have been demonstrat= ed so the MD5 security considerations apply to SHA-1 in a similar manner.= =C2=A0 Although support for hmac-sha1 in TSIG is still mandatory for compat= ibility reasons, existing uses should be replaced with hmac-sha256 or other= SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].
>
> -- It=E2=80=99s worth repeating those MD5 security considerations here=

I=E2=80=99m not really keen on doing this, since the security consideration= s in RFC 6151 cover two paragraphs and including them - or even a summary o= f them - would detract from the flow of the document.=C2=A0 However, I have= explicitly included a reference to RFC 6151 in the text.


> -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it=E2= =80=99s worth including references to the recent SHA-1 cryptoanalysis provi= ded in the SECDIR review

Added references to just one of these papers (=E2=80=9DSHA1 is a Shambles= =E2=80=9D).=C2=A0 We=E2=80=99re not doing a general analysis of the algorit= hms, so a simple reference to a paper than describes a SHA1 collision is al= l that is needed.=C2=A0 (As an aside, the paper doesn't give the date o= f publication, so I had to search the Web looking for references to it.=C2= =A0 I think I=E2=80=99ve got the date correct, but I=E2=80=99d be grateful = for a double-check.)


> -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED).

Done - see Table 2


> ** Section 10.=C2=A0 Per =E2=80=9CFor all of the message authenticatio= n code algorithms listed in this document, those producing longer values ar= e believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR rev= iew, this could be misconstrued as the algorithm choice not the digest leng= th provides the security.=C2=A0 Recommend rephrasing (or making some statem= ent=C2=A0

I=E2=80=99ve reworded this paragraph (in section 10).=C2=A0 It now reads:
=C2=A0 "Although the strength of an algorithm determines its security,= there
=C2=A0 have been some arguments that mild truncation can strengthen a MAC b= y
=C2=A0 reducing the information available to an attacker.=C2=A0 However, ex= cessive
=C2=A0 truncation clearly weakens authentication by reducing the number of<= br> =C2=A0 bits an attacker has to try to break the authentication by brute
=C2=A0 force [RFC2104]."


> ** Editorial
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CWhen verifying an incoming messag= e, this is the message after the TSIG RR and been removed and the ARCOUNT f= ield has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (i= s missing a word).
>
> -- Section 4.3.2.=C2=A0 Per =E2=80=9CA whole and complete DNS message = in wire format.=E2=80=9D, this isn=E2=80=99t a sentence.

Section 4.3.2 has been reworded to address these issues.



Comments from Benjamin Kaduk

> Thanks for putting together this update; it's good to see the secu= rity
> issue getting closed off in the udpated spec, and progression to full<= br> > Internet Standard!=C2=A0 I do have several substantive comments (as we= ll as
> some minor/nit-level ones), many of which are listed here at the top b= ut
> a few of which are interspersed in the per-section comments.
>
>
> I considered making this a Discuss point, but it should be pretty
> uncontroversial and I trust that the right thing will happen even if I=
> don't: there's a couple lingering remnants of SHA-1 being the<= br> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 an= d
> 10 (further detailed in the per-section comments).

The document now mentions SHA1 collisions and notes that the MD5 security c= onsiderations apply to SHA1.=C2=A0 It also mentions that support for SHA1 i= s mandatory for compatibility reasons but in existing uses it should be rep= laced by a stronger one.


> I also initially had made the following point a Discuss-level point, b= ut
> decided to not do so since I don't remember any BCP-level guidance=
> relating to cross-protocol attacks.=C2=A0 Nevertheless, I strongly enc= ourage
> the authors to consider that cryptographic best practice is to use any=
> given key with exactly one cryptographic algorithm.=C2=A0 The record f= ormat
> listed in Section 4.2 has the key name and algorithm as separately
> conveyed, which would allow for a given key to be used with all
> implemented algorithms.=C2=A0 We should include some discussion that i= t's
> best to only use a single algorithm with any given key.

The following text has been added to the Security Considerations section:
=C2=A0 "To prevent cross-algorithm attacks, there SHOULD only be one =C2=A0 =C2=A0 algorithm associated with any given key name."


> We also have a 16-bit wide field for "Fudge", which (since i= t counts
> seconds) corresponds to a maximum window of something like +/- 18 hour= s;
> it's hard to believe that we really want to give people the rope t= o
> allow for that much time skew.=C2=A0 (Yes, I understand that implement= ations
> will set something sane in practice but that doesn't necessarily m= ean
> that the protocol still has to allow it.)

That was set in the original RFC 2845.=C2=A0 Although I agree with the comm= ents, changing the size of that field would be a significant undertaking.= =C2=A0 However, section 10 does state that the RECOMMENDED fudge value in m= ost circumstances is 300 seconds.


> Our authoritative list of algorithm names (Table 1) is rather divorced=
> from the references to be consulted for the individual hash algorithms=
> to be used with the HMAC procedure.=C2=A0 The ones used here are suffi= ciently
> well-known that I'm not terribly concerned about it, though.

The first paragraph of the IANA considerations section lists the algorithms= and references to where they are described, and I didn=E2=80=99t want to d= uplicate the information.


> Abstract
>
> The title says "DNS" but maybe the body of the abstract shou= ld as well?

In the abstract, changed:

"It can be used to authenticate dynamic updates as coming from an appr= oved client"

to

"It can be used to authenticate dynamic updates to a DNS zone as comin= g from an approved client"


> Section 1.1
>
> Some of this language feels like it might not age terribly well, e.g.,=
> "this can provide" or "[t]here was a need".
>
>=C2=A0 =C2=A0addresses that need.=C2=A0 The proposal is unsuitable for = general server
>=C2=A0 =C2=A0to server authentication for servers which speak with many= other
>=C2=A0 =C2=A0servers, since key management would become unwieldy with t= he number
>=C2=A0 =C2=A0of shared keys going up quadratically.=C2=A0 But it is sui= table for many
>=C2=A0 =C2=A0resolvers on hosts that only talk to a few recursive serve= rs.

Changed to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The authentication mechanism proposed her= e provides a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple and efficient authentication between cli= ents and local servers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by using shared secret keys to establish a trus= t relationship between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 two entities.=C2=A0 Such keys must be protected= in a manner similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private keys, lest a third party masquerade as = one of the intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parties (by forging the MAC).=C2=A0 The proposa= l is unsuitable for general
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server to server authentication for servers whi= ch speak with many
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other servers, since key management would becom= e unwieldy with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number of shared keys going up quadratically. B= ut it is suitable for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 many resolvers on hosts that only talk to a few= recursive servers.=E2=80=9D


> Should zone transfers be mentioned here as well?

Zone transfers are mentioned in the preceding paragraph.


> Section 1.2
>
> I don't understand the motivation for changing terminology from MA= Cs to
> "signatures"; they're still MACs even though they're= transaction-based.

The mention of signatures in section 1.2 is intended as a link between the = name of the RR (TSIG or Transaction Signature) and the term MAC used in the= rest of the document.


>=C2=A0 =C2=A0MAC of the query as part of the calculation.=C2=A0 Where a= response
>=C2=A0 =C2=A0comprises multiple packets, the calculation of the MAC ass= ociated
>=C2=A0 =C2=A0with the second and subsequent packets includes in its inp= uts the MAC
>=C2=A0 =C2=A0for the preceding packet.=C2=A0 In this way it is possible= to detect any
>=C2=A0 =C2=A0interruption in the packet sequence.
>
> I suggest mentioning the lack of mechanism to detect truncation of the=
> packet sequence.

That is a fair point.=C2=A0 I=E2=80=99ve modified the last sentence to read= :

=C2=A0 =C2=A0"In this way it is possible to detect any interruption in= the packet sequence,
=C2=A0 =C2=A0although not its premature termination."


> Section 4.2
>
>=C2=A0 =C2=A0NAME=C2=A0 The name of the key used, in domain name syntax= ..=C2=A0 The name
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should reflect the names of the hosts= and uniquely identify the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key among a set of keys these two hos= ts may share at any given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time.=C2=A0 For example, if hosts A.s= ite.example and
> = B.example.net
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0share a key, possibilities for the ke= y name include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example, <id>= ..B.e= xample.net, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<id>.A.site.example.B= ..example.net.=C2=A0 It should be possible for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more than one key to be in simultaneo= us use among a set of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interacting hosts.
>
> I'd suggest adding a note along the lines of "This allows for= periodic
> key rotation per best operational practices, as well as algorithm
> agility as indicated by [BCP201].=E2=80=9D

Added.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The name may be used as a local index= to the key involved and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it is recommended that it be globally= unique.=C2=A0 Where a key is
>
> (nit?): this feels more like a "but" than an "and"= , to me.

Well spotted.=C2=A0 I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 MAC Size - an unsigned 16-bit= integer giving the length of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC field in octets.=C2=A0 Tr= uncation is indicated by a MAC size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 less than the size of the key= ed hash produced by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithm specified by the Al= gorithm Name.
>
> nit: I would suggest "output size", as there are potentially= a few
> different sizes involved (key size, block size, and output size, for > starters, though I think the possibility of confusion here is low).
I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous reference to = this field, and the other size mentioned - that of the keyed hash is, I thi= nk, also unambiguous.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 empty unless the content of t= he Error field is BADTIME, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which case it will contain th= e server's current time as the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of seconds since 00:00= on 1970-01-01 UTC, ignoring
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leap seconds (see Section 5.2= ..3).
>
> I'm slightly confused at the interplay between the explicit length= field
> and the "empty unless" directive.=C2=A0 Does this mean that = the only allowed
> values in the "Other Len" are 0 and 6?=C2=A0 Does "empt= y" mean "length-zero=E2=80=9D?

I=E2=80=99ve rewritten this slightly in a bid to make it clearer that =E2= =80=9COther Data=E2=80=9D being empty means that =E2=80=9COther Len=E2=80= =9D is zero.


> Section 4.3.1
>
>=C2=A0 =C2=A0Only included in the computation of a MAC for a response m= essage (or
>=C2=A0 =C2=A0the first message in a multi-message response), the valida= ted request
>=C2=A0 =C2=A0MAC MUST be included in the MAC computation.=C2=A0 If the = request MAC
>=C2=A0 =C2=A0failed to validate, an unsigned error message MUST be retu= rned
>=C2=A0 =C2=A0instead.=C2=A0 (Section 5.3.2).
>
> side note: while Section 5.3.2 specifies how to create an unsigned err= or
> message, it looks like Section 5.2 (and subsections lists specific
> RCODEs that are to be used.

That is the case.=C2=A0 Section 4 is a description of the TSIG RR and its f= ields.=C2=A0 Section 5 describes the contents of the fields in various situ= ations (client transmission, server reception, server transmission, client = reception).


> Section 4.3.2
>
>=C2=A0 =C2=A0When verifying an incoming message, this is the message af= ter the
>=C2=A0 =C2=A0TSIG RR and been removed and the ARCOUNT field has been de= cremented.
>=C2=A0 =C2=A0If the message ID differs from the original message ID, th= e original
>=C2=A0 =C2=A0message ID is substituted for the message ID.=C2=A0 (This = could happen,
>=C2=A0 =C2=A0for example, when forwarding a dynamic update request.) >
> I trust (based on this text having survived while going for full IS) > that there are no interesting record-keeping considerations with respe= ct
> to knowing the message ID(s) to substitute, in the "forwarding a<= br> > dynamic-update request" case, presumably since this is just the f= ield
> from the TSIG RDATA and not some externally retained state.

That is correct - the original ID is stored in the TSIG record=E2=80=99s RD= ATA and it is from there that the original ID is retrieved when a substitut= ion is made.


> Section 4.3.3
>
>=C2=A0 =C2=A0The RR RDLEN and RDATA MAC Length are not included in the = input to
>=C2=A0 =C2=A0MAC computation since they are not guaranteed to be knowab= le before
>=C2=A0 =C2=A0the MAC is generated.
>
> I appreciate that this is explicitly noted; there are some security > considerations regarding the non-inclusion of the (truncated) mac leng= th
> as input, though.=C2=A0 The local truncation policy helps here, but no= t 100%.

OK


>=C2=A0 =C2=A0For each label type, there must be a defined "Canonic= al wire format"
>
> Just to check my understanding: label types only come into play for th= e
> two fields that are in domain name syntax, key name and algorithm name= ?

There was actually an error in the text here: RFC 4034 section 6.1 is conce= rned with Canonical Name Order.=C2=A0 It is section 6.2 that details the ca= nonical wire format - I=E2=80=99ve changed the reference.

Going back to the original point, yes, that is correct.=C2=A0 Label type 00= is uncompressed name. (11 is a compressed name, and label types 01 and 10 = are discouraged - see RFC 6891 section 5).


> Section 5.1
>
>=C2=A0 =C2=A0the server.=C2=A0 This TSIG record MUST be the only TSIG R= R in the message
>=C2=A0 =C2=A0and MUST be last record in the Additional Data section.=C2= =A0 The client
>
> (Is there anything else that tries to insist on being the last record = in
> the additional data section?=C2=A0 I guess it doesn't really make = sense to
> try to Update: 1035 just to note this requirement.)

Not to our knowledge.


>=C2=A0 =C2=A0MUST store the MAC and the key name from the request while= awaiting
>=C2=A0 =C2=A0an answer.
>
> [This is going to end up alongside the request-ID that it has to store=
> already, right?]

Yes.=C2=A0 The request MAC is included as one of the components used by the= server to generate the response - which should be encoded using the same k= ey as used in the request.


>=C2=A0 =C2=A0Note that some older name servers will not accept requests= with a
>=C2=A0 =C2=A0nonempty additional data section.=C2=A0 Clients SHOULD onl= y attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> (The context in which this "SHOULD" appears makes it feel li= ke it's
> repeating an admontion from elsewhere and not the only instance of the=
> requirement, in which case a reference might be appropriate.)

I=E2=80=99ve removed this paragraph.=C2=A0 The reference to older name serv= ers is now completely out of date (it was a carry-over from the original 20= -year old text).=C2=A0 The rest of the paragraph seems superfluous - rather= like stating that TCP clients should only connect to servers that support = TCP.=C2=A0


> Section 5.2
>
>=C2=A0 =C2=A0If the TSIG RR cannot be understood, the server MUST regar= d the
>=C2=A0 =C2=A0message as corrupt and return a FORMERR to the server.=C2= =A0 Otherwise the
>=C2=A0 =C2=A0server is REQUIRED to return a TSIG RR in the response. >
> As written, this could be read as an attempt to make a normative
> requirement of servers that do not implement this spec.=C2=A0 Presumab= ly it's
> just restating a requirement of the core protocol, though?

It is the core protocol.

I see your point though.=C2=A0 However, by implication we are talking about= a server that implements TSIG.


> Section 5.2.2
>
>=C2=A0 =C2=A0Using the information in the TSIG, the server should verif= y the MAC
>=C2=A0 =C2=A0by doing its own calculation and comparing the result with= the MAC
>=C2=A0 =C2=A0received.=C2=A0 If the MAC fails to verify, the server MUS= T generate an
>
> Is there any other way to verify the MAC?=C2=A0 (Should this be a &quo= t;MUST
> verify=E2=80=9D?)

Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed.


> Section 5.2.2.1
>
>=C2=A0 =C2=A0When space is at a premium and the strength of the full le= ngth of a
>=C2=A0 =C2=A0MAC is not needed, it is reasonable to truncate the keyed = hash and
>=C2=A0 =C2=A0use the truncated value for authentication.=C2=A0 HMAC SHA= -1 truncated to
>=C2=A0 =C2=A096 bits is an option available in several IETF protocols, = including
>=C2=A0 =C2=A0IPsec and TLS.
>
> Also Kerberos, where it was the strongest option for a while and we ha= d
> to define a new encryption type to provide a better option (RFC 8009).=
>
> This text seems to be implying that HMAC SHA-1 truncated to 96 bits is= a
> recommendable option, which is ... far from clear.=C2=A0 I'd prefe= r to have a
> note that this specific truncation was appropriate when initially
> specified but may not provide a security level appropriate for all cas= es
> in the modern environment, or preferrably to just change the reference=
> to (e.g.) SHA-384-192 or SHA-256-128.

Added the following an the end of the paragraph:

=C2=A0 However, while this option is kept for backwards compatibility,
=C2=A0 it may not provide a security level appropriate for all cases
=C2=A0 in the modern environment. In these cases, it is preferable to
=C2=A0 use a hashing algorithm such as SHA-256-128, SHA-384-192
=C2=A0 or SHA-256-128 [RFC4868].

I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80=9D, = =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80=9D as = optional algorithms to the algorithm table.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is sent when the signer has truncated t= he keyed hash output
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to an allowable length, as described in [RFC= 2104], taking initial
>=C2=A0 =C2=A0 =C2=A0 =C2=A0octets and discarding trailing octets.=C2=A0= TSIG truncation can only
>
> (Or when an on-path attacker has performed truncation.)

True, but an on-path attacker can manipulate the message in any way possibl= e.=C2=A0 I=E2=80=99m not sure whether adding this caveat will add anything = to the document.


> Section 5.2.3
>
>=C2=A0 =C2=A0(BADTIME).=C2=A0 The server SHOULD also cache the most rec= ent time signed
>=C2=A0 =C2=A0value in a message generated by a key, and SHOULD return B= ADTIME if a
>=C2=A0 =C2=A0message received later has an earlier time signed value.= =C2=A0 A response
>
> (But there's no fudge factor on this check, other than the inheren= t
> limit of seconds granularity, as alluded to by the last paragraph of > this section?)

The last paragraph in the section states that handling this issue should be= left up to implementations and that the exact method (and by implication, = the size of the fudge factor) be determined by the implementation themselve= s.=C2=A0


> Section 5.3.1
>
>=C2=A0 =C2=A0A zone transfer over a DNS TCP session can include multipl= e DNS
>=C2=A0 =C2=A0messages.=C2=A0 Using TSIG on such a connection can protec= t the connection
>=C2=A0 =C2=A0from hijacking and provide data integrity.=C2=A0 The TSIG = MUST be included
>
> (I assume that "hijacking TCP" means a sequence-number-guess= ing attack
> that would require the attacker to be winning the race against the
> legitimate sender to cause modified data to be introduced into the TCP=
> stream?=C2=A0 This is maybe not the best word to use for such a case.)=

I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2=80=9D.<= br>

>=C2=A0 =C2=A0on all DNS messages in the response.=C2=A0 For backward co= mpatibility, a
>=C2=A0 =C2=A0client which receives DNS messages and verifies TSIG MUST = accept up
>=C2=A0 =C2=A0to 99 intermediary messages without a TSIG.=C2=A0 The firs= t message is
>
> (side note: I'm kind of curious what such compatibility is needed = with.
> Also, this gives an attacker some flexibility into which to incorporat= e
> a collision, though given the near-real-time constraints and the
> strength of the HMAC construction I don't expect any practical imp= act.)

The original RFC 2845 did not require all packets in a message stream to co= ntain a TSIG, it just stated that there be no more than 99 intermediary mes= sages without a TSIG (presumably to cut down on the overhead required in me= ssage calculations - remember that RFC 2845 was published 20 years ago).=C2= =A0 Although many DNS implementations now add a TSIG to every message, it i= s by no means certain that all do. (In fact, less than three years ago, a b= ug was introduced into BIND, causing it to require that all packets in a zo= ne transfer would contain a TSIG.=C2=A0 A fix allowing BIND to accept up to= 99 packets between signed ones was released shortly afterwards after repor= ts were received of zone transfers failing.)


> Section 5.3.2
>
>=C2=A0 =C2=A0 =C2=A0 Request MAC (if the request MAC validated)
>=C2=A0 =C2=A0 =C2=A0 DNS Message (response)
>=C2=A0 =C2=A0 =C2=A0 TSIG Variables (response)
>
>=C2=A0 =C2=A0The reason that the request is not included in this MAC in= some cases
>=C2=A0 =C2=A0is to make it possible for the client to verify the error.= =C2=A0 If the
>=C2=A0 =C2=A0error is not a TSIG error the response MUST be generated a= s specified
>=C2=A0 =C2=A0in Section 5.3.
>
> This makes it sound like the server excludes the request MAC from the<= br> > digest if it failed to validate (something the client cannot predict),=
> so that the client must perform trial verification of both versions in=
> order to validate the response.=C2=A0 Is that correct?

No.=C2=A0 If the incoming MAC failed to validate, the server should send ba= ck an unsigned response (MAC size =3D=3D 0 and empty MAC).


> Also, I think that the "in some cases" is not properly place= d: as-is, it
> says that the request (not request MAC) is sometimes not included
> (implying that sometimes it is), which does not match up with the
> specification for the digest components.=C2=A0 I presume that the inte= nt is
> to say that in some cases the client could not verify the error, if th= e
> request itself was always included in the digest.

Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D.

If the MAC could not be verified, it is possible that it was corrupted, whi= ch would prevent the client verifying the response. But a major reason is t= hat an incorrect MAC included in a signed response led to the CVEs that pro= mpted this document update.


> Section 5.4.1
>
>=C2=A0 =C2=A0If an RCODE on a response is 9 (NOTAUTH), but the response= TSIG
>=C2=A0 =C2=A0validates and the TSIG key recognised by the client but di= fferent
>=C2=A0 =C2=A0from that used on the request, then this is a Key Error.= =C2=A0 The client
>
> nits: missing words "key is recognized" and "but is dif= ferent=E2=80=9D

It now reads =E2=80=9Ckey is recognized but different"


> Section 5.5
>
>=C2=A0 =C2=A0destination or the next forwarder.=C2=A0 If no transaction= security is
>=C2=A0 =C2=A0available to the destination and the message is a query th= en, if the
>=C2=A0 =C2=A0corresponding response has the AD flag (see [RFC4035]) set= , the
>=C2=A0 =C2=A0forwarder MUST clear the AD flag before adding the TSIG to= the
>=C2=A0 =C2=A0response and returning the result to the system from which= it
>=C2=A0 =C2=A0received the query.
>
> Is there anything to say about the CD bit?=C2=A0 (It's independent= crypto, so
> I don't expect so, but it seems worth checking.)

No.=C2=A0 CD is just a mechanism by which a client can request that the ser= ver not do DNSSEC signature validation on the data and so allow the client = to receive the data instead of a SERVFAIL response.


> Section 6
>
>=C2=A0 =C2=A0The only message digest algorithm specified in the first v= ersion of
>=C2=A0 =C2=A0these specifications [RFC2845] was "HMAC-MD5" (s= ee [RFC1321],
>=C2=A0 =C2=A0[RFC2104]).=C2=A0 Although a review of its security [RFC61= 51] concluded
>=C2=A0 =C2=A0that "it may not be urgent to remove HMAC-MD5 from th= e existing
>=C2=A0 =C2=A0protocols", with the availability of more secure alte= rnatives the
>=C2=A0 =C2=A0opportunity has been taken to make the implementation of t= his
>=C2=A0 =C2=A0algorithm optional.
>
> It seems worth noting that the advice from RFC 6151 is already nine > years old.

I=E2=80=99ve use the phrasing "Although a review of its security some = years ago=E2=80=9D.


>=C2=A0 =C2=A0[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS1= 80-4],
>=C2=A0 =C2=A0[RFC3174].=C2=A0 SHA-1 collisions have been demonstrated s= o the MD5
>=C2=A0 =C2=A0security considerations apply to SHA-1 in a similar manner= ..=C2=A0 Although
>
> I'd consider referencing (e.g.)
> s= hattered.io
> for the "collisions have
> been demonstrated" claim, though it's pretty optional.

A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D paper= ..


>=C2=A0 =C2=A0support for hmac-sha1 in TSIG is still mandatory for compa= tibility
>=C2=A0 =C2=A0reasons, existing uses should be replaced with hmac-sha256= or other
>=C2=A0 =C2=A0SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234].=
>
> Is this "sha1 mandatory for compatibility" going to age well= ?=C2=A0 If we
> have two implementations that can operate with sha2 variants, is it > required to keep this as mandatory (vs. optional with a note about
> deployed reality at time of publication) for progression to Internet > Standard?

This has been addressed by splitting the =E2=80=9CMandatory/Optional=E2=80= =9D column in RFC4635 (from which Table 2 was derived) into =E2=80=9CImplem= entation=E2=80=9D and =E2=80=9CUse=E2=80=9D.=C2=A0 SHA1 is required to be i= mplemented (for backwards compatibility) but its use is not recommended.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Op= tional=C2=A0 =C2=A0 hmac-sha224
>
> It's not clear there's much reason to keep this around, or if = we do, it
> could probably be "not recommended".=C2=A0 (I assume that ju= st dropping it
> entirely makes things annoying w.r.t. the IANA registry.)

It has been left in for compatibility reasons, but its use is not recommend= ed.


> Section 9
>
>=C2=A0 =C2=A0Previous specifications [RFC2845] and [RFC4635] defined va= lues for
>=C2=A0 =C2=A0HMAC MD5 and SHA.=C2=A0 IANA has also registered "gss= -tsig" as an
>
> I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied gr= ouping where
> HMAC qualifies both hash algorithms is not terribly clear.

Changed to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Previous specifications [RFC2845] and [RFC4635]= defined names for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the HMAC-MD5 and the various HMAC-SHA algorithm= s.


> Section 10
>
> I suggest some discussion that the way truncation policy works, an
> attackers ability to forge messages accepted as valid is limited by th= e
> amount of truncation that the recipient is willing to accept, not the<= br> > amount of truncation used to generate messages by the legitimate sende= r.

I think this is already taken care of by the reference to a local policy in= the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5.2.4).=


> There's also some fairly standard content to put in here about all= owing
> for an unsigned error response to a signed request, so an attacker (ev= en
> off-path) can spoof such resposnes.=C2=A0 (Section 5.4 indicates that = the
> client should continue to wait if it gets such a thing, which helps a<= br> > lot.)

I=E2=80=99ve just added text that an unsigned response is not considered ac= ceptable because can be subject to spoofing and manipulation.


>=C2=A0 =C2=A0TKEY [RFC2930].=C2=A0 Secrets SHOULD NOT be shared by more= than two
>=C2=A0 =C2=A0entities.
>
> I suggest adding "; any such additional sharing would allow any p= arty
> knowing the key to impersonate any other such party to members of the<= br> > group=E2=80=9D.

Added.


>=C2=A0 =C2=A0A fudge value that is too large may leave the server open = to replay
>=C2=A0 =C2=A0attacks.=C2=A0 A fudge value that is too small may cause f= ailures if
>=C2=A0 =C2=A0machines are not time synchronized or there are unexpected= network
>=C2=A0 =C2=A0delays.=C2=A0 The RECOMMENDED value in most situations is = 300 seconds.
>
> Our experience with kerberos in modern network environments has shown<= br> > that 5 minutes is much larger than needed, though it's not clear t= here's
> a strong need to change this recommendation right now.

The value is recommended (and even then, only in =E2=80=9Cmost situations= =E2=80=9D), so implementations are free to set their own value.=C2=A0 Howev= er, any guidance as to typical time skews measured across a network would b= e useful in a number of protocols.


>=C2=A0 =C2=A0Significant progress has been made recently in cryptanalys= is of hash
>=C2=A0 =C2=A0functions of the types used here.=C2=A0 While the results = so far should
>=C2=A0 =C2=A0not affect HMAC, the stronger SHA-1 and SHA-256 algorithms= are being
>=C2=A0 =C2=A0made mandatory as a precaution.
>
> Please revise this note to not imply that SHA-1 is considered "st= rong=E2=80=9D.

Text revised to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Significant progress has been made recently in = cryptanalysis of hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 functions of the types used here.=C2=A0 While t= he results so far should not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 affect HMAC, the stronger SHA-256 algorithm is = being made mandatory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a precaution.


> Section 11.2
>
> I'm not sure why RFC 2104 is listed as informative.

RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of a pos= sible downref if the reference is placed in the =E2=80=9CNormative=E2=80=9D= section.



Comments from Mirja K=C3=BChlewind

> I only had limited time for a quick review of this document, so I migh= t not be aware of all the needed background and details. Still I have two q= uick questions on retries:
>
> 1) Sec 5.2.3:
> "Implementations should be aware
>=C2=A0 =C2=A0of this possibility and be prepared to deal with it, e.g. = by
>=C2=A0 =C2=A0retransmitting the rejected request with a new TSIG once o= utstanding
>=C2=A0 =C2=A0requests have completed or the time given by their time si= gned plus
>=C2=A0 =C2=A0fudge value has passed."
> I might not be aware of all protocol details and maybe this is already= specified somewhere: While unlikely, it is possible that a request might b= e retransmitted multiple times, as that could cause president congestion ov= er time, it's always good practice to define a maximum number of retran= smissions. If that is already defined somewhere, maybe adding a note/pointe= r would be good as well.

If someone can suggest a suitable number (and a reason for it), we can cons= ider doing this.=C2=A0 In the meantime, I=E2=80=99ve merely stated that imp= lementation should limit the number of retransmissions and so leave the cho= ice up to the implementation.


> 2) Sec 5.3.1:
> "=C2=A0 =C2=A0This allows the client to rapidly detect when the s= ession has been
>=C2=A0 =C2=A0altered; at which point it can close the connection and re= try."
> When (immediately or after some waiting time) should the client retry = and how often?

I think that should be down to the implementation to decide.


> You further say
> "The client SHOULD treat this the
>=C2=A0 =C2=A0same way as they would any other interrupted transfer (alt= hough the
>=C2=A0 =C2=A0exact behavior is not specified here)."
> Where is that specified? Can you provide a pointer in the text?

That was a mistake in transcribing the original RFC2845 text.=C2=A0 The fin= al word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client SHOULD treat this the same way as th= ey would any other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interrupted transfer (although the exact behavi= or is not specified).


> 3) Sec 8.=C2=A0 Shared Secrets: Would it be appropriate to use more no= rmative language here? There are a bunch of lower case shoulds in this sect= ion; is that on purpose?

The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear is ver= y general security advice.=C2=A0 Although this is something users ought to = do, it is not really a specific recommendation.



Comments from Barry Leiba

> =E2=80=94 Section 4.2 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Len - an unsigned 16-bi= t integer specifying the length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the "Other Data"= field in octets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Other Data - this unsigned 48= -bit integer field will be
>
> Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits?=C2= =A0 If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is = always 6?=C2=A0 If so, then shouldn=E2=80=99t it say that?=C2=A0 If not, th= en what don=E2=80=99t I understand?

Benjamin Kaduk also made the same comment, it has been addressed above.


> =E2=80=94 Section 5.1 =E2=80=94
>
>=C2=A0 =C2=A0Clients SHOULD only attempt signed
>=C2=A0 =C2=A0transactions with servers who are known to support TSIG an= d share
>=C2=A0 =C2=A0some algorithm and secret key with the client -- so, this = is not a
>=C2=A0 =C2=A0problem in practice.
>
> Why SHOULD and not MUST?

Benjamin Kaduk also noted an issue here.=C2=A0 The paragraph has been remov= ed.


> =E2=80=94 Section 5.3.2 =E2=80=94
>
>=C2=A0 =C2=A0The server SHOULD also cache the most recent time signed >=C2=A0 =C2=A0value in a message generated by a key
>
> I tripped over this until I realized you mean =E2=80=9CTime Signed val= ue=E2=80=9D.=C2=A0 You capitalize it elsewhere, and it helps the parsing if= it=E2=80=99s consistent. There are four uncapitalized instances in this se= ction.

=E2=80=9Ctime signed=E2=80=9D has been capitalised.=C2=A0 In addition, in t= he description of the field, =E2=80=9Ctims signed=E2=80=9D has been replace= d with =E2=80=9Ctime the message was signed=E2=80=9D.

Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2=80=9CFu= dge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2=80=9D h= ave not been capitalised, as the context of that is that it is referring to= the contents of the Fudge field). Also, =E2=80=9Cother data=E2=80=9D and = =E2=80=9Cother data length=E2=80=9D have been replaced with the (capitalise= d) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COther Len=E2=80= =9D.


> =E2=80=94 Section 9 =E2=80=94
>
>=C2=A0 =C2=A0There is no structure
>=C2=A0 =C2=A0required other than names for different algorithms must be= unique
>=C2=A0 =C2=A0when compared as DNS names, i.e., comparison is case insen= sitive.
>
> I found this sentence to be really awkward and hard to parse.=C2=A0 Ma= y I suggest this?:
>
> NEW
> There is no structure to the names, and algorithm names are compared a= s if they were DNS names (the comparison is case-insensitive).
> END
>
> I don=E2=80=99t think you really need to say that each name is differe= nt/unique, right?

Agreed.=C2=A0 The text has been changed to that suggested.


>=C2=A0 =C2=A0other algorithm
>=C2=A0 =C2=A0names are simple (i.e., single-component) names.
>
> Nitty thing that you can completely ignore, but I would avoid the Lati= n abbreviation thus: =E2=80=9Cother algorithm names are simple, single-comp= onent names.=E2=80=9D

Changed.



Comments from =C3=89ric Vyncke

> Thank you for the work put into this document. It is clear and easy to= read.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will = be appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -=C3=A9ric
>
> =3D=3D COMMENTS =3D=3D
>
> There are 6 authors while the usual procedure is to limit to 5 authors= .. Personally, I do not care.
>
> -- Section 1.3 --
> It is a little unclear to me whether the "two nameservers" w= ere two implementations or two actual DNS servers.

Agreed, it was unclear.=C2=A0 Changed to =E2=80=9Ctwo name server implement= ations=E2=80=9D.


> -- Section 5.2 --
> Suggest to provide some justifications about "copied to a safe lo= cation": the DNS message was sent in the clear, why does the TSIG part= be copied in a safe location? Please define what is meant by "safe lo= cation" (Mainly for my own curiosity)

It is a bit over-specified and has been changed.=C2=A0 The text now reads:<= br>
=C2=A0 =C2=A0 =C2=A0 Upon receipt of
=C2=A0 =C2=A0 =C2=A0 =C2=A0a message with exactly one correctly placed TSIG= RR, a copy of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TSIG RR is stored, and the TSIG RR is removed fr= om the DNS Message,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and decremented out of the DNS message header= 9;s ARCOUNT.


> "cannot be understood" is also quite vague.

Changed to =E2=80=9Ccannot be interpreted=E2=80=9D.


> -- Section 5.3 --
> About rejecting request with a time signed value being earlier than th= e last received value. I wonder what is the value of this behavior if there= is no 'fudge' as well... The last paragraph of this section descri= bes this case and push the error handling to the request initiator. Any rea= son why being flexible on the receiving site was not selected ?

The fudge value is to cope with clock skew between the sender and receiver.= =C2=A0 This won't impact on the order in which the packets are received= by the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-le= vel check. (It is not fool-proof - a number of packets signed by the sender= within a second of one another may have the same =E2=80=9CTime Signed=E2= =80=9D field.)

Pushing the error handling to the initiation goes back to the original RFC = 2845.


> =3D=3D NITS =3D=3D
>
> -- Section 4.3.2 --
> Is " A whole and complete DNS message in wire format." a com= plete and valid sentence?

This was also pointed out by Roman Danyliw and has been addressed.


Other changes made during editing

* There was no description of the contents of the =E2=80=9CError=E2=80=9D a= nd =E2=80=9COther Data=E2=80=9D fields were in a request.=C2=A0 This has no= w been corrected (Error is set to 0. The contents of =E2=80=9COther Data=E2= =80=9D are stated to be undefined to allow for extensions such as draft-and= rews-dnsop-defeat-frag-attack.)



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000615d0f05a5647fdc-- From nobody Mon May 11 15:49:57 2020 Return-Path: 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 7E3F23A0D82 for ; Mon, 11 May 2020 15:49:54 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.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 nz9ALnRQcW_p for ; Mon, 11 May 2020 15:49:52 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 ADD093A0BBC for ; Mon, 11 May 2020 15:49:00 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id x2so10382516ilp.13 for ; Mon, 11 May 2020 15:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ft65Z9gUOMYh19dgp2AeHBmpwq+g0qScISOVpsePg+w=; b=Uolrizi7S7LHQvgMcpJFcjjjlV36aGJxRO6CH777S2ozk64uT/a2tr8htnunIvm/QG QX+OuVgMUx3OTLmAw4kPObuzD7we3cSamZhqNs0dKxY0rvvD3t/pTge7QxTeMxZtUkfR /jXvIyYHQ2KSViy1g6qOEB5+EULTTsXwVafUwtVY3/VfVTsfzMNIO3jm2NlgwEU3jW+g 8Fp7PWJ45r7VPw6djeYeDKbTLB3TJ6EzqBJ6aCJl0MP1u764f+y02r30UsdBoX8/y8aC qn+1WRCljv2TgiAP5PIuaDAhlGNDnC7l9jR8txb9RgkSpsd4eoBVXQS5xGA0/R0Z6tgX MeLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ft65Z9gUOMYh19dgp2AeHBmpwq+g0qScISOVpsePg+w=; b=Fqxj9BLAS97jafBL3ZMoT4xM1SEVWrw3h4WI8DHTNMdVhQHoo4WHU1ABxwQj4kQsXB AXJkGe9C1bZE6e2forfReH4gtt8IrtJkQar4NLRi87sNSFVJiNCYCr4oQjUmm8ScGt7j 3vJJUqLmTZxQ5zwSnndqsaOnHQ82K6YUTqm6zAdxJs62fDDzR2x50fepMaenFot1SUFq lMzCLp/zAyOAIL+4286iFh3dupqJbN2KHXLwidEvfK4knq22OOVFGLSX0j8dSrZIkgn0 9311jcWDEzEDKXtu+GHG3BnlM78RMEZ2s/+zOzFAgJGxZ+dwhY+AqTYTgnH0g7ako2bz uG0w== X-Gm-Message-State: AGi0Puayk62pMS5GGA31hCPkGlvt+RxOFQrG9ybX2uz5spxIxDFrjDCB 76GMqWBgkCLWcr2XTvu+wWQF0f5d34z6goLG9EAzFg== X-Google-Smtp-Source: APiQypKAoDX91ss35sJ05dxAJ5VTVtSnrTDL2OdBVZJrF80TqcvSP1Fz+h9Z7oi2n+5rrHSf9faIN2qFnFExfR/tFqk= X-Received: by 2002:a92:607:: with SMTP id x7mr16863176ilg.218.1589237339720; Mon, 11 May 2020 15:48:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Tue, 12 May 2020 08:48:48 +1000 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 22:49:54 -0000 I support adoption. I wondered a little about "it is absolutely essential for these transfers to be protected from unexpected modifications on the route. So, catalog zone transfers SHOULD be authenticated using TSIG [RFC2845]." The use of a categorical *absolutely* and SHOULD is jarring. If this is really categorical, the normative enforcement needs to be stronger maybe? I also wondered why the TTL of the RR is not held to be meaningful. It felt like there is an opportunity to use this field but thats quibble, the document as-is defines it as 0 and thats ok, if perhaps missing an opportunity to use a field close to the zone being catalogued for some purpose. On Tue, May 12, 2020 at 3:42 AM Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon May 11 18:24:37 2020 Return-Path: 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 0ACA13A0E21 for ; Mon, 11 May 2020 18:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NhXj8gyz; dkim=pass (1536-bit key) header.d=taugh.com header.b=Qm060RW2 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 xxBuMoW02n9R for ; Mon, 11 May 2020 18:24:32 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 3F3663A0E24 for ; Mon, 11 May 2020 18:24:31 -0700 (PDT) Received: (qmail 67591 invoked from network); 12 May 2020 01:24:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10805.5eb9face.k2005; bh=NHDbcYufbJGFCJsIZm0HBkgIqXBCkOH05dNVdQadKME=; b=NhXj8gyzrbAmcCpzKLjPGwXokb4GHfD2Vt937pHVaiPdjdG0sumcnCNyBYQkK9PSs5tr+5aDix0it+EUixG8Qkg5uLmBj2KUbiDnMUy46YaVECwCRngKVUJsPlQf3BN2upLxXTk+EVEWcVfGhenQRCHvnK8GTtP/P4MpIoPjSvf6bA071RHTggeQU7ZzBjsDtWl2FWu5EBu+ZIuLYMaBhzYqJgkSd/sANxGd0+dIcNZwBng84Y7TR/DnQOxBZG/w DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10805.5eb9face.k2005; bh=NHDbcYufbJGFCJsIZm0HBkgIqXBCkOH05dNVdQadKME=; b=Qm060RW2azm+QetCWOOabpYswd1HJ2reFGtSIZkf1sIhUgranHP6g0TkPcmDRqqHC1nkp2ZvqGVgYHFQ6mEv5Ya+zu8V2dM7AjP0A/oE89rKvfEyw0vCBS2ul3mXnyfG/mYl2V78RCv+4fYVUrosxUvbzkEDMJ4hYOuivjUdRJA+ox7OIZcLPvpICJC+HkQFhcbr3y2NTdDBeGNv1B4SavLW++Ir+6mjSQRh1MDzw/rsGOV3OVdjdrSbPruImpUZ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 May 2020 01:24:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 31DC11908E69; Mon, 11 May 2020 21:24:29 -0400 (EDT) Date: 11 May 2020 21:24:29 -0400 Message-Id: <20200512012430.31DC11908E69@ary.qy> From: "John Levine" To: dnsop@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 01:24:34 -0000 In article you write: >Please review this draft to see if you think it is suitable for adoption >by DNSOP, and comments to the list, clearly stating your view. It doesn't seem like a bad idea but I'm wondering who's likely to implement it, since that makes it much more interesting. From nobody Mon May 11 22:19:51 2020 Return-Path: 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 EE0BD3A0C29; Mon, 11 May 2020 22:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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=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 6pMczVpujWuv; Mon, 11 May 2020 22:19:47 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 944153A0C26; Mon, 11 May 2020 22:19:47 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id s10so12486150iog.7; Mon, 11 May 2020 22:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZyOsdhQvPyd8edvUMEahOJAhYEkVzCz2FnxaJVDwtL8=; b=Eh/701DGvy5EqIggOmDwDgx8cp1je5Qu+HkWrDeiy3AFedYgxmW8TdkqojbyF87Y4W +6dqBxINggvSLpNqORWH+A9gk0GgLWA+4/vIBgMXw8MuUQOhRXK180jfh7S4HuQQHCba yR+JG0AnTzbz0K9DXTl3nscoVeCx2yEgK2ZZDDndavKQ1fSA03i6jZV4j9lXaCBinwwW 1X/wqQ3hmoesZOwXS2prLBVjIpUQ/BjIOu7xTWFDazJLpx8JkmPoqRzIZp+Tl4/epoiE tSQQTOJWjR3G9ihTSCYtTZAzbki/iNFkMO1a/qfWii7g2ScV99HlW5w/cAcAni7IAIXy Q6hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZyOsdhQvPyd8edvUMEahOJAhYEkVzCz2FnxaJVDwtL8=; b=Lq3MxPKkiAIKGzBz/xD6zq7f8hIC3Mm0EyYhK9QZluxzAK6bqbKtF89qJESUKIEw7A i67V13mRuX9C6oH1j3AZr46AHrATaa24EICfExM6Mm65eXJDd3kB8MHKCI01dMGTjkeV GhvWZZxXpIWLNdpU1vMWWRtiume9aAcJ7SDEoX/NuhLpfqzI633x8BMHIhcJLKzeOYPv 7Pb5hck3NEKgrAQHsus5PMdAfQSIYNCEEpzXwCyz99zjLRD3+Fl7aLj1OB5KHU2sCxEM yTlaOeW7ATdyRzFRi+ncf+1MoOJ0cVhYefCalIeXKqicCNPET35empAjcXkHTaxctS5M EckA== X-Gm-Message-State: AGi0Pubv49ARnpkiQ+LA4zmj3QMQTz/NGR5LaAntHYtv4cdddf4cN2jt Itf3W7ouwUmnPkLyXtlFitPhrQ513sXLvdteFIxRnhvL X-Google-Smtp-Source: APiQypJ6dD+f4dSpxsDwKuJfFshUbzlt/G4XnOHHZaRKlkMgD+qLp8kbnhTaX6vNhkh2IKmtTmZbCK+xbu/csXwH0og= X-Received: by 2002:a05:6602:164c:: with SMTP id y12mr18035213iow.138.1589260786776; Mon, 11 May 2020 22:19:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Tue, 12 May 2020 09:19:35 +0400 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 05:19:49 -0000 On Mon, May 4, 2020 at 11:10 PM Tim Wicinski wrote: > > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-requirements > > The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > I support adoption of the draft and i'm willing to review it. > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 18 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue May 12 01:23:21 2020 Return-Path: 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 5408D3A08B9 for ; Tue, 12 May 2020 01:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 mJeYi4zRWwUj for ; Tue, 12 May 2020 01:23:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 36AF43A08C5 for ; Tue, 12 May 2020 01:23:16 -0700 (PDT) Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id C8190140A57; Tue, 12 May 2020 10:23:14 +0200 (CEST) To: John Levine , dnsop@ietf.org References: <20200512012430.31DC11908E69@ary.qy> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <554fbcc4-03f7-c75e-466e-7a894ee18484@nic.cz> Date: Tue, 12 May 2020 10:23:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200512012430.31DC11908E69@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 08:23:20 -0000 On 5/12/20 3:24 AM, John Levine wrote: > It doesn't seem like a bad idea but I'm wondering who's likely to > implement it, since that makes it much more interesting. Knot DNS has an implementation already.  It's not merged and can't create catalog zones yet, but we expect to support it in future. I also see three other open-source server vendors among authors, so that might give you an idea, but I can't speak for them :-) --Vladimir From nobody Tue May 12 05:50:29 2020 Return-Path: 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 BB1AF3A08B9 for ; Tue, 12 May 2020 05:50:27 -0700 (PDT) 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 (1024-bit key) header.d=nlnetlabs.nl 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 e4KqlLhysdJG for ; Tue, 12 May 2020 05:50:26 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 2A2183A08AB for ; Tue, 12 May 2020 05:50:26 -0700 (PDT) Received: from [192.168.1.134] (happus.xs4all.nl [82.95.141.127]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 482A63426B for ; Tue, 12 May 2020 14:50:24 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=willem@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589287824; bh=tmvlfcJ6ceVkfHrRX7tEkrP0WqhoKon5FB4a/mcVJeA=; h=To:References:From:Subject:Date:In-Reply-To; b=N609DPBsRM0JvliJNceJTVyY8Vj1+8aXQk/ZB7/S31XCIKAIHXGZD7r9IW9xLJnWq 9dUAs3BOT3GAznXfxb5Z+EyLD2/e8y8OwIB6mNC8exehPUiUVI568Z2C6YgDee/dBL 3BGNf6uZ+7qFtITo9QTADqK3wwE4CJTcwG/JAiVg= To: dnsop@ietf.org References: From: Willem Toorop Autocrypt: addr=willem@nlnetlabs.nl; prefer-encrypt=mutual; keydata= mQINBE1s81EBEACuJzGgccrmYEAzHc//vBq66gH7orM0GtKfQZHh4uR1FMxZXl07WevUYNuB ywTpinU9rpY1Q3S4w6QgNklgpsaHXmbOpyFjJ8FpllV8TRPiXiNrNxTpMnlb6InoszopX69t kBVHTP6cJkNgPx6R4BM0ARqEGQmOL8mAcoWyGVzbsamuGRaia54zs/kc3i9yiqEzRkoQmfwr 7sr49n7gOpmaqXvonOSiUvgEziep77emMcqVa/qZxR1r7KUq85qTNTqsQwl2cQdKS7WwOeuG 6ZIJmJ1bakriKzLBYF5xIHKSYJW0ZA20tNFrVKgTkEjiXvAJh4HlJEIi35tqa/IzWUJSc1ai nhBjxbwSl8BRq5aaPgwB+xXiDqY6BrQW1slvl5TF2A6Xr7JJ0rkH3EZgXxABAZ3WJ3RLwq1z 8jnNYj+UW/mSLsbOtgfOiBhFUXMZneHvVVvz6F6XAtyrejDl5sD2gnzm1VDfK6T6bvLtR7zr kWre0lpycDmgmUKgaEiXzfLvwT9RaWk8GdqU2GG+QOiwf+hT0peDieuodjMr59sUbx7GqVe/ 45rJBRSx+HCl2Jm7Th2Xr0kpStCd7ebVoEq9wpMyu+dM9wOTtibA9P3+9u4rAdimpAdQxEbh WbRNCng2EVhThbqRK3cTZLbtqKaWgAJqa/IQVpL9b5ps8Z4JVQARAQABtCNXaWxsZW0gVG9v cm9wIDx3aWxsZW1AbmxuZXRsYWJzLm5sPokCTwQTAQIAOQIbIwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQTcNO5dskF7zBUeUQDl+PghL3ekmAUCXgm/sAAKCRDl+PghL3ekmLEOD/0W 50GFW5OfS/aZ3k7BfoBgSYEpgs3wUPxFCvkw4LsREcSLSdE9jFfIWh7sGiS1yP/kQGZr/yUn R58nAjGr9exyB90VsgEQqUlbks5nCqQZZrMcZRgHCB0IitYZqewBfl/GON/mqApTEQXgTJS7 0wi66828X7AyCA6kPgUfDl5V/zOE0GKm8ejNtKIIEnscNHUwpNpwTF/EegU6Fo6Ih4/bMvpg RytCgIi1tdmWETeyKjL7ASIGZL0kZkTfhQZV+V5NgToDnMFxPyndvv57Fip2mUSPkAAWRhgq ApL797C/KMpc1mCK43g6gD21KP01e5yz1BnSc09NJ7huLHYDFQKRBCfbUZuJe0KSibpRgmNE YaWT1sxByxqPbTmWDgvRXy4TGhkPm21wLqRACVmymd/KiFHdaB5NzWzrC5C0eWSCs2oziDuy Szf8/71sI8pNwjqBIp/8zA8ZI9AZrCkgzeuEeyKBcjW8O83iJkx2S9CC0KBrryvTi2QwitHX +WxJnGlOFNLQG4fp9/6EDuPUEKgmbqaiooCgDyU4aHYPFpUrHTc8aajahJ29wcXkWkIrm6rB mWzT/+05jyrrMl0HoSmZIqhwgtGHrWw+bnCxBZV2JOynDE0n+z4zh8N4rQ1vvCXu36CcR/62 YFTliLVKowkFtqO+om6DO8MBws/FoYnw/LkCDQRNbPNRARAApOziFbP3grro+2weP9wG0eYk InH0Gwc/x6hSN3iIFHtxaBNOC3U8YI0HMI8Yi5SJrzTx2rG7Uvw5aNCnBcMKNeoCJufSYIkx E41WzPEkqSNidkYoY6jxyDs6ZAFnIR3qqt/FV/93Acux1BMlnPP1sY7G5hUAC7Src8dbmAYV z6mnd43jurMYzESOygROP9yVrGOqKyiEbXf+GQ/o+8OgPs4504Z1BA/xvgZEEPqtn8Wowu/g LzTMOfMIfWsuk0ZCmV/VqfLTpZMCwMvh/qAQAsfrZMjE5fhTtbF668fHIpc4C4357H8y8XZr PXbhhtxYLu3V2pVbfKzbTMpp6Z6bJdIrFXpoyfgoFwkXcJ0zWgAFkPK+Iv16XtD/JDKWlkLo SXhCjBo8g4C7M50hzpy4zo9Na8ECtwpWBCFZ8myF94WZ+TGnP+FZz0rjTIKOZv6E9kivdFtd KxAi1RSQGo5Iwc2ugiBf4hpYyrd7vIwd0yqUqvSVTnaV8Ft8QKOV4H807grdIYkE/NOAu3N7 4uxbFIlChAxYq/ohLBCtbeuyZSOqBA2tIZE5fetHLw2+7Otq+zhrcWZ1SkchbDYp9jYzoCxf 0cEW5GyKaCoWNCblVupcDs20ckKcDVG+peWD+InnD4MSUeizHCMdL5Rt6MMaZVD4hOqWHf33 Wiw+NmrUjLUAEQEAAYkCNgQYAQIAIAIbDBYhBNw07l2yQXvMFR5RAOX4+CEvd6SYBQJeCb+w AAoJEOX4+CEvd6SYnQwQAKUN8F1N3G5rRgdyorRjX9+NEvZSn6sFAZZsngkO1fWny3z9PoGS 9n3OrKdqO2U9NdwvdWELyuFIv+3spd6Mn6DSYLSfqjg9i+YGC3AiQNoRR+VX1FWQ/TatFLpq +o1Lby04sWABhKic6pCxeCPXY2CzE7DSfUtMwBsPheK4JhpQNt6U4+7x24QIHbxcivpTq59V 7fZB8JpUgoN1k7DEAes9MEd1iOKM6ZucKgx1Q3elaS8DjRW7nJl+U9eaufa3BVt3+J3eL3Lr Q6ep4IDNEkQJoOwJytBzVQJcGkE0pdkSjO4jEocsNcQRVTahOazuYVUyYezqHDxUltAJqBux jnyyR2zZayDCoX82+UI0jtubwz1rFMqCdzID8n3PPn0AlmcHAsSNnCv4mIhI+tofc6bndNcu tJZMjoYA1MmEhgx1TStQptAQP/ZRNwV2TZFR20gwQWV1p/5R/GTlP3olNdC9Ojy0AmFMBLZb x7PI75HVJ2wtF8aq7vo2iltEM1k1zhl0Su5Ov/TEBq6JhqD5UzpqJPV6tTz76EEXfx58AxFh fVkytieLXCPI0kQTWfenexd9DUANCoa/TfYIEOi7YHJGYx/DpjfSPfThDxTGfWt0WaMILpOq +YTFA468fQW5xgeVvJlBNry4dT1XXgVbe/H+CN7q7C0Y1Ng11VOfO65X Message-ID: Date: Tue, 12 May 2020 14:50:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 12:50:28 -0000 Op 11-05-2020 om 21:38 schreef Bob Harold: > On Mon, May 11, 2020 at 1:42 PM Tim Wicinski > wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going > to run > regular call for adoptions over next few months.   > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > I support adoption and will review. > > "3.  Description > An implementation of catalog zones MAY allow the catalog to contain >    other catalog zones as member zones." > > It seems ok to me to allow catalog zones to include other catalog zones > as future feature, although I cannot figure out yet how that would work, > but it might conflict with: > > "6.1.  Implementation Notes >    Catalog zones on secondary nameservers would have to be setup >    manually" Thanks Bob, The secondary has to be "setup manually", - to regard the zone to be a catalog zone - but also, optionally, to associate a set of configuration which are applied to the zones generated from the catalog. One of the things in the associated set of configuration could be that zones from a certain catalog, are catalog zones themselves, however with which set of configuration the zones added from those catalog are associated, also needs to be configured manually on the secondaries. -- Willem > > --  > Bob Harold >   > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Tue May 12 06:07:10 2020 Return-Path: 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 098C43A08CB for ; Tue, 12 May 2020 06:07:03 -0700 (PDT) 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 (1024-bit key) header.d=nlnetlabs.nl 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 1Ezv3HDZhkdn for ; Tue, 12 May 2020 06:07:01 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 2EA253A0A01 for ; Tue, 12 May 2020 06:06:57 -0700 (PDT) Received: from [192.168.1.134] (happus.xs4all.nl [82.95.141.127]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 79AFD34309 for ; Tue, 12 May 2020 15:06:55 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=willem@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589288815; bh=z4WXFpvRFLLZttJ8RSMHIr7uQn2hUlZyaRSaP97Oy8M=; h=To:References:From:Subject:Date:In-Reply-To; b=IT8VbAUJ36DKFGT8NK62tTk88rxi+WxXklkMX6V0mtjZVNXT3YPvpQxHZA1XXeKGg jmaOguqIDlzK16o45zOv9CFmpAL8ZGcl8XmdtgJo+Td4SOzzbLRdmhYlPXd5gQibRv n9C24jPiY+v9oDBelLgXlyAQ5xZkTAA+8FuNmSSg= To: dnsop@ietf.org References: From: Willem Toorop Autocrypt: addr=willem@nlnetlabs.nl; prefer-encrypt=mutual; keydata= mQINBE1s81EBEACuJzGgccrmYEAzHc//vBq66gH7orM0GtKfQZHh4uR1FMxZXl07WevUYNuB ywTpinU9rpY1Q3S4w6QgNklgpsaHXmbOpyFjJ8FpllV8TRPiXiNrNxTpMnlb6InoszopX69t kBVHTP6cJkNgPx6R4BM0ARqEGQmOL8mAcoWyGVzbsamuGRaia54zs/kc3i9yiqEzRkoQmfwr 7sr49n7gOpmaqXvonOSiUvgEziep77emMcqVa/qZxR1r7KUq85qTNTqsQwl2cQdKS7WwOeuG 6ZIJmJ1bakriKzLBYF5xIHKSYJW0ZA20tNFrVKgTkEjiXvAJh4HlJEIi35tqa/IzWUJSc1ai nhBjxbwSl8BRq5aaPgwB+xXiDqY6BrQW1slvl5TF2A6Xr7JJ0rkH3EZgXxABAZ3WJ3RLwq1z 8jnNYj+UW/mSLsbOtgfOiBhFUXMZneHvVVvz6F6XAtyrejDl5sD2gnzm1VDfK6T6bvLtR7zr kWre0lpycDmgmUKgaEiXzfLvwT9RaWk8GdqU2GG+QOiwf+hT0peDieuodjMr59sUbx7GqVe/ 45rJBRSx+HCl2Jm7Th2Xr0kpStCd7ebVoEq9wpMyu+dM9wOTtibA9P3+9u4rAdimpAdQxEbh WbRNCng2EVhThbqRK3cTZLbtqKaWgAJqa/IQVpL9b5ps8Z4JVQARAQABtCNXaWxsZW0gVG9v cm9wIDx3aWxsZW1AbmxuZXRsYWJzLm5sPokCTwQTAQIAOQIbIwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQTcNO5dskF7zBUeUQDl+PghL3ekmAUCXgm/sAAKCRDl+PghL3ekmLEOD/0W 50GFW5OfS/aZ3k7BfoBgSYEpgs3wUPxFCvkw4LsREcSLSdE9jFfIWh7sGiS1yP/kQGZr/yUn R58nAjGr9exyB90VsgEQqUlbks5nCqQZZrMcZRgHCB0IitYZqewBfl/GON/mqApTEQXgTJS7 0wi66828X7AyCA6kPgUfDl5V/zOE0GKm8ejNtKIIEnscNHUwpNpwTF/EegU6Fo6Ih4/bMvpg RytCgIi1tdmWETeyKjL7ASIGZL0kZkTfhQZV+V5NgToDnMFxPyndvv57Fip2mUSPkAAWRhgq ApL797C/KMpc1mCK43g6gD21KP01e5yz1BnSc09NJ7huLHYDFQKRBCfbUZuJe0KSibpRgmNE YaWT1sxByxqPbTmWDgvRXy4TGhkPm21wLqRACVmymd/KiFHdaB5NzWzrC5C0eWSCs2oziDuy Szf8/71sI8pNwjqBIp/8zA8ZI9AZrCkgzeuEeyKBcjW8O83iJkx2S9CC0KBrryvTi2QwitHX +WxJnGlOFNLQG4fp9/6EDuPUEKgmbqaiooCgDyU4aHYPFpUrHTc8aajahJ29wcXkWkIrm6rB mWzT/+05jyrrMl0HoSmZIqhwgtGHrWw+bnCxBZV2JOynDE0n+z4zh8N4rQ1vvCXu36CcR/62 YFTliLVKowkFtqO+om6DO8MBws/FoYnw/LkCDQRNbPNRARAApOziFbP3grro+2weP9wG0eYk InH0Gwc/x6hSN3iIFHtxaBNOC3U8YI0HMI8Yi5SJrzTx2rG7Uvw5aNCnBcMKNeoCJufSYIkx E41WzPEkqSNidkYoY6jxyDs6ZAFnIR3qqt/FV/93Acux1BMlnPP1sY7G5hUAC7Src8dbmAYV z6mnd43jurMYzESOygROP9yVrGOqKyiEbXf+GQ/o+8OgPs4504Z1BA/xvgZEEPqtn8Wowu/g LzTMOfMIfWsuk0ZCmV/VqfLTpZMCwMvh/qAQAsfrZMjE5fhTtbF668fHIpc4C4357H8y8XZr PXbhhtxYLu3V2pVbfKzbTMpp6Z6bJdIrFXpoyfgoFwkXcJ0zWgAFkPK+Iv16XtD/JDKWlkLo SXhCjBo8g4C7M50hzpy4zo9Na8ECtwpWBCFZ8myF94WZ+TGnP+FZz0rjTIKOZv6E9kivdFtd KxAi1RSQGo5Iwc2ugiBf4hpYyrd7vIwd0yqUqvSVTnaV8Ft8QKOV4H807grdIYkE/NOAu3N7 4uxbFIlChAxYq/ohLBCtbeuyZSOqBA2tIZE5fetHLw2+7Otq+zhrcWZ1SkchbDYp9jYzoCxf 0cEW5GyKaCoWNCblVupcDs20ckKcDVG+peWD+InnD4MSUeizHCMdL5Rt6MMaZVD4hOqWHf33 Wiw+NmrUjLUAEQEAAYkCNgQYAQIAIAIbDBYhBNw07l2yQXvMFR5RAOX4+CEvd6SYBQJeCb+w AAoJEOX4+CEvd6SYnQwQAKUN8F1N3G5rRgdyorRjX9+NEvZSn6sFAZZsngkO1fWny3z9PoGS 9n3OrKdqO2U9NdwvdWELyuFIv+3spd6Mn6DSYLSfqjg9i+YGC3AiQNoRR+VX1FWQ/TatFLpq +o1Lby04sWABhKic6pCxeCPXY2CzE7DSfUtMwBsPheK4JhpQNt6U4+7x24QIHbxcivpTq59V 7fZB8JpUgoN1k7DEAes9MEd1iOKM6ZucKgx1Q3elaS8DjRW7nJl+U9eaufa3BVt3+J3eL3Lr Q6ep4IDNEkQJoOwJytBzVQJcGkE0pdkSjO4jEocsNcQRVTahOazuYVUyYezqHDxUltAJqBux jnyyR2zZayDCoX82+UI0jtubwz1rFMqCdzID8n3PPn0AlmcHAsSNnCv4mIhI+tofc6bndNcu tJZMjoYA1MmEhgx1TStQptAQP/ZRNwV2TZFR20gwQWV1p/5R/GTlP3olNdC9Ojy0AmFMBLZb x7PI75HVJ2wtF8aq7vo2iltEM1k1zhl0Su5Ov/TEBq6JhqD5UzpqJPV6tTz76EEXfx58AxFh fVkytieLXCPI0kQTWfenexd9DUANCoa/TfYIEOi7YHJGYx/DpjfSPfThDxTGfWt0WaMILpOq +YTFA468fQW5xgeVvJlBNry4dT1XXgVbe/H+CN7q7C0Y1Ng11VOfO65X Message-ID: <1bbb74ee-7e5f-564e-17cc-b1699c7ef8aa@nlnetlabs.nl> Date: Tue, 12 May 2020 15:06:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 13:07:09 -0000 Op 12-05-2020 om 00:48 schreef George Michaelson: > I support adoption. > > I wondered a little about "it is absolutely essential for these > transfers to be protected from unexpected modifications on the route. > So, catalog zone transfers SHOULD be authenticated using TSIG > [RFC2845]." > > The use of a categorical *absolutely* and SHOULD is jarring. If this > is really categorical, the normative enforcement needs to be stronger > maybe? Agree, how about replacing "it is absolutely essential" with "it is key"? > I also wondered why the TTL of the RR is not held to be meaningful. It > felt like there is an opportunity to use this field but thats quibble, > the document as-is defines it as 0 and thats ok, if perhaps missing an > opportunity to use a field close to the zone being catalogued for some > purpose. We're staying away from actual configuration properties in this draft on purpose. TTL could be used to mean something in the dynamics of adding & removing of zones itself, but it feels a bit fragile to do that to be honest - we might exclude (or make more difficult) certain setups where the catalog could not be used by or from the authoritative nameserver directly. -- Willem > > On Tue, May 12, 2020 at 3:42 AM Tim Wicinski wrote: >> >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular call for adoptions over next few months. >> We are looking for *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones >> >> The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 25 May 2020 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Tue May 12 07:32:13 2020 Return-Path: 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 2B4FE3A0A99 for ; Tue, 12 May 2020 07:32:11 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.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 ClfLceqCg_Oz for ; Tue, 12 May 2020 07:32:08 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 93BEA3A0A83 for ; Tue, 12 May 2020 07:32:08 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id w6so12450472ilg.1 for ; Tue, 12 May 2020 07:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ScjGlgzChVoXA2IOCHhFxIuWcepgafNM7JNlOz2M6Eo=; b=jCLHkGPlMZTXcoXiMBm+dZSXzwI10OgEUzqsjUVZqbJQzVqmJ/zx/otCiEheBOknO8 zoJPjSuNnYukmrBqnWk8h3/w+rIa20lTs6CQ4GSFpEP38TVBJvs01CFetV1dgyhxIjCj 6jIfDro7CizWblsg+8woEe8Ql04qspODJZAvbltD2ouzCdNiYZCrZSNfqpwQm7Tfg//P cGkQ5he0R5xATOL28s4vjvPeVhCCyeupA2vtg2NGdgmCYeLE65StaD4TlLHChMwCuKxa L0s3iS+6qCDmz1whM72ZhKIcrinCxhEtvphEa1ln/cBRn/VE1lFDZmxJkQMmG2FgRfHP AYsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ScjGlgzChVoXA2IOCHhFxIuWcepgafNM7JNlOz2M6Eo=; b=taY0fAhjyydUHI8cbJ41A9aiik3hbWjKJUzav/wOT8KGulGuAuCM1044rgM6OdxBr7 RzSxlratsTxjHfoHi1q9aIF9WBJmE+LQvRtj6uGalLMuuA4v+j4avZxEGIJGlnSstEwu Tt9pKCEDz1KVfDOLmhp0OvZQ6b3HcjXYNppzhUdNjHdrT6hdGupFp/tU6lh6uAQvyWMd 9zl4ikYAxcSTC/7V6xR1NiS5pAluBhcvaT8c8/HiIlHya9BO78F/K0ZkKUMldDVECHHO z7GChBDjD3LqO2Q1Qws6vW0b/0lXueQN9Hv02r8DdpmTwMYzmIpm5W+ck9IZlGp8WxEk Htxg== X-Gm-Message-State: AGi0PuZDIHXu32NKEvw+qlk4uSiD0ObJJY8Hd+tJq7FMIK/vSfeE+u12 kJmxifr0nXELwEd6ZXtkUAhJssk8mxHKC1tOYyNpbQ== X-Google-Smtp-Source: APiQypI3iGTIsf/en3QIaMZGNqUqSw4J2oL+3QzCBjbDAsXFDQxMfnk6emAnjpHkLvcWRsR9GCFLUosL6buCK0kS5GA= X-Received: by 2002:a05:6e02:673:: with SMTP id l19mr1993583ilt.218.1589293926514; Tue, 12 May 2020 07:32:06 -0700 (PDT) MIME-Version: 1.0 References: <1bbb74ee-7e5f-564e-17cc-b1699c7ef8aa@nlnetlabs.nl> In-Reply-To: <1bbb74ee-7e5f-564e-17cc-b1699c7ef8aa@nlnetlabs.nl> From: George Michaelson Date: Wed, 13 May 2020 00:31:54 +1000 Message-ID: To: Willem Toorop Cc: dnsop WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 14:32:11 -0000 yes. well finessed! keep the SHOULD relax the non-normative language is fine. and I understand not wanting to work on this regarding TTL and meaning against RR. as I said, support adoption. this is good work. its implemented. -G On Tue, May 12, 2020 at 11:07 PM Willem Toorop wrote: > > Op 12-05-2020 om 00:48 schreef George Michaelson: > > I support adoption. > > > > I wondered a little about "it is absolutely essential for these > > transfers to be protected from unexpected modifications on the route. > > So, catalog zone transfers SHOULD be authenticated using TSIG > > [RFC2845]." > > > > The use of a categorical *absolutely* and SHOULD is jarring. If this > > is really categorical, the normative enforcement needs to be stronger > > maybe? > > Agree, how about replacing "it is absolutely essential" with "it is key"? > > > I also wondered why the TTL of the RR is not held to be meaningful. It > > felt like there is an opportunity to use this field but thats quibble, > > the document as-is defines it as 0 and thats ok, if perhaps missing an > > opportunity to use a field close to the zone being catalogued for some > > purpose. > > We're staying away from actual configuration properties in this draft on > purpose. TTL could be used to mean something in the dynamics of adding > & removing of zones itself, but it feels a bit fragile to do that to be > honest - we might exclude (or make more difficult) certain setups where > the catalog could not be used by or from the authoritative nameserver > directly. > > -- Willem > > > > On Tue, May 12, 2020 at 3:42 AM Tim Wicinski wrote: > >> > >> > >> All, > >> > >> As we stated in the meeting and in our chairs actions, we're going to run > >> regular call for adoptions over next few months. > >> We are looking for *explicit* support for adoption. > >> > >> > >> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > >> > >> The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > >> > >> Please review this draft to see if you think it is suitable for adoption > >> by DNSOP, and comments to the list, clearly stating your view. > >> > >> Please also indicate if you are willing to contribute text, review, etc. > >> > >> This call for adoption ends: 25 May 2020 > >> > >> Thanks, > >> tim wicinski > >> DNSOP co-chair > >> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue May 12 10:33:24 2020 Return-Path: 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 E3C313A0814; Tue, 12 May 2020 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 JmWigEMslagR; Tue, 12 May 2020 10:33:21 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 543A03A0811; Tue, 12 May 2020 10:33:21 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id f7so3534969vkl.6; Tue, 12 May 2020 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pGa2DSN7yfoH0plpdhxVRhjn2U/w5I5W71q00AePDIM=; b=KRHBo4LTKqdpx5qV+csxh7T5tVIPZyBvhJvQr2WvmeNjggFTNUOvX0sfQp8YcdU/1t MOi6FD7UT7olsAJM38OvkNugdAX45kJC3MTW04GL8xBS+M5bwCFKHtw6116FYRQFU9sK lAD694Bpu3VEDjezSGP0bqeGlwfz6J2aR9b4AU367NLmUddr/rd5moh6w7Zj5Y9tv2gr n9hkguft96Osoj8abPM+KDBktj55azzCrtBRsUvPhvLcKfx5rAXi4zeY69qjl18D6cry d2WKGNhWcleuVDhb/uJAFC6Za8FlV1bgz1Ti9UHjWZbZGXaaJvvnPNQzhblirPJxWhCX f5nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pGa2DSN7yfoH0plpdhxVRhjn2U/w5I5W71q00AePDIM=; b=mdB2sL0XeWmE/CGlS84vv9bzUVxLMEJsdORZ44JelmTyCWZbsjH1xnf4pAbbjyPNnR Rn4GPllKGY799SeLzevKfnPA/pCNGa0udjghTK2xZsy6P26mxfIt6YaLsHXazxlb3CDW HPbmWMzyoNNc+8f4PpbbUZPT/EVFcCsnJ71LW6Z/Tn+CoKrvWqFtivbD0PP9D+doepkW FJYJym+v9PfVFpB8aFFCOTPhU04Fo/vZ1IgUWTT5011XpwivQIwFhQBV4efX2jc7ELLw l+9kgVB014/JzPHFFFQsJ6kr5ySBhCx/UtHj+uf9kiBWB+gIPl32dKLW84xj/pCti8sS I/AA== X-Gm-Message-State: AOAM532RWdd9CeaKGQfkhmj9H/dnQtkLP1NRLKIiIrtfrduxd1YD5AIX LvHe05XfRS827slfQtNasLEyJGIVuXWCzKT8n3Y= X-Google-Smtp-Source: ABdhPJxZyPBi9602amcjzG9kr/9/zxR2q0AGZcOD11xtQvMIDdAO66E3HXYGC0QF9SrOOSGxbKufclLbHz3aApWYc7s= X-Received: by 2002:a1f:d0c5:: with SMTP id h188mr10186178vkg.0.1589304800313; Tue, 12 May 2020 10:33:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Tue, 12 May 2020 10:33:08 -0700 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="00000000000010056705a576dc05" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 17:33:23 -0000 --00000000000010056705a576dc05 Content-Type: text/plain; charset="UTF-8" On Mon, May 11, 2020 at 10:42 AM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > I support adoption of this as a WG draft. I believe it is suitable for adoption by DNSOP. I am willing to review, and to contribute text. Brian > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000010056705a576dc05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 11, 2020 at 10:42 AM Tim = Wicinski <tjw.ietf@gmail.com&g= t; wrote:

All,

As we state= d in the meeting and in our chairs actions, we're going to run
regul= ar call for adoptions over next few months. =C2=A0
We are looking for *e= xplicit* support for adoption.


I support adoption of this as a WG draft. I believe it is suitable = for adoption by DNSOP. I am willing to review, and to contribute text.

Brian

=C2=A0

This starts a Call for Adoption for draft-toorop-dnso= p-dns-catalog-zones

The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zone= s/

Please review this draft to see if you think it is suitable f= or adoption
by DNSOP, and comments to the list, clearly stating your vie= w.

Please also indicate if you are willing to contribute text, revie= w, etc.

This call for adoption ends: 25 May 2020

Thanks,
t= im wicinski
DNSOP co-chair



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000010056705a576dc05-- From nobody Tue May 12 11:35:21 2020 Return-Path: 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 62E5B3A091C for ; Tue, 12 May 2020 11:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hAtYC7O0O8Gy for ; Tue, 12 May 2020 11:35:18 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69183A0919 for ; Tue, 12 May 2020 11:35:16 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 55149B074A for ; Tue, 12 May 2020 18:35:14 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Date: Tue, 12 May 2020 18:35:12 +0000 Message-ID: <2554196.G9qeH4o4B6@linux-9daj> Organization: none MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1840489.WsFTWvh4rX" Content-Transfer-Encoding: 7Bit Archived-At: Subject: [DNSOP] datagram-plpmtud-21 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 18:35:20 -0000 This is a multi-part message in MIME format. --nextPart1840489.WsFTWvh4rX Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" in tsvwg they are working on packetization layer path mtu discovery for datagram transports, whose primary audience seems to be quic and sctp. https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-datagram-plpmtud-19&url2=draft-ietf-tsvwg-datagram-plpmtud-21 noone who believes that DNS's future is going to be quic-based needs to read this document. however, anyone who sees a future in unencrypted UDP/53 using PMTU-sized IP packets may find it fascinating. -- Paul --nextPart1840489.WsFTWvh4rX Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

in tsvwg they are working on packetization layer path mtu discovery for datagram transports, whose primary audience seems to be quic and sctp.

 

https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-datagram-plpmtud-19&url2=draft-ietf-tsvwg-datagram-plpmtud-21

 

noone who believes that DNS's future is going to be quic-based needs to read this document. however, anyone who sees a future in unencrypted UDP/53 using PMTU-sized IP packets may find it fascinating.

 

--

Paul

--nextPart1840489.WsFTWvh4rX-- From nobody Tue May 12 18:35:23 2020 Return-Path: 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 DCCB13A0B1C for ; Tue, 12 May 2020 18:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=g001.emailsrvr.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 9zYkPVSxsfHr for ; Tue, 12 May 2020 18:35:19 -0700 (PDT) Received: from smtp96.ord1d.emailsrvr.com (smtp96.ord1d.emailsrvr.com [184.106.54.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC493A0B27 for ; Tue, 12 May 2020 18:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1589333718; bh=7DGoO3VwaTG+UsgW3aIRMRWOsUbzkTCOZq+Id/aKG+g=; h=From:Subject:Date:To:From; b=pXEqg95VBPhIiMn9XMoGopccFOitVx3XxDLWInqySNhV65cf2HzN2ltxot/S4TJ3p p79D72xA4wPJCpxWSJgKzkhTDRFX54OCF5sWEUevFSvxPbub2ToAQCbhmP0RT8nRrG THV7twGLmzoaOurzYoH1GPieFQBcy1614H0kHWpI= X-Auth-ID: ogud@ogud.com Received: by smtp21.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A580D601EF; Tue, 12 May 2020 21:35:18 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.6.34] ([UNAVAILABLE]. [96.231.186.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 12 May 2020 21:35:18 -0400 From: Olafur Gudmundsson Message-Id: <02472848-7B62-4613-AE9B-218C2709E397@ogud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_84432436-A1AF-4267-86EE-D67A66F0700D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 12 May 2020 21:35:17 -0400 In-Reply-To: Cc: dnsop , dnsop-chairs To: Tim WIcinski References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Classification-ID: a5f5d300-7756-4cd4-a643-22531b401c4f-1-1 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 01:35:22 -0000 --Apple-Mail=_84432436-A1AF-4267-86EE-D67A66F0700D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 11, 2020, at 1:41 PM, Tim Wicinski wrote: >=20 >=20 > All, >=20 > As we stated in the meeting and in our chairs actions, we're going to = run > regular call for adoptions over next few months. =20 > We are looking for *explicit* support for adoption. >=20 >=20 > This starts a Call for Adoption for = draft-toorop-dnsop-dns-catalog-zones >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ = >=20 > Please review this draft to see if you think it is suitable for = adoption > by DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. >=20 > This call for adoption ends: 25 May 2020 >=20 Tim,=20 a nit question:=20 what is the intended publication status ?=20 Experimental, Informational, Standard =20 Thanks=20 Olafur > Thanks, > tim wicinski > DNSOP co-chair >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_84432436-A1AF-4267-86EE-D67A66F0700D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 11, 2020, at 1:41 PM, Tim Wicinski <tjw.ietf@gmail.com> = wrote:


All,

As we stated in the meeting and in our chairs actions, we're = going to run
regular call for adoptions over next few = months.  
We are looking for *explicit* support for = adoption.


This starts a Call = for Adoption for draft-toorop-dnsop-dns-catalog-zones

The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog= -zones/

Please review this draft to see = if you think it is suitable for adoption
by DNSOP, and = comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, = review, etc.

This call for adoption ends: = 25 May 2020


Tim, 
a nit = question: 
what is the intended publication status = ? 
Experimental, Informational, Standard =  

Thanks 
Olafur

Thanks,
tim wicinski
DNSOP co-chair



_______________________________________________
DNSOP = mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

= --Apple-Mail=_84432436-A1AF-4267-86EE-D67A66F0700D-- From nobody Tue May 12 18:43:25 2020 Return-Path: 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 AB3793A0B30; Tue, 12 May 2020 18:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 wfM4cRBpxOtB; Tue, 12 May 2020 18:43:22 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::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 DEFB93A0B23; Tue, 12 May 2020 18:43:21 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id o24so20084124oic.0; Tue, 12 May 2020 18:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c5xppHp/X4rpyVvVg3XfLFSiEyLXcHIM1DvcZx9BT3c=; b=XsYxkVNo1Rvg2mtC0XXk3dxNP0OuHFBp98AKoyQLVkn2Ev3YmtjBLyzjM3eb/a5geN mQEBR4k09x6TjLaunXXzA90pBbFc6lzr4zNGJMoW4+8nmaqi0fw8aIHMzT4C1kiIJpfC 8PF7jrzPIX9bZcD8LukU+WtbsVGAt2EtOG5DEfTMS81trcuvQ9NsN7arFokxuyFKg7Uz i7SaUBV18q71QoWmux0VZkJq9EKdaxUqNhqqOcvZ2yczN4hThABlmxDgKo4R9fJqREzU qQs0yyreHTspdE+4mGndDdJY8HhhIonRlAx4Qk2+Y90Uh46azYm+lA0h5gRqFLdqnop7 SnxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c5xppHp/X4rpyVvVg3XfLFSiEyLXcHIM1DvcZx9BT3c=; b=cKBB6MUBDeawRkw/5fM6HMkBQvTyqlcK2D24tAn+D1DxSFfObOOvHRkQaFbvUSZq8e VVnRCwTL23epHg3oz3LdjadJqZNMvT6In3W4BOLXKs2GJlhs53D2sStZCrnQQZteHnWq kfsHo92kUvfjn5K9EACW0sO3KyEpmErOqf3qgZyrSvg6jrAkkCWCdK58rhpcj4LJEts/ k29IDndsWBiRCPrXOhKafx+Tobnti/iEwC+2LaYnrgJrKX4GfDuMvtIK2mT81W3tShNt KGMOrGTq57pQwsU/Y4OsgFuEDS2hus55lPdnrG6QfyK1wZNK/QYJVOZJdY8oFA5TsPWn lOpw== X-Gm-Message-State: AOAM530fVG5bISiSFEfG951T9tMvo0NM/mfwrVlTEVbxrz2N8Pv5Rluj X570wJHdxPi5cGMWKEXES33adwz4ofeZ8ORl39P68Jex X-Google-Smtp-Source: ABdhPJzG/R/D/S9K6tVErmfgteUffoLassNc9BEczcBSEIX+VICee3E4uPgwRkAterVy6COlTOUX218vxmZAHL9+zLo= X-Received: by 2002:aca:f02:: with SMTP id 2mr391139oip.173.1589334200979; Tue, 12 May 2020 18:43:20 -0700 (PDT) MIME-Version: 1.0 References: <02472848-7B62-4613-AE9B-218C2709E397@ogud.com> In-Reply-To: <02472848-7B62-4613-AE9B-218C2709E397@ogud.com> From: Tim Wicinski Date: Tue, 12 May 2020 21:43:09 -0400 Message-ID: To: Olafur Gudmundsson Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000007a948605a57db484" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 01:43:24 -0000 --0000000000007a948605a57db484 Content-Type: text/plain; charset="UTF-8" Olafur Currently it's marked Standards Track, but I was working on the idea that the working group would make that decision as the document works toward Working Group Last Call. I was reserving judgement until there was implementations, interoperability, etc. Please feel free to register any thoughts on publication status at this time as well. Hope that helps tim On Tue, May 12, 2020 at 9:35 PM Olafur Gudmundsson wrote: > > > On May 11, 2020, at 1:41 PM, Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > > Tim, > a nit question: > what is the intended publication status ? > Experimental, Informational, Standard > > Thanks > Olafur > > Thanks, > tim wicinski > DNSOP co-chair > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > --0000000000007a948605a57db484 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Olafur

Currently it's marked Standards Track, but I was working on the id= ea that the working group would make=C2=A0
that decision as the document works towar= d Working Group Last Call.=C2=A0=C2=A0

I was reserving judgement until there was implem= entations, interoperability, etc.=C2=A0

Please feel free to register any thoughts on pub= lication status at this time as well.

Hope that helps

tim


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 9:35 PM Olafur= Gudmundsson <ogud@ogud.com> wro= te:


On May 11, 2020, at 1:41 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote:


All,

As we stated in the meeting and in our chairs actions, = we're going to run
regular call for adoptions over next few months. = =C2=A0
We are looking for *explicit* support for adoption.


Th= is starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
<= br>The draft is available here: https://datatrack= er.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/

Please rev= iew this draft to see if you think it is suitable for adoption
by DNSOP,= and comments to the list, clearly stating your view.

Please also in= dicate if you are willing to contribute text, review, etc.

This call= for adoption ends: 25 May 2020

=
Tim,=C2=A0
a nit question:=C2=A0
what is the = intended publication status ?=C2=A0
Experimental, Informational, = Standard =C2=A0

Thanks=C2=A0
Olafur

Thanks,
tim wicinski
DNSO= P co-chair



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
http= s://www.ietf.org/mailman/listinfo/dnsop
--0000000000007a948605a57db484-- From nobody Wed May 13 00:19:15 2020 Return-Path: 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 62CC93A0F8A for ; Wed, 13 May 2020 00:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 J027BHXbgRRH for ; Wed, 13 May 2020 00:19:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 861E93A0C82 for ; Wed, 13 May 2020 00:19:09 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 89E6A860077; Wed, 13 May 2020 09:18:19 +0200 (CEST) Received: from localhost (unknown [172.29.2.100]) by trail.lhotka.name (Postfix) with ESMTPSA id E86AC860002 for ; Wed, 13 May 2020 09:18:18 +0200 (CEST) From: Ladislav Lhotka To: DNSOP WG References: Date: Wed, 13 May 2020 09:19:06 +0200 Message-ID: <87k11gjo9h.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [DNSOP] [Michelle Cotton via RT] [IANA #1168741] Early Review: draft-ietf-dnsop-iana-class-type-yang-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 07:19:14 -0000 Hi, IANA did an early review of the draft in $subj. As you can see below, Michelle proposes that the XSLT stylesheet be removed upon publication of the RFC. I am personally not much in favour of doing so. First, I don't expect that any future changes to the stylesheet will be necessary or even possible: the rules for updating YANG modules (sec. 11 in RFC 7950) effectively block any substantial changes. So, if it ever turned out that the way how the registries are modelled in YANG needs to be change, it would most likely require an entirely new YANG module. And, more importantly, the XSLT stylesheet is also kind of a formal record of the consensus regarding the mapping of registry data to YANG (there are indeed a few other options how to do it). If a change was necessary (modulo errata), then it is IMO appropriate to run it through the IETF process again. Any thoughts on this? Thanks, Lada -------------------- Start of forwarded message -------------------- Precedence: bulk Date: Fri, 08 May 2020 18:52:40 +0000 Hello Ladislav, We have reviewed the 00 version of the document and we believe all seems to be in order. The script has been tested and appears to work. One suggestion we have is before publication of the document, the script be removed from the document. If there are any adjustments needed in the future, it would be better not to have to update the RFC and be able to make changes as needed separately. Thoughts on that approach? --Michelle On Fri Apr 24 06:18:48 2020, ladislav.lhotka@nic.cz wrote: > Hi Michelle, > > thank you. We will wait with the next revision of the I-D till you > finish the review. > > Best regards, > > Ladislav > > On 23. 04. 20 22:26, Michelle Cotton via RT wrote: > > Hello Ladislav and Petr, > > > > As indicated on the DNSOP WG meeting this morning, I have initiated > > the early review of this document. We will reply back (most likely > > end of next week) with any comments and questions related to this > > document. > > > > Just letting you know the review has commenced. > > > > Best regards, > > > > Michelle Cotton > > Protocol Parameters Engagement Sr. Manager > > IANA Services > > -------------------- End of forwarded message -------------------- -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed May 13 00:44:29 2020 Return-Path: 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 D90B73A0F9A for ; Wed, 13 May 2020 00:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ciUFZcJS62pU for ; Wed, 13 May 2020 00:44:27 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 6F25B3A0884 for ; Wed, 13 May 2020 00:44:27 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id f3so17007526ioj.1 for ; Wed, 13 May 2020 00:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JI5ZTZAfImOJRZjngjdzi5+EmEY8i07Q3Eh7Y1sOY3k=; b=OFe1Ptu1qj+7coAps0ShSHsfYd8W0mJoYVbQM4JfwD/VBTSIPd4JbNIhosHth5Qmh4 x4Kz7N8K1zhplcWooLkk94znWxzAQDhuHc56zEKJuUZq/8JmVfoFCP95ULg9QdwCoTU0 2SYfdvodC49deQZdwbK9w27x1MYFi9haMgrrq7OcG7bAmJiIpntY6vwl12q47E1XCW16 KUyIP3jcTvtlq3XeTVc/Q0+7lt+Tmc7oZ7GoDiEHywmBOSx+aw+DfJJ4BJ0ZwozkaZVO nhPnXcw4+zTV3APej0QZ6uRhiPGviQ8gWSromneRLAhFNZqrvM/r4aUimxJNxAGGtnF4 YBbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JI5ZTZAfImOJRZjngjdzi5+EmEY8i07Q3Eh7Y1sOY3k=; b=lVsMC1zl9vLDbiAGXQfYUKWq1pYMzpZ11u/gdOePb+NnAiFhWN+vCd6zG849JJ8n1D M4K6fVT34RYL+NmiUiioFKBtv+0UtDyvEzEGhyZ3vrHfqmSuu0Prlzl5hTwoX2OON6mh kXLG53jyjttQjWsi61eD7yoDBqg2pEvCTujXoWct13mkOUD/v+6qVyMGeyNAltxWZb8J Lc+q63hz1bXtuXIjxQNsrx6u0RzTv1SfwS0UVj5e61mAHZFrC8PoZLQB7XZXH3+Jg/wO n04/nqw4zDrRYuesKxym9wNRLkoocSDNHBnZbGuIiFHmhFcHi+8FhHDzmhnHhWp9E9DM JiDQ== X-Gm-Message-State: AGi0PuaQd4WtGtSv7zF9Tq5N738Bc4Zn5lrh54y+obCR4avaRJ1m+M9q FPGA7rq/++wFVdAvXZPQPV7HieM2T2WLflkKmM0= X-Google-Smtp-Source: APiQypLWgQmMUsx+YHO64yERYKrkU9BULepHi0oUl6or7c71qQP+3e8wP63F7T9sfaAtbgD0MTudOpqEaHPNIzeulZA= X-Received: by 2002:a6b:e911:: with SMTP id u17mr17789805iof.29.1589355866610; Wed, 13 May 2020 00:44:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Wed, 13 May 2020 11:44:15 +0400 Message-ID: To: Willem Toorop Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 07:44:29 -0000 On Tue, May 12, 2020 at 4:50 PM Willem Toorop wrote: > > Op 11-05-2020 om 21:38 schreef Bob Harold: > > On Mon, May 11, 2020 at 1:42 PM Tim Wicinski > > wrote: > > > > > > All, > > > > As we stated in the meeting and in our chairs actions, we're going > > to run > > regular call for adoptions over next few months. > > We are looking for *explicit* support for adoption. > > > > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends: 25 May 2020 > > I support Adoption of the document and I'm willing to review it. > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > > > I support adoption and will review. > > > > "3. Description > > An implementation of catalog zones MAY allow the catalog to contain > > other catalog zones as member zones." > > > > It seems ok to me to allow catalog zones to include other catalog zones > > as future feature, although I cannot figure out yet how that would work, > > but it might conflict with: > > > > "6.1. Implementation Notes > > Catalog zones on secondary nameservers would have to be setup > > manually" > > Thanks Bob, > > The secondary has to be "setup manually", > - to regard the zone to be a catalog zone > - but also, optionally, to associate a set of configuration which are > applied to the zones generated from the catalog. > > One of the things in the associated set of configuration could be that > zones from a certain catalog, are catalog zones themselves, however with > which set of configuration the zones added from those catalog are > associated, also needs to be configured manually on the secondaries. > > -- Willem > > > > > -- > > Bob Harold > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed May 13 03:26:06 2020 Return-Path: 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 D374E3A102D for ; Wed, 13 May 2020 03:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 yPVXDA85A9Dy for ; Wed, 13 May 2020 03:26:00 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 ABBEC3A102E for ; Wed, 13 May 2020 03:26:00 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id di6so7822405qvb.10 for ; Wed, 13 May 2020 03:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=knCfAdXlfuE2Ou/vI4WIHFROedXpXwBhAQMaAMy0MO4=; b=mAP5nc25wPTFusGXg1Jv+QuE+yLK+FT22E54ME/g2AmFua8qIZmXpNXCiXjjWjJraK QZ3YRzAnNsdo1evvRb12zf68mpTGuh89haKu8C8Rd0RieayIUI90Qgg3ElTDsx4zaG9w oZgimk6s/8eDcwt70/mmLAAbCgX4eZIdP+ROg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=knCfAdXlfuE2Ou/vI4WIHFROedXpXwBhAQMaAMy0MO4=; b=eN05Z4plFPFPQDQ3Q0fmBb28pG/y1Av9shI1tdPBP1iMQA0CHWaSThu+2vsp9fMQTs CXcUkKy6Po/CJqj4DeBDoiUk0A4aIXowzIGwBYxsWRf5IBfHyIInbJnLVZ82ABbrqRyE 5UPjQkzfGGVuqHggpykRlhIXIymigUhmsCIWM1IxLLFIh0KPUYnGw26wTFvAQ5ivFpDG Fwh0rP/gyIsmRpiTG1XQyQ8kcACPrtYsKSSJH6iX8zGmX/lxAAiXYPI2rEu7zmpagj/W KswMiituwpxxwDlky1ITqrsd76rdR1sl66c3tbAGNvua5chOaznUJiCMKNkI1cKJvkIM uqYQ== X-Gm-Message-State: AOAM533rtw9UPhlhheWu0yRNQSEmTSbU9XpuEbUGy4wYE2OTI1UzlMKF y/cIzk16St+3M6KKR1yBCY4qpiGx+NY0YQFb X-Google-Smtp-Source: ABdhPJxVWz7ThTYQnfq1Nyxd3cR55JV1VvgXJbjG792XdXT3gXL2UusDCuyzOrYvdCt9qmvoKO3a4w== X-Received: by 2002:ad4:5290:: with SMTP id v16mr10360400qvr.240.1589365559348; Wed, 13 May 2020 03:25:59 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:8972:8673:6d53:e208? ([2607:f2c0:e784:c7:8972:8673:6d53:e208]) by smtp.gmail.com with ESMTPSA id l2sm13355062qkd.57.2020.05.13.03.25.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 03:25:57 -0700 (PDT) From: Joe Abley Message-Id: <161A989F-0485-40E3-910A-B06E1B8B160E@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_47D20C86-BB38-455C-9A50-FF5EF9A87F37"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 13 May 2020 06:25:56 -0400 In-Reply-To: <87k11gjo9h.fsf@nic.cz> Cc: DNSOP WG To: Ladislav Lhotka References: <87k11gjo9h.fsf@nic.cz> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] [Michelle Cotton via RT] [IANA #1168741] Early Review: draft-ietf-dnsop-iana-class-type-yang-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 10:26:04 -0000 --Apple-Mail=_47D20C86-BB38-455C-9A50-FF5EF9A87F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lada, On 13 May 2020, at 03:19, Ladislav Lhotka = wrote: > IANA did an early review of the draft in $subj. As you can see below, = Michelle proposes that the XSLT stylesheet be removed upon publication = of the RFC. >=20 > I am personally not much in favour of doing so. First, I don't expect = that any future changes to the stylesheet will be necessary or even = possible: the rules for updating YANG modules (sec. 11 in RFC 7950) = effectively block any substantial changes. So, if it ever turned out = that the way how the registries are modelled in YANG needs to be change, = it would most likely require an entirely new YANG module. >=20 > And, more importantly, the XSLT stylesheet is also kind of a formal = record of the consensus regarding the mapping of registry data to YANG = (there are indeed a few other options how to do it). If a change was = necessary (modulo errata), then it is IMO appropriate to run it through = the IETF process again. >=20 > Any thoughts on this? You seem to have addressed Michelle's concern, above. Did you give that = response to her as well as sending it to this list? What did she think? Joe --Apple-Mail=_47D20C86-BB38-455C-9A50-FF5EF9A87F37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXrvLNAAKCRA0jwy9hlI6 LKl0AJ44ij7LtW3gsjzdAYklnKguQ/WeqQCfRzQSlx3FsY6kag26eLTaSJbnJZs= =ptUd -----END PGP SIGNATURE----- --Apple-Mail=_47D20C86-BB38-455C-9A50-FF5EF9A87F37-- From nobody Wed May 13 04:09:33 2020 Return-Path: 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 EE5A23A1050; Wed, 13 May 2020 04:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 Ld0fvqHrqWi1; Wed, 13 May 2020 04:09:29 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) (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 1A1CB3A104E; Wed, 13 May 2020 04:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aP7Ex1gOp/TyCj5C7OUpQkKVNw3cvDiFYy+xpqpyTdlcr1q+qtGFmVpugvCzMpMN6AQlSJPSsSkA7BrE5Aw8sS20Mm3J2OmOh6XbVgcBZRbJcf6OyUYRut+YUjQaJK/qCwADKmMPFWc4tz3yKOr/d8eJ79o7z+oW5QHTmzMBbbsTaTvPOyj+H9ryq5SbOrp5WPYIkBVSm2PxUjoQE31q2Q9sx24JMWMux9HIpbwP98WFIAJbxL5y3NS4qTxcoo8S2bxGUIHxy7k1o6CkpPSsdSrBG9BZkGrbHculAcL0qJdBBhnM7l4HazsiktX6pi0ICJ4ZmBRjeWgpA6GmsyT7nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qj2/Stso/FfRqAKu0rsPok0r4aqisxR6MdUU1GwBfaU=; b=jyTlRwBy4nQWwZ7UYrRJ+OidrFglrG258lPyYqPOhKLurmBQGE9x7MdjftDCuJVBToccfzsK96acKGIPRh8uUx8syuJT7qG+GKUztxE+5mgIPeEHNRgaA4ei5YL3aOzU7kUf8NLP5MH/4L+wB/YdKITJGe9xPEkkH6fPtJ65Hes+/Jo24B19Cu8eqwTq/PH+X0jEEa/XBHBL/l15HtKqkI7egB9dG/SaBa8qU6LXgcUcM1y76SV40MyOXla1UDW82xZwaZrblbLC3Lja0H81aqwG1K1qPa+29Ey8UFpuZLh/iehKFNpYa7s5cgEIy1rGHDybu2szavWGzr7ePFPAAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qj2/Stso/FfRqAKu0rsPok0r4aqisxR6MdUU1GwBfaU=; b=YstrpUL2mLCXzaCjSIXuiKSwqZYjm5ivTFTqsALONJdBMk/LQlV1Vj4Lx68wmwgASLj7Pn41I4z9vYom+eE/gfOmidZkRialyFAY0h6FL6XJM8uTVZY2rAJRv9+F7E117JgVXB08r4xm+vaQJu5hdFlvU9cbxhV1iID9eT2Kf5k= Received: from VE1P194MB0942.EURP194.PROD.OUTLOOK.COM (2603:10a6:800:16b::12) by VE1P194MB0831.EURP194.PROD.OUTLOOK.COM (2603:10a6:800:14b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Wed, 13 May 2020 11:09:26 +0000 Received: from VE1P194MB0942.EURP194.PROD.OUTLOOK.COM ([fe80::2d52:9901:9699:2b3b]) by VE1P194MB0942.EURP194.PROD.OUTLOOK.COM ([fe80::2d52:9901:9699:2b3b%9]) with mapi id 15.20.3000.016; Wed, 13 May 2020 11:09:26 +0000 From: Marc Groeneweg To: Tim Wicinski , dnsop CC: dnsop-chairs Thread-Topic: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones Thread-Index: AQHWJ7uxvOtLPjHmSE+3NXgVUshdb6il//yA Date: Wed, 13 May 2020 11:09:26 +0000 Message-ID: <6E8C4D59-4469-4396-85EA-2B84A4566760@sidn.nl> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sidn.nl; x-originating-ip: [77.249.32.150] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3e5e2f8-1f5f-4859-f3ba-08d7f72e19a1 x-ms-traffictypediagnostic: VE1P194MB0831: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e/qs9Bd7oNOIhBusdxIqvBDNpM9P943ItsgNBxMTRDft0foaUN4ORNGBnutEgbKylbkrMWmEK2DVbnhcXoxyZSaw2IXBQ39k5hu8t8TYUWYEDFbvquUYcaS1omYOhI4HEpYlPMbvGnxq0fCwfZE9DdiCrqj4AcV2ULGMPyIOnJpTx3UzbxVNFrWvWUSyTD5UqDad92OrBFkBqtbcLgj0JztxinJ0dOc9eeXj+b3AsTkReeLq47XNfHgEvqF8fwnAJCG4XgiqXU+FUUjgcfEoRg6iav1ZVjEkjO+ZWoZgrmRRMa+NuNyQuKmj+vVp6iwrq6gYa2g7han4ZpPaeP54Vze1p18F1jVBTE6CNuCn1nOUoB/FsrqIIxrOGstL10NHMrXDMdZMkbcHuAIZ9dpFlcUHrzMcTlNA2grqetyYq9TR4F2ggdzQUPO6pjSen4sd3se+xfGQXv/Z+qHS1edLxDNgW/39mxlAnocEm59QeU4rZibVz6MzEIToMkoP9sSUDFLK4Xtr9NTF2qzVEQq320uhuBvo1GdfO4KqTtdDkwio6s5kuLVgDJtf6T0qQ5NbBdUzNzAWIvPe16RmbFWb7VSOVGUCdw0CAEYjjHgDp9c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1P194MB0942.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39840400004)(376002)(366004)(346002)(396003)(136003)(33430700001)(66946007)(8936002)(36756003)(5660300002)(66476007)(86362001)(2616005)(44832011)(6486002)(33656002)(4326008)(966005)(110136005)(6506007)(186003)(91956017)(53546011)(66556008)(6512007)(26005)(66446008)(64756008)(76116006)(99936003)(66616009)(33440700001)(8676002)(4744005)(2906002)(316002)(166002)(478600001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: OqPgBoNJSnOerCWMlbSGTnvdWaRV0x6B+YhNn/dX95f6chrIWjD684FiGKNO+sOVibOG7ccGUtTqX3HoxaLx5jBIzbqCrVIkL0bkB3qW6i0ny0s9UW8V2PXnnAgMb+o2qdomMrJjLJVcwk3mweU59CFL55XfYAb1wfheToXZDHIKXZcN3Z/kd9efz8YWAOXUf9IC4kicqDsy9aNj6qSWTIVcaySdae8qUwDQceqVtrffeQfENe9xysmRhFyPv4bB6FcKVC1P2lSn3W6gdxsoQ3FW/IGDh9lDyr+TcHNZZ4DE3rI92vIjXve4iuaKjN/uK0tuzaeeOGbbrTeE958wrsZcqeiGEkTo6UkycI+THvydV/eofAuWKLbszUnpTpaS9Sbv1HQSc8nIzNTQW2bgxbZlIhAnNmUOR1cPeQtqbu1cbmjljwJlo/QhDRdYf4wMS6w2QEuQipjb70Cqo3fCoaGlApXcuBxpXUp8/dB94M5hsAqB6gnP3BNWd4uAk8ER x-ms-exchange-transport-forked: True Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3672220166_1320061290" MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: d3e5e2f8-1f5f-4859-f3ba-08d7f72e19a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 11:09:26.5431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Uo1Ksx4EtRURFteQERNjrMdzc8hfRZDq11N5K9kgkB3edYXkLCrlm0oNxXd6vP+372ODr+aIUPgqOGCD6tpAfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1P194MB0831 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 11:09:32 -0000 --B_3672220166_1320061290 Content-type: multipart/alternative; boundary="B_3672220165_124043624" --B_3672220165_124043624 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi, I support adoption and will review it. Regards, Marc From: DNSOP on behalf of Tim Wicinski Date: Monday, 11 May 2020 at 19:43 To: dnsop Cc: dnsop-chairs Subject: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 25 May 2020 Thanks, tim wicinski DNSOP co-chair --B_3672220165_124043624 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

I support adoption and will review it.

 =

Regards,

Marc

 

From: DNSOP <dnsop-bounces@ietf.org> on behalf of Ti= m Wicinski <tjw.ietf@gmail.com>
Date: Monday, 11 May 2020 at= 19:43
To: dnsop <dnsop@ietf.org>
Cc: dnsop-chairs= <dnsop-chairs@ietf.org>
Subject: [DNSOP] Call for Adoption:= draft-toorop-dnsop-dns-catalog-zones

 


All,
As we stated in the meeting and in our chairs actions, we're going to run<= br>regular call for adoptions over next few months.  
We are looking= for *explicit* support for adoption.


This starts a Call for Adop= tion for draft-toorop-dnsop-dns-catalog-zones

The draft is available = here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-z= ones/

Please review this draft to see if you think it is suitable= for adoption
by DNSOP, and comments to the list, clearly stating your vi= ew.

Please also indicate if you are willing to contribute text, revie= w, etc.

This call for adoption ends: 25 May 2020

Thanks,
ti= m wicinski
DNSOP co-chair


--B_3672220165_124043624-- --B_3672220166_1320061290 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIISWgYJKoZIhvcNAQcCoIISSzCCEkcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg8LMIIGSDCCBTCgAwIBAgIQASRff3Zhe4I6JwROqUifPTANBgkqhkiG9w0BAQsFADBp MQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVy ZGFtMQ8wDQYDVQQKEwZURVJFTkExHTAbBgNVBAMTFFRFUkVOQSBQZXJzb25hbCBDQSAzMB4X DTE5MDgxOTAwMDAwMFoXDTIxMDgxOTEyMDAwMFowfjELMAkGA1UEBhMCTkwxDzANBgNVBAcT BkFybmhlbTE3MDUGA1UEChMuU3RpY2h0aW5nIEludGVybmV0IERvbWVpbnJlZ2lzdHJhdGll IE5lZGVybGFuZDEMMAoGA1UECxMDSUNUMRcwFQYDVQQDEw5NYXJjIEdyb2VuZXdlZzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMtHtx7uX77izyjQFNvlTvAGk/rYkXWT5z/P kZ5zIgg8/e7Qyvp7C16pnM0swLj+0jtrDXa/QA4gFFwslpDzxFWnn9o05dW0Sea171sc5p/u wRDVrMhkiCt2Wy4WQNaZ9dnt2FyqUAknfw5Cq5xJdoCVdzcyLuaOh143pRFKqiAWRfXJsHVG JJ9lGRpLZdrPgha90gJ+ERfZ6rqKdOmdqBrqjkaCvh1gsm0xk3JMLqUNn6hP56qlQFke65O/ KlE2IzrCvCwIJVo2HrLe2dmR5dR5JykCmLSGDho0Ps3JnEkmlXwwTHSRGxSKVHPPnWiYuTIn /PYkBd20i4rNEUkexakyjmdj1YMTCIG7VJ8iULY4L6TKUVtzCc6UXpwXS/qJieAOv0F6x5EO DvVJA89UMxoAQi9RY8UD4K/qxhgd0198mAxOyuc39Mnl7ewe/xJa7hQfALtRBA4F2o4LSgF0 iGQsbic5rw8i4yOW2PFVuENClSgRBlblbju6FVrsL/mpGfLY5YTfY61HHLsuIjzYTwBLgV4v g5T5G5STAQ6ZwoCjzmjZsth1EIBNduQHeQKezrfEFGm0f2/goVmxcXCbRGiwnLqunFapt+T9 9Qq7kn5fLhxlhVOTxcoG+F0VPYi4LdTctAdo5l5pFQg2jcZboI1+vwdzheYncfB6iLs8qX9h AgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBTwIelJd3Ofha4YO+hScBQG7ULuyjAdBgNVHQ4E FgQU471SPWo/Og8Y0s/FME/5Mhl69UUwDAYDVR0TAQH/BAIwADAhBgNVHREEGjAYgRZtYXJj Lmdyb2VuZXdlZ0BzaWRuLm5sMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2Ny bDMuZGlnaWNlcnQuY29tL1RFUkVOQVBlcnNvbmFsQ0EzLmNybDA0oDKgMIYuaHR0cDovL2Ny bDQuZGlnaWNlcnQuY29tL1RFUkVOQVBlcnNvbmFsQ0EzLmNybDBzBggrBgEFBQcBAQRnMGUw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTA9BggrBgEFBQcwAoYxaHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1RFUkVOQVBlcnNvbmFsQ0EzLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAiz4SXvCE4uh/TtO2NiCbY4GudVE6hsoOyh8d91nCGY6AQLXpVqumB+fK E3O/WkzBNMyolYyJVMEBvz7MrOXCnW6WGpBeleN07t6a4UiFfpbgJuCtd8iN1lAAhP6JIZH0 bg0Wupv4ul9sWRaaC9Rh1/fs83MuNWeMKeH8nEWdzPwoZxUjZhHgK8BeSu9GBwmJBdu+IkkE gIfnHT9uUjicuK0t2sDlJge0CBQYqZagnBYmb6IICHZZ11Xf5/OazjHS51bxijv+0bDdF3tl WaSQegGqcqRs2TNSHnP3wyZuWVbF4dmPrT7PBJ2+a4zI63jWpsIsRjkraIWxzzS/ykTGSDCC BQAwggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAw MFoXDTI0MTExODEyMDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxh bmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJF TkEgUGVyc29uYWwgQ0EgMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9V gvSlNHIUcmWbX9XqoGjYm4KJT1NinHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9 AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuTYGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw 4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm14DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslm OQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BT ATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwBQSsCAwEAAaOCAaYwggGiMBIGA1Ud EwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsGAQUFBwEBBG0wazAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2Fj ZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1 cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRw czovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEA OsIbK/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb 0kQQWratCbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVL YbbvsoAvl8hHraeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbga ftu3K9qR7IW1h5uvYqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo 7dqc/YrbuMZlHZuLVVfU1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCA7cwggKfoAMCAQIC EAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaU iKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08 qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7On g9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9Ay WqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spft qqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReui r/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm 2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338J PJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklb nwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrx EkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t 4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggMTMIIDDwIBATB9MGkxCzAJBgNVBAYTAk5MMRYw FAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRF UkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEAEkX392YXuCOicETqlInz0w DQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgEoOiRrTGizM5z7/zI23oBghSYBgh 3gv/5vQ9019qv2gwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MjAwNTEzMTEwOTI1WjANBgkqhkiG9w0BAQEFAASCAgA8h4ZIMdh3V1CNOboQwO0n2LxsHxLo 5ArDDHdIg4XvHLVBSdT3tFV5ivwynYvXgf2F0VMVBN5VZ2rTL6JFnEZY52/foHxcDLUT9qwJ 3V45tGLOBTDH/IlVwbiZBc6LsfuyWYTP+vmjdrp0JzSKJe5/2C87feESINSRAO1mVYf9UthT tZgux4h98/kfwo/DYeE9kOscgxmACheQ2F6RCLu1amEk/PNgyszwg8PyjYfs/j6mkgfgd3we FtbrhafIjtqyMHc0gKFEycIP7BQbwgjIJNe3w4dnZT5xJm35gzGi0T12t3B3QdgimLavBXpO j1IIllnPL6xVoo7rdBdW49FXKwtzKeArJiAuWaiLyisw8DdQVEEctmzhI19QpJrjzOWDCw7D wFDs4lHOhblgENb7AsU2rQZFs7xWD8RCyd434lxSPMUnKni5n0nfeSjGo1Ilk6zJu942ErH1 tNhZsbnL8kc0LbZS3q1mP6dpdVmi6RZhzBH3rye1tUabGUxdZuHfdziYc9zBm1OO1bSFWuLr DBXGBYfq5HqUhYdzKpDG3OfigYmwqT4DCMAHBg23CvPixuTFQpegAKG5s+kAPS5uyLnPcesM 43iEThyrOVw/GlhOVAyXdzVD+JcP5RJgOmNjc/+RCNdDVbS/pgeD7/HiFm9MG3hcVFmAsTdb +ivufQ== --B_3672220166_1320061290-- From nobody Wed May 13 05:27:51 2020 Return-Path: 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 06CE03A10CC for ; Wed, 13 May 2020 05:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EcjHW4yxwuUR for ; Wed, 13 May 2020 05:27:47 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 723B93A10C8 for ; Wed, 13 May 2020 05:27:47 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 8075C6A2CF; Wed, 13 May 2020 14:27:43 +0200 (CEST) Received: from plato (e82143.upc-e.chello.nl [213.93.82.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 5FDA73C0432; Wed, 13 May 2020 14:27:43 +0200 (CEST) Message-ID: From: Peter van Dijk To: dnsop@ietf.org Date: Wed, 13 May 2020 14:27:42 +0200 In-Reply-To: <20200512012430.31DC11908E69@ary.qy> References: <20200512012430.31DC11908E69@ary.qy> Organization: PowerDNS.COM B.V. Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:27:49 -0000 On Mon, 2020-05-11 at 21:24 -0400, John Levine wrote: > In article you write: > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and comments to the list, clearly stating your view. > > It doesn't seem like a bad idea but I'm wondering who's likely to > implement it, since that makes it much more interesting. co-author here :) PowerDNS has a PoC, external, implementation of a previous incarnation of this draft. We will certainly implement (inside or outside PowerDNS) this draft when the shape of things is sufficiently agreed on. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Wed May 13 05:50:03 2020 Return-Path: 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 119D43A10EC for ; Wed, 13 May 2020 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 PMCOZKfRFuPZ for ; Wed, 13 May 2020 05:49:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C2CC63A10E3 for ; Wed, 13 May 2020 05:49:56 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115] (unknown [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115]) by mail.nic.cz (Postfix) with ESMTPSA id 38B8613FC40; Wed, 13 May 2020 14:49:53 +0200 (CEST) To: Joe Abley Cc: DNSOP WG References: <87k11gjo9h.fsf@nic.cz> <161A989F-0485-40E3-910A-B06E1B8B160E@hopcount.ca> From: Ladislav Lhotka Autocrypt: addr=ladislav.lhotka@nic.cz; keydata= mQINBFhU5JIBEACmGIeLglGrwf6JBcNrcLoO19yAdKcH7V132STGHlhEAgmdzwclgVE7GN7y 5+1ySQ8jhDM80QSQ+XaXsSbHTQl23vcVvSfKNdme11kGEQ7kO/bTbUYxpRRa5dqDjLeEHhol WiNk6nUHqEAExbpEoITiO216Lwxh8gD2+39ZH/UVJgMHoZD1VmrxHSnp9b1SpmDWkbILRc93 u6lADieU67SG5vWqGaBgp8JQAVI3F+ZhcLXHQiQLPliePT3YKfvubWg9NIprts9fv2JAUywv NN4R5gg1oFegOXouzlBySiUNXndzJsj1JAcI4psGA9iGYBhgdILXg+2Kwkok9rrx1gWsqtmb lcFDiJRx52FUohHz9obZ9gkOd4NoV4jatjnu+9HKA8V2T5JUgTCgOWeI2yHoSNFJvKO0ygIg /5ccrB9iRdmJIiA2cAmu5MaHnKxAcQ7eaXqQN+JRcpFUH2ooFHKm0750U3aAZY3an5+a5Njh XddaDDX/7f0a68jaWuoKFn7Mqa2HhNnLJs2Nsq9quLdWEUh59wOgTrp2TZnkAFtG1MGa2dNz M3YX22+jwbnfv/U72fEu33juXfMLWfwzJEzQG47dnpmsArt8fM+atOvTSvkLQDNJkOSVZT8m NR5/OeIYfxhe3FUSrljRQBXN8ioVoiMtcCR8EKXCwCnja20vdQARAQABtChMYWRpc2xhdiBM aG90a2EgPGxhZGlzbGF2Lmxob3RrYUBuaWMuY3o+iQJUBBMBCgA+FiEEtr1TxpCtJF8Aid5X uPkrCKn3bGcFAl3k3q0CGwMFCQecs7wFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQuPkr CKn3bGeXZA/+IM3zgfkMwQ+rvYMEn1cHoYwA0j8iwGtQp6FQYO/Vj0d6Q07Q5/iUqM0UuniU HN6xC5APrPsxwyeSuJUW1zjGm6JD8U5WinbNJuBU/FMC7XyHgOwwXdlT1bLlhOYnvUrZx0bB QeMLnUinvTHLVFnpUCfFpyKRUKh3kkUJS5AXRz5ZgEqJUr79GSTg46dluXlz9mnPIkwluwYO ydlhtW/+s/xVuCIqRUdhhc30d8K5XB+smiYmHSzePjLGwsP1pHt1e8we57EFNvm7iiwXPCAI cy+PAtCxmq2zsIxsZxtZP4SWbRcj2Z16XTtT+hhNK6SWKhpDuacadpWChXpYc36xtuJ5Ll3C lZqa/6mDRcagJy016pQboW/4JIkFcFhu6ugNwvR1OBom04VPVBxqQRgazqpfkB0jSWWS4rwh l30kwDFW5eWcski3Ja5g2drj0YpUeEkMOQcToxLPXffI6dauKTMh7K6RF++LGCYxOukWt2r+ jk6/pB3rSVztAJDb4kc/EgE7yNwrVQOxkKHfk3rGCXkvijCgU3jS0k5g01/OwENxpEUk0Nln mlLJdb8Bju6Jp2y3ZX97+Szs2tH8M6Mpny213lFgc4EVCOFVtIPsyYfiR9On1IIdRqMx3mQC 5AV+3Wc0o3M7Ku0ZbuhkYLNIhlNrRjlxFRk12FpZwFwznY+5AQ0EWFTnYgEIAM6XJ37HGp7H nzztkWbCW+5zkLzff2LQh7yoH32CGJTK7vnQKOY+JKi16lR1qUDHOUtYfRj17jBNWaB0CY0k qkRWCDXG0pff8VT63Kg/DlS2LLbPQpO2NcjdMhPTTUadnKWeo7h6/mFF7VW4X2sm1NYeNWD5 VQxdPQUbnCJ4Pi23QZRJnBu2ycM9aXa7ERRvpN3i3mAc2UgkJWq4KGjI74cd7ytCsU0RN6RT S0sFE4zCB1r6nXqfHHiousATS6+3GnuIGTtaeR0nXHlIvl2AC91+hswsWaA7YB4dB2/GJ8PN L3d07gA6yR2DoZJZhAmtMUiUzap4jgf07UoTOY80MHkAEQEAAYkDcgQYAQoAJgIbAhYhBLa9 U8aQrSRfAIneV7j5Kwip92xnBQJcLzGrBQkHnLFJAUDAdCAEGQEKAB0WIQQ+THLKBBuTzVYa 3ozuYRDCyLOtngUCWFTnYgAKCRDuYRDCyLOtnhnlB/49PV5puyMGBJXY5XBdaPIKFfC5eBfy EOgMqDfJS9yhV7bhFRzzztX9Z7COod6mxmlogNaDFMk/yFH25DOe2tpjKs6sqa9bwyY3cOFw pp38VdeAq0FxF3qOhjKzF12RVQ4Ipu/ahzzQ6V5reia+onOghw+BrjOsPExJaDbiif5UqL/F yWvERlR46GGbFzK9gEvUo+52Wjx3t4hW2IMZKS58xvzkMkTQtxYHAM++jO7bH18wV603JJC3 mZxq9YKKFHVcxinp9l8yzVxfIjhiklednvb30lggY4VEG6X+BER/lcw1QgSDojjbHY72o+76 rBYZ+pSacY/idn5AkAEkQyxsCRC4+SsIqfdsZ1aAEACjuN1b73KNsdsNZuV/MSdmfC+LkoG2 +20kGWzHHiq1Owc4W3fDRohJThM5xyKt2RAcLZAqzfeef1AuoESTqqR6OheaF3u0HAa+U87E /dfjflBOsGZloNi/0/JcN2B8VJpXBwA55adA4YwNL/i8k/roIZ0Yh4wd8Bv8G4exrjvPZPCG klGNBvIJomaqgb9YDvdN22CW3f0zoCwdTX+XV7YL6IQsZroRViLWZv12UCKO1kVop8IMQolx XGbo4kVkqtVx0A4O+ZqCiG819QGZIAtaKSG6aK1xWxNg16ClbEoCEglPeLiOr1ttibO6emuK 4w+4vA5nu+q5niUZ611f/9OtnNO6w/EZ9jRjiqBbo7esNkzal4LjwZUa0B3poWRz+7B++CYS F0c/qdfqjYmiN4IEbXnC0EFhwOYejTayy/H/nA0yGjxF7xA2Krom8B3YTaOnaZ2lVx0gtQK6 Ih7SSc842yRyBnMoVko8mzcHb/0urD2uWkPI5VfXLF9OJhfe3J1xswtqfOxFtf1cZv6fnQID 4gfsvRP8s8Wow5m3gp1HLSlxeZcc57nK8/nKWaTssdOf6doSw8kLWC5Dcwx2Ld15SsjkHeCO MtOaIxq+Er6vnvcepj76pZZJznS/bMriYPyyw0FIYmAPcnm3v5W+HZ339ktp+Kk3fNl3qJo6 C+Sjv7kBDQRYVOgGAQgA0GW5sWxqhcD9hxi/LQZ/hzPBgrpTvyIgxHrJN1HZ2BzdpNU7UlnC DVDzvAV2/1kEIiCdTYnnly0+PCHhyEdP45M9//oH7KYd/F/JSQwI+56mGP2O0fBBu9WStHws RraGfzGGZDV1XutvIz/qzpkBGpXGzA73Bi2Xye+/9JtHXmjhoXnItQLO38Hqnb5kXk79cSC4 TStPAKdrB/CMolcArT8j9eijIUOPMkWCGCeICv/hECpA5CZma2tplU80cKiOIYknFG8E+5Pr FlW962P7njIaahWSIObM2/C48uu5KAwgyDj6DA14cwc/4wfRsXZFjUMNpI0xer1iLQV5y1vi 6QARAQABiQI8BBgBCgAmAhsMFiEEtr1TxpCtJF8Aid5XuPkrCKn3bGcFAlwvMc8FCQecsMkA CgkQuPkrCKn3bGfkEg//alC3LNxnyH3tNy/OKQqOFJLUCidIm77DT/ZQfjLMAZezzCAq1Adf hVg7uV5a/dFdQdVDnjEz+SQ6/EzyqGashdAMnlBDwiqPe3MhB0L97VQwjNQa0wf1AsHdQCv8 i3e7U6RjlEmSC42dA+RjhrFOCZPtUTlCVDoSnY1S0kZOvEjhHvw901MPEINikZY4TBc18Xnk fbGQhglvI9NqBawlBKHyDGTAVJL7ld60iHsWt3prq+h48iFjc7x2JT39oBxT5Jhl3pg01QSC vu2Fg99vUuRr3u8tavnMKX4Vk3bujpHhuyOTSm0X37nwwu9DpMqkeUNvYR2RM+EuGGltonrN yrb5S21omN7fLDvRtdUBUOCFJLxZunTDLlkig/QuT+QlW7CG59Ussuu37HxgpiICCeeBDOaF bkZku43Qwt5cTtdJ8BkzYgvvoC7NegBn9N+U+Etrrvs09Slo11wlQx1F3sk9T9rjz1QrPM8j blxEgepm+W75VJ22z1qY/JnNElygR7KeTaeOY+iCn4wgDeC964AHMuGzG7aUg8P3zjgClL1T pFJwQUml880L6C+VuWPxuFIS18BPCYtLGlfQc5jp4dGN87ftenT13W70XiGXdrmIAFBF6Jjk 3huuDoRvdbPavAGdxu5QGdHeH0/GjfTxq7lRwgamoY0lw1LIB6LOzXo= Organization: CZ.NIC Message-ID: Date: Wed, 13 May 2020 14:49:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <161A989F-0485-40E3-910A-B06E1B8B160E@hopcount.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020708080509030409080306" X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] [Michelle Cotton via RT] [IANA #1168741] Early Review: draft-ietf-dnsop-iana-class-type-yang-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:50:01 -0000 This is a cryptographically signed message in MIME format. --------------ms020708080509030409080306 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 13. 05. 20 12:25, Joe Abley wrote: > Hi Lada, >=20 > On 13 May 2020, at 03:19, Ladislav Lhotka wrot= e: >=20 >> IANA did an early review of the draft in $subj. As you can see below, = Michelle proposes that the XSLT stylesheet be removed upon publication of= the RFC. >> >> I am personally not much in favour of doing so. First, I don't expect = that any future changes to the stylesheet will be necessary or even possi= ble: the rules for updating YANG modules (sec. 11 in RFC 7950) effectivel= y block any substantial changes. So, if it ever turned out that the way h= ow the registries are modelled in YANG needs to be change, it would most = likely require an entirely new YANG module. >> >> And, more importantly, the XSLT stylesheet is also kind of a formal re= cord of the consensus regarding the mapping of registry data to YANG (the= re are indeed a few other options how to do it). If a change was necessar= y (modulo errata), then it is IMO appropriate to run it through the IETF = process again. >> >> Any thoughts on this? >=20 > You seem to have addressed Michelle's concern, above. Did you give that= response to her as well as sending it to this list? What did she think? Yes, I did. Michelle's answer was: We can see what others think as the document goes through the process. During Last Call we will provide another review and comments. I will now submit a new revision addressing the (minor) issues that we have collected so far. Then the document could IMO proceed to WGLC. Lada >=20 >=20 > Joe >=20 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 --------------ms020708080509030409080306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BsEwgga9MIIEpaADAgECAgIClDANBgkqhkiG9w0BAQsFADCBhjELMAkGA1UEBhMCQ1oxDzAN BgNVBAcTBlByYWd1ZTEZMBcGA1UEChMQQ1ouTklDLCB6LnMucC5vLjExMC8GA1UEAxMoQ1ou TklDIFNIQTIgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEYMBYGCSqGSIb3DQEJARYJ Y2FAbmljLmN6MB4XDTE5MTAwNDEwNDYzMFoXDTIxMTAwMzEwNDYzMFowcDELMAkGA1UEBhMC Q1oxDzANBgNVBAcTBlByYWd1ZTEPMA0GA1UEChMGQ1ouTklDMRgwFgYDVQQDEw9MYWRpc2xh diBMaG90a2ExJTAjBgkqhkiG9w0BCQEWFmxhZGlzbGF2Lmxob3RrYUBuaWMuY3owggIiMA0G CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDb1ymAkFE5Upp9SplW9Hvz6pph245Xvy1YN/Vk mEO9hkW+RcneEWsGW4B0zKDUPOqQpcf4vOm5VEoHoyCvnP0MoJbDEsjmvVrX1ur3kPI1+URq uIHjguh1vscrJpKvZGqb4m5R8uAL57YM93r/RqD5neEdqCJZ4f61b1b7GrjSqNpHLyRFgVE8 GY3Kg1SWOYTT1kWF23bZB1k2gpuSlqjqfaxg51svZj6rY8CkAstOZw//D1QKPqQHAttpCtYZ 9mgX+AN4Xb3h17CcKbFQPORtGvDe6Rrgt85n6k1Yof+NvdrhMspgi5KOszglN5nsmFN4PvvF C7iI4mORePJhgcK9sC40K88olYYlXlq/KH8UOhIgbu2S/ulkBw9Q6F4EgFi+XG8tG3sDB0Dy tuq06HbfSvFK/o1PjruT6qeeeF4xNwpobysu8i0HUdNQVPU0vVsxxX9PwTdnlFGFaDWuNxlE I+5kDswSrd00cAY5+1LZ21epK2GajcJqRJKrfTqdw+5vqhXQnJq9CRjsZ0lLRKhgxRFaNjdG So8gnJG9Ki1qb7I7p0ROgwXjygNoI023KbGLACdsVT9ktufaPpIF7uBSyMXBo+GlmUbsIWY7 Vlnw43Ngct8QvnWBfL4acmqcMHSoHrs0S/5uUhUdNDP6Zx5LGb8Kv4ctcZiv6gSLX0+gvQID AQABo4IBSDCCAUQwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwHQYDVR0OBBYEFP6x 5mU0PL6AOeC219Ceig0GRPHlMIG7BgNVHSMEgbMwgbCAFM8SUF6TH18JXhePFldBep95coS4 oYGMpIGJMIGGMQswCQYDVQQGEwJDWjEPMA0GA1UEBxMGUHJhZ3VlMRkwFwYDVQQKExBDWi5O SUMsIHoucy5wLm8uMTEwLwYDVQQDEyhDWi5OSUMgU0hBMiBSb290IENlcnRpZmljYXRpb24g QXV0aG9yaXR5MRgwFgYJKoZIhvcNAQkBFgljYUBuaWMuY3qCCQCcbURrLzYp3zAUBgNVHRIE DTALgQljYUBuaWMuY3owIQYDVR0RBBowGIEWbGFkaXNsYXYubGhvdGthQG5pYy5jejAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAI/2k2oESGN5CXKLtWDw7y606g+XBcp2 ZWBtpTYZUw1CyKlUjtrDcqQ+LuK6wVtaj/oNiXObk14DGhiXbDdXtTSFM9ev7vtoZMaVrUR4 LhB0eMLgEgrVmpcadgtsfZzxTojpR4PMtds4A/EFsXYJb+tInzwiZNGMBcgTgO9MswbpV9xS crZ6jiaCObdoAf+Eo/Wv2GAnu+Zr8tr3lRkCEG00BcDdvm17WVMRKvcOCjMtoSp1YyXytmP5 haK5qb2pT77rK0bqqVEy4M1HzvViCKmRdmX4dD3jC2OtlZm9v/lm6Ys12MwidQfScqp57E8b lqoDdko3oyjmDYCrlxaXxYGbzLbuFQWs3y7BMSMGU/xTAhwVIqmoCDCgfI1+sKzN4sjqYOFx JzQ4rDATlziaUdoYvYPyhSBof4t3FDTqwXCkur8YDtfjA0dCUI5hEALQ7RzDR5H9dbNkQOZ3 HcvY4Rq9fUO2278wRd0Uy1255ztAmIr9cmU2qEgB2RksHXsL9MEgEdAMX4RbKt9FXpfcfLxw QryWU7/zawa/uVmi4OYuhtqLKs8TV8bsXVsSTacci+3ko4d/x6iRTk/Qm5ft24+evxXKvKnE IXbxpC9IapFp7Tvba/JTkhdu3NeNEEfOXyz6hwLqGfT+fmoYQvUxRfY634NfLGGvySiJohE6 SRPcMYIE+DCCBPQCAQEwgY0wgYYxCzAJBgNVBAYTAkNaMQ8wDQYDVQQHEwZQcmFndWUxGTAX BgNVBAoTEENaLk5JQywgei5zLnAuby4xMTAvBgNVBAMTKENaLk5JQyBTSEEyIFJvb3QgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkxGDAWBgkqhkiG9w0BCQEWCWNhQG5pYy5jegICApQwDQYJ YIZIAWUDBAIDBQCgggI7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTIwMDUxMzEyNDk1MlowTwYJKoZIhvcNAQkEMUIEQM0JtWFEMPsed/VWrembpybIqZp+ Rb4nqgxQXzJEOJv47HncHFmaXSL1mgQsUkZlABFSyMILlhhvpP15Z5lNjhAwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBngYJKwYB BAGCNxAEMYGQMIGNMIGGMQswCQYDVQQGEwJDWjEPMA0GA1UEBxMGUHJhZ3VlMRkwFwYDVQQK ExBDWi5OSUMsIHoucy5wLm8uMTEwLwYDVQQDEyhDWi5OSUMgU0hBMiBSb290IENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MRgwFgYJKoZIhvcNAQkBFgljYUBuaWMuY3oCAgKUMIGgBgsqhkiG 9w0BCRACCzGBkKCBjTCBhjELMAkGA1UEBhMCQ1oxDzANBgNVBAcTBlByYWd1ZTEZMBcGA1UE ChMQQ1ouTklDLCB6LnMucC5vLjExMC8GA1UEAxMoQ1ouTklDIFNIQTIgUm9vdCBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEYMBYGCSqGSIb3DQEJARYJY2FAbmljLmN6AgIClDANBgkqhkiG 9w0BAQEFAASCAgDS2834Okxz0GnpV0zZV/ajAYzykJqLqi3oolwkNUOt9iMcbKzRFi8PDTr0 2BKLWC9P9xGPy9zpgfH+olIVveifh5xf0MSwaHUPH4++vEH73kXU+AizmS1p8FQpzXLseSCx OwYa/0SCn49rpP8PqzRChX7QY1sLxKXh+o5t7Y0lUUBS14OQQoT4xQlG1hW3MGlJEMAczogf LiQlmJtLW8PYOKJhkocjyv8c8Yd0yjGb7ChMNG099D6gSkWQqvjImBwy3arRF2ztyUa+24Pi aSX+dmXGsD6Mb4i+J79TGdtbYh6CyNphq6CFGxO+uqeB+ZRw1Vzcsl2vrCP8l0YnpQSQIZAE uUjUFTRnCb3F4b50+yd34W7U651+V3nZtdqk4PHZw4JGbSZU4Hdk3IBG3AgH3R3PHNKohVTr jzmVHLV5Otnf8GVlqNd3OgLJeAmgQzHfZmYilRTIOS0V17j9P/oLLz0sS4TqktlBfRLL8U82 UR8hOmh+qXT9cpjHJfPo0FQ+oNW5bCnqEKpSFDJPqdauNzGa57nPUMnljoxfE6iSJJU9bX2I DZBr8nDihYfF4S6dSK1yMQWnqnJU0sXWc0pvT7ZxgbLTyBLtCCtQxG1aCHq0PEpIj9QuO8gT z6OhUmTQPZYuHdgZmmzpl+fZuXMKUOr9wK0O8vXuQ7mGHM/yLQAAAAAAAA== --------------ms020708080509030409080306-- From nobody Wed May 13 08:32:00 2020 Return-Path: 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 C6A243A0FA4 for ; Wed, 13 May 2020 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.797, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Y9ZplrCYkVd5 for ; Wed, 13 May 2020 08:31:57 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 13B663A0E49 for ; Wed, 13 May 2020 08:31:57 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id e2so14557202eje.13 for ; Wed, 13 May 2020 08:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2/eg8+EzotLZMuYbav9OQV0IvSsuiSOPNVS2VSfwdWk=; b=C7VDwz0MU3vkR2Jp5P6uMKpEy9J/IZTf47ALyFQORR8hmdXULZmQ1ym6Xs5pcOqcit tGlw+p3AKlEvS7Q6cSEH6q1c3uzqlCrq0vKd6FSTcrXAIhh+xTrhUekRxWOXzJ+vPux3 GlaBeLlCctRDRJYuntFv7QtiOOHD7n9YsNzmOruPqAcfsKHelVnZRcadr4ODZid+md4D H5lZO+UEjWG5pVSUCypQqtSkmJ4VoZhv4pAcnTJ/EV+x6hEfK6U9ruWPDxmiM5+aJA5L xKTkrLjFbAkW2T2hvNPIu3BOC/vOzmf79vTKzjKnWxCBCes90Bk7MbBTs3wlpw9i1oAF iMbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2/eg8+EzotLZMuYbav9OQV0IvSsuiSOPNVS2VSfwdWk=; b=dMtdN4wsAKDWJh4TzPc7UVPsbgcN072rGL9qYc5vlAaefmVYlszEj5mvNdvJ4qnv/F 3efowyK0qWz+X+REDeCpa0P06WMBgQPuwzmiHLJviAv6qSEjezJ8xr6XRWf4eD2rJtOO vxj4AwhbDSxTQcicZH6uw6Jw/l0khMamKFHvmTso6dEq7xiJR/YNrKaTW7hwt1i2kgNV w/o/Bx7ZSm6m4L0yTod273vIqDeiIum+D1nrBrX7KZYnnzUVtETNSGpfMUMRWnAJ+ZYJ j8tCSdDul1LX1ssSKwy+ecIs71KNcapkGBYrjQJDnVmRbo7EJ/ehRcTiOHHX5UgZ8LIi +LSw== X-Gm-Message-State: AGi0PuaYyMCxBPolcqb6zxLyjuP5LcDnkX9VuQWPEa6V2j2WrtlwaoBw Nm/HqKH0SRqng5hx06ud0d5OP2B62qXwAAVYdLA= X-Google-Smtp-Source: APiQypIFoRoyjTdkfliD2PQNjb78Le5fpXkGK0LE59n94LR5w5MmXhoGMqmcSgDqm2H5JUEpxbEzCvUx/dLC10Xq44s= X-Received: by 2002:a17:906:3da:: with SMTP id c26mr23385866eja.290.1589383915521; Wed, 13 May 2020 08:31:55 -0700 (PDT) MIME-Version: 1.0 References: <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> In-Reply-To: From: Shumon Huque Date: Wed, 13 May 2020 11:31:34 -0400 Message-ID: To: "Giovane C. M. Moura" Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="000000000000b24b9705a58947bb" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 15:31:59 -0000 --000000000000b24b9705a58947bb Content-Type: text/plain; charset="UTF-8" On Mon, May 11, 2020 at 9:00 AM Giovane C. M. Moura wrote: > > >> Do you plan to maintain the parent/child disjoint NS > >> domain (marigliano.xyz ) going forward? And what > >> about the test > >> domains for other types of misconfigurations? > > > > Great idea. Let me look into this, will get back to with that. > > > Done. Check http://superdns.nl :) > > Marco and I (mostly Marco, I've got say) set up this website and all the > delegations/records that replicates the setup of the paper. > Thanks Giovane (and Marco)! Looks pretty good at first glance. A few tangential questions though: The HTTPS site goes to a different and mostly empty page - and Chrome doesn't like the certificate because it has a wildcard Subject CN. Are you planning to fix that? I know DNSSEC is likely not the focus of your experiment, but the zones do seem to be signed - but with algorithm 16 (Ed448), which not a lot of resolvers or debugging tools support yet. Any reason you didn't choose a more widely supported algorithm? We did under a diff domain for sake of simplicity for us and differently > from the paper, we create 4 delegations, each one corresponding to one > of the scenarios (in the paper we change the NS configurations in > between experiments, we want a static setup here for folks to test). > > Hope it helps and if you need any help, let me know. > > /giovane > > ps: Raffaele, the first author of our paper, will present the study on > RIPE80 on Tuesday's plenary: > https://ripe80.ripe.net/programme/meeting-plan/plenary/#tue4 , in case > you want to check it out > Thanks for the pointer. I missed it, but will try to view the recording soon. Shumon. --000000000000b24b9705a58947bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 11, 2020 at 9:00 AM Giovane C= . M. Moura <giovane.moura=3D= 40sidn.nl@dmarc.ietf.org> wrote:

>>=C2=A0 Do you plan to maintain the parent/child disjoint NS=C2=A0 >> domain (marigliano.xyz <http://marigliano.xyz>) going forw= ard? And what
>> about the test
>> domains for other types of misconfigurations?
>
> Great idea. Let me look into this, will get back to with that.


Done. Check http://superdns.nl :)

Marco and I (mostly Marco, I've got say) set up this website and all th= e
delegations/records that replicates the setup of the paper.

Thanks Giovane (and Marco)!

L= ooks pretty good at first glance.

A few tangential= questions though:

The HTTPS site goes to a differ= ent and mostly empty page - and
Chrome doesn't like the certi= ficate because it has a wildcard Subject
CN. Are you planning to = fix that?

I know DNSSEC is likely not the focus of= your experiment, but the
zones do seem to be signed - but with a= lgorithm 16 (Ed448), which
not a lot of resolvers or debugging to= ols support yet. Any reason you
didn't choose a more widely s= upported algorithm?

We did under a diff domain for sake of simplicity for us and differently from the paper, we create 4 delegations, each one corresponding to one
of the scenarios (in the paper we change the NS configurations in
between experiments, we want a static setup here for folks to test).

Hope it helps and if you need any help, let me know.

/giovane

ps: Raffaele, the first author of our paper, will present the study on
RIPE80 on Tuesday's plenary:
https://ripe80.ripe.net/programme/meetin= g-plan/plenary/#tue4 , in case
you want to check it out

Thanks for the= pointer. I missed it, but will try to view the recording soon.
<= br>
Shumon.

--000000000000b24b9705a58947bb-- From nobody Wed May 13 13:31:50 2020 Return-Path: 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 CA6233A097C for ; Wed, 13 May 2020 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.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 rFJsFyeBdVbR for ; Wed, 13 May 2020 13:31:41 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 DFCEE3A097F for ; Wed, 13 May 2020 13:31:37 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id c21so674237lfb.3 for ; Wed, 13 May 2020 13:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fpV+EBeXoDe8NoECnqjddOnBlSa1ocRjPsmfiDSScBg=; b=TBllmgm873WOPftsfi+qLcN8rShwndXN+eVw2NSSuw2q7g6ZaiwLp5p8wY7RPsFP3D 1mMAvWZDbL03K4nUG7j/MuCoe1R4DzBOuImJyCyhEWgJDOmy86coWkGdqLA5V78M0DIC JVYgRTxTu+0OqPQ1Ay/718dUSzWt34dFQwl4DQFn+SymA9NWZCuWFND8iCnld23ToDVI QQ9Z0VXlhK5VGrK9QyVuoq9lZ6uWmvquv8hK86f9qNk+25R3jdvB25dAOD4snyXVFhDU bFgpkFX2WGH0f+C8dJfCDxNX8LFKMPvviHBp33wovDWXLXeaE0M0JvyVkdo1E85qmBsh j+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fpV+EBeXoDe8NoECnqjddOnBlSa1ocRjPsmfiDSScBg=; b=eY2upJzQr4ydPq0i/cWBCv/ghYH2A21xApcjBItAhfLPkDYiBXjdZUIyP1ch1VlaoN SCXUJqzy2phOnY5sfvY8NiSwED+gdkI6qKaX3M/v1YyfGBK7B6kd5LxnVb52+GqazLf8 dJ8SH47/g606ggQ6/znmrwZCH6wtA7QMTEpUQ+Vntld+8gQSgCUZ+zoGl804UtrvKhAP jRGAu95Ufw8w0SAQH1qFR5kJMCowo/6PpJyesw+SwC3RraINSLQcWuztz9NijPG4bu8S lsiuoMz2PFhb4n97LJF+ldqrbrRQ3Sia82S1D4gYERQGlY1jhhKSMgGH6klY0bOF62sL 2/+Q== X-Gm-Message-State: AOAM533rEvVOBMwHAVnXRpNnId83DmYV1PaZuqCI2q/BQWQXQ7aS7ldl NSUQ2V3l8uCJbtU1KRswG1G68ooBQGq6FIxs19dnIg== X-Google-Smtp-Source: ABdhPJxs9mAkz1YbDtbsJu19Ajy2GtS1f1DUze2arGpGD6VyuKM4GferwJb35Vry6gTbrbs3f3qJrPOJYPA0bwYGMGc= X-Received: by 2002:ac2:57cd:: with SMTP id k13mr823390lfo.104.1589401895772; Wed, 13 May 2020 13:31:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Pounsett Date: Wed, 13 May 2020 16:31:27 -0400 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000674ce005a58d7752" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 20:31:49 -0000 --000000000000674ce005a58d7752 Content-Type: text/plain; charset="UTF-8" On Mon, 11 May 2020 at 13:42, Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > I support adoption, and will review the draft. --000000000000674ce005a58d7752 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 11 May 2020 at 13:42, Tim Wic= inski <tjw.ietf@gmail.com> = wrote:

All,

As we stated = in the meeting and in our chairs actions, we're going to run
regular= call for adoptions over next few months. =C2=A0
We are looking for *exp= licit* support for adoption.


This starts a Call for Adoption for= draft-toorop-dnsop-dns-catalog-zones

The draft is available here: <= a href=3D"https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-z= ones/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-toorop-dnso= p-dns-catalog-zones/


I = support adoption, and will review the draft.=C2=A0
--000000000000674ce005a58d7752-- From nobody Wed May 13 19:44:01 2020 Return-Path: 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 5F88C3A092E for ; Wed, 13 May 2020 19:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=g001.emailsrvr.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 58Ag_DI28anP for ; Wed, 13 May 2020 19:43:57 -0700 (PDT) Received: from smtp119.ord1c.emailsrvr.com (smtp119.ord1c.emailsrvr.com [108.166.43.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9BC3A092A for ; Wed, 13 May 2020 19:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1589424236; bh=iQOztjhyhvWHWJaoEwX5J3WTkubHtuX9rRofJWOX9R4=; h=From:Subject:Date:To:From; b=eHSmfx4A2lSQaCVHg2gMFds+XYwf7xA28eHmvWO0ZORLN90QHEih3EI7dAqxKUlRs nQXSfc50GUR5M1OgDG6j93icDz3z2IH2fMkFjnk2gK6zRr5qvgpy0PoA9XUM+R7+7b ZcmGsvNc5UxL7Eum6dO/uQabsjM5sLUINIW9Uteo= X-Auth-ID: ogud@ogud.com Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 2277F2013C; Wed, 13 May 2020 22:43:56 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.6.34] ([UNAVAILABLE]. [96.231.186.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 13 May 2020 22:43:56 -0400 From: Olafur Gudmundsson Message-Id: <8DF32635-8A42-40C9-8B04-DD04107AD96A@ogud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6938147A-7A90-4826-99BF-EA33C408802D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 13 May 2020 22:43:54 -0400 In-Reply-To: Cc: dnsop , dnsop-chairs To: Tim WIcinski References: <02472848-7B62-4613-AE9B-218C2709E397@ogud.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Classification-ID: f03c8897-d85a-483e-8377-353c4e2b000f-1-1 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 02:43:59 -0000 --Apple-Mail=_6938147A-7A90-4826-99BF-EA33C408802D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 12, 2020, at 9:43 PM, Tim Wicinski wrote: >=20 > Olafur >=20 > Currently it's marked Standards Track, but I was working on the idea = that the working group would make=20 > that decision as the document works toward Working Group Last Call. =20= >=20 Tim=20 Thanks for the clarification,=20 > I was reserving judgement until there was implementations, = interoperability, etc.=20 >=20 Fair point=20 > Please feel free to register any thoughts on publication status at = this time as well. >=20 > Hope that helps >=20 This draft is a result of a failure by the DNS community to create any = kind of framework to manage distributed name server clusters.=20 The draft is a =E2=80=9Chack=E2=80=9D of the best kind it is low impact = but does the work for a sub-set of usage cases that a real control plane = should have.=20 I think making this document a standard would be a mistake. =20 I think NOT publishing this document at all would be a BAD thing.=20 I support adoption and will review and continue to agrue against = standards track.=20 > tim >=20 Olafur >=20 > On Tue, May 12, 2020 at 9:35 PM Olafur Gudmundsson > wrote: >=20 >=20 >> On May 11, 2020, at 1:41 PM, Tim Wicinski > wrote: >>=20 >>=20 >> All, >>=20 >> As we stated in the meeting and in our chairs actions, we're going to = run >> regular call for adoptions over next few months. =20 >> We are looking for *explicit* support for adoption. >>=20 >>=20 >> This starts a Call for Adoption for = draft-toorop-dnsop-dns-catalog-zones >>=20 >> The draft is available here: = https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ = >>=20 >> Please review this draft to see if you think it is suitable for = adoption >> by DNSOP, and comments to the list, clearly stating your view. >>=20 >> Please also indicate if you are willing to contribute text, review, = etc. >>=20 >> This call for adoption ends: 25 May 2020 >>=20 >=20 > Tim,=20 > a nit question:=20 > what is the intended publication status ?=20 > Experimental, Informational, Standard =20 >=20 > Thanks=20 > Olafur >=20 >> Thanks, >> tim wicinski >> DNSOP co-chair >>=20 >>=20 >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop = >=20 --Apple-Mail=_6938147A-7A90-4826-99BF-EA33C408802D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 12, 2020, at 9:43 PM, Tim Wicinski <tjw.ietf@gmail.com> = wrote:

Olafur

Currently it's marked = Standards Track, but I was working on the idea that the working group = would make 
that decision as the document works = toward Working Group Last Call.  

Tim 

Thanks for the clarification, 

I was reserving judgement until there = was implementations, interoperability, etc. 

Fair point 

Please feel free to register any = thoughts on publication status at this time as well.

Hope that helps


This = draft is a result of a failure by the DNS community to create any kind = of framework to manage distributed name server = clusters. 
The draft is a =E2=80=9Chack=E2=80=9D of the = best kind it is low impact but does the work for a sub-set of usage = cases that a real control plane should have. 

I think making this document a standard would be a = mistake.  
I think NOT publishing this document at all = would be a  BAD thing. 

I = support adoption and will review and continue to agrue against standards = track. 

tim


Olafur


On Tue, May 12, 2020 at 9:35 PM Olafur = Gudmundsson <ogud@ogud.com> wrote:


On May = 11, 2020, at 1:41 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote:


All,

As we stated in the meeting and in our chairs actions, we're = going to run
regular call for adoptions over next few = months.  
We are looking for *explicit* support for = adoption.


This starts a Call = for Adoption for draft-toorop-dnsop-dns-catalog-zones

The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog= -zones/

Please review this draft to see = if you think it is suitable for adoption
by DNSOP, and = comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, = review, etc.

This call for adoption ends: = 25 May 2020


Tim, 
a nit = question: 
what is the intended publication = status ? 
Experimental, Informational, = Standard  

Thanks 
Olafur

Thanks,
tim wicinski
DNSOP co-chair



_______________________________________________
DNSOP = mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


= --Apple-Mail=_6938147A-7A90-4826-99BF-EA33C408802D-- From nobody Wed May 13 22:48:58 2020 Return-Path: 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 4CD803A0B8A for ; Wed, 13 May 2020 22:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OCX4DcmYBszZ for ; Wed, 13 May 2020 22:48:54 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 987953A0B88 for ; Wed, 13 May 2020 22:48:54 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id i5so719596uaq.1 for ; Wed, 13 May 2020 22:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=o0scWCBdxJg0fMtrYxXcZBGaPPP2pmcOD7wX8bydu5s=; b=XmA+MsN0JsY6PE9obkI/Dn+X4tv4nRMRGor/82QdzVbB+slD7JCIw4n7YYfcqV7x+2 W1ktfNyxiNxAyQfyCvN5VAuuP10iD5iSKzLbex4A9NwEC1XgRu5G/DbKwc4+LHXYLrtU gn1991FnBylWRMZF+WO6//DiN0eWH8+97bu5ec82pWFdBzyW8H1E1NDzoO3dfA5GInWr 0wsD1PHqHELZIcSP/GESPaLhUum3YtcOlRSrKE4ircXg+ZztWvTPckz8jt4LGb8QxDcS Vm7bOyjsO0tdNbCg4dTZh/kM0Yt/keShnJvXg7B65HOiGXhMLXh9qWzodagrAUeAmDSN IwuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=o0scWCBdxJg0fMtrYxXcZBGaPPP2pmcOD7wX8bydu5s=; b=Yrdis3ubrSUlKtnHAvVG1irZjJTB1gTm8+K3gsCRAmwQP2vxUw9ps6O+kiPzMH4Q/c cFYgDnzFe61rbs0iWc1KBA0B9WNulpceG841Ciz2o8Ge/XWWjaF1mMvgxyDM+fO1ZjgL aLZdvFGDKKMEMlRnM7kO6Kk44OxDA3GjfdAvDTyA6xv7NYQowuAgnZ6D+S69zIcFkHpL LKisWnUeR6+7RfBNXUhRpiLajytgev5b7nz0UaRhPpnKHkzG4CCgJdpDjRrrJ6bGK+Oa ZRRKb9K7O0CqR8kbVXc8R7FKufHqNQKwWxD1oGrvs09cExocUdUgy6nO5CH9Xao7fNVD P8rA== X-Gm-Message-State: AOAM530ivmEb6GIqIyAshC7Yah9L0ZBcFWnlHGhWvOsmxeXKtfMaN5JE sJe3aQ9lMCrxutXY9VL5kFZNhAgsBMe9TyGkiUAEfyFvNvc= X-Google-Smtp-Source: ABdhPJxlOZTOmPkwPPe8ipenbAVYF4fmJGahf9BGclrBUyrJyE3IIwffMYmlMWbOQ4DJMyRJe5ZKzr7ue8qfB99Kwuo= X-Received: by 2002:ab0:2a8:: with SMTP id 37mr2590934uah.23.1589435332413; Wed, 13 May 2020 22:48:52 -0700 (PDT) MIME-Version: 1.0 References: <158871188730.7528.4018207019268407373@ietfa.amsl.com> In-Reply-To: <158871188730.7528.4018207019268407373@ietfa.amsl.com> From: Puneet Sood Date: Thu, 14 May 2020 01:48:39 -0400 Message-ID: To: IETF DNSOP WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 05:48:57 -0000 Google Public DNS is planning to implement this draft in responses from us (recursive resolver) to clients. *** Question: When can we expect to have an EDNS option code assigned for the EDE option? *** Request for clarification on Section 3. Extended DNS Error Processing The text in this section (and in the introduction) implies that a response with a NOERROR RCODE may contain an EDE option. "Receivers MUST be able to accept EDE codes and EXTRA-TEXT in all messages, including those with a NOERROR RCODE, but need not act on them" Scenario: Response has a NOERROR RCODE and contains some response RRs. If the client sent an EDE option and the server supports EDE, is the expectation that the server should always include the EDE option? If the server includes an EDE option in the response, what is the right EDE code to use? EDE code 0 [other] seems the closest but it still implies an error. Also the description for it suggests including EXTRA-TEXT which would not be useful. If the server does not include an EDE option in the response, the response looks A-OK to the client. However if the client is attempting to detect EDE option support on the server it might incorrectly assume the server does not support EDE. To simplify the NOERROR scenario, can we have a no error EDE code similar to the NOERROR RCODE? With this a server can include an EDE option in all responses to queries containing an EDE option. Thanks, Puneet On Tue, May 5, 2020 at 4:52 PM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Extended DNS Errors > Authors : Warren Kumari > Evan Hunt > Roy Arends > Wes Hardaker > David C Lawrence > Filename : draft-ietf-dnsop-extended-error-16.txt > Pages : 15 > Date : 2020-05-05 > > Abstract: > This document defines an extensible method to return additional > information about the cause of DNS errors. Though created primarily > to extend SERVFAIL to provide additional information about the cause > of DNS and DNSSEC failures, the Extended DNS Errors option defined in > this document allows all response types to contain extended error > information. Extended DNS Error information does not change the > processing of RCODEs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed May 13 23:09:45 2020 Return-Path: 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 CA4763A0BAB for ; Wed, 13 May 2020 23:09:43 -0700 (PDT) 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=unavailable 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 tK4rLHMKaOMm for ; Wed, 13 May 2020 23:09:41 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 73E393A0BA5 for ; Wed, 13 May 2020 23:09:41 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 49FF93AB005; Thu, 14 May 2020 06:09:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3DA6E160042; Thu, 14 May 2020 06:09:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 29503160066; Thu, 14 May 2020 06:09:41 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S20H4NW6PX2J; Thu, 14 May 2020 06:09:41 +0000 (UTC) Received: from [172.30.42.99] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 59700160042; Thu, 14 May 2020 06:09:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Mark Andrews In-Reply-To: Date: Thu, 14 May 2020 16:09:34 +1000 Cc: IETF DNSOP WG Content-Transfer-Encoding: quoted-printable Message-Id: <98FA896F-5034-40CE-8B25-15DA230FBBB8@isc.org> References: <158871188730.7528.4018207019268407373@ietfa.amsl.com> To: Puneet Sood X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 06:09:44 -0000 > On 14 May 2020, at 15:48, Puneet Sood = wrote: >=20 > Google Public DNS is planning to implement this draft in responses > from us (recursive resolver) to clients. >=20 > *** Question: When can we expect to have an EDNS option code assigned > for the EDE option? It=E2=80=99s already assigned. See the IANA registry. The value is 15. > *** Request for clarification on Section 3. Extended DNS Error = Processing > The text in this section (and in the introduction) implies that a > response with a NOERROR RCODE may contain an EDE option. > "Receivers MUST be able to accept EDE codes and EXTRA-TEXT in > all messages, including those with a NOERROR RCODE, but need not act > on them" >=20 > Scenario: Response has a NOERROR RCODE and contains some response RRs. > If the client sent an EDE option and the server supports EDE, is the > expectation that the server should always include the EDE option? No. While not explicitly specified a server would only include a EDE if it have something extended to report. There is also no requirement for there to be a EDE in the request before sending a EDE in a response. If EDE was expected to be in the request then there would have been a request format specified. All EDNS clients should handle unknown EDNS options in responses as that is a requirement of the base EDNS specification. > If the server includes an EDE option in the response, what is the > right EDE code to use? EDE code 0 [other] seems the closest but it > still implies an error. Also the description for it suggests including > EXTRA-TEXT which would not be useful. >=20 > If the server does not include an EDE option in the response, the > response looks A-OK to the client. However if the client is attempting > to detect EDE option support on the server it might incorrectly assume > the server does not support EDE. There is no reliable way to determine if a server supports EDE. There = is no requirement to return any given EDE. Which EDE return (if any) is up = to the server developer. > To simplify the NOERROR scenario, can we have a no error EDE code > similar to the NOERROR RCODE? With this a server can include an EDE > option in all responses to queries containing an EDE option. >=20 > Thanks, > Puneet >=20 >=20 > On Tue, May 5, 2020 at 4:52 PM wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Domain Name System Operations WG of = the IETF. >>=20 >> Title : Extended DNS Errors >> Authors : Warren Kumari >> Evan Hunt >> Roy Arends >> Wes Hardaker >> David C Lawrence >> Filename : draft-ietf-dnsop-extended-error-16.txt >> Pages : 15 >> Date : 2020-05-05 >>=20 >> Abstract: >> This document defines an extensible method to return additional >> information about the cause of DNS errors. Though created = primarily >> to extend SERVFAIL to provide additional information about the = cause >> of DNS and DNSSEC failures, the Extended DNS Errors option defined = in >> this document allows all response types to contain extended error >> information. Extended DNS Error information does not change the >> processing of RCODEs. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 >> = https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-extended-error-16 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 14 02:28:09 2020 Return-Path: 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 DBCF93A0845 for ; Thu, 14 May 2020 02:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.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 60XnmGCybPql for ; Thu, 14 May 2020 02:28:04 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 1E0543A0842 for ; Thu, 14 May 2020 02:28:03 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id m12so24524096wmc.0 for ; Thu, 14 May 2020 02:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=mIOknwrczSVt7GFYyEnuCDL/+a+mlMq+IsQqE+Zqn8E=; b=kehDuGuaTcLEGk5vUQGSNdeCHImeS3skbWS/YfyX+FuCLyXWBQqnLaOp6PiY1e+VXP G0aOMeNCDh1ihEJV6I7U6bfm/3wuFrCMMRW9LIfFSKNTcyCUF+VUUb689lYXC+Bqn46W f/JLKL0xdBy6Dp8kJJ75lu8tJeUPZ9FXAkEVOQG0QvTmVkqZLFBLp6L7xYJGMdCexOn2 XeQuDrkqRsTJNZepq6QJXXobDmYCNxKnZRbS4fzULP3s9CKmHA3hi7bPK/A10G3AThiR c8XTdlikAZUKg9WMMlwax5Cw+Fx8iIwyA4q7ZdgJSsa/jtt2vQWdgL2DgAEXniMrSZ+q vbFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=mIOknwrczSVt7GFYyEnuCDL/+a+mlMq+IsQqE+Zqn8E=; b=M6TVzcLzzEjKtwlKUZqscrl8mYgCYVgMuiNVSeSawps8SQKHbtQFMMeg1ixp/OYs8T ycK4b3NekyDjNoMvndh23I0uzCAKq159obTwNdjmKa6SgqTnCYO8llPgFrA9mkK0THE6 EvZGpHUrbpY/iTrDHqmFPllnk2N6ISeBrNsYTtqsU+w1Txoxu1pHKNXGMrbinJySjeNy PfGen8gfh2GRiJRZTm3EisJlorOTT3MdNQtfpJUnVjN9DzjpOCcgB7jNYcsy65EpotrE bzNZrfcZxFMvuDeqtNELuRZOXL2SpQ9G9nBQAarI6EvrSgPMgYs+h0omo+GrHzqzmqP+ WtCA== X-Gm-Message-State: AGi0PuarCmEQsMw+v+DnsvJ1aZ0vqGBCJ69JEZPS52IipP7KnB1GVV0u ltnN0shWhurrTRM+idFPBopH+g== X-Google-Smtp-Source: APiQypJx0EAIrbw9pXTha3NiGxffbCHLovzLlK6fMvhxYfTzKi9ixM26SyLnfiZJBla1cwldhsD4hQ== X-Received: by 2002:a1c:7714:: with SMTP id t20mr22868493wmi.132.1589448481926; Thu, 14 May 2020 02:28:01 -0700 (PDT) Received: from miek.nl (dhcp-077-251-206-012.chello.nl. [77.251.206.12]) by smtp.gmail.com with ESMTPSA id 7sm3212534wra.50.2020.05.14.02.27.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2020 02:28:00 -0700 (PDT) Date: Thu, 14 May 2020 11:27:57 +0200 From: Miek Gieben To: Olafur Gudmundsson Cc: Tim WIcinski , dnsop , dnsop-chairs Message-ID: <20200514092757.GC7693@miek.nl> Mail-Followup-To: Olafur Gudmundsson , Tim WIcinski , dnsop , dnsop-chairs References: <02472848-7B62-4613-AE9B-218C2709E397@ogud.com> <8DF32635-8A42-40C9-8B04-DD04107AD96A@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8DF32635-8A42-40C9-8B04-DD04107AD96A@ogud.com> Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 09:28:07 -0000 >I think making this document a standard would be a mistake. >I think NOT publishing this document at all would be a BAD thing. > >I support adoption and will review and continue to agrue against standards >track. +1 on what's said here. /Miek -- Miek Gieben From nobody Thu May 14 07:03:04 2020 Return-Path: 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 75C3B3A0A63 for ; Thu, 14 May 2020 07:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 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, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, 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=umich.edu 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 oBvGCJjWeTNE for ; Thu, 14 May 2020 07:02:59 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 81A383A0A3B for ; Thu, 14 May 2020 07:02:59 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id a9so2717133lfb.8 for ; Thu, 14 May 2020 07:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:from:date:message-id:subject:to; bh=4Kvsn16mA4xREPq2mH0nNWAeJr5yBjm/8e/NXXHMZJI=; b=dmLYi5uVIpQkPDldLN7blmZ599zY21aujWjeM4tWBleSlfNuPsP/7YK5vyAIdPlzA2 j/pZZb+tHGbBqRDb6qMX/t+IOdFsntAPO1UFYVaZnODEXx8A2+vx4uX0ci2vPW0kFgwA BbMpxK72uqQdusrcRAv4kdBHDitvbkfkyHjNW8cTZoNcghKpFAvuwe2Lu06MAUv6sViT d72QMUlM7cGWs2tT74dwoonu5iZQFNja2dzIc/qenZiX4uGvQ7c/GujesI/9fn4BQlso S9IspY2UdExm2JPeNJUC9nAyO8gMiB5Ldg+JfzDPFv2vQsMCTC+LOApV1n4RmuqfHcG5 /Mtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4Kvsn16mA4xREPq2mH0nNWAeJr5yBjm/8e/NXXHMZJI=; b=m3GD4+p4OCeIKP0I7VIHj+OPEAUX/BbeXSrm43sujkYCSuWgX9nDa44RhXeLhRKUyp EvDx0+pFPhTVXEEKcTbkLb9KX7pNgoVcgqqfsONxveK9lInmsxJBi0yp+gWWcOlXL4La R5CuOYG1mo9FjC2UIMWgamG/8xciuBJqV/qGNSb30jQN7FrXxZ4kt0B75c9lFp6w5gaE 5HPouJr71yIsu3bGXLwCzua/JpZiKVKITQPK8rEma9ivZ8z1SJWwTaWs6Kh+IkQVK41o mCWGXR5BelqnRNOSha6jEiqtt7RVoGeQltTUbpNwNq3VAGaCd5gLvqA4SvFHA7dzFONe tVvg== X-Gm-Message-State: AOAM530oG8db1LktF4p9xm77SbJi3Nt+bZ2tS/gNJdX+5+Y4bPPBnkRz mJ5cflwY1aEtPdDG8+4FLn+2kefnUeRlBlNvAvMm5P7UTmY= X-Google-Smtp-Source: ABdhPJzsl4fA8Ii1mwzVEbYtVOfpzXYrlEcMj/xcJlfDo2VwZIz8XFBPLWhq17P8On151ZCizRSpnq+VJUdqaHp6uyA= X-Received: by 2002:a19:84b:: with SMTP id 72mr3452937lfi.133.1589464976751; Thu, 14 May 2020 07:02:56 -0700 (PDT) MIME-Version: 1.0 From: Bob Harold Date: Thu, 14 May 2020 10:02:45 -0400 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary="00000000000052940d05a59c27e3" Archived-At: Subject: [DNSOP] DNSSEC validates even if expired? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:03:03 -0000 --00000000000052940d05a59c27e3 Content-Type: text/plain; charset="UTF-8" I am preparing to enable DNSSEC validation, so I am working on alerts for failed validations, so I can see whether they are user errors (that might need negative trust anchors or other exceptions) or actual attacks. I stumbled on "mff.cuni.cz" which has RRSIG records that expired 3 months ago, but my validating server still gives an answer and says that it is valid. Is that expected? BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) [hostmast@ns-umd-nsbs-1 named]$ delv mff.cuni.cz @127.0.0.1 ;; validating mff.cuni.cz/DNSKEY: verify failed due to bad signature (keyid=47500): RRSIG has expired ; fully validated mff.cuni.cz. 28546 IN A 195.113.27.221 mff.cuni.cz. 28546 IN RRSIG A 13 3 28800 20200611045052 20200512043705 47500 mff.cuni.cz. ZbW+RXOvA24E+Fb0Z/M3OfMJdFD9vdRKD8nhylZSfB0fkq236lohWHGu 4A54HrqasAPkUHJd/LcoN1+k6bkAqw== [hostmast@ns-umd-nsbs-1 named]$ dig mff.cuni.cz @127.0.0.1 +adflag ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> mff.cuni.cz @127.0.0.1 +adflag ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17300 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mff.cuni.cz. IN A ;; ANSWER SECTION: mff.cuni.cz. 28784 IN A 195.113.27.221 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 14 09:51:53 EDT 2020 ;; MSG SIZE rcvd: 56 -- Bob Harold --00000000000052940d05a59c27e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am preparing to enable DNSSEC validation, so I am workin= g on alerts for failed validations, so I can see whether they are user erro= rs (that might need negative trust anchors or other exceptions) or actual a= ttacks.

I stumbled on "mff.cuni.cz" which has RRSIG records that expired 3 months ago,= but my validating server still gives an answer and says that it is valid.<= /div>
Is that expected?

BIND 9.11.4-P2-RedHat-= 9.11.4-9.P2.el7 (Extended Support Version) <id:7107deb>

[hostmast@ns-umd-n= sbs-1 named]$ delv mff.cuni.cz =C2=A0 @<= a href=3D"http://127.0.0.1">127.0.0.1
;; validating mff.cuni.cz/DNSKEY: verify failed due to bad sign= ature (keyid=3D47500): RRSIG has expired
; fully validated
mff.cuni.cz. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A028546 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0A =C2=A0 =C2=A0 =C2=A0 195.113.27= .221
mff.cuni.cz. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A028546 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0RRSIG =C2=A0 A = 13 3 28800 20200611045052 20200512043705 47500 mff.cuni.cz. ZbW+RXOvA24E+Fb0Z/M3OfMJdFD9vdRKD8nhylZSfB0fkq236lohWHG= u 4A54HrqasAPkUHJd/LcoN1+k6bkAqw=3D=3D

[hostma= st@ns-umd-nsbs-1 named]$ dig mff.cuni.cz= @127.0.0.1 +adflag

; <<>&= gt; DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> mff.cuni.cz @127.0.0.1 += adflag
;; global options: +cmd
;; Got answer:
;; ->>HEADER&l= t;<- opcode: QUERY, status: NOERROR, id: 17300
;; flags: qr rd ra ad;= QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTI= ON:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mff.cuni.cz. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0A

;; ANSWE= R SECTION:
mff.cuni.cz. =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A028784 =C2=A0 IN =C2=A0 =C2=A0 =C2=A0A =C2=A0 = =C2=A0 =C2=A0 195.113.27.221

;; Query time: 0 msec
;; SERVER: 127= .0.0.1#53(127.0.0.1)
;; WHEN: Thu May 14 09:51:53 EDT 2020
;; MSG SIZ= E =C2=A0rcvd: 56

--
Bob Harold
--00000000000052940d05a59c27e3-- From nobody Thu May 14 07:25:13 2020 Return-Path: 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 A97143A0B15 for ; Thu, 14 May 2020 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org 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 i105CQTKiHnK for ; Thu, 14 May 2020 07:24:59 -0700 (PDT) Received: from jupiter.mukund.org (jupiter.mukund.org [IPv6:2a01:4f8:231:3f69::9e]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABEF3A0B05 for ; Thu, 14 May 2020 07:24:57 -0700 (PDT) Date: Thu, 14 May 2020 19:54:50 +0530 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1589466295; bh=IIQefmGmhRJGR9GkrLZK9R5hxAHY8flzR3iaKbQSFo8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S0R05JJwmCaLE3R6kwQpVjGhHNQBIGSbYI9JkWx1+B9IMdLENXGmZ1qR+HTr8oaTP w3RHJWuOtZgFy/Av5Vj4amoxH50OeBEsQUFtdYFbGjE4scoPgJxeJ2iwXx+olXHjNE FEP1mOOZ/Ej0ZJR/pKv4gsQJIQUDmuKcD/VjjC+U= From: Mukund Sivaraman To: Bob Harold Cc: IETF DNSOP WG Message-ID: <20200514142450.GA36078@jurassic.vpn.mukund.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] DNSSEC validates even if expired? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:25:10 -0000 Hi Bob On Thu, May 14, 2020 at 10:02:45AM -0400, Bob Harold wrote: > I am preparing to enable DNSSEC validation, so I am working on alerts for > failed validations, so I can see whether they are user errors (that might > need negative trust anchors or other exceptions) or actual attacks. > > I stumbled on "mff.cuni.cz" which has RRSIG records that expired 3 months > ago, but my validating server still gives an answer and says that it is > valid. > Is that expected? > > BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) > > > [hostmast@ns-umd-nsbs-1 named]$ delv mff.cuni.cz @127.0.0.1 > ;; validating mff.cuni.cz/DNSKEY: verify failed due to bad signature > (keyid=47500): RRSIG has expired > ; fully validated > mff.cuni.cz. 28546 IN A 195.113.27.221 > mff.cuni.cz. 28546 IN RRSIG A 13 3 28800 20200611045052 > 20200512043705 47500 mff.cuni.cz. > ZbW+RXOvA24E+Fb0Z/M3OfMJdFD9vdRKD8nhylZSfB0fkq236lohWHGu > 4A54HrqasAPkUHJd/LcoN1+k6bkAqw== delv is complaining a signature for the DNSKEY set has expired. There is a signature that has not expired though: [muks@jurassic ~]$ dig +rrcomments +dnssec mff.cuni.cz dnskey ; <<>> DiG 1.1.1.20200413085522.7eb91c6988 <<>> +rrcomments +dnssec mff.cuni.cz dnskey ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55595 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mff.cuni.cz. IN DNSKEY ;; ANSWER SECTION: mff.cuni.cz. 28291 IN DNSKEY 257 3 13 1PMTgkDSUJEO8PbtFEtJ6sqtBUwlqv5yWMAQpedPoJtvJ9Oxoen3OJoF xEnZCFBCouNsR58PYdzYDowWEQAJVw== ; KSK; alg = ECDSAP256SHA256 ; key id = 47500 mff.cuni.cz. 28291 IN RRSIG DNSKEY 13 3 28800 20200206004306 20200107001237 47500 mff.cuni.cz. j9FdwbEIhxtLXPnTWNhTIuRDXEeF/1NDLoCT6obI+2LbjAEea9cfu3kr 1LKRJZRKmNlJIh4siJ+jQPXj7p+Kcw== mff.cuni.cz. 28291 IN RRSIG DNSKEY 13 3 28800 20200611043903 20200512034907 47500 mff.cuni.cz. +aAX+S8d8GpGLzytpqCAH0vLui8P2Pij9Y9TyiDIA4SsN1s02xSDz0ON iK6g8fwegqdiFv2yUqr/7XUZD0XSUw== ;; Query time: 1 msec ;; SERVER: 10.98.0.1#53(10.98.0.1) ;; WHEN: Thu May 14 19:53:56 IST 2020 ;; MSG SIZE rcvd: 334 The second signature in the set above has not expired and is a valid path in the trust chain. Mukund From nobody Thu May 14 07:39:48 2020 Return-Path: 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 7B07A3A0AC9 for ; Thu, 14 May 2020 07:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 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, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, 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=umich.edu 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 uwEhWsRqaMOg for ; Thu, 14 May 2020 07:39:42 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 7EA043A0B44 for ; Thu, 14 May 2020 07:39:39 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id b6so3833682ljj.1 for ; Thu, 14 May 2020 07:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bb/FvhW0U8gcV8HnU5TKIDsVsSoMoy8KTKtV89B3N+s=; b=nwf/6GecdXUTOn5J/y5K6gjyn28TEOYLmGh+jjTYNOHXEn/06zma/Zwtiati+e2i2Q 0eSx13LsiabmgOool9C0XUrfy/d8sHxuE80o4veAtNOLqnOJrHhuL6qgX6uMIO4T65PQ wp2R3fGf5EY5WQFjIt7a4NVwIam96j9M8sD1TC0Z2HtbVc6mydmQrPUTLg+kUGkfJdjt hfF148IRtBSAukK68ptl6lN1QF9H5fcaYxAWosLWua5nD+CoeXxtauP4Ph3mnWkPGAJF w2N/3HGQytebU1r3iQGMp4nOvBxyVYduJFgYnrN4fnH2P1bQpb0prgZZs02Zu3N+A4v4 4Bgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bb/FvhW0U8gcV8HnU5TKIDsVsSoMoy8KTKtV89B3N+s=; b=Wmenzjn/drY0dXECf2wobmPCfF+v+3PWI+LfFFWQK/0bTpi2iXc7urBHYiTwAHyatv xJN5XjFNL0le8+AP0yPHrh1eRBUswkwK5xf9cCjiltFirbaYB/wddHD/g0gWPEjHO0nv nz5UmQgkL19r4lCuNfQ/xRh2lig7UcUBNGVhj+7NhxRLkSU5YW8+1BBh4ZsTAgkhFjNU V9S8HIOfm9D/y7EDlJzrTRuA2DNA1We4/JnYkrhOwMqZmxqOxZt9oeb0lyMcLwxZqvBJ NsWK/kyB1N8IC8i+KbQUHz100UrlQN4kDjZhHdnf1JgOazKhBDNaWH74i38qwf0txNFd L21w== X-Gm-Message-State: AOAM5324M4OQT9YNey8JyFe9mFZYkzU1NUAyYb2olbg+AWulyoPLMMEp HlNwnftDmHklqOB9cUPh6oPPJnKLQniehCI+q7yMXCaJzRk= X-Google-Smtp-Source: ABdhPJyCdG70/wP1dVP89CuJREbZHU3L6Ura5gsvwRKTdFh2AFf2zUvSVxanNOsflCxds3T5ezQa/XVrkT8+1pZZ7zM= X-Received: by 2002:a2e:547:: with SMTP id 68mr2960163ljf.25.1589467177480; Thu, 14 May 2020 07:39:37 -0700 (PDT) MIME-Version: 1.0 References: <20200514142450.GA36078@jurassic.vpn.mukund.org> In-Reply-To: <20200514142450.GA36078@jurassic.vpn.mukund.org> From: Bob Harold Date: Thu, 14 May 2020 10:39:26 -0400 Message-ID: To: Mukund Sivaraman Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="0000000000007f082a05a59caa2a" Archived-At: Subject: Re: [DNSOP] DNSSEC validates even if expired? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:39:48 -0000 --0000000000007f082a05a59caa2a Content-Type: text/plain; charset="UTF-8" On Thu, May 14, 2020 at 10:25 AM Mukund Sivaraman wrote: > Hi Bob > > On Thu, May 14, 2020 at 10:02:45AM -0400, Bob Harold wrote: > > I am preparing to enable DNSSEC validation, so I am working on alerts for > > failed validations, so I can see whether they are user errors (that might > > need negative trust anchors or other exceptions) or actual attacks. > > > > I stumbled on "mff.cuni.cz" which has RRSIG records that expired 3 > months > > ago, but my validating server still gives an answer and says that it is > > valid. > > Is that expected? > > > > BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) > > > > > > [hostmast@ns-umd-nsbs-1 named]$ delv mff.cuni.cz @127.0.0.1 > > ;; validating mff.cuni.cz/DNSKEY: verify failed due to bad signature > > (keyid=47500): RRSIG has expired > > ; fully validated > > mff.cuni.cz. 28546 IN A 195.113.27.221 > > mff.cuni.cz. 28546 IN RRSIG A 13 3 28800 > 20200611045052 > > 20200512043705 47500 mff.cuni.cz. > > ZbW+RXOvA24E+Fb0Z/M3OfMJdFD9vdRKD8nhylZSfB0fkq236lohWHGu > > 4A54HrqasAPkUHJd/LcoN1+k6bkAqw== > > delv is complaining a signature for the DNSKEY set has expired. There is > a signature that has not expired though: > > [muks@jurassic ~]$ dig +rrcomments +dnssec mff.cuni.cz dnskey > > ; <<>> DiG 1.1.1.20200413085522.7eb91c6988 <<>> +rrcomments +dnssec > mff.cuni.cz dnskey > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55595 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;mff.cuni.cz. IN DNSKEY > > ;; ANSWER SECTION: > mff.cuni.cz. 28291 IN DNSKEY 257 3 13 > 1PMTgkDSUJEO8PbtFEtJ6sqtBUwlqv5yWMAQpedPoJtvJ9Oxoen3OJoF > xEnZCFBCouNsR58PYdzYDowWEQAJVw== ; KSK; alg = ECDSAP256SHA256 ; key id = > 47500 > mff.cuni.cz. 28291 IN RRSIG DNSKEY 13 3 28800 > 20200206004306 20200107001237 47500 mff.cuni.cz. > j9FdwbEIhxtLXPnTWNhTIuRDXEeF/1NDLoCT6obI+2LbjAEea9cfu3kr > 1LKRJZRKmNlJIh4siJ+jQPXj7p+Kcw== > mff.cuni.cz. 28291 IN RRSIG DNSKEY 13 3 28800 > 20200611043903 20200512034907 47500 mff.cuni.cz. > +aAX+S8d8GpGLzytpqCAH0vLui8P2Pij9Y9TyiDIA4SsN1s02xSDz0ON > iK6g8fwegqdiFv2yUqr/7XUZD0XSUw== > > ;; Query time: 1 msec > ;; SERVER: 10.98.0.1#53(10.98.0.1) > ;; WHEN: Thu May 14 19:53:56 IST 2020 > ;; MSG SIZE rcvd: 334 > > The second signature in the set above has not expired and is a valid > path in the trust chain. > > Mukund > Thanks for explaining! That was not clear, even when looking at places like: https://dnssec-analyzer.verisignlabs.com/mff.cuni.cz https://dnsviz.net/d/mff.cuni.cz/dnssec/ -- Bob Harold --0000000000007f082a05a59caa2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 14, 2020 at 10:25 AM Mukund S= ivaraman <muks@mukund.org> wro= te:
Hi Bob

On Thu, May 14, 2020 at 10:02:45AM -0400, Bob Harold wrote:
> I am preparing to enable DNSSEC validation, so I am working on alerts = for
> failed validations, so I can see whether they are user errors (that mi= ght
> need negative trust anchors or other exceptions) or actual attacks. >
> I stumbled on "mff.cuni.cz" which has RRSIG records that expire= d 3 months
> ago, but my validating server still gives an answer and says that it i= s
> valid.
> Is that expected?
>
> BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version)
> <id:7107deb>
>
> [hostmast@ns-umd-nsbs-1 named]$ delv mff.cuni.cz=C2=A0 =C2=A0@127.0.0.1
> ;; validating mff.cuni.cz/DNSKEY: verify failed due to bad signatu= re
> (keyid=3D47500): RRSIG has expired
> ; fully validated
> mf= f.cuni.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28546=C2=A0 =C2=A0I= N=C2=A0 =C2=A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A0195.113.27.221
> mf= f.cuni.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28546=C2=A0 =C2=A0I= N=C2=A0 =C2=A0 =C2=A0 RRSIG=C2=A0 =C2=A0A 13 3 28800 20200611045052
> 20200512043705 47500 mff.cuni.cz.
> ZbW+RXOvA24E+Fb0Z/M3OfMJdFD9vdRKD8nhylZSfB0fkq236lohWHGu
> 4A54HrqasAPkUHJd/LcoN1+k6bkAqw=3D=3D

delv is complaining a signature for the DNSKEY set has expired. There is a signature that has not expired though:

[muks@jurassic ~]$ dig +rrcomments +dnssec mff.cuni.cz dnskey

; <<>> DiG 1.1.1.20200413085522.7eb91c6988 <<>> +rr= comments +dnssec mff.cuni.cz dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55595
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mff.cu= ni.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0IN=C2=A0 =C2=A0 =C2=A0 DNSKEY

;; ANSWER SECTION:
mff.cun= i.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28291=C2=A0 =C2=A0IN=C2= =A0 =C2=A0 =C2=A0 DNSKEY=C2=A0 257 3 13 1PMTgkDSUJEO8PbtFEtJ6sqtBUwlqv5yWMA= QpedPoJtvJ9Oxoen3OJoF xEnZCFBCouNsR58PYdzYDowWEQAJVw=3D=3D=C2=A0 ; KSK; alg= =3D ECDSAP256SHA256 ; key id =3D 47500
mff.cun= i.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28291=C2=A0 =C2=A0IN=C2= =A0 =C2=A0 =C2=A0 RRSIG=C2=A0 =C2=A0DNSKEY 13 3 28800 20200206004306 202001= 07001237 47500 mff.cuni.cz. j9FdwbEIhxtLXPnTWNhTIuRDXEeF/1NDLoCT6obI+2LbjAEea9= cfu3kr 1LKRJZRKmNlJIh4siJ+jQPXj7p+Kcw=3D=3D
mff.cun= i.cz.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 28291=C2=A0 =C2=A0IN=C2= =A0 =C2=A0 =C2=A0 RRSIG=C2=A0 =C2=A0DNSKEY 13 3 28800 20200611043903 202005= 12034907 47500 mff.cuni.cz. +aAX+S8d8GpGLzytpqCAH0vLui8P2Pij9Y9TyiDIA4SsN1s02x= SDz0ON iK6g8fwegqdiFv2yUqr/7XUZD0XSUw=3D=3D

;; Query time: 1 msec
;; SERVER: 10.98.0.1#53(10.98.0.1)
;; WHEN: Thu May 14 19:53:56 IST 2020
;; MSG SIZE=C2=A0 rcvd: 334

The second signature in the set above has not expired and is a valid
path in the trust chain.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund

Thanks for explaining!=C2=A0 That was not clear, ev= en when looking at places like:

=
--=C2=A0
Bob Harold

--0000000000007f082a05a59caa2a-- From nobody Thu May 14 07:51:12 2020 Return-Path: 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 E0B2F3A0B0E for ; Thu, 14 May 2020 07:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=umich.edu 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 tpm5EiHcAEVB for ; Thu, 14 May 2020 07:50:59 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 750BA3A0AD1 for ; Thu, 14 May 2020 07:50:59 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id b26so2878138lfa.5 for ; Thu, 14 May 2020 07:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:from:date:message-id:subject:to; bh=PNVlmjaFRz0Pzt1xqcUiYoYKTHx4sEGNqs1E1CIAjQ0=; b=awuJnzO6VS/58NLI2jfd4uodqY+W+YQdycMe+DsyYI+yPwUU4qGf1ub00mTe9KGZDb +ZjWC0yXKqK+c320uzgx/hH6vCbUo1zuLvjQ9+acFHfDR+1rDYqge0vuWkXAZVhD54kd gg2jYJFqpEcnWxt+kZ5nDQEpk3aXqM93yk2bvJ8+QcpV/rs15nGHdx1xBrNHqA88yA/R ovzxYc2v8Nv4jjk7gEnG5h9rTB4F0KUcskBfvUrEskfjZi/tOqaf22c7Ny2+VeqW6As5 veT6meTkIoWvY+DCbQxuyxwHOkNxXAZrw4e8yoFagj03DNC6BLTniavPY9mJHDzjDe53 wqIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PNVlmjaFRz0Pzt1xqcUiYoYKTHx4sEGNqs1E1CIAjQ0=; b=WY18TVItgHajoB7dj+N+TCRRUGJrR3oPyvjMlPlWK7yqFWcGCJk2k/kCaSClZ1W+x+ sWJo0CShIikUw1Ha2zQCn+un9Lsmc1tnhCX+QtKdkuqZJO+lV+m+gFQoKIIlUcvlHdEh lcU7Z6Iv0/mnqjc4qcxNp2nVbhDL7YdgXB2/nS5S4UBsWw+1Zt83DmDZbUzTKMSdj09S 85j+IqYS30LQnk0MS/ofDivpQa4ZfVjP8FaGpx3WYn55Yh09glhgeDXZn56UdX3a5zQ4 WMYXSc/q//IDyBZAHrbRsJRoScY80rq5U/PcTGD3Gp209ZLJtlghIY0EPHmTcYnaFszR Bi3A== X-Gm-Message-State: AOAM533HaKL9FeIOOghQ2Do0u/V7UlGp5rmVB9sJMYbA5HhEjTj/MAqt IG9ynI6kso66LsPKYbxxL3RnYVsmFKhUDB/m1gnRWex0Z+U= X-Google-Smtp-Source: ABdhPJxBeXyvJ89sTW5UW9Ju6QPEuS0dVafUeLcPnZABaoz3u/9OEGusZMnmydRuKpVv22vInTOGrO1PzqtIqKXf3KY= X-Received: by 2002:ac2:5384:: with SMTP id g4mr3577138lfh.1.1589467857193; Thu, 14 May 2020 07:50:57 -0700 (PDT) MIME-Version: 1.0 From: Bob Harold Date: Thu, 14 May 2020 10:50:46 -0400 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary="00000000000002a75b05a59cd34c" Archived-At: Subject: [DNSOP] DNSSEC actual failures log where? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:51:09 -0000 --00000000000002a75b05a59cd34c Content-Type: text/plain; charset="UTF-8" I am preparing to enable DNSSEC validation, so I am working on alerts for failed validations, so I can see whether they are user errors (that might need negative trust anchors or other exceptions) or actual attacks. But it seems that the "dnssec" category logs all sorts of DNSSEC issues, even if the response validates correctly. Is there something that I can match on to get just the responses that fail? (user gets SERVFAIL instead of an answer) ? -- Bob Harold --00000000000002a75b05a59cd34c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am preparing to enable = DNSSEC validation, so I am working on alerts for failed validations, so I c= an see whether they are user errors (that might need negative trust anchors= or other exceptions) or actual attacks.
But it seems that the "dnssec" category logs all sorts of DNSSEC= issues, even if the response validates correctly.=C2=A0 Is there something= that I can match on to get just the responses that fail? (user gets SERVFA= IL instead of an answer) ?

--
Bob Harold

--00000000000002a75b05a59cd34c-- From nobody Thu May 14 08:30:03 2020 Return-Path: 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 025A03A0BE9 for ; Thu, 14 May 2020 08:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 nUlRbFDHlEjw for ; Thu, 14 May 2020 08:29:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 D6C573A0BBF for ; Thu, 14 May 2020 08:29:55 -0700 (PDT) Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id D2049140B87; Thu, 14 May 2020 17:29:51 +0200 (CEST) To: Bob Harold References: Cc: IETF DNSOP WG From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <6396f85d-da61-1a5a-1616-8ade7eb08e44@nic.cz> Date: Thu, 14 May 2020 17:29:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FCAA8A4ACED8DBBE16C9C91A" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] DNSSEC actual failures log where? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 15:30:02 -0000 This is a multi-part message in MIME format. --------------FCAA8A4ACED8DBBE16C9C91A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/14/20 4:50 PM, Bob Harold wrote: > I am preparing to enable DNSSEC validation, so I am working on alerts > for failed validations, so I can see whether they are user errors > (that might need negative trust anchors or other exceptions) or actual > attacks. > But it seems that the "dnssec" category logs all sorts of DNSSEC > issues, even if the response validates correctly.  Is there something > that I can match on to get just the responses that fail? (user gets > SERVFAIL instead of an answer) ? That's a question specifically for BIND 9.11, right? In any case, there's a module in Knot Resolver just for this: https://knot-resolver.readthedocs.io/en/stable/modules-bogus_log.html --Vladimir --------------FCAA8A4ACED8DBBE16C9C91A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/14/20 4:50 PM, Bob Harold wrote:
I am preparing to enable DNSSEC validation, so I am working on alerts for failed validations, so I can see whether they are user errors (that might need negative trust anchors or other exceptions) or actual attacks.
But it seems that the "dnssec" category logs all sorts of DNSSEC issues, even if the response validates correctly.  Is there something that I can match on to get just the responses that fail? (user gets SERVFAIL instead of an answer) ?

That's a question specifically for BIND 9.11, right?

In any case, there's a module in Knot Resolver just for this: https://knot-resolver.readthedocs.io/en/stable/modules-bogus_log.html

--Vladimir

--------------FCAA8A4ACED8DBBE16C9C91A-- From nobody Thu May 14 11:52:14 2020 Return-Path: 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 2CF563A0412 for ; Thu, 14 May 2020 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Qp_-z9M_RXcr for ; Thu, 14 May 2020 11:52:08 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 46A273A0405 for ; Thu, 14 May 2020 11:52:08 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id y13so2613460vsk.8 for ; Thu, 14 May 2020 11:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wk6YuKXQra2c7jglm+Ieolp7lJbJbbJb39oBFtufNRk=; b=RaG8Uon99GtqUpbwAmtcMxDT67g382zf/ZBLLnfszJP+cy7PdqE15xcDelkBjA5SK1 gp+ba70gbuXK1Z5afucLMSnahFEnwraKUqyrxLhmyVNcu/KyZ45HrZ7lrMvOCcCY6Z7E hDcRcxQHm1RAtknZ9JZsNy6alm8jakjDYK62H8JUgOyOKsdqp3DpPI4MTnrn8QY86+M2 WmxIkhp8pXJrllMS1C6Chmvg3tmmp9gT+uTgrcr9uXoD5bjhzLSq+pOVKdQ7xZ8J/9Nq J77FdekBUFPp1xN0DGMUbNWiVjweMG9OdDhelL+irA4AyJRAbW5PiKSeYgobbNlWBBC0 M1aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wk6YuKXQra2c7jglm+Ieolp7lJbJbbJb39oBFtufNRk=; b=EySVfwA2fYCuT/4F7bB5XyykuO+EogOAR6uoMpAjQpGlWumaWFCopz1I2xkbkp8apE 5PXwwtFOz8wf0CmLplHpA8Ne5HSua4fNTa2JF5Tc5s8XgtlZTWXiZVdzawses8VMaqXE WnwTBMD4gOjRp/aMGqzIvc3DVNwSuNyCGMYZGZyEzW5HN9+d7ckJWreFxZnTYOVUIuCF pFNcHv2JMs+rM+LSSs1KVUopsNkS3Z46XWKqkY3+vzqDUBrw0bSOfms5IPKprZ61I4XS 0VFhO+urQIWEJd5e+UD4a/9mif/ECLvZhfUIHB7KuNuyfs4V4dadiRMK1ZvqFncfho5t fMWg== X-Gm-Message-State: AOAM533DxoQicEAUnSq/bCkR8gz+dsd5VeMoW8UEa2GATOyZS8LJSnj8 pRJfHH/bZua/OYtCTkRsGzqwORhYHgqVTF4mCgy2RA== X-Google-Smtp-Source: ABdhPJxuvK0Dn72lB45zIDL0HbN2uGRdICYtI+W+l5S/Em6zVoeX9qxIRpGUTtRWdkia80vK6oT7jGZwRgDUh9fwbQ8= X-Received: by 2002:a67:c482:: with SMTP id d2mr4871886vsk.37.1589482326998; Thu, 14 May 2020 11:52:06 -0700 (PDT) MIME-Version: 1.0 References: <158871188730.7528.4018207019268407373@ietfa.amsl.com> <98FA896F-5034-40CE-8B25-15DA230FBBB8@isc.org> In-Reply-To: <98FA896F-5034-40CE-8B25-15DA230FBBB8@isc.org> From: Puneet Sood Date: Thu, 14 May 2020 14:51:55 -0400 Message-ID: To: Mark Andrews , IETF DNSOP WG Content-Type: multipart/alternative; boundary="0000000000007aeb4c05a5a03185" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-16.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 18:52:12 -0000 --0000000000007aeb4c05a5a03185 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2020 at 2:09 AM Mark Andrews wrote: > > > > On 14 May 2020, at 15:48, Puneet Sood 40google.com@dmarc.ietf.org> wrote: > > > > Google Public DNS is planning to implement this draft in responses > > from us (recursive resolver) to clients. > > > > *** Question: When can we expect to have an EDNS option code assigned > > for the EDE option? > > It=E2=80=99s already assigned. See the IANA registry. The value is 15. > > > *** Request for clarification on Section 3. Extended DNS Error Processi= ng > > The text in this section (and in the introduction) implies that a > > response with a NOERROR RCODE may contain an EDE option. > > "Receivers MUST be able to accept EDE codes and EXTRA-TEXT in > > all messages, including those with a NOERROR RCODE, but need not act > > on them" > > > > Scenario: Response has a NOERROR RCODE and contains some response RRs. > > If the client sent an EDE option and the server supports EDE, is the > > expectation that the server should always include the EDE option? > > No. While not explicitly specified a server would only include a EDE > if it have something extended to report. > > There is also no requirement for there to be a EDE in the request > before sending a EDE in a response. If EDE was expected to be in the > request then there would have been a request format specified. All > EDNS clients should handle unknown EDNS options in responses as that > is a requirement of the base EDNS specification. > Thanks for clarifying this. Makes the resolver response logic much simpler. I had incorrectly remembered that the client had to specify this option in the request. -Puneet > > If the server includes an EDE option in the response, what is the > > right EDE code to use? EDE code 0 [other] seems the closest but it > > > still implies an error. Also the description for it suggests including > > EXTRA-TEXT which would not be useful. > > > > If the server does not include an EDE option in the response, the > > response looks A-OK to the client. However if the client is attempting > > to detect EDE option support on the server it might incorrectly assume > > the server does not support EDE. > > There is no reliable way to determine if a server supports EDE. There is > no requirement to return any given EDE. Which EDE return (if any) is up = to > the server developer. > > > To simplify the NOERROR scenario, can we have a no error EDE code > > similar to the NOERROR RCODE? With this a server can include an EDE > > option in all responses to queries containing an EDE option. > > > > Thanks, > > Puneet > > > > > > On Tue, May 5, 2020 at 4:52 PM wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Domain Name System Operations WG of > the IETF. > >> > >> Title : Extended DNS Errors > >> Authors : Warren Kumari > >> Evan Hunt > >> Roy Arends > >> Wes Hardaker > >> David C Lawrence > >> Filename : draft-ietf-dnsop-extended-error-16.txt > >> Pages : 15 > >> Date : 2020-05-05 > >> > >> Abstract: > >> This document defines an extensible method to return additional > >> information about the cause of DNS errors. Though created primarily > >> to extend SERVFAIL to provide additional information about the cause > >> of DNS and DNSSEC failures, the Extended DNS Errors option defined i= n > >> this document allows all response types to contain extended error > >> information. Extended DNS Error information does not change the > >> processing of RCODEs. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16 > >> > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-extended-error-16 > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > marka@isc.org > > --0000000000007aeb4c05a5a03185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 14, 2020 at 2:09 AM Mark = Andrews <marka@isc.org> wrote:


> On 14 May 2020, at 15:48, Puneet Sood <puneets=3D40google.com@dmarc.ietf.org<= /a>> wrote:
>
> Google Public DNS is planning to implement this draft in responses
> from us (recursive resolver) to clients.
>
> *** Question: When can we expect to have an EDNS option code assigned<= br> > for the EDE option?

It=E2=80=99s already assigned. See the IANA registry.=C2=A0 The value is 15= .

> *** Request for clarification on Section 3. Extended DNS Error Process= ing
> The text in this section (and in the introduction) implies that a
> response with a NOERROR RCODE may contain an EDE option.
> "Receivers MUST be able to accept EDE codes and EXTRA-TEXT in
> all messages, including those with a NOERROR RCODE, but need not act > on them"
>
> Scenario: Response has a NOERROR RCODE and contains some response RRs.=
> If the client sent an EDE option and the server supports EDE, is the > expectation that the server should always include the EDE option?

No.=C2=A0 While not explicitly specified a server would only include a EDE<= br> if it have something extended to report.

There is also no requirement for there to be a EDE in the request
before sending a EDE in a response.=C2=A0 If EDE was expected to be in the<= br> request then there would have been a request format specified.=C2=A0 All EDNS clients should handle unknown EDNS options in responses as that
is a requirement of the base EDNS specification.

<= /div>
Thanks for clarifying this. Makes the resolver response logic muc= h simpler. I had incorrectly remembered that the client had to specify this= option in the request.

-Puneet


> If the server includes an EDE option in the response, what is the
> right EDE code to use? EDE code 0 [other] seems the closest but it

> still implies an error. Also the description for it suggests including=
> EXTRA-TEXT which would not be useful.
>
> If the server does not include an EDE option in the response, the
> response looks A-OK to the client. However if the client is attempting=
> to detect EDE option support on the server it might incorrectly assume=
> the server does not support EDE.

There is no reliable way to determine if a server supports EDE.=C2=A0 There= is
no requirement to return any given EDE.=C2=A0 Which EDE return (if any) is = up to
the server developer.

> To simplify the NOERROR scenario, can we have a no error EDE code
> similar to the NOERROR RCODE? With this a server can include an EDE > option in all responses to queries containing an EDE option.
>
> Thanks,
> Puneet
>
>
> On Tue, May 5, 2020 at 4:52 PM <internet-drafts@ietf.org> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts= directories.
>> This draft is a work item of the Domain Name System Operations WG = of the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Extended DNS Errors
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Warren Kumari
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Evan Hunt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Roy Arends
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Wes Hardaker
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 David C Lawrence
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-dnsop-extended-error-16.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 15
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2020-05-05
>>
>> Abstract:
>>=C2=A0 =C2=A0This document defines an extensible method to return a= dditional
>>=C2=A0 =C2=A0information about the cause of DNS errors.=C2=A0 Thoug= h created primarily
>>=C2=A0 =C2=A0to extend SERVFAIL to provide additional information a= bout the cause
>>=C2=A0 =C2=A0of DNS and DNSSEC failures, the Extended DNS Errors op= tion defined in
>>=C2=A0 =C2=A0this document allows all response types to contain ext= ended error
>>=C2=A0 =C2=A0information.=C2=A0 Extended DNS Error information does= not change the
>>=C2=A0 =C2=A0processing of RCODEs.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.o= rg/doc/draft-ietf-dnsop-extended-error/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/d= raft-ietf-dnsop-extended-error-16
>> https://datatracker= .ietf.org/doc/html/draft-ietf-dnsop-extended-error-16
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-dnsop-extended-error-16
>>
>>
>> Please note that it may take a couple of minutes from the time of = submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 INTERNET: marka@i= sc.org

--0000000000007aeb4c05a5a03185-- From nobody Fri May 15 02:10:09 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2013A078F; Fri, 15 May 2020 02:10:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158953380668.11479.15115828281496051727@ietfa.amsl.com> Date: Fri, 15 May 2020 02:10:06 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-iana-class-type-yang-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 09:10:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : YANG Types for DNS Classes and Resource Record Types Authors : Ladislav Lhotka Petr Spacek Filename : draft-ietf-dnsop-iana-class-type-yang-01.txt Pages : 13 Date : 2020-05-15 Abstract: This document introduces the YANG module "iana-dns-class-rr-type" that contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as a minimum basis for future data modeling work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-iana-class-type-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-iana-class-type-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 02:31:38 2020 Return-Path: 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 519273A0834 for ; Fri, 15 May 2020 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 AdgJ9QbDIJoB for ; Fri, 15 May 2020 02:31:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 3A7943A082B for ; Fri, 15 May 2020 02:31:30 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115] (unknown [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115]) by mail.nic.cz (Postfix) with ESMTPSA id 9D5F3140BA2 for ; Fri, 15 May 2020 11:31:25 +0200 (CEST) To: dnsop@ietf.org References: <158953380668.11479.15115828281496051727@ietfa.amsl.com> From: Ladislav Lhotka Autocrypt: addr=ladislav.lhotka@nic.cz; keydata= mQINBFhU5JIBEACmGIeLglGrwf6JBcNrcLoO19yAdKcH7V132STGHlhEAgmdzwclgVE7GN7y 5+1ySQ8jhDM80QSQ+XaXsSbHTQl23vcVvSfKNdme11kGEQ7kO/bTbUYxpRRa5dqDjLeEHhol WiNk6nUHqEAExbpEoITiO216Lwxh8gD2+39ZH/UVJgMHoZD1VmrxHSnp9b1SpmDWkbILRc93 u6lADieU67SG5vWqGaBgp8JQAVI3F+ZhcLXHQiQLPliePT3YKfvubWg9NIprts9fv2JAUywv NN4R5gg1oFegOXouzlBySiUNXndzJsj1JAcI4psGA9iGYBhgdILXg+2Kwkok9rrx1gWsqtmb lcFDiJRx52FUohHz9obZ9gkOd4NoV4jatjnu+9HKA8V2T5JUgTCgOWeI2yHoSNFJvKO0ygIg /5ccrB9iRdmJIiA2cAmu5MaHnKxAcQ7eaXqQN+JRcpFUH2ooFHKm0750U3aAZY3an5+a5Njh XddaDDX/7f0a68jaWuoKFn7Mqa2HhNnLJs2Nsq9quLdWEUh59wOgTrp2TZnkAFtG1MGa2dNz M3YX22+jwbnfv/U72fEu33juXfMLWfwzJEzQG47dnpmsArt8fM+atOvTSvkLQDNJkOSVZT8m NR5/OeIYfxhe3FUSrljRQBXN8ioVoiMtcCR8EKXCwCnja20vdQARAQABtChMYWRpc2xhdiBM aG90a2EgPGxhZGlzbGF2Lmxob3RrYUBuaWMuY3o+iQJUBBMBCgA+FiEEtr1TxpCtJF8Aid5X uPkrCKn3bGcFAl3k3q0CGwMFCQecs7wFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQuPkr CKn3bGeXZA/+IM3zgfkMwQ+rvYMEn1cHoYwA0j8iwGtQp6FQYO/Vj0d6Q07Q5/iUqM0UuniU HN6xC5APrPsxwyeSuJUW1zjGm6JD8U5WinbNJuBU/FMC7XyHgOwwXdlT1bLlhOYnvUrZx0bB QeMLnUinvTHLVFnpUCfFpyKRUKh3kkUJS5AXRz5ZgEqJUr79GSTg46dluXlz9mnPIkwluwYO ydlhtW/+s/xVuCIqRUdhhc30d8K5XB+smiYmHSzePjLGwsP1pHt1e8we57EFNvm7iiwXPCAI cy+PAtCxmq2zsIxsZxtZP4SWbRcj2Z16XTtT+hhNK6SWKhpDuacadpWChXpYc36xtuJ5Ll3C lZqa/6mDRcagJy016pQboW/4JIkFcFhu6ugNwvR1OBom04VPVBxqQRgazqpfkB0jSWWS4rwh l30kwDFW5eWcski3Ja5g2drj0YpUeEkMOQcToxLPXffI6dauKTMh7K6RF++LGCYxOukWt2r+ jk6/pB3rSVztAJDb4kc/EgE7yNwrVQOxkKHfk3rGCXkvijCgU3jS0k5g01/OwENxpEUk0Nln mlLJdb8Bju6Jp2y3ZX97+Szs2tH8M6Mpny213lFgc4EVCOFVtIPsyYfiR9On1IIdRqMx3mQC 5AV+3Wc0o3M7Ku0ZbuhkYLNIhlNrRjlxFRk12FpZwFwznY+5AQ0EWFTnYgEIAM6XJ37HGp7H nzztkWbCW+5zkLzff2LQh7yoH32CGJTK7vnQKOY+JKi16lR1qUDHOUtYfRj17jBNWaB0CY0k qkRWCDXG0pff8VT63Kg/DlS2LLbPQpO2NcjdMhPTTUadnKWeo7h6/mFF7VW4X2sm1NYeNWD5 VQxdPQUbnCJ4Pi23QZRJnBu2ycM9aXa7ERRvpN3i3mAc2UgkJWq4KGjI74cd7ytCsU0RN6RT S0sFE4zCB1r6nXqfHHiousATS6+3GnuIGTtaeR0nXHlIvl2AC91+hswsWaA7YB4dB2/GJ8PN L3d07gA6yR2DoZJZhAmtMUiUzap4jgf07UoTOY80MHkAEQEAAYkDcgQYAQoAJgIbAhYhBLa9 U8aQrSRfAIneV7j5Kwip92xnBQJcLzGrBQkHnLFJAUDAdCAEGQEKAB0WIQQ+THLKBBuTzVYa 3ozuYRDCyLOtngUCWFTnYgAKCRDuYRDCyLOtnhnlB/49PV5puyMGBJXY5XBdaPIKFfC5eBfy EOgMqDfJS9yhV7bhFRzzztX9Z7COod6mxmlogNaDFMk/yFH25DOe2tpjKs6sqa9bwyY3cOFw pp38VdeAq0FxF3qOhjKzF12RVQ4Ipu/ahzzQ6V5reia+onOghw+BrjOsPExJaDbiif5UqL/F yWvERlR46GGbFzK9gEvUo+52Wjx3t4hW2IMZKS58xvzkMkTQtxYHAM++jO7bH18wV603JJC3 mZxq9YKKFHVcxinp9l8yzVxfIjhiklednvb30lggY4VEG6X+BER/lcw1QgSDojjbHY72o+76 rBYZ+pSacY/idn5AkAEkQyxsCRC4+SsIqfdsZ1aAEACjuN1b73KNsdsNZuV/MSdmfC+LkoG2 +20kGWzHHiq1Owc4W3fDRohJThM5xyKt2RAcLZAqzfeef1AuoESTqqR6OheaF3u0HAa+U87E /dfjflBOsGZloNi/0/JcN2B8VJpXBwA55adA4YwNL/i8k/roIZ0Yh4wd8Bv8G4exrjvPZPCG klGNBvIJomaqgb9YDvdN22CW3f0zoCwdTX+XV7YL6IQsZroRViLWZv12UCKO1kVop8IMQolx XGbo4kVkqtVx0A4O+ZqCiG819QGZIAtaKSG6aK1xWxNg16ClbEoCEglPeLiOr1ttibO6emuK 4w+4vA5nu+q5niUZ611f/9OtnNO6w/EZ9jRjiqBbo7esNkzal4LjwZUa0B3poWRz+7B++CYS F0c/qdfqjYmiN4IEbXnC0EFhwOYejTayy/H/nA0yGjxF7xA2Krom8B3YTaOnaZ2lVx0gtQK6 Ih7SSc842yRyBnMoVko8mzcHb/0urD2uWkPI5VfXLF9OJhfe3J1xswtqfOxFtf1cZv6fnQID 4gfsvRP8s8Wow5m3gp1HLSlxeZcc57nK8/nKWaTssdOf6doSw8kLWC5Dcwx2Ld15SsjkHeCO MtOaIxq+Er6vnvcepj76pZZJznS/bMriYPyyw0FIYmAPcnm3v5W+HZ339ktp+Kk3fNl3qJo6 C+Sjv7kBDQRYVOgGAQgA0GW5sWxqhcD9hxi/LQZ/hzPBgrpTvyIgxHrJN1HZ2BzdpNU7UlnC DVDzvAV2/1kEIiCdTYnnly0+PCHhyEdP45M9//oH7KYd/F/JSQwI+56mGP2O0fBBu9WStHws RraGfzGGZDV1XutvIz/qzpkBGpXGzA73Bi2Xye+/9JtHXmjhoXnItQLO38Hqnb5kXk79cSC4 TStPAKdrB/CMolcArT8j9eijIUOPMkWCGCeICv/hECpA5CZma2tplU80cKiOIYknFG8E+5Pr FlW962P7njIaahWSIObM2/C48uu5KAwgyDj6DA14cwc/4wfRsXZFjUMNpI0xer1iLQV5y1vi 6QARAQABiQI8BBgBCgAmAhsMFiEEtr1TxpCtJF8Aid5XuPkrCKn3bGcFAlwvMc8FCQecsMkA CgkQuPkrCKn3bGfkEg//alC3LNxnyH3tNy/OKQqOFJLUCidIm77DT/ZQfjLMAZezzCAq1Adf hVg7uV5a/dFdQdVDnjEz+SQ6/EzyqGashdAMnlBDwiqPe3MhB0L97VQwjNQa0wf1AsHdQCv8 i3e7U6RjlEmSC42dA+RjhrFOCZPtUTlCVDoSnY1S0kZOvEjhHvw901MPEINikZY4TBc18Xnk fbGQhglvI9NqBawlBKHyDGTAVJL7ld60iHsWt3prq+h48iFjc7x2JT39oBxT5Jhl3pg01QSC vu2Fg99vUuRr3u8tavnMKX4Vk3bujpHhuyOTSm0X37nwwu9DpMqkeUNvYR2RM+EuGGltonrN yrb5S21omN7fLDvRtdUBUOCFJLxZunTDLlkig/QuT+QlW7CG59Ussuu37HxgpiICCeeBDOaF bkZku43Qwt5cTtdJ8BkzYgvvoC7NegBn9N+U+Etrrvs09Slo11wlQx1F3sk9T9rjz1QrPM8j blxEgepm+W75VJ22z1qY/JnNElygR7KeTaeOY+iCn4wgDeC964AHMuGzG7aUg8P3zjgClL1T pFJwQUml880L6C+VuWPxuFIS18BPCYtLGlfQc5jp4dGN87ftenT13W70XiGXdrmIAFBF6Jjk 3huuDoRvdbPavAGdxu5QGdHeH0/GjfTxq7lRwgamoY0lw1LIB6LOzXo= Organization: CZ.NIC Message-ID: <53ddd8ba-6bea-0ca9-8fc8-618d0efcb786@nic.cz> Date: Fri, 15 May 2020 11:31:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <158953380668.11479.15115828281496051727@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-iana-class-type-yang-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 09:31:37 -0000 Hi, this revision fixes only formal and cosmetic issues. The authors believe the document is now ready for WGLC. The question whether or not to remove appendix A (with the XSLT stylesheet) before publication can be addressed in later stages, perhaps after te second IANA review. Thanks, Lada On 15. 05. 20 11:10, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : YANG Types for DNS Classes and Resource Record Types > Authors : Ladislav Lhotka > Petr Spacek > Filename : draft-ietf-dnsop-iana-class-type-yang-01.txt > Pages : 13 > Date : 2020-05-15 > > Abstract: > This document introduces the YANG module "iana-dns-class-rr-type" > that contains derived types reflecting two IANA registries: DNS > CLASSes and Resource Record (RR) TYPEs. These YANG types are > intended as a minimum basis for future data modeling work. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-iana-class-type-yang-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-iana-class-type-yang-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri May 15 08:17:01 2020 Return-Path: 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 86D9C3A0AB4 for ; Fri, 15 May 2020 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 sSIo01W42Dq2 for ; Fri, 15 May 2020 08:16:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C6A663A0AAF for ; Fri, 15 May 2020 08:16:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49NsT30tQyz2kb; Fri, 15 May 2020 17:16:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589555815; bh=JiHhopcY2SZbp7yL2c4RcZZ/NAkDtcujn7Wub8s9dCM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=poKuJ8W1ZPGo9YFYZLJmtcB1vzZTSzLwk4OYEZ/a8YsDnyG9F/ktNlHZXypuBJKX8 rOl1Gpznf3OR6ftpkmSM5+WV9uvF/RGXok9wgEKOamWNXc2tmy+P3Zwi/bGUh4jiNW bobiyAGwpQThUu36gdDfCWumPZ3MULCIu1UXrNXA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BZ6MlYO4lRGm; Fri, 15 May 2020 17:16:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 15 May 2020 17:16:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5212E6020D8D; Fri, 15 May 2020 11:16:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 513D966B7C; Fri, 15 May 2020 11:16:53 -0400 (EDT) Date: Fri, 15 May 2020 11:16:53 -0400 (EDT) From: Paul Wouters To: Ladislav Lhotka cc: dnsop@ietf.org In-Reply-To: <53ddd8ba-6bea-0ca9-8fc8-618d0efcb786@nic.cz> Message-ID: References: <158953380668.11479.15115828281496051727@ietfa.amsl.com> <53ddd8ba-6bea-0ca9-8fc8-618d0efcb786@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-iana-class-type-yang-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:17:00 -0000 On Fri, 15 May 2020, Ladislav Lhotka wrote: > The authors believe the document is now ready for WGLC. The question > whether or not to remove appendix A (with the XSLT stylesheet) before > publication can be addressed in later stages, perhaps after te second > IANA review. I agree with this view. Paul From nobody Mon May 18 08:56:02 2020 Return-Path: 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 06E973A05A4 for ; Mon, 18 May 2020 08:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=gmx.net 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 ijAUvU8eIppk for ; Mon, 18 May 2020 08:55:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 0C6303A0484 for ; Mon, 18 May 2020 08:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589817351; bh=vMsnVqxEJp3xUW+v2iT4gtncnjaKaeA/f9sJ1iMX4m0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ItJ3+TnNaDQ62MKeQcUOoUwFU+2qeABWpnHUFqylbbOP1gScXkHLT0NSdvkc+ABKF E0tgqQ4DX3+gqNB9ESrqa8pLLfsfrDk3RPwrMYCxcu0LIBXJKHw/QCRqdENQ2qUzc6 zgPqxMjSM7RdsJFYceYC/O/I6sx1PQpP5Zz+s1/Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.101] ([217.235.141.176]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MzQkK-1ioEEh0PIG-00vKyN; Mon, 18 May 2020 17:55:51 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Normen Kowalewski In-Reply-To: <53ddd8ba-6bea-0ca9-8fc8-618d0efcb786@nic.cz> Date: Mon, 18 May 2020 17:55:50 +0200 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <165FBC6E-E537-4093-A862-2D40C7CDD131@gmx.net> References: <158953380668.11479.15115828281496051727@ietfa.amsl.com> <53ddd8ba-6bea-0ca9-8fc8-618d0efcb786@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.100.39) X-Provags-ID: V03:K1:9n/7F4/6rLpl5CRv88EpOcgW8PaDsxqaDQcCYiU7Ps/G+LO1GQ2 U1ZlcZdC/iQrQIPAnuP2QTZJdJmGSdxuH7rWIh4RfK1xx1bsPDsFFsqZb1lDfa+qh0Wc+nP 5Sqlw02GIAEKSUPzAg2+AnT+QmHZg+hmQq0VjKxJNkno1Pg2HNE3OIG1INlPWshvfFvU9CG MO3sjtLd2+sKq9igbtmIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:0Bp19CaDKSg=:WYdCngyET9M4E8F0w6RV3Y qmqGA6JomKtClnD+8j0Dcxc7U4xD4R3NPbal+t5o+U7ybc2AIOQZc6ysWYbrhAoW1MfbSD+N2 4ZVHHsrWZpy3dhDyNfMMU/ERX1PU2TbHfqFnF3XY1mztrB59biJxXcMv2gyprSMqmOaOseoY0 QDV2tdfFzki/eMQBB1qdDq27eqn7hvX2cx0p8G9+KyAihwawlEB8wQwJWRYHLYlKR3s34lXuy 91PB7O9TrUMOOZILxMy62Sca1I7+ohij/oViomlhTAazEoHSuP7+jytCzy57qDdpe9DEcDonb oAMimQM4P4PWw+qyVsD0B02IJvxKvHTaAknHuBaxOtL2KDrBAsbcdFw6gHBmFDEYDEv+51dCa YUcXqk9B2qaFuWaQAINfxFD7tHxp1FC5aIZlu8ODdBtNKKiKoy6jxARigDf9lexrstEVYyqCR h39DfCLHSS1bbKAWrPErbXO6lEBc/S39BYvu14pNkydrNlRs0pMpWi/OZK7aH9+TuKJhW6YP0 JtDDjZKwiBn4p06Y6b2X469OA03Hobk40WluMUIXpbLPqYF6yMekEQBqNL87EkMrYlZeBSh7a Mlav/K8+mx8W9abJtZ5pWBg9SB0DlH2eMPJYif2yD+AnSBR/zEKmiRax+TGrPpIekDf5Rw+Mi P8tnwXZQt0gAhKsqg1u2eDCU7EaK9/zlTiDiA2tiCvIHw9OWd1hyKco9Z8uvmfirq1dgZyzkC 1Rum2HigOJVgqwkb0kAVeYimo3EIhqogu8MSmB6Q2vHbcZir4Vd721Z4gExqFP789BT2OmK90 8hRqzNBX4U3NKMYUY2zpZYc95x5D5BPZNyEscQigsvvFbi0GQ1CHh2N90s6VJ7QYDDedGxA+9 I29a/IJyz4CZfLGk9AeiL81q3IH9O9rr1MrGtrrCr0nQxwgbwkjiEzWiJzf5KuYcoDtnvIuW4 bq7G8+HPKuSSBwjJC0IbwMYR01ea9i2eFqkVy19puDG8UPmLVlqMgjr5YLF7f/LbyVXe0iww+ aKXzcV+Oqd/9EBKNlaIxDzTZ4UlPy8aMkfBBa+jBm/47dYhVf7324mq3HTyXAiCKemjdSCHe/ 3tvB/usdxLI+NzLlfN/M5ivQvkZi9v8GmJzohUC5DUNHQatnsEIRo6EAMpj60o9jDoGrYxCq5 7qMFbgujWBGoZM5vslbYlZkswSP3Q/efnes3s3ODy8uO/ehpGKYzHtK/jRtw9/HVEWBpD7fEU dQZrAWA1qfApWzSUB Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-iana-class-type-yang-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 15:56:00 -0000 Dear Lada, et al. Thanks for the update, I support your proposal. BR, Normen=20 > On 15. May 2020, at 11:31, Ladislav Lhotka = wrote: >=20 > Hi, >=20 > this revision fixes only formal and cosmetic issues. >=20 > The authors believe the document is now ready for WGLC. The question > whether or not to remove appendix A (with the XSLT stylesheet) before > publication can be addressed in later stages, perhaps after te second > IANA review. >=20 > Thanks, Lada >=20 > On 15. 05. 20 11:10, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Domain Name System Operations WG of = the IETF. >>=20 >> Title : YANG Types for DNS Classes and Resource = Record Types >> Authors : Ladislav Lhotka >> Petr Spacek >> Filename : draft-ietf-dnsop-iana-class-type-yang-01.txt >> Pages : 13 >> Date : 2020-05-15 >>=20 >> Abstract: >> This document introduces the YANG module "iana-dns-class-rr-type" >> that contains derived types reflecting two IANA registries: DNS >> CLASSes and Resource Record (RR) TYPEs. These YANG types are >> intended as a minimum basis for future data modeling work. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-01 >> = https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-iana-class-type-yan= g-01 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-iana-class-type-yang-= 01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >=20 > --=20 > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon May 18 10:48:56 2020 Return-Path: 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 8B0FC3A0B03; Mon, 18 May 2020 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 qpDcD8ui4e0t; Mon, 18 May 2020 10:48:52 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 DA4573A0AF4; Mon, 18 May 2020 10:48:51 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id w4so5899773oia.1; Mon, 18 May 2020 10:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcIvChUmsJILUNJ/saSReydyjE7up3mw1zH6RST6EqU=; b=Qtp3d8WxGFRriys9N48IwmqNk01TC6WzHpjiBY1hHdjxQaRg8j5oPxtf4qpvRk9BVC 04WRyKgvF1DC4Y0Hdz3yKFJXGU66+CiYtrX3gfMZtdJlqtiI8hTLug/GqxgUZrTFpzhO HJ/gxrVNEW66kjLdSOkDH3/kYohYodX6kX/jYKgb8ixJAD+i+LZoKbN35rDmzD9WySL2 7yBM1P/rzKjT1pQOIPAigGQMy15bNMlaPe7AF7yqMDcSQRKT3SG3HXgjiYj8mZXDWVdg p9S3ScDUSfshsR3DzOLxrOmslUPIps81ncTj+Bb6eL7OmGo6eyOflIkZGh6XMl9W60hD Z2AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xcIvChUmsJILUNJ/saSReydyjE7up3mw1zH6RST6EqU=; b=DovKZU5QJQWagUiPtjkL4c29lOQZtv6bFxCqzXzGAeISU8pQxUu3BUKh5DJK+A+g5G CkEN7rVcRMZnZWzXX59nz6X+zEDHoRTWvJUBuD0OoXEMzwNQCyVzzYbodpZNL5HjPUVf YTUgF4eOyxTEl2W0kYZ7Z8/tCWTU5nbkEaX8dH1VdQ50etILMNMgJAoGhibma4CZEieG 4F+EtgTVQGlXSzdBFFHuW7kfadhx43thrf7uRreqv7saql48T1zhU8qlSKvlziTJA6r9 0wGG7hDnbOjSabeRQE/68ystfNfLJZ5apu3kCidrx0P0QLvVMDRAXgOF4NJkcNOiHg+0 KEIA== X-Gm-Message-State: AOAM532JP9HO6gHFewTEvwEEmZiw1nj8FdF+atD8zKdjmafCewF1lqa/ ryGcYukWSLbUda1Fg8jIjo6EeUmKwb8jEJPVwlk= X-Google-Smtp-Source: ABdhPJzyU58pEJIRXRA/L+w2JGRuYvUVJ3G7YAgZTDmIXG2SLiUt4awdboXPm5BK4b25uYQEKpvd5RCawunWHkmUasE= X-Received: by 2002:aca:518c:: with SMTP id f134mr412741oib.6.1589824131123; Mon, 18 May 2020 10:48:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 18 May 2020 13:48:40 -0400 Message-ID: To: Loganaden Velvindron Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000974e2f05a5efc663" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 17:48:54 -0000 --000000000000974e2f05a5efc663 Content-Type: text/plain; charset="UTF-8" All Thanks for all the feedback on this call for adoption. DNSOP will be adopting this document to work on thanks tim On Tue, May 12, 2020 at 1:19 AM Loganaden Velvindron wrote: > On Mon, May 4, 2020 at 11:10 PM Tim Wicinski wrote: > > > > > > > > All, > > > > As we stated in the meeting and in our chairs actions, we're going to run > > regular call for adoptions over next few months. > > We are looking for *explicit* support for adoption. > > > > > > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ > > > I support adoption of the draft and i'm willing to review it. > > > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends: 18 May 2020 > > > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000974e2f05a5efc663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
Thanks for all the feedback on this call for adoption.=C2=A0 DNSOP will
be adoptin= g this document to work on

thanks
tim


On Tue, May 12, 2020 at 1:19 AM Loganaden Velvindron <<= a href=3D"mailto:loganaden@gmail.com">loganaden@gmail.com> wrote:
On Mon, May 4, 202= 0 at 11:10 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
>
>
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going= to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for draft-mglt-dnsop-dnssec-validator-= requirements
>
> The draft is available here: https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-vali= dator-requirements/
>
I support adoption of the draft and i'm willing to review it.
>
> Please review this draft to see if you think it is suitable for adopti= on
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.
>
> This call for adoption ends: 18 May 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop
--000000000000974e2f05a5efc663-- From nobody Mon May 18 10:49:25 2020 Return-Path: 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 553B83A0B6A; Mon, 18 May 2020 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 vaWhEHx9gsTP; Mon, 18 May 2020 10:49:16 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 C03EE3A0B69; Mon, 18 May 2020 10:49:15 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id 19so9776686oiy.8; Mon, 18 May 2020 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5+uI49DJaS7ijZPZ620yGGDhmEihPxbKJP+9FbMfbF0=; b=fzCRdxmjThAvrLHCjtF44XjLuuRUY5q4JkUhKzv243mX0h8Zptc3CfZAo91uVXYQz2 tYvJqsxyqXyM5xwpy8nrGxc4ScmQFl3vWD6Led2TQNznbjM8M158F1ivWehDyLqOoZ7o 666gSAdA+AZ+MqgRoXmGIsqAyCD8Fc0XDqDju9iPiJLu9r4TkM3ZcYFigZP7+O95bHdD 6JdH8ROIO6jEyTd/ur7mFeFohA3Dg5Zej9dC09MZCkJ2JT15ESL48OtDz7M+LMA3bGOy njPu/cMuj3dkvMNprfHMIGqSPhjSudmLQpFUIpCjAjXauNALtIV9Ssrt4KkyJe8RYlu8 G2/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5+uI49DJaS7ijZPZ620yGGDhmEihPxbKJP+9FbMfbF0=; b=rX+U+/lcNkJVQCOG0lHShVe7GSc0XAOb1Nxtlfbrrbj+kTxts7rXdPGsCw1GuP1guI VC2i9HfbcQ8eDCDKiHah8SRptRJejnsuG3qsi6WNAHoeQbHZfE6H37j8Czmp4UkJahDa U7RswbvnIIR1BRtBO+JUY8Wd8kg2gmruqJtM969/p7T91dqKx9AXSZqs7cG4xmf/KnWS w0J+/qm5MeZANLXdtwOr8aH25CxZTEpl4B1MTn1kAlH3717nfOzbf2vQVWNzQybjK0Q+ Q4kYYO1t8mTquGaSv02tYgS0jJdfHMdt3c730YvXX4Ys8qSjRs8to/X3zK2RwdJbO9jf 9KOA== X-Gm-Message-State: AOAM530mrx8fb0KHMM7MAQ1KI8PH+dL+RfAdbIzjN38IqR9WRBTIgQmv xZoUrM9vobPNrpCF/bsrjg/puvSUK42fGjr9XyDPNISUZ8I= X-Google-Smtp-Source: ABdhPJyVuH3A2yXEarJ1JXj0m89dWMc4idLJXc9QBN2l6FQ8wRUO1ANH2/bGPICdsP+N/cSlx/bSC5zvRczxlJ+xt0Y= X-Received: by 2002:aca:f02:: with SMTP id 2mr350267oip.173.1589824154862; Mon, 18 May 2020 10:49:14 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Mon, 18 May 2020 13:49:04 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000000192d805a5efc870" Archived-At: Subject: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 17:49:24 -0000 --0000000000000192d805a5efc870 Content-Type: text/plain; charset="UTF-8" All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional The draft is available here: https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 1 June 2020 Thanks, tim wicinski DNSOP co-chair --0000000000000192d805a5efc870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,

As we stated in the meeting and in our chairs actions, w= e're going to run
regular call for adoptions over next few months. = =C2=A0
We are looking for *explicit* support for adoption.


Th= is starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional<= br>
The draft is available here: https://datatracker.ietf.or= g/doc/draft-andrews-dnsop-glue-is-not-optional/

Please review th= is draft to see if you think it is suitable for adoption
by DNSOP, and c= omments to the list, clearly stating your view.

Please also indicate= if you are willing to contribute text, review, etc.

This call for a= doption ends: 1 June 2020

Thanks,
tim wicinski
DNSOP co-chair<= br>
--0000000000000192d805a5efc870-- From nobody Mon May 18 10:50:06 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 009653A0CCE; Mon, 18 May 2020 10:50:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158982420098.2549.16461558649949157453@ietfa.amsl.com> Date: Mon, 18 May 2020 10:50:00 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-andrews-dnsop-glue-is-not-optional in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 17:50:04 -0000 The DNSOP WG has placed draft-andrews-dnsop-glue-is-not-optional in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ From nobody Mon May 18 11:30:51 2020 Return-Path: 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 43D113A0C35; Mon, 18 May 2020 11:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 SfvnlW1Cb7Qj; Mon, 18 May 2020 11:30:47 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 B5AF33A0C31; Mon, 18 May 2020 11:30:47 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id s5so3837950uad.4; Mon, 18 May 2020 11:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=McIO47M9eyR4qoMmnhkkHajCvKlsIkHT/QjjiNGdJOM=; b=RwKqq7808EpflVhzoQA+kNNs29ZQKHWKAqAadugObbjFDbWj3f+yCd0tBgf0cgVuRI qytRSiD4feeek9YW6Izryd02k4/etLhQhP39xLZTxjC58K+Z7wb6Vt49yZt4ZRJFIz/n kZNmhdFJdu7zE90mCOT+kEoEb8M5B1LagKPZ+zh5ocwQVk9a+NvA540q0f0gWqMOut2j dp/VO2P3wnwhcdhHtPNignswPOt6iRAKY02alHe3DkDEq2NdMGFVQznoWgDTyQFNM6Cu r77vg+rjqp/ZVkI+M0pcc3K9oHtHe6ZzTQjsVzf4zSLHZ/snwL4WXPZYyog250I7ymfT JFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=McIO47M9eyR4qoMmnhkkHajCvKlsIkHT/QjjiNGdJOM=; b=i5pdo+i59ifBbIndIsXkywGovMKQ1zeK3j6PmzFU4HshitBcLgfYlREpIQ/FPGaaYM adqRU9fdBNHmFUSoCo1uswWSsn8FLsiDTZZA3hCH433xKgck0trPLhCsUXwT/HF6Vrvr S7wiqZ3uKYB5CK5RbdAwgjygVnsznymc1M1dZhVs1Zy4xZan/5qEbAMDIDleWTuQgkZi V+5vwVDfbAC81wgLaXep6eLYI17bquN5eGwB9/cPuEBMDHb9zl0gaKib5l2YqYcVupS0 xsBCbwjOxN0XsIDK91puCozhM0Z/pUXAYXWKpbQ8uMfCZd/Ntq2UJ3XjU/Qmxc/slDDZ xkAw== X-Gm-Message-State: AOAM530T0bRsQaLymGNln+m+dK9vR6MBhhr9Y/1pHkYB5iihPUMSOsYp RWUd3FxsZKSIr5aKU+Ngn1vyNyeCg20/w1OH6dQ= X-Google-Smtp-Source: ABdhPJysFG1byBoURHsr9DAGbyBAvuXDMYJ2rHSXEMm/eCXfAa2Lgf7k80M9eC8t+ExD2Ase9sp21d9MH6muPVDZMFY= X-Received: by 2002:ab0:6ed0:: with SMTP id c16mr10201683uav.62.1589826646756; Mon, 18 May 2020 11:30:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 18 May 2020 11:30:35 -0700 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="00000000000088cf6d05a5f05cd2" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 18:30:50 -0000 --00000000000088cf6d05a5f05cd2 Content-Type: text/plain; charset="UTF-8" On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > I support adoption by the WG, believe it is suitable, and am willing to review and contribute text. Brian > This call for adoption ends: 1 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000088cf6d05a5f05cd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 18, 2020 at 10:50 AM Tim = Wicinski <tjw.ietf@gmail.com&g= t; wrote:

All,

As we state= d in the meeting and in our chairs actions, we're going to run
regul= ar call for adoptions over next few months. =C2=A0
We are looking for *e= xplicit* support for adoption.


This starts a Call for Adoption f= or draft-andrews-dnsop-glue-is-not-optional

The draft is available h= ere: https://datatracker.ietf.org/doc/draft-a= ndrews-dnsop-glue-is-not-optional/

Please review this draft to s= ee if you think it is suitable for adoption
by DNSOP, and comments to th= e list, clearly stating your view.

Please also indicate if you are w= illing to contribute text, review, etc.


I support adoption by the WG, believe it is suitable, and = am willing to review and contribute text.

Brian

=C2=A0
This call = for adoption ends: 1 June 2020

Thanks,
tim wicinski
DNSOP co-c= hair
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000088cf6d05a5f05cd2-- From nobody Mon May 18 11:39:53 2020 Return-Path: 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 346633A0AC9; Mon, 18 May 2020 11:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Tb1zP5MP09hq; Mon, 18 May 2020 11:39:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5764A3A0AB9; Mon, 18 May 2020 11:39:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49Qnqj4cTZzDjV; Mon, 18 May 2020 20:39:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1589827185; bh=XsxbqZM/zNlqZhtSOj6iEjMcOCvofN1iqiHgDhol9gQ=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=dVQk92Y9VJY8ESabVqV7iVEgTGa5yec/0T5LALrAtzKoueT6TzUyobyxZU+hn2czV NMrLhT+Fkz61UGHoyEC/l9uXOs+K2jv7p5NQzUctCnU9YNqbccV/H+GlROppwbuAUt uL2qSoqjXPoVWmk+zAQ9aVLX25VjnTRdYnQYEnbg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Bj5YZXSMbvlV; Mon, 18 May 2020 20:39:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 May 2020 20:39:43 +0200 (CEST) Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id E7A5B6020D59; Mon, 18 May 2020 14:39:42 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3C3A3A4B-97DE-4C6C-BFE9-A3952FA58C2C Content-Transfer-Encoding: 7bit From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Mon, 18 May 2020 14:39:41 -0400 Message-Id: References: Cc: Tim Wicinski , dnsop , dnsop-chairs In-Reply-To: To: Brian Dickson X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 18:39:51 -0000 --Apple-Mail-3C3A3A4B-97DE-4C6C-BFE9-A3952FA58C2C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In favour of adoption but like to see text from both AUTH and recursive beha= viour. Not convinced the situation should be this black and white - eg perhaps part= ial glue would be enough not to require TC=3D1 or behaviour for resolvers co= uld be a little more advanced to try with partial before going to TCP. If my request seem stupid, the draft needs clarification for stupid people l= ike me :) Paul Sent from my iPhone > On May 18, 2020, at 14:30, Brian Dickson w= rote: >=20 > =EF=BB=BF >=20 >=20 >> On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote:= >>=20 >> All, >>=20 >> As we stated in the meeting and in our chairs actions, we're going to run= >> regular call for adoptions over next few months. =20 >> We are looking for *explicit* support for adoption. >>=20 >>=20 >> This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optio= nal >>=20 >> The draft is available here: https://datatracker.ietf.org/doc/draft-andre= ws-dnsop-glue-is-not-optional/ >>=20 >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >>=20 >> Please also indicate if you are willing to contribute text, review, etc. >>=20 >=20 > I support adoption by the WG, believe it is suitable, and am willing to re= view and contribute text. >=20 > Brian >=20 > =20 >> This call for adoption ends: 1 June 2020 >>=20 >> Thanks, >> tim wicinski >> DNSOP co-chair >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-3C3A3A4B-97DE-4C6C-BFE9-A3952FA58C2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable In favour of adoption but like to see text f= rom both AUTH and recursive behaviour.

Not convinced the s= ituation should be this black and white - eg perhaps partial glue would be e= nough not to require TC=3D1 or behaviour for resolvers could be a little mor= e advanced to try with partial before going to TCP.

If my request seem stupid, the draft needs clarification for stupid people l= ike me :)


Paul

Sent from my iPhone

O= n May 18, 2020, at 14:30, Brian Dickson <brian.peter.dickson@gmail.com>= ; wrote:

=EF=BB=BF


On Mon, May 18, 2020 at 10:5= 0 AM Tim Wicinski <tjw.ietf@gmail.c= om> wrote:
=

All,

As we s= tated in the meeting and in our chairs actions, we're going to run
regula= r call for adoptions over next few months.  
We are looking for *exp= licit* support for adoption.


This starts a Call for Adoption for d= raft-andrews-dnsop-glue-is-not-optional

The draft is available here: <= a href=3D"https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-o= ptional/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-andrews-d= nsop-glue-is-not-optional/

Please review this draft to see if you= think it is suitable for adoption
by DNSOP, and comments to the list, cl= early stating your view.

Please also indicate if you are willing to c= ontribute text, review, etc.


=
I support adoption by the WG, believe it is suitable, and am willing to= review and contribute text.

Brian

 
This call for adoption ends:= 1 June 2020

Thanks,
tim wicinski
DNSOP co-chair
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP m= ailing list
DNSOP@ietf.org
https://www.ietf.= org/mailman/listinfo/dnsop
= --Apple-Mail-3C3A3A4B-97DE-4C6C-BFE9-A3952FA58C2C-- From nobody Mon May 18 14:05:55 2020 Return-Path: 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 A9F073A0D3D for ; Mon, 18 May 2020 14:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=kumari-net.20150623.gappssmtp.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 Pim9aMn0QJlG for ; Mon, 18 May 2020 14:05:52 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 D98E83A0D19 for ; Mon, 18 May 2020 14:05:51 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id c12so5881686lfc.10 for ; Mon, 18 May 2020 14:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ly8qTHzauUTmZodDQVHfG8Nl9e99J1FwOjDdUSvbJpI=; b=yiXnXJRyr6neFh3IXJ++9Lyf3cvBC3xybxA3XFqmwjDwd1Wf/IYvijSgHuS+aqgEb2 UHBAEEhfj2F0BQ9sen+OLI7YN46G+tJbrY9XnDQ0yI7MxwFGnjlJi5mklPmUi8kANC4Q BdVXVm+UwBlAQepf+XdjUA43YYJnHs7fergQ7xaOIGPassNhazfQK8rA1FycfszGvQKU 6OW/dvYjYc2Qv4VjkBWKN8Zc8KbJkWjtNqTP1bwyrJoGBI1Gm4iWCIqWablKvE5IwIfk jngpdXJrfy1sNU0H0v+nIDUmIveseM+hP4xQYJEswDcmLipRxjZBkgIgZW1FKh3GH/dK R+Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ly8qTHzauUTmZodDQVHfG8Nl9e99J1FwOjDdUSvbJpI=; b=Kb/dH31tu0M7JoytSwfUWw49O8NBpt3Lq3jQmHnQseIWb72RCsBBrySVBjisyNdMsW fJ3WaDiF4g/O+3RuifEsRXb9T8AYwHnfMQ2+4UUU+x2hq2f2kQBG1c5pCmfckxGqKdP8 C8tVHjd3UN33WyluLZ2NbR6Mnv/RnDAmGHNbhEfTpp9dNiiIa4c75kMRusIw6Z6Xh056 MiWiaGGHafLJKkHXjG8B/b6tClYz4qU68uPY3Xc46y4Rtuc9Iy0MLKfcr6bXgZe9Vi6C 73eQgwW1s7gG+VGP6W7epLx0HkaKE0IqSBz7dZAtIVBqkE1eqd+kjSJTnPt969Xojblb 8RVA== X-Gm-Message-State: AOAM532XWdH4ISomqidSVI6P9r4y4QEUAakiW+0yzDQ2CwxRJUWULxhM 8fEciVIOaWSb/Ubb0o7uEzyokd0ey+2ef/+bltCVs++FQ4w= X-Google-Smtp-Source: ABdhPJzxPK5hJdZywlhwHK0jllE2Ko1KxSnvOOIPjCDJibGut0FlwY4WHIUTvwg5d3MdyPOLsmU6uGlVJcv4FgIr+HY= X-Received: by 2002:a19:987:: with SMTP id 129mr12796656lfj.8.1589835949317; Mon, 18 May 2020 14:05:49 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 18 May 2020 17:05:13 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="00000000000002b50405a5f28779" Archived-At: Subject: [DNSOP] A quick update on ICANN SSAC and .internal... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 21:05:54 -0000 --00000000000002b50405a5f28779 Content-Type: text/plain; charset="UTF-8" Hi all, I'd like to provide an update -- back in July 2017 I published https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00 . This was presented at IETF100 (slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-wkumari-dnsop-internal-00), and my reading of the feedback was that I should take this to ICANN (Jim, Joe, Andrew, Olaf, Ed Chung) -- feedback starts at: https://youtu.be/DjbBQDMGf9s?t=7921 I followed the DNSOP direction, and ICANN SSAC is currently working on an advisory on this topic (which SSAC hopes to have published soon). Due to confidentiality expectations[0], I have refrained from / limited my discussions on this, but the fact that SSAC is working on this is in the slidedeck from ICANN 67 - https://static.ptbl.co/static/attachments/237788/1583951065.pdf?1583951065 . W [0]:I checked with the SSAC Admin committee before sending this to make sure it was OK. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000002b50405a5f28779 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,<= /span>

I'd like to provide an update -- back in July 2017 I p= ublished
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00=C2=A0.
This was presented at IETF100 (slides:
https://datatracker.ietf.org/meeting/100/materials/slides= -100-dnsop-sessa-draft-wkumari-dnsop-internal-00), and my reading of the feedback was that = I should take this to ICANN
(Jim, Jo= e, Andrew, Olaf, Ed Chung) -- feedback starts at:
https://youtu.be/DjbBQDMGf9s?t=3D7921

I f= ollowed the DNSOP direction, and ICANN SSAC is currently working on<= br style=3D"font-family:Arial,Helvetica,sans-serif">an advisory on this topic (which SSAC hopes= to have published soon).

Due to confidentia= lity expectations[0], I have refrained from / limited
my discussions on this, but the fact that SSAC is working= on this is
in the slidedeck from IC= ANN 67 -=C2=A0https://static.ptbl.co/static/a= ttachments/237788/1583951065.pdf?1583951065=C2=A0.

W

[0]:I checked with the SSAC Admin committee before sending this to mak= e sure it was OK.

--
I don't think the exe= cution is relevant when it was obviously a bad idea in the first place.
= This is like putting rabid weasels in your pants, and later expressing regr= et at having chosen those particular rabid weasels and that pair of pants.<= br>=C2=A0 =C2=A0---maf
--00000000000002b50405a5f28779-- From nobody Mon May 18 15:38:51 2020 Return-Path: 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 908693A08CB for ; Mon, 18 May 2020 15:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 Lbhi7FJot7Vo for ; Mon, 18 May 2020 15:38:48 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 E43E73A08CA for ; Mon, 18 May 2020 15:38:47 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id x23so4019557oic.3 for ; Mon, 18 May 2020 15:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1J2GklB1V7w0wACAKIBDVfPIEy6LZImXyMcCPcQUSp0=; b=YSjOoEXnV4PcmxF2flwjXYtjaMcimCtKgEU4yX5fe5Bh6nBL2nPSOfhoS3sotjojcb gli1c/QFmGGtyKA4t5CnDVmoqewlZ1s05w3ZmM9PZsTt9e2ohN0LlDoP0israxGAy9QE 3xNRneUx9iEnIpxhx41NRzzo/1bzVMva4sH2It2D/+KQpz1OD//wuKsi4tszH3JphtQ+ 72DaNrnOhYFfOl+GfPYs3HCT1/KjzDwZukYUWC8sL5f4YgBNkOhXPY++MzWLa7TACQig f6MSKdDj4icP0m4AmTWLinZyH89wRjyitP+3hKaKrh8rQUQJQ4elX65g/xCP5NV52Q2m y0wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1J2GklB1V7w0wACAKIBDVfPIEy6LZImXyMcCPcQUSp0=; b=rW2y0UVm++OQeVaJqi5EXJcrpEo2J6Q2JeqF1OPtnJhNKWkMI+Ja2wwuRoh2jXGCOJ O/WvJf6BiN6b3FpBCfsUPabEWfAB1wx5CFEvd9wlEsY7gJ0Pz71JkmFgQ5gLANly8j7Z pwMKhAll0JG3lUVPRWnRtZiYz0NeJGCb77fQFEr4vVVgKEwNIHCmjfAgGiHwDZns4eDT XIFIJxklDAsr+k7ID6ULK3p8+4JSbHjq9BgO88i3+9ZDgD5hs9XUspQ6AtTBH9O6QryB Div2ppIzNK6Oy58vK8y3b1a6in+FkHboD2ubc2J4bw0qjlgr41CxACJkyKIVpifucOHD v7yw== X-Gm-Message-State: AOAM532/xDLRVowSFJ1KlTETRt7NqB9o2/BMbkSeTQBmOL2q/KIVokeo V58dRfk14rkWcpqGgYVcsOAsqS6NhN0P+U857dqAg4Wyhzg= X-Google-Smtp-Source: ABdhPJzX0trVOOpqx45GEFJeQ/uii7udYstnGdMBrtVAuO8x0UeA62GI1AkgHZroJzIwG5s5FxoIknkuzOl0sTlx1iw= X-Received: by 2002:aca:518c:: with SMTP id f134mr1208424oib.6.1589841527044; Mon, 18 May 2020 15:38:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 18 May 2020 18:38:36 -0400 Message-ID: To: Paul Wouters Cc: Wes Hardaker , dnsop Content-Type: multipart/alternative; boundary="00000000000077fbe305a5f3d303" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 22:38:50 -0000 --00000000000077fbe305a5f3d303 Content-Type: text/plain; charset="UTF-8" All This call for adoption ended last week and the chairs were very much on the fence over adopting this document. We went to our AD to help decide this and after some poking, this was what we received: I too would like to have seen more support, but I do think that the selection and "strength" of the support messages makes this OK; I tend to side with Warren's view on this, so we're going to adopt this document for now, and we'll see how the working group works on it. tim On Tue, Apr 28, 2020 at 5:17 PM Paul Wouters wrote: > On Tue, 28 Apr 2020, Wes Hardaker wrote: > > >> We are looking for *explicit* support for adoption. > > > > I support it, though I'd feel more comfortable hearing from operators > > that want to deploy it. I suspect there are many, but that's just > suspicion. > > I think you really mean IPAM vendors? Like is this something Infoblox, > bind, Bluecat and BT and Microsoft would want to incorporate into their > enterprise products? > > Paul > --00000000000077fbe305a5f3d303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
This c= all for adoption ended last week and the chairs were very much on
the fence over ado= pting this document.=C2=A0 We went to our AD to help decide
this and after some poki= ng, this was what we received:=C2=A0

I too w= ould like to have seen more support, but I do think that the
selection and "strength" o= f the support messages makes this OK;

I tend to side with Warren's view on th= is, so we're going to adopt this
document for now, and we'll see how the wor= king group works on it.

tim



On Tue, Apr 28, 2020 at 5:17 PM Paul Wouters <paul@nohats.ca> wrote:
On Tue, 28 Apr 2020, Wes Hardaker= wrote:

>> We are looking for *explicit* support for adoption.
>
> I support it, though I'd feel more comfortable hearing from operat= ors
> that want to deploy it.=C2=A0 I suspect there are many, but that's= just suspicion.

I think you really mean IPAM vendors? Like is this something Infoblox,
bind, Bluecat and BT and Microsoft would want to incorporate into their
enterprise products?

Paul
--00000000000077fbe305a5f3d303-- From nobody Mon May 18 16:41:34 2020 Return-Path: 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 B8B9D3A0BEA; Mon, 18 May 2020 16:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-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 LslAm_I8-4m7; Mon, 18 May 2020 16:41:31 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720433A0BE9; Mon, 18 May 2020 16:41:31 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 140DEB074A; Mon, 18 May 2020 23:41:29 +0000 (UTC) From: Paul Vixie To: dnsop Cc: dnsop-chairs , Tim Wicinski Date: Mon, 18 May 2020 23:41:28 +0000 Message-ID: <2079230.6TsT3RLsXa@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 23:41:33 -0000 On Monday, 18 May 2020 17:49:04 UTC Tim Wicinski wrote: > ... > > This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. +1. long overdue after false starts by me and others. > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 June 2020 i'm willing to review. -- Paul From nobody Mon May 18 17:37:07 2020 Return-Path: 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 0F9683A0D95 for ; Mon, 18 May 2020 17:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=p1vvYxoI; dkim=pass (1536-bit key) header.d=taugh.com header.b=WZKKroi3 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 BmP-Tp4vTu88 for ; Mon, 18 May 2020 17:37:02 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 784B13A0D91 for ; Mon, 18 May 2020 17:37:02 -0700 (PDT) Received: (qmail 41915 invoked from network); 19 May 2020 00:37:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a3b9.5ec32a2d.k2005; bh=9KHpOrli5U4YoKRustPgc8F0Asy1FB9u8hTHoPTrNLk=; b=p1vvYxoIwxtxYSxM5fZIC3jXRmECf8plIpNKVy9cb91gsNHUazk3EEB4EryKTO26q/2DPJ3+++wr0Kep/5R8ueq7Haneblqi+RgMxgMgfUb3kpUtko7q6YJWCpnaPkeiZDrvUYaf4P2/ix93Sv4c2lDkrDwo9QH/VeK9unVgVEnTVgq26rB+t0sztwJSVYcSdDwjNWQ6nF2MtNbzspfKDuQ4pVuB2A/h+D1Ypyp4bZYfJOS9xZszfwbWmLWN8K6u DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a3b9.5ec32a2d.k2005; bh=9KHpOrli5U4YoKRustPgc8F0Asy1FB9u8hTHoPTrNLk=; b=WZKKroi3K5kRqA8zSvITotfyn7l10ymMMd8rhl7hBzoXNdz2ZO6V00EpLRN/5Uah+rjwE26vrRTTuIxsZ/FdA0YcrwHC9W6vtSx1pbwGaHPga0WqAECkexb4NMcADUOX00nOH6sJ0QE/8R6eZfqVc4MR4rHoswebxRLGXV/Dn4BtzebY1kZlMzitT2ens3bTp7p7NlxImVEADE2D0qrmAXe/wogazLXkErZaIRrz71EB+ugotidYh5MYrUzZUyEp Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 May 2020 00:37:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 05FD119711F6; Mon, 18 May 2020 20:37:00 -0400 (EDT) Date: 18 May 2020 20:37:00 -0400 Message-Id: <20200519003701.05FD119711F6@ary.qy> From: "John Levine" To: dnsop@ietf.org Cc: paul@nohats.ca In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 00:37:05 -0000 In article you write: >Not convinced the situation should be this black and white - eg perhaps partial glue would be enough >not to require TC=1 or behaviour for resolvers could be a little more advanced to try with partial >before going to TCP. > >If my request seem stupid, the draft needs clarification for stupid people like me :) The draft, which I hope we adopt, could use clarification if that seems like a good idea. Imagine you have foo.example with two nameservers, ns1.foo.example and ns2.foo.example. Client looks up something.foo.example, server returns a referral with two NS records but only has room for one A record for ns1. The Internet is having a bad day and ns1 is unreachable while ns2 is fine. Since there's no TC=1 the client has no idea that requerying would return the A record for ns2, so it wrongly assumes ns2 has no A record and the domain is kaput. It can't separately requery for ns2, since who would it ask? It's fine to return a partial result with TC=1, that's always been the case. R's, John From nobody Tue May 19 00:44:20 2020 Return-Path: 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 6F9403A12B8 for ; Tue, 19 May 2020 00:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 (1024-bit key) header.d=nlnetlabs.nl header.b=lH5Jvm1u; dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=MIxV8Xru 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 mozMr83em8W6 for ; Tue, 19 May 2020 00:44:16 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 191EB3A12B7 for ; Tue, 19 May 2020 00:44:16 -0700 (PDT) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 09B2416BBC; Tue, 19 May 2020 09:44:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589874253; bh=tE9yq8S3K0lR0Ev1J5I3SeaytdLe/Q4M2jTLr1/lDPU=; h=To:References:From:Subject:Date:In-Reply-To; b=lH5Jvm1unExXUkO1yQd8bWbb0m4MsIq8ouozCY0tYkb/FVJEY+rZiUa6GZwEnu1ld FYdoYtZ8UhIDAKTHWTXU1TD5W080SXecKEmeMRof3zVDM3UCiA/v7+g29Vtdq1Momy oZ/xtx5qzQYqPlZOrquL4Jfg/QhsSJ8uK4vcb88k= Received: from nagini.nlnetlabs.nl (nagini.nlnetlabs.nl [185.49.140.134]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id 38D9E16BBA for ; Tue, 19 May 2020 09:44:12 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=berry@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589874252; bh=tE9yq8S3K0lR0Ev1J5I3SeaytdLe/Q4M2jTLr1/lDPU=; h=To:References:From:Subject:Date:In-Reply-To; b=MIxV8XrubH+laEJgvxm0g2jv0wWuqHOD5jF89wYFliiQh9W0bvTVd2KU9ZNApCwmG J2MNQ53gxpwH2ndZsyEWT/y+J8Tu0s7M2JWa5NjPZNjp6hDzKGcu+hbzIxL6tvhmD9 Yiy7A2cEFTQh7xH+DqdejmYgzYyR2WlLGe+5upuA= To: dnsop@ietf.org References: From: "Berry A.W. van Halderen" Autocrypt: addr=berry@nlnetlabs.nl; prefer-encrypt=mutual; keydata= mQENBFR8e+MBCADL+8Ah1Erj+E2z19Bk7RvCza96twZDN6DDOM4NBYbzPhPFN+L4brYMjqFs 1U8OPxQhf1bcAS9ruDgK1oEMJ5CWMDkSapIOdLgPu02cAOOPko3KwtzcKwDJdZnjhSHwGsGF OKqE5sqJuUeEs5ztvEtXDpcGazzEyv/KvkWixQQyrMenr+q4Ka/w6kV3YcDTe58Ondfw4+tu sbWrqVe7MdBoFq4zDQIHLf8iuhCdwp8KCRDUI14OIo+5EuN02CF0t1dKU1wZdRWnNyQ5rO7D HDQekphPr1e17xvMvBJ8gZWyAw6PN3Vkl0e0NpiCzOlhL0t8tL3iEM9t7L46bPubHdW/ABEB AAG0LihCZXJyeSkgQS5XLiB2YW4gSGFsZGVyZW4gPGJlcnJ5QG5sbmV0bGFicy5ubD6JATgE EwECACIFAlR8e+MCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGhT7MajGDIncq0I AJHLqL+rIwXIahdlEIe2UczBfLfZOW/a3+S6x3TeTcC0CbBFiSxqRNryMI8ubJGJQOwX56eO xQW36edwG8rgHpQza5pObsv8APdM2bXuEuncNVp+v12Gg6W+QWwmgPk0mKOmZ6mz6PKl7nwQ E4yT5DoFMNwl9Y9sf2VhaMLbHiMh2ZxHOmAf6phE5ioXNaO6mDD24xsDD1RYIaDc3HKbpPxF rttGD1m55bff0DefnTfGspX+ogstwnl9nInW6Ae+1EoC6aG1Z46/TzPGLWCtpNMdjQWsi1YA Uv3UeEzf9M38QK7HBXe+Ey4IdxwYpCbx7UwoT+LR6YQM/7rZ+x3ZEgC5AQ0EVHx74wEIAMch p6EiZJqUbB4Z3atzTBimrCd2xBwy474oQSdqioHqoiEZywWBAR7OBv3scqOEELwPqej7dE/I 5RaNQlm5sSgHsFFs7TmHzDRCpMByL7dC+dKkPwmnZViSviOc789tlIXgGpYDiLkt2bKxwdP3 9bFLRT0vORRgO+c3rp9q4xwlYKrG7sqW8u/I6Qq9FksX1R1wNyCDI72Mojq6PzRS5QGO2aZ2 YmOWnz3xUPLtqn4zk85kCbj3NdCV/ayF4QfXHYQOnZSHqdwRrAwhW1VjyZxDsrgAQbiDnGmm tU6GCPBSp9Y57ndPVTDnEMD5bil2yve0djcUTE3A7fNdn8pGiJUAEQEAAYkBHwQYAQIACQUC VHx74wIbDAAKCRBoU+zGoxgyJzl/B/wKdDFJJX3Hw/K/Q2v/0KiTYOLCYx9TZKvkQeoT27+Y dYH9Zkv+PglD1XYZGAO2JvQscrUpQYbrsjbo50pjDXZq2BZ1mHGxTnZXm+fMBMIM4DzmDvFj X4EKFdb9PG9mhEJJE84aQ5/bg68Ze3PMuCcrJkjS+B3101Tt0BI/Y3sXaUIncurEd1EURDyy 4tPkKWZzpLkJsGo+juIYWxOZ9SS2P+g1ba+ye7zcOu77jD699v+xRgAuexyZSXnnUNGfY41R jtQ7NqXS5p3KANtnwmXDbWhdeIZFtL+muVyGC1yvVqoyc9Zha2IQmkYK0cGCbnJWLQkyoL3u j7Xywxer6Voa Organization: NLnetLabs Message-ID: <6b805dfe-d33a-53a3-3fc1-38d5b7fb8b39@nlnetlabs.nl> Date: Tue, 19 May 2020 09:44:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-pusateri-dnsop-update-timeout X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 07:44:17 -0000 A bit of a late input, because well,.. the known. For most of the software stack of NLnet Labs, the update timeout isn't too relevant, as dynamic updates aren't there. Dynamic updates, and thus the timeout would be most relevant to OpenDNSSEC, and dynamic updates are on the list. But I tend to agree to consider this feature pull driven. I'm not sure how effective this feature is without clear user want. Since explicit adoption means, in my book, to implement this shortly as well, I rather wait on the above. BR, \Berry From nobody Wed May 20 11:16:07 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB73A098E; Wed, 20 May 2020 11:15:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <158999855128.27433.564716276484439989@ietfa.amsl.com> Date: Wed, 20 May 2020 11:15:51 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 18:15:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Interoperable Domain Name System (DNS) Server Cookies Authors : Ondrej Sury Willem Toorop Donald E. Eastlake 3rd Mark Andrews Filename : draft-ietf-dnsop-server-cookies-03.txt Pages : 16 Date : 2020-05-20 Abstract: DNS cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of denial-of-service and amplification, forgery, or cache poisoning attacks by off-path attackers. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. This document updates [RFC7873] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 21 05:23:49 2020 Return-Path: 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 1C4B73A0C19 for ; Thu, 21 May 2020 05:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 YgD19z94zm8R for ; Thu, 21 May 2020 05:23:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 D2B1D3A0C18 for ; Thu, 21 May 2020 05:23:40 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:b882:23f3:9ccd:6a68]) by mail.nic.cz (Postfix) with ESMTPSA id 8D21213FE04 for ; Thu, 21 May 2020 14:23:37 +0200 (CEST) To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: <7dd08da3-72f8-f25a-c6be-4ff7f76a4084@nic.cz> Date: Thu, 21 May 2020 14:23:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 12:23:48 -0000 On 10. 04. 20 15:45, Shumon Huque wrote: > Hi folks, > > Paul Vixie, Ralph Dolmans, and I have submitted this I-D for > consideration: > >    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 I would appreciate a practical example of changes envisioned in the following paragraph: > A common reason that zone owners want to ensure that resolvers place > the authoritative NS RRset preferentially in their cache is that the > TTLs may differ between the parent and child side of the zone cut. > Some DNS Top Level Domains (TLDs) only support long fixed TTLs in > their delegation NS sets, and this inhibits a child zone owner's > ability to make more rapid changes to their nameserver configuration > using a shorter TTL, if resolvers have no systematic mechanism to > observe and cache the child NS RRset. Could someone please post an example in steps? Something like: - time 0, NSSET parent = {P0}, NSSET child = {C0} - time 1, NSSET parent = {P1}, NSSET child = {C1} ... along with textual description what operator is hoping to achieve? It would help me to appreciate the value of the proposal. Ad 4. Delegation Revalidation: I agree with author's note "we would prefer to discard the extensive mechanism" but the simple mechanism has simple description for me to understand consequences. > The simple mechanism: > > o Cap the time to cache the child NS RRset to the lower of child and > parent NS RRset TTL. The normal iterative resolution algorithm > will then cause delegation revalidation to naturally occur at the > expiration of the capped child NS TTL, along with dispatching of > the validation query to upgrade NS RRset credibility. So far so good, but it does not specify what should happen with RRsets other than NS. Even if nothing is prescribed please state that explicitly. Most importantly: - Does the NS affect maximum TTL of _other_ data in the zone? - If it does, doesn't it increase risk of thundering herd behavior? - If it does not, is it even worth the effort if attacker can put week long TTL for A/AAAA and keep using that? - How should resolver handle RCODE=NXDOMAIN? Should it have different effect than changing NS set to different set of servers? Or change in DS record value? For me personally mixing two problems (GHOST domains and NS inconsistency) in single proposal does not help me to understand reasoning behind the proposal and its intended effects. Take care. -- Petr Å paÄek @ CZ.NIC From nobody Thu May 21 07:41:27 2020 Return-Path: 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 1C4DD3A0CF0; Thu, 21 May 2020 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 0IQUGgGLNnnu; Thu, 21 May 2020 07:41:25 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36A93A0D16; Thu, 21 May 2020 07:41:24 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 34512219AE; Thu, 21 May 2020 07:41:20 -0700 (PDT) From: Wes Hardaker To: Tim Wicinski Cc: dnsop , dnsop-chairs In-Reply-To: (Tim Wicinski's message of "Mon, 18 May 2020 13:49:04 -0400") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Date: Thu, 21 May 2020 07:41:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 14:41:26 -0000 Tim Wicinski writes: > We are looking for *explicit* support for adoption. Yes please! -- Wes Hardaker USC/ISI From nobody Thu May 21 09:03:36 2020 Return-Path: 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 C84A83A0836; Thu, 21 May 2020 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 2XyfUog2Op5L; Thu, 21 May 2020 09:02:55 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 835E33A041D; Thu, 21 May 2020 09:02:54 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id k4so2726310uaq.10; Thu, 21 May 2020 09:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CZyc08jXB4ekXSwUmWA0m/4nBU3peWJ5TN2cEIoU9Co=; b=i/Wmy+wvBKrlYlTIGOSwhj9P8lV3W3OpueEb6AspjNDwdWUAoBVybW5WHp9jCdraRA 9e7JM/NLIwahSM4XUX6eeFAsVHJnwsdMg/PmkECPPNDKccdyPmyVcK9/D7rOOom53y1Q uluuPHyekypFrG6jBD2onqHOih391tvumUkMTCqxyONppU9uCOWWLGo20TF3Y8tTf5Z5 Q4Zc/ypth4e1cWv/hISu4aObd0VBoRott+oydS7kXyQQElHToMyYpuqPeYh7hc+uTof+ Y1rYGvtkcpAKrJJEsx+Am7SNFokBuHSgkKcgNMXr37yjMQIFv3sNP3+wgLXBMfAZcQkC riBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CZyc08jXB4ekXSwUmWA0m/4nBU3peWJ5TN2cEIoU9Co=; b=s1QzOkeoq6TpRE2aaXfn37FoQkx4vQAHM7Gmc+DOaIbSGKlj7YxBPShpwoChvk+MZP pkdV7UQZtTH5EhG1vqzFyasv7cWjzLtbsJEwAK3Ec8qVMEgiD5KU1Jy9E1eGUq6iWwiN HE7YCdoGpnq/r3sT0kKtA6G/pNrQkC66EDg6y4RkzQnASq5a2pMzjjQiFE+r0RqAmILj Jl4dvwpuFkxEEjexxDwVJT5SqmXbekKIsP2jVGyXr/I8OWf2+RxtC7PrKTj+PAcJja2o d7blSkivlGu33NMGSrc8IVam0bbGLZpMiB0gIlPG4jYC6ZlEK3Y9GdSLaOr4Gf+hQo7D QzCw== X-Gm-Message-State: AOAM530eyqH3HEwoE7aXNKAZMIiqKwMBhuANiKh4tRgCR8iRH9r+gBN6 o798AdR0UDR16fabTk4DKwIpv4F3Xsb8rJannjg= X-Google-Smtp-Source: ABdhPJxOSscXCbrsMzuqrFuy+1H6x/WgZi+1ZuKuMLSak1GMGmkw6Eu/HOO0iK4ASicF53Fd9BBKdNDF0lhGvPIj8EE= X-Received: by 2002:ab0:2c02:: with SMTP id l2mr7629957uar.66.1590076973211; Thu, 21 May 2020 09:02:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Thu, 21 May 2020 12:02:42 -0400 Message-ID: To: Wes Hardaker Cc: Tim Wicinski , dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000002763d305a62aa56c" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 16:03:03 -0000 --0000000000002763d305a62aa56c Content-Type: text/plain; charset="UTF-8" I am supporting adoption. Yours, Daniel On Thu, May 21, 2020 at 10:41 AM Wes Hardaker wrote: > Tim Wicinski writes: > > > We are looking for *explicit* support for adoption. > > Yes please! > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson --0000000000002763d305a62aa56c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am supporting=C2=A0adoption.=C2=A0
Yours,=C2=A0
D= aniel

On Thu, May 21, 2020 at 10:41 AM Wes Hardaker <wjhns1@hardakers.net> wrote:
Tim Wicinski <tjw.ietf@gmail.com> writ= es:

> We are looking for *explicit* support for adoption.

Yes please!
--
Wes Hardaker
USC/ISI

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Daniel Migault
Ericsson
--0000000000002763d305a62aa56c-- From nobody Thu May 21 09:10:12 2020 Return-Path: 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 D635B3A0404; Thu, 21 May 2020 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 50Hdqo3rJgvA; Thu, 21 May 2020 09:10:08 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 6B7923A053E; Thu, 21 May 2020 09:10:06 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a2so9444817ejb.10; Thu, 21 May 2020 09:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gpg2TG/hvZmLbs6ESI6EGOcOKqma07uPenvqmSMsqVs=; b=NhKRDBaZsNV0e8EXGWML5q3ZZjuxNIIjf4ClHbKaGhSPf+9ACjn3eb7VRa2GV0CRJb p1E//7QVY4xbFktWdhXl/4aHvQDdFDAfaWsVV6s+GrsxL3sDp8bqAYAylVyKuNuRy3Ty E35UmAp8lxJFSbmItz5ACdTLr+/pXddzegnCoIyMuL0y/7ELR/G9+/7vYNP6UdHBJoZW oZnV2Qu2Bh9Uxccmd8q6s2udf1mgbIY7wH6B0q7FpO9U3O2mfPjE1+seEvsY8Klzp/rW Zr1vZNver1GfQyTAA+iwvK25Lnt/DGgXZsq0UTXuq7uNmnKym9VyDx7nHmajI2j0X3UA EwDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gpg2TG/hvZmLbs6ESI6EGOcOKqma07uPenvqmSMsqVs=; b=ag4m1Oi8wmKcCZulrzA40ObXHqU9ZE9P0gkoCdFpm2iy3dwbU00VBTz35HKl6zr4px A9BAC6I1x1gRNZ2Cj2aWJpN42eAsfcZmtBVRYmd7fH4tg0weAj7EjFJDqC5qsxBG9sXt LrlZHVBUK38as3hPl0/PwayH26yEw0OGU3tV2aGX6hgDrZtdUSOu/nb32QBwjF0oIuFB R+ASPx+wybzXjA3hsyZ3qJycHrQxPvx6VxyOxanLkVInre2EcEmU3qz5D7S+gpKsl0Hj P8GGz2MDkgygBU8uduprJBu84q+y6wHxLZqntseXXRpJ5xH3vtJ/EeCLbtoSW1Vgnzbm 4CNQ== X-Gm-Message-State: AOAM530tYi5skBQFzFP3CBFD1DUh5nkeGbcV1fQ0/mY7y4AaHw40Hoay I7jfteXQOZtjSX/tqGqepO2fsd8jAqXquDSSf2rYIw== X-Google-Smtp-Source: ABdhPJwGG+afYDlyyttDQucr4JhVsD8h8dPDoFC4PPpHb+7uO+9tAyGgWfzJh4BibJYKknYuYnyAauxYyxb9pKY3u9Y= X-Received: by 2002:a17:906:57d6:: with SMTP id u22mr4231033ejr.49.1590077404644; Thu, 21 May 2020 09:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shumon Huque Date: Thu, 21 May 2020 12:09:52 -0400 Message-ID: To: Tim Wicinski Cc: dnsop , dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000de8a4005a62abecb" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 16:10:10 -0000 --000000000000de8a4005a62abecb Content-Type: text/plain; charset="UTF-8" On Mon, May 18, 2020 at 1:50 PM Tim Wicinski wrote: > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for > draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 1 June 2020 > I've read the draft. It's a useful clarification to the spec, so I support adoption and will review etc. I have one question for the Mark A though: Since you specifically cite the example of the GOV servers, did you ask Verisign about this behavior, and if so, what was their response? Maybe this is just a bug, rather than a "widespread misbelief" about additional data & truncation that you more generally attribute as the cause for this. Shumon --000000000000de8a4005a62abecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 18, 2020 at 1:50 PM Tim Wicin= ski <tjw.ietf@gmail.com> wr= ote:
All,
<= br>As we stated in the meeting and in our chairs actions, we're going t= o run
regular call for adoptions over next few months. =C2=A0
We are = looking for *explicit* support for adoption.


This starts a Call = for Adoption for draft-andrews-dnsop-glue-is-not-optional

The draft = is available here: https://datatracker.ietf.o= rg/doc/draft-andrews-dnsop-glue-is-not-optional/

Please review t= his draft to see if you think it is suitable for adoption
by DNSOP, and = comments to the list, clearly stating your view.

Please also indicat= e if you are willing to contribute text, review, etc.

This call for = adoption ends: 1 June 2020

I= 9;ve read the draft. It's a useful clarification to the spec, so I supp= ort adoption and will review etc.

I have one quest= ion for the Mark A though:

Since you specifically = cite the example of the GOV servers, did you ask Verisign about this behavi= or, and if so, what was their response? Maybe this is just a bug, rather th= an a "widespread misbelief" about additional data & truncatio= n that you more generally attribute as the cause for this.

Shumon

--000000000000de8a4005a62abecb-- From nobody Thu May 21 13:06:13 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A443A0994; Thu, 21 May 2020 13:06:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: tjw.ietf@gmail.com, warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159009156348.13198.5866199794817499249@ietfa.amsl.com> Date: Thu, 21 May 2020 13:06:04 -0700 Archived-At: Subject: [DNSOP] dnsop - New Meeting Session Request for IETF 108 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 20:06:11 -0000 A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 100 Minutes, 50 Minutes Number of Attendees: 160 Conflicts to Avoid: Chair Conflict: dhc homenet dnssd dprive maprg add Technology Overlap: lamps dmarc acme trans intarea regext People who must be present: Suzanne Woolf Warren "Ace" Kumari Tim Wicinski Benno Overeinder Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu May 21 13:08:30 2020 Return-Path: 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 D9EB63A0791 for ; Thu, 21 May 2020 13:08:28 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=kumari-net.20150623.gappssmtp.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 i6BndQu756VN for ; Thu, 21 May 2020 13:08:26 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 29CBB3A0A64 for ; Thu, 21 May 2020 13:08:21 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id q2so9819320ljm.10 for ; Thu, 21 May 2020 13:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=91ZYkClhZUkXsTseMRdOdoVT0VTP3CKABlYnsJQP8eg=; b=EQUpSfy13gYgq0BRdj/DfKeW2RhbNoNi4Q3SSLHxTiyIj8gZhKAkQOrsvIFE5MdCss LnmGWyO2qp8dZqKgW18QT1kigMJ9gkdd3L88bHUvRdioGWiuGZjamLJ9aHVxgEAUwPl+ NAt61PkEUHAK2z2PwB0zcSdLdRMRKM7A2wxQkESOpwKWyiM+gEg5UQNlBXqyJS1fZjXX a6pTToxGDywZqtdrC8zzRw5NXL8frjfWTxa1CXIRc9DTgQa+8Ft4KrdOLMnLMWw2L98N +GdX8oqmolXVehEbNLJcbkOjPWZ4ToEJ7/fJIEU2piEXGQ0H6dbXL4YKP2oxS2S7Hhei VdAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=91ZYkClhZUkXsTseMRdOdoVT0VTP3CKABlYnsJQP8eg=; b=mnC8yODAEcgrMwRnW9klsc0NOg5seAMxRpb4tnx96KBerocKwIAzVCuciErYal1cYV lxvROLnPZUZFC6QWe5c3Xl8NJhOu7oGD0LHFIz3IrlrCih1Smy2R2LPKQoe0AT5f/vTa JeSc5uBN3lDIQ2TQSAFODrOofGXUW6Tl2psK9R7vzA3md8PVdnbEsv1nRQ6wK67+g8d+ QMQNfCM77ldUZs21BQuI3ujK/EN2jN+rrewVO9j1QPkgMUzvEMxhlK4579a2V4R05T1N PxCU/yR9PRjw+e53RqcoGoJAF0BehNioE6cAvJM8PAqhyWIpv6mrE4V3/WGKMRmOIz5E 0K0w== X-Gm-Message-State: AOAM531+U60Gnksdf8lhkeJTF5rWk8eYQiYLMwIdLwIernknO0dIWh6u 7z1Gnhu8x+0hG8ZY+EeQx+MShzvjpzdQrvG9cce8SBqmkIQ= X-Google-Smtp-Source: ABdhPJxv4i3QXiD7Sz5MggiJPbCfrocpY6wu3vYxHaeE2TebuWRGih3ickEAm0yeaWqEerkHtKYt6ZMXwpN/icwjXnQ= X-Received: by 2002:a2e:958d:: with SMTP id w13mr6070802ljh.207.1590091698221; Thu, 21 May 2020 13:08:18 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Thu, 21 May 2020 16:07:41 -0400 Message-ID: To: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 20:08:29 -0000 Hi all, I decided to start a new thread for this, because it isn't really about draft-andrews-dnsop-glue-is-not-optional - it is more of an interesting aside / rathole... What if you *only* have glue, and no authoritative answer / server? Can I register example.com, put in www.example.com A 192.0.2.1 as glue, and not bother with this whole annoying authoritative server thing? I asked this back in 2014, and was (correctly) told that this should not work - I was pointed at RFC2181, which says: "Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse." I did some testing on this back in late 2014, and the "success" rate was ~75% - this has now dropped to ~5% (using Atlas to measure). What on earth am I talking about? For the domain wow4dns.com, I have *only* got glue (answers edited for brevity): $ dig +nostat +nocmd ns wow4dns.com @a.gtld-servers.com ;; QUESTION SECTION: ;wow4dns.com. IN NS ;; AUTHORITY SECTION: wow4dns.com. 172800 IN NS www.wow4dns.com. wow4dns.com. 172800 IN NS www1.wow4dns.com. ;; ADDITIONAL SECTION: www.wow4dns.com. 172800 IN A 193.151.173.35 www1.wow4dns.com. 172800 IN A 193.151.173.35 There is no name-server listening on 193.151.173.35: $ dig www.wow4dns.com @193.151.173.35 ;; connection timed out; no servers could be reached There is, just for giggles, a webserver... Using 1000 RIPE Atlas nodes, I try to resolve the name www.wow4dns.com -- according to RFC2181 this Should Not Work(tm) -- and yet, ~3-5% of resolvers (in this run, 38 out of 984) will resolve it, and to the correct IP. This is RIPE Measurement #25400908 [0] for those who want to play along at home... The majority of these resolvers are in RFC1918 space, but there are also some public addresses, including open recursives - e.g: $ dig www.wow4dns.com @37.32.120.136 www.wow4dns.com. 86037 IN A 193.151.173.35 $ host 37.32.120.136 136.120.32.37.in-addr.arpa domain name pointer ns1.systec.ir. $ dig www.wow4dns.com @185.210.180.6 www.wow4dns.com. 84737 IN A 193.151.173.35 $ host 185.210.180.6 6.180.210.185.in-addr.arpa domain name pointer ns2.txtv-tz.com. Looking in the webserver log, there are also some hits - e.g: - - [21/May/2020:19:09:10 +0000] "GET /favicon.ico HTTP/1.1" 404 209 "http://www.wow4dns.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36" What does all of this *mean*? . . . Sorry, I haven't a clue, other than maybe: The DNS is weird. We passed the complexity event horizon a long time back... W [0]: https://atlas.ripe.net/measurements/25400908/#!probes -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 21 14:41:31 2020 Return-Path: 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 312663A0C62 for ; Thu, 21 May 2020 14:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=e3MxMVxT; dkim=pass (1536-bit key) header.d=taugh.com header.b=LFLHdRjh 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 ywC9mzVgQphc for ; Thu, 21 May 2020 14:41:26 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1ED853A0C5F for ; Thu, 21 May 2020 14:41:25 -0700 (PDT) Received: (qmail 59275 invoked from network); 21 May 2020 21:41:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e788.5ec6f584.k2005; bh=qFg1Fkbqa9ETB3DWNwgLF47/uyyfTklENvsw/Pku2HQ=; b=e3MxMVxTxXbgHSELeT2oCyh9adtOi2GMdwq/zTiXQp3OAv8qKC2aRMnZNitWlRrjnPdQz1KnGsx7mpfRCb2KFZnjrI2pa2HwiYhFvCCS64jdu4MdUS7LhNUyIoUHEVgHr385d/4bfWME2l9ySw+JdrASIoTMeEgl3c2sAKqhHndkciDLOqD6coAgCqIb31eEI0auGpDaJikGCt7qv+JBMbJjvOIImvVyMEmunCOWnfQD78Lp0u/BfyBSBZGmNSyB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e788.5ec6f584.k2005; bh=qFg1Fkbqa9ETB3DWNwgLF47/uyyfTklENvsw/Pku2HQ=; b=LFLHdRjhk0UnBC+DKkQTdORl4ubksh7t0S2/5uZ28EUY0Qyw+mhsZS6E7dcz0bhfMb7Pwgsj/3xAKmgfz0pFztJ6/T7e6koI+63zSjxevuHEimNfrrqrINxzLA3TcBdwbhBbhDRnc4LgksQpHNPB0zRzZzKw/vSNN+I/daKOgSPKzMtKYsgnLCap7HFsPuLli6brJhokCLdwWpAvfuIdrm2dQWqYIFEjRoZeVNV7Ns5D9dHiQfoNYORASJlhJkEn Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 21 May 2020 21:41:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 271EC197E0DF; Thu, 21 May 2020 17:41:23 -0400 (EDT) Date: 21 May 2020 17:41:23 -0400 Message-Id: <20200521214124.271EC197E0DF@ary.qy> From: "John Levine" To: dnsop@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 21:41:29 -0000 In article you write: >What if you *only* have glue, and no authoritative answer / server? >Can I register example.com, put in www.example.com A 192.0.2.1 as >glue, and not bother with this whole annoying authoritative server >thing? Based on my recent analysis of TLD zones, yes if the zone is managed by Afilias, or if you have friends at Nominet. Otherwise not so much. For wow4dns.com it looks pretty normal other than that your NS is lame. Here's what's in this morning's .COM zone file, but I assume you've updated the NS since then: WOW4DNS NS NS1.AUTH-SERVERS.NET. WOW4DNS NS NS2.AUTH-SERVERS.NET. Your registrar record and the live .COM NS say: $ dig @g.gtld-servers.net. wow4dns.com a ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45456 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wow4dns.com. IN A ;; AUTHORITY SECTION: wow4dns.com. 172800 IN NS www.wow4dns.com. wow4dns.com. 172800 IN NS www1.wow4dns.com. ;; ADDITIONAL SECTION: www.wow4dns.com. 172800 IN A 193.151.173.35 www1.wow4dns.com. 172800 IN A 193.151.173.35 R's, John From nobody Thu May 21 14:52:22 2020 Return-Path: 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 932223A0C06 for ; Thu, 21 May 2020 14:52:20 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=kumari-net.20150623.gappssmtp.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 QqS-yjME3u0U for ; Thu, 21 May 2020 14:52:17 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 7F62F3A0C00 for ; Thu, 21 May 2020 14:52:16 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q2so10139969ljm.10 for ; Thu, 21 May 2020 14:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3lqHYnI5umoSyvvgWA+93sq72xRrMvWRJHRN0AQ+RnY=; b=Bmj2a7kErChy+2HKvKrM+Li/yMvGIi9cvcpNOa1Cg+sStR7sO5v0RvwZA40tS3zvUt dzX3lHc3Xl4d+/2fWy7t2kUEmQFus6+iV8eGRQBBN4g8fOEYWq3aIw7+EXAFcOK5215W axsTe+45w8LnMEcU5MHj7MZMwC+w72Z72UPSONUXWQMHs63b7tg0Xm5r/LWNsfooHw+U JyK8nZy8GVqhiYuA5wdmiwWDy8FR8iXJBhpRrKOkm8YSP8JRj8d07BYarECC3BG0gngk Plp+y0oDKHFiOE5joQif2k9KQ6lsIeB8umPc4jxb8q2IOzdl4FNx8YxT/k9JGHALZG5J n3zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3lqHYnI5umoSyvvgWA+93sq72xRrMvWRJHRN0AQ+RnY=; b=jdgL2JElBByzUcykiRGFyfSUAfYubCvhBwaFuXxO9lDXQkwhapwDxlql1Ue6NwhoZg RGN+TcnRiniKEdPynyhrXrO+YpAVS96jHGe04nux3nyAjEKc86I2rR6B4GuJvyZnXfCz kUS/ltohXOYpuCLvz8qmRUztMMxKsOE4DtMpwSOtnpvFDDS965Tlw7zsgW2PPHdV05sA Ps+nDwqwP5zOzlbUqfs58cCueGXVqMtpv/Rwnj98Ntn43RpnyPpDw4KP81NScEM4LVc3 9ouUjPF0azyIdYZVWiyC6gitqaCopWnuauJcJCJOzTsBpBNXXxCyTWECUnMOz3+66j/Z msDQ== X-Gm-Message-State: AOAM530+nKDuCEkIy5kZesSHJFZWNUWK+KyD5KWudQ9c2PBZ5FcwPkmG 44lK+56yUbFK8+tQcKVuB+MnXZs10SuzJjye91Rs19xe X-Google-Smtp-Source: ABdhPJxwt2CHq8Kk6oiCQ5lbdES6hH0UyiRKYM2eAJCMTmgI7wUPYHSZOmSka8smPdr9hwW49NO13LCqiCYgnK+Z/8g= X-Received: by 2002:a2e:8654:: with SMTP id i20mr4574134ljj.79.1590097934146; Thu, 21 May 2020 14:52:14 -0700 (PDT) MIME-Version: 1.0 References: <20200521214124.271EC197E0DF@ary.qy> In-Reply-To: <20200521214124.271EC197E0DF@ary.qy> From: Warren Kumari Date: Thu, 21 May 2020 17:51:37 -0400 Message-ID: To: John Levine Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 21:52:21 -0000 On Thu, May 21, 2020 at 5:41 PM John Levine wrote: > > In article you write: > >What if you *only* have glue, and no authoritative answer / server? > >Can I register example.com, put in www.example.com A 192.0.2.1 as > >glue, and not bother with this whole annoying authoritative server > >thing? > > Based on my recent analysis of TLD zones, yes if the zone is managed by > Afilias, or if you have friends at Nominet. Otherwise not so much. > > For wow4dns.com it looks pretty normal other than that your NS is lame. > > Here's what's in this morning's .COM zone file, but I assume you've updated the NS since then: > > WOW4DNS NS NS1.AUTH-SERVERS.NET. > WOW4DNS NS NS2.AUTH-SERVERS.NET. > Yeah, that was earlier in the day (before the testing, etc). > Your registrar record and the live .COM NS say: > > $ dig @g.gtld-servers.net. wow4dns.com a > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45456 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wow4dns.com. IN A > > ;; AUTHORITY SECTION: > wow4dns.com. 172800 IN NS www.wow4dns.com. > wow4dns.com. 172800 IN NS www1.wow4dns.com. > > ;; ADDITIONAL SECTION: > www.wow4dns.com. 172800 IN A 193.151.173.35 > www1.wow4dns.com. 172800 IN A 193.151.173.35 Yes -- but information in the additional section should not be promoted to an answer. These IPs are only in the ADDITIONAL section - they should not be used as answers. W > > R's, > John -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 21 15:00:15 2020 Return-Path: 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 F27393A080B for ; Thu, 21 May 2020 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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=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 TUsV6MtVBKLv for ; Thu, 21 May 2020 15:00:11 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 0B5A83A0659 for ; Thu, 21 May 2020 15:00:11 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id i16so3593067ybq.9 for ; Thu, 21 May 2020 15:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Zo4rrrR7SaoYN+21mc6C0uOJe+QI77X/FlQZi46PmRk=; b=fmfcFhCUDp4RTOn+5WOIXAriiAQ6wXvlS+xOT2s40h6UeD5/liKAKHmncXjfzVZ0Qt QdTLYrO3ypklSo7CPTCBZqM6f2GMi8YF39tsV4dMRI9ihr3RZfZVKeAGT8lUrkFEd1al 6MtQdXtMjx+q3NnHe5P9OR1BkycMNLJTCDFkw4mCqjuyWX/CU9EMUVPgEtZQaJ9DYlkn wJ3OhFkSo5Qo/uZjZw1IxpSIvjJlW52eUNN+TGf2W3aG2tKkIG2VkEVeLPeRZE0tMQgZ /29xD4Ny9kOSo9h8zt9oDHQIHt3yoIrphWZSx5hLbePITCOssdg7DBCQBYjWHQZ28Kee 26Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zo4rrrR7SaoYN+21mc6C0uOJe+QI77X/FlQZi46PmRk=; b=U+NOL+S5W/CSYOwfUxj/WKKAJz+7QCY8Dk1P+rxulT4oPtN9iluHdEC/3PybbmAybA GP3uuoHHORo8XhcS3d9lWMhArk6z9cgPf75N8dMTvglXk57fTP8KqMUAu47/036u6msN HnkhTDcOlTVTjDhM0uWJmc76q16iX0ubTzkIHfr4mHmPbDSoveAs32cgP6ZKXJr7deNm 61QgUxombUXk0flqzbytjrQe9yc/9iZtBUOGX4e7/osfxa5XYoQ2JzDDZdiAf/9Aej23 m/4YIMYFIWYoxTs+E6Lg2cakPv/xm18Ind8eA0onLQ60i72HzhLJBO11Qq6Dpgffkw9Q 4gFQ== X-Gm-Message-State: AOAM530Ns/qiOGUTkpdoGZrTFWuMAawQRUJzUwCXOaziQVqWYtoxxrb6 0LJNdgASiDYJDfUHXbDLFEpnK4IW8K8WcQqBheyWpXQd X-Google-Smtp-Source: ABdhPJwTc35n80F5gOPPdkupx+mnf41jPC4M/rvsxvke/HYFwI5FG+tV9Vg0iW04jxWbCYI8V1WM2PR0mWlo268a81Q= X-Received: by 2002:a25:4984:: with SMTP id w126mr19723647yba.20.1590098410056; Thu, 21 May 2020 15:00:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Fri, 22 May 2020 00:59:49 +0300 Message-ID: To: Warren Kumari Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 22:00:14 -0000 Peace, On Thu, May 21, 2020 at 11:08 PM Warren Kumari wrote: > [..skip..] > Looking in the webserver log, there are also some hits - e.g: > - - [21/May/2020:19:09:10 +0000] "GET /favicon.ico HTTP/1.1" 404 209 > "http://www.wow4dns.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 > Safari/537.36" Is there a statistically =E2=80=94 or somehow otherwise =E2=80=94 reason to= think this was not a coincidence? (I'm just askin' before going to repeat the same experiment) -- T=C3=B6ma From nobody Thu May 21 15:19:46 2020 Return-Path: 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 C528C3A0C19 for ; Thu, 21 May 2020 15:19:42 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=kumari-net.20150623.gappssmtp.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 YVQDAj2hP_HH for ; Thu, 21 May 2020 15:19:39 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 911573A0C10 for ; Thu, 21 May 2020 15:19:39 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id w10so10316918ljo.0 for ; Thu, 21 May 2020 15:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l/gPhk7Q3GikCtO4xPmKQaG4isYMPZarrq3w0dhPmYI=; b=rtseLznw2K9BuKPtqFYpa4CtOftdOfO283AfATbycN16Dosi1M2tBtLu8iRWMWwc3t GS2bf1LikcDM0P/QARW8nlDn3sw/SOXNGLVK9XoiV2NoD+8aLZM3T2+Dx3ldGAzvVXy/ DTdlKxFMD5Ow/YVpmmjUrb44/oce+2HLEvMuIYUj7DdRwuzCPCUPw9b2Aoqk45wjNIYX FvQMrtgXQW4MsCoJceBcfEg6HeAO+bv7ZBDo2TuBl9bnzasHbCffTYxYZ4yeEu6vkQkJ 8q/Bk+I0gYR69ybHPRGfb2ADTa3wpG39+XsPjOYoN+sZ3VE+kLieyNHu1eKeXk42ayW6 i9iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l/gPhk7Q3GikCtO4xPmKQaG4isYMPZarrq3w0dhPmYI=; b=GbbNFllfwWY51MsYivm44cVXt/mrBTdtP+oZ0lfBpY+MJgGvT3VxtefSIkgeGz9ZM+ jz5lncgJsX6qBnOYkrFJSk7hGsFv0k1mxPUsk2Tmq8IDYO+wzI6IhMqIOx/XIezBX2IE prLFFS/gARw7qmhJYfEUQEDH6QhlXP/KVZqHGBzp1yFtKiqILddNZ6+J3LZ7dZFwQWpf QHa2Nd/e331rr/bFpLniHXktJgamKryMpE96/ekNfdorWs99awFH6TMHNEwgxJvAqluA kf6aiBRSNIP2kViHglDIOO9HSrImbNYBVP0ysBXb2YQdX/UEx1vWhwKx1lbnWzJhhx4O eH5g== X-Gm-Message-State: AOAM533I33ogA2U1Hu0nVubKbIowSy2LpWvrCNyfgiH4sRVQeVZtvy48 SmdmM85gtfI6NxkqeSPxdUAdRqd9W8YUP3D+H8kXwA== X-Google-Smtp-Source: ABdhPJzTiVykDjLNI/4tPBbIpc/nzTiSrw6wolCQf+YYUJYm0pddKxCCdbt817OpcucXXbQn4eL6pyeNgkgVq5cykIU= X-Received: by 2002:a2e:b4e3:: with SMTP id s3mr5997497ljm.11.1590099577171; Thu, 21 May 2020 15:19:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Thu, 21 May 2020 18:19:00 -0400 Message-ID: To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 22:19:43 -0000 On Thu, May 21, 2020 at 6:00 PM T=C3=B6ma Gavrichenkov = wrote: > > Peace, > > On Thu, May 21, 2020 at 11:08 PM Warren Kumari wrote: > > [..skip..] > > Looking in the webserver log, there are also some hits - e.g: > > - - [21/May/2020:19:09:10 +0000] "GET /favicon.ico HTTP/1.1" 404 209 > > "http://www.wow4dns.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X > > 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 > > Safari/537.36" > > Is there a statistically =E2=80=94 or somehow otherwise =E2=80=94 reason = to think this > was not a coincidence? > (I'm just askin' before going to repeat the same experiment) Yes, no, maybe?! www.wow4dns.com was never pointed at this machine until I added the glue and NS records (it used to point elsewhere). It's quite probable that this was triggered by something other than the Atlas measurement, but all that that means is that someone actually resolved the name "for real". I haven't seen any more hits since then, so, um, who knows... I initially wanted to do an Atlas HTTP measurement (instead of a DNS measurement), but then realized that the HTTP measurement type can only be directed at a RIPE Anchor (not an arbitrary name). If there are any Atlas folk around (or if people want to test from other tools / vantage points), feel free... W > > -- > T=C3=B6ma -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 21 15:45:32 2020 Return-Path: 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 CCB773A0C58 for ; Thu, 21 May 2020 15:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UxlOLybX; dkim=pass (1536-bit key) header.d=taugh.com header.b=uMSmNZzz 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 zU1tnX8_M0dy for ; Thu, 21 May 2020 15:45:28 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D4A8F3A0C53 for ; Thu, 21 May 2020 15:45:27 -0700 (PDT) Received: (qmail 71550 invoked from network); 21 May 2020 22:45:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11776.5ec70486.k2005; i=johnl-iecc.com@submit.iecc.com; bh=uvTclANQvBl7rJB3/9nB4dInI3EHq1V7hQ4YBI2Hj8A=; b=UxlOLybXnLWom5q/9yNB/OuEFzaOugOG4GdHXDjdPzWLGFd32C+GZV8EHErsj91JP3rbUaX2OO+nzCixKH+HR8lhShwdBnUHqhzgi4CXm/RiACyPVhEH/mMWesxo4ozNlVfnYfR20DuKWbu5MfeLpwAFbEmhXo5TM1wMG+3D8hbcM/Lirs8A23ISAoQm+bpdMFKtLzjjPq/GFxSY6aywsQAfWL19qTZfBuT1tSaHAui7BtG/ceV3SgatB1+MiYC/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11776.5ec70486.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=uvTclANQvBl7rJB3/9nB4dInI3EHq1V7hQ4YBI2Hj8A=; b=uMSmNZzzWA8YHkco/G8oy7WcKAvQ94wWSb8wOZX3aDcfee908MHPLNW9tZDx3TmcGdus/rmQgJSv7JCslgDzMyh3cgZummm/vrdQZveadWWBxoohIrpZhxSFElP3OfnxihhJnpjE4jZC/zMQztd3ABRZmRw3X9+NRipnr3Rois1TnTBddkN058oFcNk63i4usZjfY2pMkixM7seMfuFwH/cFR7YEJjE8n8qESkaoeH0sZm8VNLsD3K3ll1a/qxug Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 May 2020 22:45:25 -0000 Date: 21 May 2020 18:45:25 -0400 Message-ID: From: "John R Levine" To: "Warren Kumari" Cc: "dnsop" In-Reply-To: References: <20200521214124.271EC197E0DF@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 22:45:30 -0000 On Thu, 21 May 2020, Warren Kumari wrote: > Yes -- but information in the additional section should not be > promoted to an answer. A week or two ago I scannned TLD zone files to see how many signed A and AAAA records there were. Quite a lot, most looks to be orphan glue in Afilias zones that they didn't delete after the registered zone went away. No promotion needed. If anyone wants, I can rerun the scan and show you what I found. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 21 17:31:22 2020 Return-Path: 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 061643A0D35 for ; Thu, 21 May 2020 17:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 QA_UmvqEsxiK for ; Thu, 21 May 2020 17:31:19 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0B6873A0D33 for ; Thu, 21 May 2020 17:31:14 -0700 (PDT) Received: (qmail 59414 invoked from network); 22 May 2020 00:14:38 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 May 2020 00:14:38 -0000 To: dnsop@ietf.org References: From: Masataka Ohta Message-ID: <380a2b8e-0680-5caf-401f-b7b4f1bafb1f@necom830.hpcl.titech.ac.jp> Date: Fri, 22 May 2020 09:31:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 00:31:21 -0000 Tim Wicinski wrote: > This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional > > The draft is available here: > https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. While I'm not against the clarification, the draft should mention that rfc1034 already states: To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cut, and are only used as part of a referral response. ^^^^^^^^^ which means the glue RRs are necessary for a referral response. Though not very obvious, it logically means that they MUST be included as part of a referral response, because it is the only reason to make them necessary. Masataka Ohta From nobody Thu May 21 17:55:51 2020 Return-Path: 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 954253A0D52 for ; Thu, 21 May 2020 17:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 8wdECwX77nor for ; Thu, 21 May 2020 17:55:47 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 026C13A0D3C for ; Thu, 21 May 2020 17:55:46 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id d5so161829ios.9 for ; Thu, 21 May 2020 17:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=HGOhSTmQfJqy/4Rtj3poqAR1Xsp3jbB5LrqytszrmsE=; b=zfzlrk9NBxW4p3H1fUlHZ7/aqcFGojx8scrhBPrBanr4cQGhkc3wuGnvMsiRdoIAIt 4D7K1tad4znnz1Cd8Zs7TPZ4JuxHL6XNNT8IqgI+zK9VvzZbr+WQelqRm4052dLzx0W7 6h3PSLXDGAxevMYuWrCX9R43WTewTBZf0HHFvAV0+4yFADhtFxhouA+HNZXbO7k4BJpA nTOTelEiEkEyfwQEJMYBUXNuspKh2GUsUKQgcu7VMTh9ktYoh16b2dTHZqJFTgkJuSN0 TzlMOnt/LOj80q0XXm2PeYdA53WGcUF681rYm0mT/0+N2T5MFKFglZ9JKTZ4kRxkwezz s3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HGOhSTmQfJqy/4Rtj3poqAR1Xsp3jbB5LrqytszrmsE=; b=OPObMbegWopBu/T+nxZqNi9wtW9nMEDOiN92ScawCjRfYdZkKA6mhPOrnSjl38RY5j kqzA5TU7M6YbhR297XvRo3WftDlcDBwCfMgAMAhPtVSbrknYy/NYX6XpEDYk4gyWQ7nD KWNpTbqTImXtI2nI/sry75zKDcYiu6jf5X/ErUoA8JGJdw4MXfxqVLWNH2Orvo8pyJt9 ybchF96Ysct6GLXkILyXmtslS8+qya3gWiFm26qo1gP7644odw+b9w73p0nyYyC6OCRV v7225aToCx5oxBrioZwdaLKC9lh52omlIDF8ySmn9przzwlvVfSw4uz8UfvPEG0oAj2L CFIg== X-Gm-Message-State: AOAM531y8lVBjWVHiWdsdvIYFTUnWgh44BWqzjbjpqMgQaENZkxcctO+ mhDyjvSHhgPzCpFuoRbFb2aooQHQwAbmuzeEoxGfUPvq X-Google-Smtp-Source: ABdhPJxdvHXj1AKB137EMdKlsuJCj5FFaw7N743KkfdUboOAw2iG7cGacn1i2O1HqO308QghbWDhgvM2AZWPOM/1KzY= X-Received: by 2002:a02:cc81:: with SMTP id s1mr6460004jap.64.1590108945688; Thu, 21 May 2020 17:55:45 -0700 (PDT) MIME-Version: 1.0 From: George Michaelson Date: Fri, 22 May 2020 10:55:34 +1000 Message-ID: To: dnsop WG , George Kuo Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 00:55:50 -0000 My Colleague George Kuo asked me for definitions of public DNS service. not "public DNS" but the trigram "public DNS service" Colloquially we understand this reasonably well. It is in the space of what Google, quad9, CloudFlare and others do. The various clean DNS feeds people subscribe to, it is the functional role of a recursive, but to the public, yet somehow not the bad one of an open DNS resolver being abused to do DDoS: its the conscious service offering of a recursive/cache/forwarder in the public view, a declared intent. A Google search lists (some of) them by name and IP. I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, and he said he is but the humble scribe, and words appear in the dictionary when he is directed. What does the WG feel? The definitions of the "elements" of a public DNS service are of course defined. But not (I feel) the "collected whole" which most definitely exists, out there. (if anyone feels this is adequately defined, please correct me and share a URL) -George From nobody Thu May 21 18:36:08 2020 Return-Path: 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 2D1F83A0D68 for ; Thu, 21 May 2020 18:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 pave2OlESzxx for ; Thu, 21 May 2020 18:36:03 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27553A0C3D for ; Thu, 21 May 2020 18:36:02 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4737CB074A; Fri, 22 May 2020 01:35:59 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Date: Fri, 22 May 2020 01:35:58 +0000 Message-ID: <2579854.HOIbhPnuQa@linux-9daj> Organization: none In-Reply-To: <380a2b8e-0680-5caf-401f-b7b4f1bafb1f@necom830.hpcl.titech.ac.jp> References: <380a2b8e-0680-5caf-401f-b7b4f1bafb1f@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 01:36:07 -0000 On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote: > ... > > While I'm not against the clarification, the draft should mention > that rfc1034 already states: > > To fix this problem, a zone contains "glue" RRs which are not > part of the authoritative data, and are address RRs for the servers. > These RRs are only necessary if the name server's name is "below" the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > cut, and are only used as part of a referral response. > ^^^^^^^^^ > > which means the glue RRs are necessary for a referral response. > Though not very obvious, it logically means that they MUST be > included as part of a referral response, because it is the only > reason to make them necessary. i agree. this is why later versions of BIND would return referrals rather than answers when queried for these names, which were in-bailiwick but below-zone. by implication, they can only be retrieved from the delegating server as part of a referral, and they will be in the additional section not the answer section even though they do match the qname. this distinction is also necessary in the assignment of credibility levels in the downstream cache. -- Paul From nobody Thu May 21 18:36:47 2020 Return-Path: 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 380F63A0E2A for ; Thu, 21 May 2020 18:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 vP3EjAySeayF for ; Thu, 21 May 2020 18:36:39 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 D42273A0DC2 for ; Thu, 21 May 2020 18:36:34 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id dh1so4019522qvb.13 for ; Thu, 21 May 2020 18:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P8xcoUDvp4/xA0NGZnAY+ki86PMTo8NaEXAjRCwjzzo=; b=bOOIQgxCHgExgPUfl5TQMhZCKg/P/DsrAX8BaFqR8eHKS07xZ/cLNilG5PfJ746hVn IBa+2imerSRFvlYXAkkIbcNh259gYyfnYlraXPWDlQk8x13jOKIutfsXbLaUjFfhp86s NHY5w3iQJSSk6+GdBgDo0pfukxZnhjHWURLhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P8xcoUDvp4/xA0NGZnAY+ki86PMTo8NaEXAjRCwjzzo=; b=EkSPrYElkrpM7jmWLkILN3tu4j23VxR8+54+e8D1/6tzvWRana5gCDwOXzoFj5ZZsH vBcCsflg7dXFBHllOPk3ZT1P7BcEzeKbneu/KPSkA+vSoSMcFvat4VPPSdKbKZuAei3h KBbSE9zMCOuo8nm6u14sIQipfdbCnFteHgp2SHeZaftqmdNOPs6AAFFtZyHFzsnvYjZG n4JAHBi8WH0ydHBDKQCLh3DhQKjVZhy/IgARIFSUt6+fsCh1HBxTiA/plcEUOgajXjmE g8DK4ytmaqakrulplWDQcJ4E77O8+0m/b+I6IoFLflHeH0/QU2oBuXBpKh1fvCfhp8TO Ls8g== X-Gm-Message-State: AOAM5313MS36NLwSpvCnpSkJjcO7rg0NXcZI9RjciecP62O/FTvj8YTN 84DGNS+FxX8yvZnufr7YVE71Kw== X-Google-Smtp-Source: ABdhPJz3MfktICYwVKsnWoEJ3lMPYho6iaJGI/oDIrLTdF4Oo9RTrO1aOa7t6BZ/mw5yjJt3KkGEKw== X-Received: by 2002:ad4:58cb:: with SMTP id dh11mr1422600qvb.211.1590111393667; Thu, 21 May 2020 18:36:33 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:75f9:587b:a741:8b32? ([2607:f2c0:e784:c7:75f9:587b:a741:8b32]) by smtp.gmail.com with ESMTPSA id v69sm2280196qkb.96.2020.05.21.18.36.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 18:36:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joe Abley In-Reply-To: Date: Thu, 21 May 2020 21:36:31 -0400 Cc: dnsop WG , George Kuo Content-Transfer-Encoding: quoted-printable Message-Id: <67EC8652-11C6-4A24-9560-4E23EBD401E6@hopcount.ca> References: To: George Michaelson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 01:36:47 -0000 On 21 May 2020, at 20:55, George Michaelson wrote: > My Colleague George Kuo asked me for definitions of public DNS > service. not "public DNS" but the trigram "public DNS service" >=20 > Colloquially we understand this reasonably well. It is in the space of > what Google, quad9, CloudFlare and others do. For what it's worth, I think those things are public DNS resolver = services. To me, public DNS resolver services are subsets of a larger "public DNS = service," which is (something like) the larger facility for translating = globally-unique (QNAME, QCLASS, QTYPE) tuples into resource record sets = on the Internet. I don't think that's a very good definition. Something more like Seth = Briedbart's definition of "Internet"[1] would be better, but it turns = out that it's late and I'm tired and also I'm not as smart as Seth. Joe [1] http://web.mit.edu/kolya/misc/txt/internet= From nobody Thu May 21 18:38:17 2020 Return-Path: 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 0180E3A0C3D for ; Thu, 21 May 2020 18:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 IoScfk1pPC9n for ; Thu, 21 May 2020 18:38:13 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621243A0D9F for ; Thu, 21 May 2020 18:38:13 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1C780B074A; Fri, 22 May 2020 01:38:13 +0000 (UTC) From: Paul Vixie To: dnsop WG , George Kuo Cc: George Michaelson Date: Fri, 22 May 2020 01:38:12 +0000 Message-ID: <2487238.otjEU5M4pH@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 01:38:15 -0000 On Friday, 22 May 2020 00:55:34 UTC George Michaelson wrote: > My Colleague George Kuo asked me for definitions of public DNS > service. not "public DNS" but the trigram "public DNS service" > > Colloquially we understand this reasonably well. It is in the space of > what Google, quad9, CloudFlare and others do. The various clean DNS > feeds people subscribe to, it is the functional role of a recursive, > but to the public, yet somehow not the bad one of an open DNS resolver > being abused to do DDoS: its the conscious service offering of a > recursive/cache/forwarder in the public view, a declared intent. these services aren't public in any way, and should not be described as public. they are operated privately for private purposes, and merely used by some members of the public. a county park is public. anycast RDNS is a business. -- Paul From nobody Thu May 21 19:33:12 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1C3A0E12; Thu, 21 May 2020 19:33:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <159011478284.5398.16651306969805139036@ietfa.amsl.com> Date: Thu, 21 May 2020 19:33:03 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-validator-requirements-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 02:33:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Recommendations for DNSSEC Resolvers Operators Authors : Daniel Migault Edward Lewis Dan York Filename : draft-ietf-dnsop-dnssec-validator-requirements-00.txt Pages : 23 Date : 2020-05-21 Abstract: The DNS Security Extensions define a process for validating received data and assert them authentic and complete as opposed to forged. This document is focused clarifying the scope and responsibilities of DNSSEC Resolver Operators (DRO) as well as operational recommendations that DNSSEC validators operators SHOULD put in place in order to implement sufficient Trust that makes DNSSEC validation output accurate. The recommendations described in this document include, provisioning mechanisms as well as monitoring and management mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-validator-requirements-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-requirements-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 21 21:02:16 2020 Return-Path: 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 810833A0E66 for ; Thu, 21 May 2020 21:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 r_9BoP-dq8Z0 for ; Thu, 21 May 2020 21:02:11 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 298743A0E65 for ; Thu, 21 May 2020 21:02:10 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id n22so7313988qtv.12 for ; Thu, 21 May 2020 21:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E08jQs9AjT+82V0sSIdt48lppA0invTSWnUkUfQaML8=; b=uzKzUeJ4dTHrtXEyiRPZZb5t1OiFoFHnIbDe7FD11fH4vOrB+sIGZwqPZb5Z1p0gyE tmGnI8fCetVt/RNt2EYA73Zir2R4F/34dkB2CG4QEyWeRFqqTiqkBR2wqj+M3mxL209s 44oyIfYjib3Wgqzg+I8UwdI8J12uN9mtQTmQUzBCwtKG+j70UxCdbKGXASjmTp40pE0M VKPjBy0RcJRPYZYMXRTjOf2vNtcdgIIsEB6PO2FKZdWBzmKwpCsgc3YcnO9ookuo3LDr 5OSH8z7y+F3I9WGE6x8tH+E34bNkzqn3gaDgq9Nuzf8vz96p4TwDTmCWlAOyF7prnofp K7Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E08jQs9AjT+82V0sSIdt48lppA0invTSWnUkUfQaML8=; b=Kf6X9LDuAmweKUe4HYheG5VjfO3x8uL5B4t6r2bBzOKvjudyXeoSv3R/SJyOOUF6W5 DR1hjnoJT2+Kq9uKTdeExCkQM2HLbcdOArHXWSjmO0UNJQ1Erd07duuHELPaTZ5PaZJf Oy8+epAb1KfLzwZe6KKmD/bqEtM2PE8UXFccnqfri6+8XnsShbMeJgTYnEW741ntCXg5 5hwWc87bh8KIICKrdQKwkQk8wd6unnQQHzk7TxovaFXNVuPAbTZkrQlc1XmZdd/27mej KRO+R5Os4iKTXtMRotVJ6yA79PW6GdvMzD3Lp45SWv/alZCMBZpWMULgtxzLNGwXWL+W X7CA== X-Gm-Message-State: AOAM532nqf9cBmMwzhk3qCQsAHy4fhkbOB8qt4VtxzjK7uVMeiOzEp2U j/k+Jjo5kh5ivXQmLKMNAHor0MBc0EDi42RfqGo= X-Google-Smtp-Source: ABdhPJz4Cr4YdMiiBrbOwNghWacFjrBcx+I89vVxRDRnzhJ29aFLgh10kP+cdKbzlqP+fSgSD/fGOBuF9gFi2+Lq1Vg= X-Received: by 2002:ac8:226d:: with SMTP id p42mr34056qtp.1.1590120129899; Thu, 21 May 2020 21:02:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davey Song Date: Fri, 22 May 2020 12:01:58 +0800 Message-ID: To: George Michaelson Cc: dnsop WG , George Kuo Content-Type: multipart/alternative; boundary="0000000000007e328c05a634b195" Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 04:02:14 -0000 --0000000000007e328c05a634b195 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMHO, public DNS is not a technical jargon which needs a DNS terminology RFC to record (it collects all DNS definition and terms from other DNS RFC). The term "Public DNS" or "Public DNS service" belongs to the scope of how people provide and operate DNS services to their best interests. There are many similar terms, such as Cloud DNS, Dynamic DNS, DNS firewall, and many DNS-attacking terms. BTW, I'm happy to see there is a document to define all DNS attacks and mitigation suggestions. Best regards=EF=BC=8C Davey On Fri, 22 May 2020 at 08:56, George Michaelson wrote: > My Colleague George Kuo asked me for definitions of public DNS > service. not "public DNS" but the trigram "public DNS service" > > Colloquially we understand this reasonably well. It is in the space of > what Google, quad9, CloudFlare and others do. The various clean DNS > feeds people subscribe to, it is the functional role of a recursive, > but to the public, yet somehow not the bad one of an open DNS resolver > being abused to do DDoS: its the conscious service offering of a > recursive/cache/forwarder in the public view, a declared intent. > > A Google search lists (some of) them by name and IP. > > I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, > and he said he is but the humble scribe, and words appear in the > dictionary when he is directed. > > What does the WG feel? The definitions of the "elements" of a public > DNS service are of course defined. But not (I feel) the "collected > whole" which most definitely exists, out there. > > (if anyone feels this is adequately defined, please correct me and share = a > URL) > > -George > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000007e328c05a634b195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMHO, public DNS is not a technical jargon which needs a D= NS terminology RFC to record (it collects all DNS definition=C2=A0and terms= from other DNS RFC).=C2=A0=C2=A0

The term "Public DNS"=C2= =A0 or "Public DNS service" belongs to the scope of how people pr= ovide and operate DNS services to their best interests. There are many simi= lar terms, such as Cloud DNS,=C2=A0 Dynamic DNS, DNS firewall,=C2=A0=C2=A0a= nd many DNS-attacking terms. BTW,=C2=A0 I'm happy to see there is a doc= ument to define all DNS attacks and mitigation suggestions.

Best reg= ards=EF=BC=8C
Davey

On Fri, 22 May 2020 at 08:56, George Micha= elson <ggm@algebras.org> wrot= e:
My Colleague = George Kuo asked me for definitions of public DNS
service. not "public DNS" but the trigram "public DNS servic= e"

Colloquially we understand this reasonably well. It is in the space of
what Google, quad9, CloudFlare and others do. The various clean DNS
feeds people subscribe to, it is the functional role of a recursive,
but to the public, yet somehow not the bad one of an open DNS resolver
being abused to do DDoS: its the conscious service offering of a
recursive/cache/forwarder in the public view, a declared intent.

A Google search lists (some of) them by name and IP.

I asked "Dr Johnson" (Paul Hoffman) why it was not in his diction= ary,
and he said he is but the humble scribe, and words appear in the
dictionary when he is directed.

What does the WG feel? The definitions of the "elements" of a pub= lic
DNS service are of course defined. But not (I feel) the "collected
whole" which most definitely exists, out there.

(if anyone feels this is adequately defined, please correct me and share a = URL)

-George

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000007e328c05a634b195-- From nobody Thu May 21 21:11:33 2020 Return-Path: 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 C938D3A0E6F for ; Thu, 21 May 2020 21:11:31 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.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 zfdGsqGlmo0T for ; Thu, 21 May 2020 21:11:29 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 BA66C3A0E71 for ; Thu, 21 May 2020 21:11:29 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id m6so9442342ilq.7 for ; Thu, 21 May 2020 21:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l43F4nGUarXp28++fxW8J0L3sKVfy6KLb7GGx18eyhI=; b=c+qYm0AGyWIzjRNImnH+GMkwXsqqxaue61rEIr69s5ZIHqYFMWLePpjLMk9bOSXG0p PnnbZFAeuI35KU3LD0OCjeGhYQhjNgLr9DVF1w2PF67dvG8e20H7nrBuZ9AeCf3ClIyg 7VM8f9G3b1zYBpTIfsYp++Xa9RO2id3IMRCde4eda3Unq0CTLFxqrx0nH/mZEtDzyK0Q A2U8v5et/cyhL2krSDC8JeXr9KVlCVKDj5IjSshsHoGf/HL3j9aVd3Cr+jRXP90brAOd 57ZGg0aMefE5AahYiEo01JAwXch3RuyYsGmfNculMODKhuI7xFEd0WU7MPPYafXRl29c LV8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l43F4nGUarXp28++fxW8J0L3sKVfy6KLb7GGx18eyhI=; b=o2SvDEZwPvFnkJAPeqS02OOYcUcR3+bQABrq/dKG+VcPdpN2gzyQopY/xRFbjVd7nH j+GiKtxvYe6kxjXPwk3DS5Tl7HIsVMeTLY4+mevyeqSUDNdQQiVDmO3Ktt65+L7Ym5RL 6t6ngu77cEZ9wahXtV41rUzJx0+hyw3/DaoX9kMt7pU69VxmLw4Qi0eVhZypBPtCNS4G 68dXTVfFWNZhjF9qUZrGPP4kzO/EcxGWbzjdThjNG7JYFX3B207VdFLKnbPbcDEjICpY 78A/D/EvnZgLkNo77hNoCd+SN0GsNPmBeVzm03GHEQAPnRz2BKo0a7PdymknMJRmshFK 9blg== X-Gm-Message-State: AOAM531YkD7osI2U7bduhCDQVOypssGGF63t44KFCqgKQpqq6IBOVbR7 vWUYVRZz9OKDRDFn6k7f5CyWwMN29ul50APmECZESx3D X-Google-Smtp-Source: ABdhPJx37IbH81YDC4q4tYxub7mfQbf3vPwrtd1LgHj42DDKyi1c+KQV5sf3JsJTaBgEgltZKSaJsb+7MygNq84FZ8c= X-Received: by 2002:a92:de09:: with SMTP id x9mr12446391ilm.176.1590120688314; Thu, 21 May 2020 21:11:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Fri, 22 May 2020 14:11:16 +1000 Message-ID: To: dnsop WG Cc: George Kuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 04:11:32 -0000 Thank you all for the responses. This has been very interesting. Paul actually hinted this was the probable direction, and I think we can say categorically the dictionary doesn't need updating because there isn't a sense this concept needs defining in this context within this WG. Many thanks -George (not Kuo. Btw, there are five georges at APNIC. hash collisions happen all the time) On Fri, May 22, 2020 at 2:02 PM Davey Song wrote: > > IMHO, public DNS is not a technical jargon which needs a DNS terminology = RFC to record (it collects all DNS definition and terms from other DNS RFC)= . > > The term "Public DNS" or "Public DNS service" belongs to the scope of ho= w people provide and operate DNS services to their best interests. There ar= e many similar terms, such as Cloud DNS, Dynamic DNS, DNS firewall, and m= any DNS-attacking terms. BTW, I'm happy to see there is a document to defi= ne all DNS attacks and mitigation suggestions. > > Best regards=EF=BC=8C > Davey > > On Fri, 22 May 2020 at 08:56, George Michaelson wrote: >> >> My Colleague George Kuo asked me for definitions of public DNS >> service. not "public DNS" but the trigram "public DNS service" >> >> Colloquially we understand this reasonably well. It is in the space of >> what Google, quad9, CloudFlare and others do. The various clean DNS >> feeds people subscribe to, it is the functional role of a recursive, >> but to the public, yet somehow not the bad one of an open DNS resolver >> being abused to do DDoS: its the conscious service offering of a >> recursive/cache/forwarder in the public view, a declared intent. >> >> A Google search lists (some of) them by name and IP. >> >> I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, >> and he said he is but the humble scribe, and words appear in the >> dictionary when he is directed. >> >> What does the WG feel? The definitions of the "elements" of a public >> DNS service are of course defined. But not (I feel) the "collected >> whole" which most definitely exists, out there. >> >> (if anyone feels this is adequately defined, please correct me and share= a URL) >> >> -George >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu May 21 22:13:19 2020 Return-Path: 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 2E2443A0EAD for ; Thu, 21 May 2020 22:13:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.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 x3tAKN3R_krJ for ; Thu, 21 May 2020 22:13:14 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 529F43A0EAF for ; Thu, 21 May 2020 22:13:12 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id c16so10114693iol.3 for ; Thu, 21 May 2020 22:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Tp6sLDnNzzJpSKXU+gccTfextfGaJi7CvIW3gTtX6Yw=; b=W2nRQBwv3wj/1KB+GLZljIdNen5qjH1qMpvpyc+si4nda9L2rADRLQ73bPnBkiIKU1 lN5YKcPaBK7nfQKhTr6y0OA6bRkDL4VM+6G2F/6wtyLHQ4ONEEisNPQwydUYqx5uIVWc Kyrasgeedv1q9zsIAPTzAvn0VhmWXMIDXTgguM0K9BUx0vHi6g3pgPcLmFosFO81QWb0 fyln516kcsD1FVHcQsjdntFlclXmNFwcdj7zVp4cuRb7WToNfwKVOPfO3UuZCHJ3sfTG 8eGxbekii3JV872bnpYoKThh/58fJo2iUNIWZuLCxa4Qh5RYTNEeA5aUcZSDy/Eszk3A JdbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Tp6sLDnNzzJpSKXU+gccTfextfGaJi7CvIW3gTtX6Yw=; b=t5aWJGGl0Z8xFmIpMoGl42pN74jRjZ9bCZu/SifE5vrY/6SrBfuW33SSpa+DGu1Ydv p1lu9beugZgp35VxHhBeIze63BrV6AUUdJg2R5fVo9lZUYBYuciv062/b96rPxqjwDRe iw/3zdLYugC2QzL8cR28Gj+pQI9lqULadglxtiwhF/gNA7+ssPGcEgnB7PIAIn/ExP1U pgUEvlhfNwuL/mIOs4Qv2bcF06IcaPxuB8ny4Vxzc/AjTNJTLhU7IkRh7dhBUHJIHcvU zDP+61WdhvcbdbTqctXxEAKdCh+eK/71IWZ8gBHYhBqW43udcBkEWJORMRXPl6J6kzeY aq+Q== X-Gm-Message-State: AOAM5331tbEIgaSmJoZIV+zh6LGXYBP+jIGQYc8jDw2CbUNs8TmOZKBx yWL59FuOrJ6YVnnGosztdmMx5YiEuJTNBfYrxrPbSwltsLM= X-Google-Smtp-Source: ABdhPJy8IBSlT6ItRaa1O2IUqMUz7LfCKCB92TztSMZIdOH/HmWCWRTIV9xNMae4K5XtAAA1vY8F6fFLIhekfG2hhB8= X-Received: by 2002:a05:6638:158:: with SMTP id y24mr6709883jao.43.1590124392000; Thu, 21 May 2020 22:13:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Fri, 22 May 2020 15:13:00 +1000 Message-ID: To: dnsop WG Cc: George Kuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 05:13:17 -0000 George Kuo who is not subscribed to the list said this: >Thanks all for sharing. >I have learned from all your input. > >George Kuo. On Fri, May 22, 2020 at 2:11 PM George Michaelson wrote: > > Thank you all for the responses. This has been very interesting. Paul > actually hinted this was the probable direction, and I think we can > say categorically the dictionary doesn't need updating because there > isn't a sense this concept needs defining in this context within this > WG. > > Many thanks > > -George (not Kuo. Btw, there are five georges at APNIC. hash > collisions happen all the time) > > On Fri, May 22, 2020 at 2:02 PM Davey Song wrote: > > > > IMHO, public DNS is not a technical jargon which needs a DNS terminolog= y RFC to record (it collects all DNS definition and terms from other DNS RF= C). > > > > The term "Public DNS" or "Public DNS service" belongs to the scope of = how people provide and operate DNS services to their best interests. There = are many similar terms, such as Cloud DNS, Dynamic DNS, DNS firewall, and= many DNS-attacking terms. BTW, I'm happy to see there is a document to de= fine all DNS attacks and mitigation suggestions. > > > > Best regards=EF=BC=8C > > Davey > > > > On Fri, 22 May 2020 at 08:56, George Michaelson wrot= e: > >> > >> My Colleague George Kuo asked me for definitions of public DNS > >> service. not "public DNS" but the trigram "public DNS service" > >> > >> Colloquially we understand this reasonably well. It is in the space of > >> what Google, quad9, CloudFlare and others do. The various clean DNS > >> feeds people subscribe to, it is the functional role of a recursive, > >> but to the public, yet somehow not the bad one of an open DNS resolver > >> being abused to do DDoS: its the conscious service offering of a > >> recursive/cache/forwarder in the public view, a declared intent. > >> > >> A Google search lists (some of) them by name and IP. > >> > >> I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, > >> and he said he is but the humble scribe, and words appear in the > >> dictionary when he is directed. > >> > >> What does the WG feel? The definitions of the "elements" of a public > >> DNS service are of course defined. But not (I feel) the "collected > >> whole" which most definitely exists, out there. > >> > >> (if anyone feels this is adequately defined, please correct me and sha= re a URL) > >> > >> -George > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri May 22 05:18:08 2020 Return-Path: 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 5DB3F3A0B8E for ; Fri, 22 May 2020 05:18:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=yitter.info header.b=D58yMSLk; dkim=pass (1024-bit key) header.d=yitter.info header.b=HA92558k 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 qffBjiE-mVnV for ; Fri, 22 May 2020 05:18:02 -0700 (PDT) Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793473A0B8F for ; Fri, 22 May 2020 05:18:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 39929BD512 for ; Fri, 22 May 2020 12:18:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1590149880; bh=mNR9OBC2GZlslh2hfXTa4XJp3cdbp4XwZ9Cq+xujZGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=D58yMSLkQ1AW4qe1d2qXiBpFLVuM495x5CyNRYVJFWeNP6IRpsrzGAnzkthXuzapy fmwcTIqoXFhaKM4jefeQwpjVHENFnf++1KkSQDouuG9bKtufqi8UgXvnXuLChYBWTv 70K7hIUR8cLAR3//pJqb00GsJDgUW9if8VOZN2SE= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8FZcf6BaeP9 for ; Fri, 22 May 2020 12:17:57 +0000 (UTC) Date: Fri, 22 May 2020 08:17:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1590149877; bh=mNR9OBC2GZlslh2hfXTa4XJp3cdbp4XwZ9Cq+xujZGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HA92558kNGa5u0RiIBCiAFszIDj2NBV5dzs8XBpEauWzIH7b8FGS5b7QXYgC0yzLU Nd4LDuv8tmWRl5u8hYl7pzG9SlFPd7yYiOYzjQG2lDfsjZncKBU5lJIdUvBHdVxJVT s/hfYy5QbHEt6T15aj9L3OXo2bcGOhKKLmf8pZN0= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20200522121756.flbhzzkfht73kf5h@crankycanuck.ca> References: <20200521214124.271EC197E0DF@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 12:18:07 -0000 [ObDisclaim: I work for the Internet Society, but I'm not speaking for them.] On Thu, May 21, 2020 at 05:51:37PM -0400, Warren Kumari wrote: >These IPs are only in the ADDITIONAL section - they should not be used >as answers. Are you quite sure they're not getting used as answers though? Are you sure query minimization is on for all cases? If not, you'll ask the parent-side server for the A record and may get an answer, though non-authoritative. The _reason_ you'll get an answer is because of the need for the glue -- it could be that you're asking the question because you didn't have the glue because of TC or something, and so you're coming back and asking explicitly. I know that at least one system that I worked on would definitely respond this way, because under some circumstances it was certainly necessary to be able to give such an answer. The AA bit wasn't set due to the delegation, but you could get the answer by asking for it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri May 22 05:47:41 2020 Return-Path: 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 E16933A0BB2 for ; Fri, 22 May 2020 05:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 W_0KbDhuVaDb for ; Fri, 22 May 2020 05:47:35 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A33E43A0BAE for ; Fri, 22 May 2020 05:47:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:33352) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1jc75J-000LC1-d6 (Exim 4.92.3) (return-path ); Fri, 22 May 2020 13:47:33 +0100 Date: Fri, 22 May 2020 13:47:32 +0100 From: Tony Finch To: John R Levine cc: Warren Kumari , dnsop In-Reply-To: Message-ID: References: <20200521214124.271EC197E0DF@ary.qy> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 12:47:38 -0000 John R Levine wrote: > > A week or two ago I scannned TLD zone files to see how many signed A and AAAA > records there were. Quite a lot, most looks to be orphan glue in Afilias > zones that they didn't delete after the registered zone went away. I vaguely remember a policy change in .com and .net years ago when they stopped including orphan glue in the zones. Was this to do with prep work for DNSSEC? I'm slightly surprised .org didn't follow suit. Tony. -- f.anthony.n.finch http://dotat.at/ Rattray Head to Berwick upon Tweed: Southwest 5 to 7, increasing gale 8 at times later. Moderate or rough. Rain then showers. Good, occasionally poor at first. From nobody Fri May 22 06:24:57 2020 Return-Path: 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 33C453A0366 for ; Fri, 22 May 2020 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jQphWFSI; dkim=pass (1536-bit key) header.d=taugh.com header.b=XymKDCbb 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 12Ft-IvL-tV5 for ; Fri, 22 May 2020 06:24:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6913E3A0365 for ; Fri, 22 May 2020 06:24:54 -0700 (PDT) Received: (qmail 72028 invoked from network); 22 May 2020 13:24:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11959.5ec7d2a4.k2005; i=johnl-iecc.com@submit.iecc.com; bh=X+j1J5VbImrAhbgFlZyTmZHGKGFdWonWz9NpTqmBaBA=; b=jQphWFSIl9DH7QY86nKKQ3q2BU81C7+KpJwfmkPjZsXPt31y5ie07+SqDPtkBfM7DP00/qHksHabUJCJyU/1Budj0ZKp/p+7bW6oWY1Jn07FmE/5Wtni0GaAEjyYT7IcotjRb/M7up9sK2glSnZGrtd//YpkFIDLnrD5i75CW0HCilNoU2kesB/kzvp96fEs9sw8Cp4GUxYbZxDjFySTJppqZA3rXQQXV5VF1qrHMm6meGlo88lcIvjibZOvOUPP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11959.5ec7d2a4.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=X+j1J5VbImrAhbgFlZyTmZHGKGFdWonWz9NpTqmBaBA=; b=XymKDCbbdUVyhuxIVPqQC2OQ9RmXIK1k3vMsISYieRvCe7/fy15vIkYRsNietPBOwrLkYHOpSdXXHNlze88YNQZJFr9k4Mv45A/oucNtpfdMbPd2+19NU1kK7ZE/nphFqb3AU8eB+0bMuuNCVfxyTK6KxDRLrR6HmuhndTGNmZIrkMZfbBvWr5sFS0bGQF+KbzalTxlgc24Vqg6jmylKJuC4pisUqgDqHqwPewZPM/rt8IZDt/AsUo0Ks8Alwtdy Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 May 2020 13:24:52 -0000 Date: 22 May 2020 09:24:51 -0400 Message-ID: From: "John R Levine" To: "Tony Finch" Cc: "Warren Kumari" , "dnsop" In-Reply-To: References: <20200521214124.271EC197E0DF@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 13:24:56 -0000 On Fri, 22 May 2020, Tony Finch wrote: > I vaguely remember a policy change in .com and .net years ago when they > stopped including orphan glue in the zones. Was this to do with prep work > for DNSSEC? I'm slightly surprised .org didn't follow suit. I believe that the policy is to remove orphan glue, and the glue in the Afilias zones is due to software bugs. It's not just .org, it's also .info and .mobi and other zones they manage directly. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 22 06:36:15 2020 Return-Path: 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 EB36F3A053E for ; Fri, 22 May 2020 06:36:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=yitter.info header.b=gIL7+fI/; dkim=pass (1024-bit key) header.d=yitter.info header.b=hqsFAOdD 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 XkDrNHpNTXfa for ; Fri, 22 May 2020 06:36:10 -0700 (PDT) Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A031A3A048A for ; Fri, 22 May 2020 06:36:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id B2BDCBD512 for ; Fri, 22 May 2020 13:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1590154539; bh=rfqszbuMoDfEG9kiR1LJhUOHz/Y1Qrgx8/SRJIAo0R4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gIL7+fI/9cFz5NRQmak/spsvHPDBXtwCDgj7fUHmEdwIaXgALJFI7MvIwFUiVJs91 uzMGpcGDpL8MgDEJ+4Adn8mQguXA35G1+tC7xY4STZbXtvQH+udUizEoGnerdal27B O9TcUt8miBRP9p7ZVCHJIxaMuSypL8f7QA0VjTdc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnCX4V7XCLLk for ; Fri, 22 May 2020 13:35:38 +0000 (UTC) Date: Fri, 22 May 2020 09:35:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1590154538; bh=rfqszbuMoDfEG9kiR1LJhUOHz/Y1Qrgx8/SRJIAo0R4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hqsFAOdDEnNtJiTGWdPzqE05iE3afI9YWLqW6X5QtQnnZPFI1/jFWam+3nKP0RjI0 lomsU0ZmUdqHIhq87PF2HjbzODsjAgUdoNJtSfE5bm0f2pC5jUfKAAQh0Qw/iJpoP+ 6chXQLKvhyfkCffUe7FoaQ2EEGIB14cvkjZhltRM= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20200522133537.krrhliu2rvuvy3qn@crankycanuck.ca> References: <20200521214124.271EC197E0DF@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 13:36:13 -0000 [ObDisclaimer: I work for ISOC, but don't speak for them.] On Fri, May 22, 2020 at 09:24:51AM -0400, John R Levine wrote: >I believe that the policy is to remove orphan glue, and the glue in >the Afilias zones is due to software bugs. It's not just .org, it's >also ..info and .mobi and other zones they manage directly. > There were historical reasons why glue was not removed on various occasions, on purpose. So I doubt it's just bugs. I know there was a policy decision sometime around 05 or 06 that caused orphan glue to be removed, because I wrote the database code for it. That is, by the way a good reason to suppose that bugs could be part of the problem! A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri May 22 07:33:10 2020 Return-Path: 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 E47083A09C6 for ; Fri, 22 May 2020 07:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 RPvyRUnbwR2C for ; Fri, 22 May 2020 07:33:06 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 7054A3A09B9 for ; Fri, 22 May 2020 07:33:06 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id o19so8373522qtr.10 for ; Fri, 22 May 2020 07:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v08Zfi61F8PlDrdvk5DnLnVMTyLnwcCJOzQr+JE3D50=; b=fZjkLSffdjsVCxRTugkywzaA4jTpiGz39aJtNuA/tk56hkMam2YUvQGNk8qFEHOyNM N+6ImBIS3qDoa64KWZ3D6NJpKeHxiOrLkYmrTQUx+SBE+MpeccGUmZN059jFNtEyR3AC n2j+cG3NDkOuTSEZ8HbiShia3p/PBeDxDb42I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v08Zfi61F8PlDrdvk5DnLnVMTyLnwcCJOzQr+JE3D50=; b=doBPILt5LgWR3wEk3eUUnkBQti8ayYfeFPKUMZeEo0336RFm1PYxc1Lox5+YcJvHpl Pq5ytGlVnSKreA0Rdq9y3PsQdsWONXL1eLUUqJYb6UeSvK3DYa5vwmd3zrFEOwk73MKM ED6TH7kRUL00L142o11YoH28uZ2EZf2UDgyEuycYZV04BKMYFzCjyFTxmjgbTKIlQV8d DF4N6l+KGUb1A7JiW4fQWis0Zas5WHzlCOydLQrCnEALCX9NAPU23PNVp22g/ohirpEm qm58pHlsEdHdoD3jWojUQRCc1tfSf65QGJvgs2N+SBQEsJnbm6drGOb7vvQt/l+PWZys dgww== X-Gm-Message-State: AOAM5321DSbIk2SBGy5ai2tGApuylBeR+s+zTH+V/cEYqZdPLVKoX0Ow uGLnitOV675I3eCINWo40BVobsB23Tr0B9EJ X-Google-Smtp-Source: ABdhPJwp7YS0SotWShWqQ87AsQP9/0Qq0FphqM3rNSYNdAwy6ZvP5RbqZcsFEZ6atPELYIgsre5IjQ== X-Received: by 2002:aed:2467:: with SMTP id s36mr16013368qtc.292.1590157985090; Fri, 22 May 2020 07:33:05 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:dc08:d905:3ae2:aab9? ([2607:f2c0:e784:c7:dc08:d905:3ae2:aab9]) by smtp.gmail.com with ESMTPSA id l6sm6549280qkc.59.2020.05.22.07.33.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 07:33:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joe Abley In-Reply-To: <20200521214124.271EC197E0DF@ary.qy> Date: Fri, 22 May 2020 10:33:01 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <907EFB9A-590D-49B5-B8D9-80D9E38F2D10@hopcount.ca> References: <20200521214124.271EC197E0DF@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 14:33:09 -0000 Hi John, On 21 May 2020, at 17:41, John Levine wrote: > In article = = you write: >> What if you *only* have glue, and no authoritative answer / server? >> Can I register example.com, put in www.example.com A 192.0.2.1 as >> glue, and not bother with this whole annoying authoritative server >> thing? >=20 > Based on my recent analysis of TLD zones, yes if the zone is managed = by > Afilias, or if you have friends at Nominet. Otherwise not so much. I think that some of the things you have been looking at concern orphan = glue, John -- glue records that have been promoted to authoritative, = signed RRSets in the TLD zone following the removal of a zone cut. I think what Warren is talking about is the behaviour of the DNS as a = whole (stub through authoritative) in the case where the zone cut is = still there, so the A/AAAA records he is exercising are glue in the = proper sense. Joe From nobody Fri May 22 07:44:20 2020 Return-Path: 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 DB08C3A0B06 for ; Fri, 22 May 2020 07:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 lNZDrLed6ne5 for ; Fri, 22 May 2020 07:44:17 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 AD21B3A0B00 for ; Fri, 22 May 2020 07:44:17 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id l1so8434500qtp.6 for ; Fri, 22 May 2020 07:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X7Odz+GZo6UhCQIOxuk9/kI3kYNLKhM8cb3gEcMCJBw=; b=CqhTo8JXbWfmD6dRy4aoBzadf4oAj3FV8Qbt18v8+8meIxTcVVBacmAPxog1dYq4Mk Q2wpnV0mTjwjodXpGSLcsnbtrZS1/pzTdzHLC/lWzWmb649LMM5dDr/GDoxTcCKSmVBe wx8FwBY+6W1YjUPihk41fJrGRMoqX2fgOc2dk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X7Odz+GZo6UhCQIOxuk9/kI3kYNLKhM8cb3gEcMCJBw=; b=d1Fm2YBvRE936PrsdDPBm+aCXmmmxsp7pkIHRsq5t23bYEOc2nS8KJAM7ROMqr87P3 bg5oRaUeOH9qsNT2Ww95ThgTAsPW9LSVfkAMopiKsBoP9Dyg6T1RAtvRCktagIoso41p hwuPf5ZleQarCWYw1rU6I/R3VHKFfO3pr7p9jm6EM656fFgtbuOWl8u2r1ValWiBqpTN MXeSPjHH6W1MdtztaPqWGTIhnF5SadFxCmbFrkSVS9qvPoH+TyK1DC+twZn/EtQWz4lG lGuger1VfQcRNOwvI3X4ZmljgtSROG2E6J4a+/XhTL4SkmNH7O6HhbXQV3QpvDCUq2MB MwOg== X-Gm-Message-State: AOAM533Hk/KvMli5nVCh7WaWwr2WPPEhxEVZCZjgIaX51lL7cpSHatqd M4JdZST8p8QezhNwmhI+IFtbtPBRoBCyQpop X-Google-Smtp-Source: ABdhPJwNk2nW0LzcbivGxHyeS4Qd02IgLDxQjC+ajFjpOvdEhX3GTuEi3U201YuyR0gjmAW03LXNtA== X-Received: by 2002:ac8:326d:: with SMTP id y42mr15903184qta.243.1590158656431; Fri, 22 May 2020 07:44:16 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:dc08:d905:3ae2:aab9? ([2607:f2c0:e784:c7:dc08:d905:3ae2:aab9]) by smtp.gmail.com with ESMTPSA id h185sm6056544qkd.80.2020.05.22.07.44.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 07:44:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joe Abley In-Reply-To: Date: Fri, 22 May 2020 10:44:14 -0400 Cc: John R Levine , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <52A07992-DF42-4029-ADE7-E6B27BEBCA34@hopcount.ca> References: <20200521214124.271EC197E0DF@ary.qy> To: Tony Finch X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 14:44:19 -0000 Hi Tony, On 22 May 2020, at 08:47, Tony Finch wrote: > John R Levine wrote: >>=20 >> A week or two ago I scannned TLD zone files to see how many signed A = and AAAA >> records there were. Quite a lot, most looks to be orphan glue in = Afilias >> zones that they didn't delete after the registered zone went away. >=20 > I vaguely remember a policy change in .com and .net years ago when = they > stopped including orphan glue in the zones. Was this to do with prep = work > for DNSSEC? I'm slightly surprised .org didn't follow suit. I think the change you remember was a change in the way that responses = were returned from the Atlas nameserver. Once upon a time, glue was = returned in the answer section alongside a referral. The change I am = thinking of changed that behaviour to follow other implementations, = returning glue in the additional section instead. ORG has not been served using the Atlas nameserver since the = redelegation to PIR. Joe= From nobody Fri May 22 07:49:36 2020 Return-Path: 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 26B723A0B8B for ; Fri, 22 May 2020 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 3i6jAgzCSK_d for ; Fri, 22 May 2020 07:49:24 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 77F103A0B76 for ; Fri, 22 May 2020 07:49:17 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id i9so2213413ool.5 for ; Fri, 22 May 2020 07:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wZjKlDJwqPgApq7x2kZ6DP9s9PY5ong0mBT3CTxC6GU=; b=qH1eqisAMbNeTvlSXD0ScT1ScS7mAOmusyuto5MvG5hHuoRr0yZg5AOnS97IN+oU7E 9f5wDCvl60NYzVxRrug59wHgwynhuZ4irntPrC80YNaAYRSqX1S39JuNGdAe7YuQbH4S Ym6rVBc3Tw81zYFzd1smG07hVLxlAewRyUw7Rvb0atDnxehUmEjfl7rfh9vPEfHHQh+7 Qmug6zsBjQFeY9aWCjx/969ErJHBRj6bNaaYp0nN/DO1Z2R2FoN0rnSnu31+PwaUWIhy CQE6lHPd9SRlsU4OHMvwU2lWhgqVqO4m7eZljvSRPemOKd52GCFbvEhzMluhmDbHiYhM jlMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wZjKlDJwqPgApq7x2kZ6DP9s9PY5ong0mBT3CTxC6GU=; b=R6oXAELJq28lYgn31QBew3xcD0Ie/enebsgHYbHmwdv22+a5p0SmSuR05hNmkcBUwQ zJTCb5DGAZVtniwhKJLC4PkPujocP+PYpJ3pkcgC15wigoJAu4Z6MnpmTgCTHVziPFYj sOZUs7/vY3wCWN+WrEo5+XHaM2Gy1M7ztcRo4Ugxpk2RU9qNDsy3DElP16Lut1ljwlbd pDlq40XuFJIqd8d37iQAG4Y8Nmd6C95cQrYslpgiCuzw0SGKqcCG5I0ZBvPHC3ytNWcS 3AtLusg2zke+aREUI8/drEg8rV+2kdRviZVVR3BwkZtgclNJWynOyJMW5YFBq2E4Baj2 Za8Q== X-Gm-Message-State: AOAM53089alsZuKZzfTLujOecM0r62OvwvRRJRyFsyRGh5Y7L8fA3B4x 0N3h1eGjoOEe481RCBDxTbd4NUe2QHdEIa5PwSo= X-Google-Smtp-Source: ABdhPJznLOuojFVw+4filHuIYYAOX9WRQqRmhA3hOfjE/HnTLZ45AYerOyVoXMxuB+7CpZxGnQn7iSpOjbwBaUI/aBQ= X-Received: by 2002:a4a:e795:: with SMTP id x21mr3205700oov.91.1590158956665; Fri, 22 May 2020 07:49:16 -0700 (PDT) MIME-Version: 1.0 References: <20200521214124.271EC197E0DF@ary.qy> <52A07992-DF42-4029-ADE7-E6B27BEBCA34@hopcount.ca> In-Reply-To: <52A07992-DF42-4029-ADE7-E6B27BEBCA34@hopcount.ca> From: Shumon Huque Date: Fri, 22 May 2020 10:49:04 -0400 Message-ID: To: Joe Abley Cc: Tony Finch , dnsop , John R Levine Content-Type: multipart/alternative; boundary="000000000000bf9feb05a63dbb04" Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 14:49:34 -0000 --000000000000bf9feb05a63dbb04 Content-Type: text/plain; charset="UTF-8" On Fri, May 22, 2020 at 10:44 AM Joe Abley wrote: > Hi Tony, > > On 22 May 2020, at 08:47, Tony Finch wrote: > > > John R Levine wrote: > >> > >> A week or two ago I scannned TLD zone files to see how many signed A > and AAAA > >> records there were. Quite a lot, most looks to be orphan glue in > Afilias > >> zones that they didn't delete after the registered zone went away. > > > > I vaguely remember a policy change in .com and .net years ago when they > > stopped including orphan glue in the zones. Was this to do with prep work > > for DNSSEC? I'm slightly surprised .org didn't follow suit. > > I think the change you remember was a change in the way that responses > were returned from the Atlas nameserver. Once upon a time, glue was > returned in the answer section alongside a referral. The change I am > thinking of changed that behaviour to follow other implementations, > returning glue in the additional section instead. > Here's the announcement of that change from Verisign (January 2010): https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004841.html Shumon. --000000000000bf9feb05a63dbb04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 22, 2020 at 10:44 AM Joe Able= y <jabley@hopcount.ca> wrot= e:
Hi Tony,

On 22 May 2020, at 08:47, Tony Finch <dot@dotat.at> wrote:

> John R Levine <johnl@taugh.com> wrote:
>>
>> A week or two ago I scannned TLD zone files to see how many signed= A and AAAA
>> records there were.=C2=A0 Quite a lot, most looks to be orphan glu= e in Afilias
>> zones that they didn't delete after the registered zone went a= way.
>
> I vaguely remember a policy change in .com and .net years ago when the= y
> stopped including orphan glue in the zones. Was this to do with prep w= ork
> for DNSSEC? I'm slightly surprised .org didn't follow suit.
I think the change you remember was a change in the way that responses were= returned from the Atlas nameserver. Once upon a time, glue was returned in= the answer section alongside a referral. The change I am thinking of chang= ed that behaviour to follow other implementations, returning glue in the ad= ditional section instead.

Here's th= e announcement of that change from Verisign (January 2010):
--000000000000bf9feb05a63dbb04-- From nobody Fri May 22 07:52:36 2020 Return-Path: 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 CBA0A3A0A84 for ; Fri, 22 May 2020 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 DC3PLUOwg_Hx for ; Fri, 22 May 2020 07:52:32 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 B451E3A0A36 for ; Fri, 22 May 2020 07:52:32 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id f83so10860108qke.13 for ; Fri, 22 May 2020 07:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BhtmnAS2kwG2Q1Neu+izGzj9ujex9ssniKKG2y71rXo=; b=mme+6n6MASISvQpfYc4GFOVCElEYpeihFuIg2vu4tgwiXA2DG6ZnvXUSqP9bzx4DY8 hW1oV7UHpcKPJ7ngQRIUDb71G/ppBMqPgQ+isTujpcfpU536SkvmpBjUGq/5i4aSXVDY VSqjoynSC49WNJyqyRWyJ5OOgEXhdW/oZ5oAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BhtmnAS2kwG2Q1Neu+izGzj9ujex9ssniKKG2y71rXo=; b=QiTBB60yKtGKzuNwwQpzUoNmspBh8ghrxpwA7DvrCJYPsOAUfAQ3wR7G68lKF32XZ6 +3UBUlMRQaJNx+hAQlHuqz6a3gDmdyM+PBleWzbyT3ICrD20jmzdznRausZP2o6nYvSU by2ovt2q/fSIC3rD4OZUDklr9UhDtdwu6FxjuZxqyfV1qPENFoFq62l4g0DLmK5GBEVi EHTAh1hCpLNIa5zXb55gL7FTP2GnVH9H7EOFRtVMgtvy1d98VsuItD1+hN0XpuhY3JgY mcB3omUqrvAAbkHuvneSjXdonL4z6wlXSkR6HABTvUeo+9hvr/YJ4WB5K6Rf5b9N3SmB YOog== X-Gm-Message-State: AOAM530b8q5fwAIc9Y780YGttADpGHoYd5f25EtNujLmXAyPGNPPUNmo kW/ocn9FI5YyqYl3ksIQvh64oZ5LR2JV1QIj X-Google-Smtp-Source: ABdhPJy1waX6ywJCCzNXyrMJQerd9at9jfGqEeMYtx8DlLmeyxIq+apZbI7r5YVgp4OcmPuOPHpgIg== X-Received: by 2002:a37:bd82:: with SMTP id n124mr15623867qkf.168.1590159150574; Fri, 22 May 2020 07:52:30 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:dc08:d905:3ae2:aab9? ([2607:f2c0:e784:c7:dc08:d905:3ae2:aab9]) by smtp.gmail.com with ESMTPSA id g1sm7999121qkm.123.2020.05.22.07.52.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 07:52:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joe Abley In-Reply-To: Date: Fri, 22 May 2020 10:52:28 -0400 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 14:52:34 -0000 On 21 May 2020, at 16:07, Warren Kumari wrote: > What does all of this *mean*? > .. > .. > .. > Sorry, I haven't a clue, other than maybe: > The DNS is weird. In your experiment it seems clear that all the glue records you are = looking for are being returned from the involved authority-only servers = in the additional section, and since for the COM zone that's a = well-constrained monoculture of software it seems reasonable to imagine = that's not where to look. Similarly, by testing using Atlas probes the stub resolver presumably = also represents a monoculture (or if there are different versions of = probes, there are surely not that many different versions). What remains is the tangle of resolvers, forwarders and proxies that = exist between RIPE atlas probes and the authority servers, where there = might actually be dragons. Not for the first time, I wish we had = something like traceroute in the DNS so that we could isolate those = paths rather than simply looking at exit addresses and trying to make = inferences from them. I guess for some (apparently decreasing) = proportion of those Atlas probes there's at least one dragon between the = probe and the COM server that caches additional section glue and is = happy to return it as an answer. I don't have any clever ideas about how = you'd isolate any particular fictional reptile, however. It'd be interesting to continue this kind of experiment over time and = see where the success rate for those queries is trending. Joe= From nobody Fri May 22 07:55:13 2020 Return-Path: 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 93EAE3A0C50 for ; Fri, 22 May 2020 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=kTkNzrdE; dkim=pass (1536-bit key) header.d=taugh.com header.b=IG14Xrgf 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 yLvZdpHUxt-r for ; Fri, 22 May 2020 07:55:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E3E723A0BCE for ; Fri, 22 May 2020 07:54:59 -0700 (PDT) Received: (qmail 7218 invoked from network); 22 May 2020 14:54:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1c2f.5ec7e7c2.k2005; i=johnl-iecc.com@submit.iecc.com; bh=19oBQnClx1l2T5rA+bpiFNbaaboaPQVdAAYoGpRu0ao=; b=kTkNzrdEb6vMlc1aHH7ZIPZL1NxsCUnLJIaq4WGlyhenaXnRPXjmBDMoha7uVkHMN9xcbm2NkMnBdFpJ1kMZl54IOr6bwTmm8GSiiM/aTHxmA+NTEKL+TNaJAJ/dqFOMsIW+t2az1Su4ypsqKoHMbf8ezD2dp096ezBfyyskjt6u8Ia/Hc0NvY3c4Krh3AG0q5KLXW1hh8zd0/ZVjbfsq8g76J12LpvLiVi29Yw3x6QwLEIjH77OIoWuII8aI5Ga DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1c2f.5ec7e7c2.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=19oBQnClx1l2T5rA+bpiFNbaaboaPQVdAAYoGpRu0ao=; b=IG14Xrgfr/9YlLpqIy2vy7NNlV4c2incjOdtQvIpspKNgqyC5zvFtihtmhN4wOKR5G6KEd+NGU/PI/7KsYroVZI59w9XdHkm3Y9d6L9UYI9rNuGYTipNZgFO0DHNYSC8TLOP0zAxfc/XQOf5libdN3Yxm1cucLl+pT5nqhwODPGiszM81n5yagkbCjcnrz7aS72AQIrav5Teb+8HxDzwMv3nC0Lwo/ZcDIg5qRzTyKIcCvU0E7H8MvbvuRK2vt7Z Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 May 2020 14:54:58 -0000 Date: 22 May 2020 10:54:58 -0400 Message-ID: From: "John R Levine" To: "Joe Abley" Cc: dnsop@ietf.org In-Reply-To: <907EFB9A-590D-49B5-B8D9-80D9E38F2D10@hopcount.ca> References: <20200521214124.271EC197E0DF@ary.qy> <907EFB9A-590D-49B5-B8D9-80D9E38F2D10@hopcount.ca> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 14:55:09 -0000 On Fri, 22 May 2020, Joe Abley wrote: > I think that some of the things you have been looking at concern orphan glue, John -- glue records that have been promoted to authoritative, signed RRSets in the TLD zone following the removal of a zone cut. > > I think what Warren is talking about is the behaviour of the DNS as a whole (stub through authoritative) in the case where the zone cut is still there, so the A/AAAA records he is exercising are glue in the proper sense. You're right, they're different. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 22 08:00:29 2020 Return-Path: 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 F389E3A0A01 for ; Fri, 22 May 2020 08:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 tUQ8XFHsKJcb for ; Fri, 22 May 2020 08:00:17 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 40DDB3A0B11 for ; Fri, 22 May 2020 08:00:16 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id y85so9474541oie.11 for ; Fri, 22 May 2020 08:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nf0A6lM2uDrlpzuMrVKFHT91zL9E7peWbx+7j+SzUo4=; b=cXqssilDEV5ekb3dR8F9sylPE1IZ884sC0oRf+1mnYx/VxoKqAEzbwhXgcut5ZRxLX byu8e4HtsZOi4sCuKfNoQ+ByBuyImqAt7kpxMMMxUB+Hk+MvjQ3GSZf0fw4TZ24w9Xxf 4QBtiL/caE/32OTMKMB5t/0H/Yt2J8bJ7FRdSDxrpq/kUUV07NI5JR3hqEqh3Lg2qqkq f1q4jJ4hnWoRdik2H3mZo5SR3kshGWEFddkPZvnuYQKK6E2yfUvfvLOqz9ecoQm6SxG0 27rcITE0nqGRYoFbhW8eYR87ncCsksAjLthrOVcwKApSy7rxtYUi71plnC8oNHhtokYK yklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nf0A6lM2uDrlpzuMrVKFHT91zL9E7peWbx+7j+SzUo4=; b=oDpNtQSWUjPk9b+w6txqo7oI7n5+Bckl8VVnRLZQZKWrsbau7GLGe8GDz+JE9WDnb6 ynLWJO97R/MZb5Q1BwJHoFngUiZyoNOeb4vQMaXple18HtmP6FPI9AqITZjUAVJ8NVjP QJUPlYtvtjJovAV/nMtPsoudt4BGUkNWI9SzpCUFMK+PqXEwSwrNTIi+OliB1YqRAD9D 2pTxcUfktjQGGHc9FDgzF6QDPZ7Eqv8jzihk9UOC5BBRAlnFcc0qpVbJdB0U+tasDPTO eZeVZ6/MNdHuFa8VwyAVNxMCpu7np0e83QxQLSWQ0eMD1dGuyRTKAE2SjGM2kTvu2ZqM ieUA== X-Gm-Message-State: AOAM532dcjTRip3pB52HPuRoUdzmJmrol09Xu6TiKeTiNIl7+H6zCavH ny9ksUk52ujEDklnuCRNYYrjCu/TrIFI4kIB4mM= X-Google-Smtp-Source: ABdhPJxnjiWag1aUlSU7IYTJ82QSYmseBvG/CixkroeGIjceUPL7y3qEFI626dtSnZmXNRdYOoJBIl+lEaYh7Si4i9w= X-Received: by 2002:aca:be41:: with SMTP id o62mr2891608oif.133.1590159614710; Fri, 22 May 2020 08:00:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shumon Huque Date: Fri, 22 May 2020 11:00:02 -0400 Message-ID: To: Joe Abley Cc: Warren Kumari , dnsop Content-Type: multipart/alternative; boundary="000000000000f897f105a63de24a" Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 15:00:22 -0000 --000000000000f897f105a63de24a Content-Type: text/plain; charset="UTF-8" On Fri, May 22, 2020 at 10:52 AM Joe Abley wrote: > On 21 May 2020, at 16:07, Warren Kumari wrote: > > > What does all of this *mean*? > > .. > > .. > > .. > > Sorry, I haven't a clue, other than maybe: > > The DNS is weird. > > In your experiment it seems clear that all the glue records you are > looking for are being returned from the involved authority-only servers in > the additional section, and since for the COM zone that's a > well-constrained monoculture of software it seems reasonable to imagine > that's not where to look. > Indeed. Since the COM referral response to glue queries is correct, this means that some resolvers the Atlas probes are using are promoting glue to answers. Has anyone surveyed which of the following category of things are promoting glue to answer: (1) other TLD authoritative services, (2) authoritative server software implementations, (3) "public" (contentious term I know) resolvers, and (4) resolver software implementations? That would be an interesting but possibly very time consuming project - but we could focus on the major ones. Shumon. --000000000000f897f105a63de24a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 22, 2020 at 10:52 AM Joe Able= y <jabley@hopcount.ca> wrot= e:
On 21 May 2020, at 16:07, Warren Kumari <warren@kumari.net> wrote:

> What does all of this *mean*?
> ..
> ..
> ..
> Sorry, I haven't a clue, other than maybe:
> The DNS is weird.

In your experiment it seems clear that all the glue records you are looking= for are being returned from the involved authority-only servers in the add= itional section, and since for the COM zone that's a well-constrained m= onoculture of software it seems reasonable to imagine that's not where = to look.

Indeed. Since the COM referral= response to glue queries is correct, this means that some resolvers the At= las probes are using are promoting glue to answers.

Has anyone surveyed which of the following category of things are promoti= ng glue to answer: (1) other TLD authoritative services, (2) authoritative = server software implementations, (3) "public" (contentious term I= know) resolvers, and (4) resolver software implementations?

=
That would be an interesting but possibly very time consuming pr= oject - but we could focus on the major ones.

Shum= on.

--000000000000f897f105a63de24a-- From nobody Fri May 22 08:57:05 2020 Return-Path: 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 700B23A0B71 for ; Fri, 22 May 2020 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 j_KRg-nUOs_9 for ; Fri, 22 May 2020 08:56:58 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110078.outbound.protection.outlook.com [40.107.11.78]) (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 D4D0A3A0D1A for ; Fri, 22 May 2020 08:56:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PikSrP2jrc6XcLCcQbLD3bV3YvXRBLV0aqXWYog9BaTGLhUmhdyyUCunn6wT9s7OnfvPpQgDOpNX6GW9Owhsjyft/ZHtFM2ux00eij1X8RM6XubgkGNv+8rI2GiDTHnXhyeEmBl/05tB8mbv0UN0wQGorc0vGcn9HflhIXdD9jEU/4CWNaNWJepAjUND1tanE2c/Lf7jfKAhRz0dU4ZCV936p9C/yEryM5TA18hW24tfSzZU+mc5wGEqUswTi6P/ViRL80ibPhkGhZeilxlr47w7bUqJftc/mMyhSDdRz8ckF/WC6Rx3+kCUKqh2tTlyktzaMxJ/DUyz5DSQD5zyTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kc6YOTG+H6Akne50HRnLYqnNdi6E1sB6Crd6AVukw60=; b=nD2k5iVp3fyyUiUUhyYdAxl0mhOJ3vFZpbjxYo8u3I9l7XNxGXpFSkuAjnk3YU1q6jF7qUerMJJCJqK51ShFrbNIVMve6F2VkPrT50+vMtNVsR5jufIQPyER2sWsqF1S80GgYzn6O1ifWi9mOrPgVFUxc4njBZqKC1lZfvz29bwUvox5SOrIWLvnoT1jKry3e0CPXJ8JTSVufB8DjhfEhxVq640Kspa/TZ4feHOVpZMSyRUoFs32MjstLGw20id3NbohrcoL+NqdSbzJb9HFTeJG9j8nan2w6IFG3uKkaZ52MjIj6gdmbW8yckGFI+e9Xnl0cFg640K96bucs9SLIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kc6YOTG+H6Akne50HRnLYqnNdi6E1sB6Crd6AVukw60=; b=NP1aCyAHs/jx4P2EV49Pgp3MKshqlAQvZsVgirAxHIsAU7RfvHkZ7xgTruliOL7iIW1fkoXhVJTusvn/Z3L4rGPeCdvWAcRfshZR4nCryLg4F7N0/fcC0x14KcR2lEbxduc6F7+Gpcm1gHIjbDLBnmBsxuoRH52WCkn2TUpCN9c= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB1120.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:91::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Fri, 22 May 2020 15:56:41 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a%5]) with mapi id 15.20.3000.034; Fri, 22 May 2020 15:56:41 +0000 From: Andrew Campling To: Paul Vixie , dnsop WG , George Kuo CC: George Michaelson Thread-Topic: [DNSOP] definitions of "public DNS Service" Thread-Index: AQHWL+3aGvUjaE4STUS08wT8dS5KOai0QN8A Date: Fri, 22 May 2020 15:56:41 +0000 Message-ID: References: <2487238.otjEU5M4pH@linux-9daj> In-Reply-To: <2487238.otjEU5M4pH@linux-9daj> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redbarn.org; dkim=none (message not signed) header.d=none; redbarn.org; dmarc=none action=none header.from=419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18ac9aba-3180-4513-e4f6-08d7fe68b7e9 x-ms-traffictypediagnostic: LO2P265MB1120: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 04111BAC64 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HjCLuZrlvs5L7FAe5DsO/DUKdLvGvVF+f4NpMd/rhZLMkPEX2TrJKVNZdJyadHsAiOCzPoY8KD9CV0K1/VhFrIv9pXGA18Ic4RnSavf0/cLiw4l2ftsYXf6vx921rWH4Ay4TWhReH9aMRteF5yJiFlUTCAr6qJmbru/U931LaLPMSZnc7MLBT1y4arv/9yf7SQCTziuwxh9ZHPlloQ0F7woGyibOVfL4LyN+OBbY77QI7JnCshTm8FkfzfSpfAjEhugCJ1mXzBjh3HOv18Ma/eCyaYcOLacfp9uea9ZWrLZ1Elzbu/qoXUeaGwZarT5RUFmRNBn87+x3bzfZwg6MwOUKD5V+VjrO6wWGIG8u7kIafk0TiBR4f/Q76fsXoLFA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(39830400003)(366004)(346002)(376002)(136003)(396003)(110136005)(4326008)(6506007)(52536014)(2906002)(7696005)(186003)(316002)(64756008)(8936002)(66446008)(9686003)(86362001)(76116006)(66946007)(33656002)(44832011)(71200400001)(8676002)(66556008)(5660300002)(55016002)(66476007)(508600001)(46492006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NaWik0eviaT9nLVlWbhG9nbtybTlP1CY3AXhh7j4HORMGelrN6RYnhqH3qOx9LuTpakjzf2wiCqjmAOpPynYUf06qiLlD9owo4VGStByYE6JdK+5YimIVi1T+KsXbw+of96EgzwZ5bTbz0njpaaBf4n4SLzBI2ZQlp7JRF52Z3owj2e05pp+06ozmEX4+jTfFUD7UuULVcL4lPUW5Cn+9hN/QXovaenVbhoHQ0HJ0fTk6HAaGVxg8UxlFtHq+0Ws5muILdmz6IGtFS7ujU8woQYSUvdN6eCQbos/+tjqNHkyHM+EDDwk0KwAq+iVCaUqt/saSuvqlkwEJhm2fNtyqGDqyLu2kJc89NCmwXuGZWjKvSc9ovGYZjv/sSWQsHscDDae7bxp87I1x/ZexULrjKX+9YiUbjWXjBJXE+C3CvMxY+9YAP32GkpdyEUqBuF6TV/d5euh7WZmLyPW79B3ASEKclKi36eW8uijHe93jRfGFyf3X0WcWEEyZ+GtR38F/ic+NHo3QcaC0Qo5SvxJPgW30FO1fL7qP5dNuUzGLOk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 18ac9aba-3180-4513-e4f6-08d7fe68b7e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 15:56:41.0628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CB8Mo6ca9g36izYZdaO1DaQfzmjxPPjh7TzTNvdSMqtz7nuksb5I8+V8wU5+5RHY/+4TDFDHIXVqxa/ejiAzEeCfVfbFMStAM/j/3kDLmoE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1120 Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 15:57:00 -0000 On Friday, 22 May 2020 02:38 Paul Vixie wrote: > > On Friday, 22 May 2020 00:55:34 UTC George Michaelson wrote: >> My Colleague George Kuo asked me for definitions of public DNS=20 >> service. not "public DNS" but the trigram "public DNS service" >>=20 >> Colloquially we understand this reasonably well. It is in the space of=20 >> what Google, quad9, CloudFlare and others do. The various clean DNS=20 >> feeds people subscribe to, it is the functional role of a recursive,=20 >> but to the public, yet somehow not the bad one of an open DNS resolver=20 >> being abused to do DDoS: its the conscious service offering of a=20 >> recursive/cache/forwarder in the public view, a declared intent. > > these services aren't public in any way, and should not be described as p= ublic.=20 > they are operated privately for private purposes, and merely used by some= =20 > members of the public. I agree with Paul that the use of "public" in this context is ambiguous in = meaning. Instead of "public DNS service" I'd suggest that "cloud-based DN= S service" is a better fit, no doubt others will have their views too. Andrew=20 From nobody Fri May 22 09:31:07 2020 Return-Path: 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 977333A0AD7 for ; Fri, 22 May 2020 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 dyZ8M03rWqIw for ; Fri, 22 May 2020 09:31:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C423B3A02BC for ; Fri, 22 May 2020 09:31:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49TBnH6ptczG4L; Fri, 22 May 2020 18:30:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1590165059; bh=adBwXNTrrvPSADodGHw0OaDDUomMTDz2nbMuaBRLdPk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DDvRanIXqSb9WjVMBo1IZprIqADYvESxMpFZSHQYleZtPr3Y0/SqfS6WCZidvYZBR p1MPRHLc7QOE1knhPN8PZv9T7nKkncO7MW0YdKG8qnxrTSVxuoyIXiCJIXCh8G01Ca BPNjeFSebauu4xviloQ/UNhs6AC7MICe5EwVb3qY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5q-Xzq2Fprbm; Fri, 22 May 2020 18:30:59 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 22 May 2020 18:30:59 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 348346020EFF; Fri, 22 May 2020 12:30:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 33D8066B7C; Fri, 22 May 2020 12:30:58 -0400 (EDT) Date: Fri, 22 May 2020 12:30:58 -0400 (EDT) From: Paul Wouters To: Joe Abley cc: Warren Kumari , dnsop In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 16:31:06 -0000 On Fri, 22 May 2020, Joe Abley wrote: > It'd be interesting to continue this kind of experiment over time and see where the success rate for those queries is trending. Although the 2010 announcement email listed only 2829 out of what? 70M domains? And that was before DNSSEC and servers like unbound doing referral harderning that would also lead those to not return answers to clients that are just based on glue. So I would expect that number to be even lower now. So it seems compared the other DNS problems, this is pretty much non-existing. Paul From nobody Fri May 22 09:32:01 2020 Return-Path: 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 4501B3A0B47 for ; Fri, 22 May 2020 09:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 R_OAHlXx5ZSg for ; Fri, 22 May 2020 09:31:58 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 3BF463A0B15 for ; Fri, 22 May 2020 09:31:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60170) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1jcAaK-00068R-eY (Exim 4.92.3) (return-path ); Fri, 22 May 2020 17:31:48 +0100 Date: Fri, 22 May 2020 17:31:48 +0100 From: Tony Finch To: Shumon Huque cc: Joe Abley , dnsop , John R Levine In-Reply-To: Message-ID: References: <20200521214124.271EC197E0DF@ary.qy> <52A07992-DF42-4029-ADE7-E6B27BEBCA34@hopcount.ca> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 16:32:00 -0000 Shumon Huque wrote: > > Here's the announcement of that change from Verisign (January 2010): > > https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004841.html That's the one! - point 2 was what I was thinking of. The way they handle glue under domains that are on hold is very tricky. And I think not possible with standard zone files and zone transfers... Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Northerly or northeasterly 6 to gale 8, perhaps severe gale 9 later. Moderate or rough, becoming very rough or high later. Fog patches at first in north, otherwise rain. Moderate, occasionally very poor at first in north. From nobody Fri May 22 09:59:29 2020 Return-Path: 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 7578E3A0C4E for ; Fri, 22 May 2020 09:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 64_uqmSZn1Fh for ; Fri, 22 May 2020 09:59:25 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 C3A313A0C24 for ; Fri, 22 May 2020 09:59:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:43790) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1jcB0x-000oW0-l1 (Exim 4.92.3) (return-path ); Fri, 22 May 2020 17:59:19 +0100 Date: Fri, 22 May 2020 17:59:19 +0100 From: Tony Finch To: George Michaelson cc: Paul Vixie , Andrew Campling , dnsop WG , George Kuo In-Reply-To: Message-ID: References: <2487238.otjEU5M4pH@linux-9daj> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 16:59:28 -0000 I think despite what Paul H. said this is already covered in RFC 8499: Open resolver: A full-service resolver that accepts and processes queries from any (or nearly any) client. This is sometimes also called a "public resolver", although the term "public resolver" is used more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open. Open resolvers are discussed in [RFC5358]. Paul V. is right that "public" is not a good term in this context. IIRC it was introduced as part of a product name to make it sound less monopolistic. And just "DNS" is unhelpfully unclear about whether it's a recursive or authoritative service. Tony (whose random .sig seems to be trolling). -- f.anthony.n.finch http://dotat.at/ public services of the highest quality From nobody Fri May 22 11:30:26 2020 Return-Path: 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 038393A00C0 for ; Fri, 22 May 2020 11:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bRUDSqv7; dkim=pass (1536-bit key) header.d=taugh.com header.b=CcQfpfVU 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 6nrr2-RJkCPN for ; Fri, 22 May 2020 11:30:21 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 24CF63A0D0E for ; Fri, 22 May 2020 11:30:20 -0700 (PDT) Received: (qmail 56868 invoked from network); 22 May 2020 18:30:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=de22.5ec81a3b.k2005; bh=1dbaVIii2Q1E1O59oMWkEU6uBWdlMMj/2fZMMxRPwFg=; b=bRUDSqv75y7OP8wuvGj7sCX3MrNTVJacyfRyxKpoIiMWPof3YFpMyQ4nU2XCTPO+LZQTU31wSLbeix3A44Ba7ZDl5iQuF72ZjwFP8uxpEzADwcOOaM5vdsLTE7iugtF0zJnDyx3VYPgR9HfvjW0blzSF2qXl/k84yIXoMeVQ9+V4ep2ojRtQO0j293wmwQiw+JxVjPbLJQdu0Q5k28WMXRWM6kkudCrUwkLfhn8Q60gLMCR5CQCalHo7mNoipnxT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=de22.5ec81a3b.k2005; bh=1dbaVIii2Q1E1O59oMWkEU6uBWdlMMj/2fZMMxRPwFg=; b=CcQfpfVUsP7Qwd1UWDyxtUHEVy3F9OHhMxty+rHTj0x+L7GTOoEFMlrBLvz6x2qiJUgZkoqgH6j7ahVWMe77S178w8VwzQ1IHKeDN5aZniBsb2OURg14IItGphI7ukPYLcH9uGM6Np6dRabWqmmTrSgtJLt9bS12dAoxKMkjvOxhVWPgBGSFOovRK2bxUBW866PKzTkvaz/1oOU/lm4EUnqumdO/gc+afa0k63TalHNCFX0d+j4axO8IGSNYhVET Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 22 May 2020 18:30:18 -0000 Received: by ary.qy (Postfix, from userid 501) id C03641984D66; Fri, 22 May 2020 14:30:18 -0400 (EDT) Date: 22 May 2020 14:30:18 -0400 Message-Id: <20200522183018.C03641984D66@ary.qy> From: "John Levine" To: dnsop@ietf.org Cc: paul@nohats.ca In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 18:30:23 -0000 In article you write: >So it seems compared the other DNS problems, this is pretty much >non-existing. It seems to me it's more a policy issue than a technical one. It's technically trivial for any zone manager to compare the glue in the zone with the delegated entries and see what's different. The interesting part is what you do about it. The answer in all the TLDs I know seems to be nothing. There is the separate but related issue of orphan glue, of which there is quite a lot, 28K signed A/AAAA records in .org and 54K in .info. This is not a technical DNS issue, since technically those are just ordinary records in the zone, but they would seem to be policy issues, particularly for fans of POWERBIND or whatever it's called now. R's, John From nobody Fri May 22 12:30:19 2020 Return-Path: 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 8A96A3A0A56 for ; Fri, 22 May 2020 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 xgun4PSvWH8r for ; Fri, 22 May 2020 12:30:12 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 B27763A053F for ; Fri, 22 May 2020 12:30:12 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id a23so9238195qto.1 for ; Fri, 22 May 2020 12:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=2lCpqEPA1YvWdB3S+4vzX+W8GsnqNS0ufBxdIKeTC+Y=; b=vskvOQVsyKF9KUw4tSs8MTWgReLIp11GopQUrK3P/XY9ZU/L8pVSgkOSnSSscY6/jl t64YGDbuZV50db6c22NyGUUY/ORZjpYOR90F2yka1aL3TykPyk5+wyFl8WT5P0kHG8dj hGhVAtLrrYikzK2kMXy+Px/a0FW/WVUnx0mibmkEQOe4OaYJDJhOmlsG4Yo2SuxCv+60 gSUDDIOvUG88yNSFeNhUHyAe7HdiXj3LKR1/zi8p3h4pAaXaMvW6SoF7NCAMOAadOgoH nDxyeys7RmFNGovYamI79fs2GBm0Db6vTxXcvPXjOhnx+oXb6QZMapNrEOD+VFPxKsi1 wBVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2lCpqEPA1YvWdB3S+4vzX+W8GsnqNS0ufBxdIKeTC+Y=; b=nvKNfo8fXmxKJBzyOq77KUmFLPsi1QVRH8kRrXAigL2zZagE/+tbQCIs9HIZkhD2l4 OZ+dzawXxstNat/xZqgV5FtDutELP82rOK0qGE17I6/+Qzq1hrUWp7dc9+YNBpVp9af8 8r9Mz0UG1xGFJkz64lqWvhCmibr1gUFsnqmisJJmLk2bq9rT5Pz0aAV8XXo8neCCmA87 4ahCTo1fo2PWOgzPlrytSfDL+OHcF/rPTyo5FkinF49zdrLEInlPnsMcW0daC8oOIXg+ G8mEH0zT9MIMlE4wmPA7nh6MMbIkrKnMsQCbTb0iLjmDcDi15xFJF3RZEWmCtAIWLoYD SB3Q== X-Gm-Message-State: AOAM530WULXYMaSu7mTxCg6HJu6wWRQYnJopm24+aE2f9W1lYEPm0Je6 7gtCbZNbvxKgrsFRj1fHylqaLuCflG+vYw== X-Google-Smtp-Source: ABdhPJwk7yweA45Rzf80K3mkSrjaUDgHDsn2GWwn2HnRvYA8VbDZYjKPFJvB5x9urwRv9hImDmCiZw== X-Received: by 2002:ac8:2f50:: with SMTP id k16mr17857439qta.392.1590175810450; Fri, 22 May 2020 12:30:10 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 190sm8346448qke.104.2020.05.22.12.30.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 12:30:09 -0700 (PDT) From: Michael StJohns To: "Wessels, Duane" , Dick Franks Cc: Mark Andrews , Tim Wicinski , IETF DNSOP WG References: <93E835F5-5421-4343-9D2B-A88937675E0A@verisign.com> <6aeded6f-e0eb-063b-a3f1-f33402b21c3a@nthpermutation.com> Message-ID: <8387bcfe-6386-77ba-9db7-1326645ec8d4@nthpermutation.com> Date: Fri, 22 May 2020 15:30:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <6aeded6f-e0eb-063b-a3f1-f33402b21c3a@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------CCA00D6C9363C57EBE9486EC" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 19:30:18 -0000 This is a multi-part message in MIME format. --------------CCA00D6C9363C57EBE9486EC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi - With the change to remove ZONEMD from the calculation (apparently in -06), I no longer have any objections related to future proofing. But, with the change, the text needs some additional clean up. Instead of the current section 3 - use something like this: >> 3. Updating the Zone for ZONEMD RRs 3.1 "Step 1 - remove any existing apex ZONEMD RR from the zone" 3.2 "Step 2 - for each scheme, form a canonical representation of the zone according to the scheme.  The canonical representation for the SIMPLE scheme is listed in <> below." 3.3S "Step 3 (SIMPLE):  For each digest type in the SIMPLE scheme, calculate the digest over the canonical representation and form the appropriate ZONEMD RR for later inclusion" [Note: Other Schemes may have other processing at this point] 3.3O "Step 3(Other): For any other scheme/digest pair form the appropriate ZONEMD RRs and it them to the set for later inclusion. 3.4. "Step 4: Add each of the ZONEMD RRs formed in step 3 to the zone" 3.5. "Step 5 (Optional):  Sign the zone adjusting NSEC/NSEC3 records as appropriate to account for the existence of the ZONEMD RRSet". 4. Canonical representation and Digest Calculation for the SIMPLE scheme. (move the  old 3.3, 3.4 and 3.5 sections under this heading). >> Note:   The presence or absence of _provable_ DNSSEC for the ZONEMD RRs is irrelevant to whether or not the zonemd rr set can be verified.  It would seem to me that if you have a chain of DNSKEY RRs back to a trust point, you can verify the zonemd RR whether or not the zone claims the records should exist.     NSEC records say that the record SHOULD exist, but AFAICT NSEC records aren't actually checked if the records do exist.  That may have changed from the original model, but I mention it with respect to  section 4, first bullet which reads as if the expectation is the important thing rather than actual signature data. I'm still not a big fan of this as a standards track document as I don't feel it provides enough general benefit nor does it provide a standard and programmatic answer to "what do I do if it doesn't verify", but I'm no longer adamant it needs to be experimental as it no longer forces a contract for future digesting models. Later, Mike On 3/9/2020 5:24 PM, Michael StJohns wrote: > On 3/9/2020 4:46 PM, Wessels, Duane wrote: >>> Michael StJohns pointed out (Feb 25) that a verifier that does not >>> recognise a particular >>> ZONEMD Scheme and/or Hash Algorithm may be unable to create the >>> required placeholders, >>> and therefore unable to perform a verification using any >>> (Scheme,Algorithm) at all. >> I don't believe that to be the case. For the unknown schemes/algorithms >> the recipient simply replaces how ever many octets the received ZONEMD digest >> had with all zeros. >> >> >> > > As of right now, I don't believe the current format is future proofed. > > Current encoding: > > 0x01 - simple > 0x01 - SHA384 > 48 bytes of digest. > > 0x01 - simple > 0x02 - SHA512 > 64 bytes of digest. > > 0x02 - Complex > 0x00 - Ignored - mainly because I'm forced to have it here because of > the SIMPLE scheme - it doesn't specify a digest type. > [Opaque values that describe the complex scheme - e.g. btree > description, partial hashes, selection matrix of RRs I actually care > about etc] > [More opaque values that are the various digest(s)] > > These are OPAQUE from a receiver that only understands SIMPLE. > > For the latter scheme, I want to include the first part of the opaque > values in the various hash calculations.   But the SIMPLE scheme will > set them to zero for its own calculations?   And I have to do special > things for scheme 1 to do my calculations. AND I have to know that > digest 0x02 requires 64 bytes of zero for the calculation even if I'm > only able to verify SHA384 digests.  Any error in the formation of the > digest 0x02 digest field or scheme 0x02 data field means that the 0x01 > digest won't verify.  Ditto for any formation for the scheme 2 complex > digest relative to the Scheme 1 digests.  This makes all digests > interdependent which I believe was not desired. > > I see no benefit to including the ZONEMD RR in any digest calculation > with our without placeholdering it. > > Just omit any ZONEMD RR from the calculation and be done with it.  > Make ALL ZONEMD RRs independent from each other. > > > > --------------CCA00D6C9363C57EBE9486EC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi -

With the change to remove ZONEMD from the calculation (apparently in -06), I no longer have any objections related to future proofing.

But, with the change, the text needs some additional clean up.

Instead of the current section 3 - use something like this:

>>
3. Updating the Zone for ZONEMD RRs

3.1 "Step 1 - remove any existing apex ZONEMD RR from the zone"

3.2 "Step 2 - for each scheme, form a canonical representation of the zone according to the scheme.  The canonical representation for the SIMPLE scheme is listed in <> below."

3.3S "Step 3 (SIMPLE):  For each digest type in the SIMPLE scheme, calculate the digest over the canonical representation and form the appropriate ZONEMD RR for later inclusion" [Note: Other Schemes may have other processing at this point]
3.3O "Step 3(Other): For any other scheme/digest pair form the appropriate ZONEMD RRs and it them to the set for later inclusion.

3.4. "Step 4: Add each of the ZONEMD RRs formed in step 3 to the zone"

3.5. "Step 5 (Optional):  Sign the zone adjusting NSEC/NSEC3 records as appropriate to account for the existence of the ZONEMD RRSet".


4. Canonical representation and Digest Calculation for the SIMPLE scheme. (move the  old 3.3, 3.4 and 3.5 sections under this heading).
>>


Note:   The presence or absence of provable DNSSEC for the ZONEMD RRs is irrelevant to whether or not the zonemd rr set can be verified.  It would seem to me that if you have a chain of DNSKEY RRs back to a trust point, you can verify the zonemd RR whether or not the zone claims the records should exist.     NSEC records say that the record SHOULD exist, but AFAICT NSEC records aren't actually checked if the records do exist.  That may have changed from the original model, but I mention it with respect to  section 4, first bullet which reads as if the expectation is the important thing rather than actual signature data.

I'm still not a big fan of this as a standards track document as I don't feel it provides enough general benefit nor does it provide a standard and programmatic answer to "what do I do if it doesn't verify", but I'm no longer adamant it needs to be experimental as it no longer forces a contract for future digesting models.

Later, Mike



On 3/9/2020 5:24 PM, Michael StJohns wrote:
On 3/9/2020 4:46 PM, Wessels, Duane wrote:
Michael StJohns pointed out (Feb 25) that a verifier that does not
recognise a particular
ZONEMD Scheme and/or Hash Algorithm may be unable to create the
required placeholders,
and therefore unable to perform a verification using any
(Scheme,Algorithm) at all.

I don't believe that to be the case.  For the unknown schemes/algorithms
the recipient simply replaces how ever many octets the received ZONEMD digest
had with all zeros.


As of right now, I don't believe the current format is future proofed.

Current encoding:

0x01 - simple
0x01 - SHA384
48 bytes of digest.

0x01 - simple
0x02 - SHA512
64 bytes of digest.

0x02 - Complex
0x00 - Ignored - mainly because I'm forced to have it here because of the SIMPLE scheme - it doesn't specify a digest type.
[Opaque values that describe the complex scheme - e.g. btree description, partial hashes, selection matrix of RRs I actually care about etc]
[More opaque values that are the various digest(s)]

These are OPAQUE from a receiver that only understands SIMPLE.

For the latter scheme, I want to include the first part of the opaque values in the various hash calculations.   But the SIMPLE scheme will set them to zero for its own calculations?   And I have to do special things for scheme 1 to do my calculations.  AND I have to know that digest 0x02 requires 64 bytes of zero for the calculation even if I'm only able to verify SHA384 digests.  Any error in the formation of the digest 0x02 digest field or scheme 0x02 data field means that the 0x01 digest won't verify.  Ditto for any formation for the scheme 2 complex digest relative to the Scheme 1 digests.  This makes all digests interdependent which I believe was not desired. 

I see no benefit to including the ZONEMD RR in any digest calculation with our without placeholdering it.

Just omit any ZONEMD RR from the calculation and be done with it.  Make ALL ZONEMD RRs independent from each other.





--------------CCA00D6C9363C57EBE9486EC-- From nobody Fri May 22 14:59:24 2020 Return-Path: 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 654B73A0BEA for ; Fri, 22 May 2020 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ba9dyT5vTVRr for ; Fri, 22 May 2020 14:59:21 -0700 (PDT) Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A293A0BE5 for ; Fri, 22 May 2020 14:59:20 -0700 (PDT) X-Footer: cGNoLm5ldA== Received: from [10.19.48.14] ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for dnsop@ietf.org; Fri, 22 May 2020 14:59:15 -0700 From: Bill Woodcock Content-Type: multipart/signed; boundary="Apple-Mail=_B9E4D03D-2683-48E6-AB67-F47BE1E75872"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 22 May 2020 23:59:11 +0200 References: <2487238.otjEU5M4pH@linux-9daj> To: dnsop WG In-Reply-To: <2487238.otjEU5M4pH@linux-9daj> Message-Id: <51096CAB-97BC-496D-8322-40BEB0F7334E@pch.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 21:59:23 -0000 --Apple-Mail=_B9E4D03D-2683-48E6-AB67-F47BE1E75872 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On May 22, 2020, at 3:38 AM, Paul Vixie wrote: > > On Friday, 22 May 2020 00:55:34 UTC George Michaelson wrote: >> My Colleague George Kuo asked me for definitions of public DNS >> service. not "public DNS" but the trigram "public DNS service" >> >> Colloquially we understand this reasonably well. It is in the space of >> what Google, quad9, CloudFlare and others do. The various clean DNS >> feeds people subscribe to, it is the functional role of a recursive, >> but to the public, yet somehow not the bad one of an open DNS resolver >> being abused to do DDoS: its the conscious service offering of a >> recursive/cache/forwarder in the public view, a declared intent. > > these services aren't public in any way, and should not be described as > public. they are operated privately for private purposes True of Google and Cloudflare, not true of Quad9. > a county park is public. anycast RDNS is a business. Again, true of Google and Cloudflare, but not true of Quad9. -Bill --Apple-Mail=_B9E4D03D-2683-48E6-AB67-F47BE1E75872 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEm6XJ0FdpKWJHso4lb6RwSyiLf4cFAl7ISy8ACgkQb6RwSyiL f4f8xRAAjCRvw81AZB4PEVfVqPMSWPVAWusT+TnpHm+9osKyxGyrZSwYMfWP0H/j NVVkv/IIN/hx7E1xJ2Ed0o1Az4w3h6YwL7k2165bWB0p13uU1snJQaMiGFnBr778 p9KWHIpDnJzJp+h89Nql0MfdDWMuxboW7ZXtKNSaQHhZkSJ0nta53zyzJDwc4k3u I8VBnxle64+HRl90m8cERRCUryjIk3oSS2GfASHzZQx5SJdztl9MwFeOT1X7P2Ku NcveX84W28/brLG5NqXZByLDmQaVfLnTCKvwJZwNbwrAr7oJa8Lhf+L9cf1H4N7W 0q9rMTAFqExBuPEJzLZdDdLiLkouBgcjx40YC6Yy3zB6GYwHnOKip5lwpz3MxB50 CSLdP7hj/OoKO6vpNUSvH5PP5c2bL4PfD+ZNnaPy1wVjp5ve6RjLfA+SIoOqSPJ1 FlmLdvEaAOd1LXHob5WTZAWl5AmuXfgQZKxQqZCAz/xPzqmQS6Mp6p/jFWbQMwCN DOgPV9JP23UunVQ1CioTQzV4x6+aKA/xFp4tGcihIMXF7aSv9lojrH/0v3NDMZiP 8sEfN4C0wxiOvxMAMBmSWyE6DCmS2hMlQqG7foPGhfEcW41DA6ty0rD6NY92FUo5 Xl/AY9oyXkRXB09OOP38YhnM4+DcFbaIxzvFq5jWTocJ8N3pEH4= =pXRZ -----END PGP SIGNATURE----- --Apple-Mail=_B9E4D03D-2683-48E6-AB67-F47BE1E75872-- From nobody Fri May 22 15:10:37 2020 Return-Path: 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 5CE9F3A0C46 for ; Fri, 22 May 2020 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 8KLB1rjTCAyW for ; Fri, 22 May 2020 15:10:30 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 F2E3D3A0DBB for ; Fri, 22 May 2020 15:10:29 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id h7so9423555otr.3 for ; Fri, 22 May 2020 15:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vy0xbkdBLaSZX1JQOgdKxj5vE2IAM2/IPf8Azcx0eww=; b=HRCFjKHgCzn2o4FIa4AWVuD0jLPr3bRNSrqX0kkK+6TyAunBDiic/xon7XyG/icgm4 q5gkfd2VvXrTrujw/b8XYrGtXPxP+6wRmJmGy4TzesUeMiVCLrqFJh9XEv8T5Sv0N9f+ ilAnT+HOveRft9d8J6W+VOkrzvph5y6jytUIVL1GDYVXZqPoCuA6Oiy6LxoHWG+q5a2c op8sBrF/ZDdZhZ/8CI92jcSeNyfaRgmA0rH/uBCsRiA1SShlheKhySY40+URbBZyO4CA a/gvH9lamJAS9tVE7uhdP2iGNpozY/YndVcid8nTCWRPjH4A7rnhrbwDn29mlxKVc8CX e/tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vy0xbkdBLaSZX1JQOgdKxj5vE2IAM2/IPf8Azcx0eww=; b=MX4jIyKiclO2jD1BmCQ8RB7q8gLYFPirWcCpqihZh/eK4L4ywDbVde69nrFu5eMkUs 7HM2XrG9bLtqyBWO5PTLDeKkgXXdY8Df4Ct7hrMbLrqoU2U+aAKpTtLHCMP0h4tsGxZQ lzcewb5N4gmPoFQwoYc2u17c0l87/6FIvqqLr0HCkYKA94lpJ0NoTcHH0s9yFHYTIrIA dQE8snqBPjcmzFwksltzzMsVy0v6rehPEyIwmq2h0l0W28Jn1qUl+pb1FI7P8nkpIY6P dNmzrl7rirRHno7KXMY6T5FTuTZzToDmpctV99ze0Ny47sMdZNiZYLBjute87L+i9N1f pJWA== X-Gm-Message-State: AOAM532lwhz6U/Eo3f0ywr3hrLbi5ugADFgcGe9fNSLWpF+UeJWXgJS0 groIKTEH8ziRal2nmZ2tlX7/KpSrx4sHtcXPyWE= X-Google-Smtp-Source: ABdhPJyWY078jb0KvOh8Ayw20ukyt4tVD1dYoTh0UGY7ryJfegkQml5vxFi0R5WruQ8/vOCzIusvqNpK1DDhsgAvvng= X-Received: by 2002:a05:6830:3109:: with SMTP id b9mr9270146ots.41.1590185429330; Fri, 22 May 2020 15:10:29 -0700 (PDT) MIME-Version: 1.0 References: <93E835F5-5421-4343-9D2B-A88937675E0A@verisign.com> <6aeded6f-e0eb-063b-a3f1-f33402b21c3a@nthpermutation.com> <8387bcfe-6386-77ba-9db7-1326645ec8d4@nthpermutation.com> In-Reply-To: <8387bcfe-6386-77ba-9db7-1326645ec8d4@nthpermutation.com> From: Tim Wicinski Date: Fri, 22 May 2020 18:10:18 -0400 Message-ID: To: Michael StJohns Cc: "Wessels, Duane" , Dick Franks , Mark Andrews , IETF DNSOP WG Content-Type: multipart/alternative; boundary="000000000000a46cfd05a643e5e8" Archived-At: Subject: Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 22:10:34 -0000 --000000000000a46cfd05a643e5e8 Content-Type: text/plain; charset="UTF-8" Michael Thanks for reviewing the -06 changes and thanks for dropping your objections. I will work with the authors on cleaning up the text. As for your comments on Standards Track, as a chair and not a chair, I have moved back toward not making this Standards Track, but Informational. I will need to talk with the other chairs on this more. tim On Fri, May 22, 2020 at 3:30 PM Michael StJohns wrote: > Hi - > > With the change to remove ZONEMD from the calculation (apparently in -06), > I no longer have any objections related to future proofing. > > But, with the change, the text needs some additional clean up. > > Instead of the current section 3 - use something like this: > > >> > 3. Updating the Zone for ZONEMD RRs > > 3.1 "Step 1 - remove any existing apex ZONEMD RR from the zone" > > 3.2 "Step 2 - for each scheme, form a canonical representation of the zone > according to the scheme. The canonical representation for the SIMPLE > scheme is listed in <> below." > > 3.3S "Step 3 (SIMPLE): For each digest type in the SIMPLE scheme, > calculate the digest over the canonical representation and form the > appropriate ZONEMD RR for later inclusion" [Note: Other Schemes may have > other processing at this point] > 3.3O "Step 3(Other): For any other scheme/digest pair form the appropriate > ZONEMD RRs and it them to the set for later inclusion. > > 3.4. "Step 4: Add each of the ZONEMD RRs formed in step 3 to the zone" > > 3.5. "Step 5 (Optional): Sign the zone adjusting NSEC/NSEC3 records as > appropriate to account for the existence of the ZONEMD RRSet". > > > 4. Canonical representation and Digest Calculation for the SIMPLE scheme. > (move the old 3.3, 3.4 and 3.5 sections under this heading). > >> > > > Note: The presence or absence of *provable* DNSSEC for the ZONEMD RRs > is irrelevant to whether or not the zonemd rr set can be verified. It > would seem to me that if you have a chain of DNSKEY RRs back to a trust > point, you can verify the zonemd RR whether or not the zone claims the > records should exist. NSEC records say that the record SHOULD exist, > but AFAICT NSEC records aren't actually checked if the records do exist. > That may have changed from the original model, but I mention it with > respect to section 4, first bullet which reads as if the expectation is > the important thing rather than actual signature data. > > I'm still not a big fan of this as a standards track document as I don't > feel it provides enough general benefit nor does it provide a standard and > programmatic answer to "what do I do if it doesn't verify", but I'm no > longer adamant it needs to be experimental as it no longer forces a > contract for future digesting models. > > Later, Mike > > > > On 3/9/2020 5:24 PM, Michael StJohns wrote: > > On 3/9/2020 4:46 PM, Wessels, Duane wrote: > > Michael StJohns pointed out (Feb 25) that a verifier that does not > recognise a particular > ZONEMD Scheme and/or Hash Algorithm may be unable to create the > required placeholders, > and therefore unable to perform a verification using any > (Scheme,Algorithm) at all. > > I don't believe that to be the case. For the unknown schemes/algorithms > the recipient simply replaces how ever many octets the received ZONEMD digest > had with all zeros. > > > > > > As of right now, I don't believe the current format is future proofed. > > Current encoding: > > 0x01 - simple > 0x01 - SHA384 > 48 bytes of digest. > > 0x01 - simple > 0x02 - SHA512 > 64 bytes of digest. > > 0x02 - Complex > 0x00 - Ignored - mainly because I'm forced to have it here because of the > SIMPLE scheme - it doesn't specify a digest type. > [Opaque values that describe the complex scheme - e.g. btree description, > partial hashes, selection matrix of RRs I actually care about etc] > [More opaque values that are the various digest(s)] > > These are OPAQUE from a receiver that only understands SIMPLE. > > For the latter scheme, I want to include the first part of the opaque > values in the various hash calculations. But the SIMPLE scheme will set > them to zero for its own calculations? And I have to do special things > for scheme 1 to do my calculations. AND I have to know that digest 0x02 > requires 64 bytes of zero for the calculation even if I'm only able to > verify SHA384 digests. Any error in the formation of the digest 0x02 > digest field or scheme 0x02 data field means that the 0x01 digest won't > verify. Ditto for any formation for the scheme 2 complex digest relative > to the Scheme 1 digests. This makes all digests interdependent which I > believe was not desired. > > I see no benefit to including the ZONEMD RR in any digest calculation with > our without placeholdering it. > > Just omit any ZONEMD RR from the calculation and be done with it. Make > ALL ZONEMD RRs independent from each other. > > > > > > --000000000000a46cfd05a643e5e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael

Thanks for reviewing the -06 changes and thanks for dropping your obj= ections.
= I will work with the authors on cleaning up the text.

As for your comments on Standards = Track, as a chair and not a chair, I have=C2=A0
moved back toward not making this St= andards Track, but Informational.=C2=A0
I will need to talk with the other chairs on= this more.

t= im


=


On F= ri, May 22, 2020 at 3:30 PM Michael StJohns <msj@nthpermutation.com> wrote:
=20 =20 =20
Hi -

With the change to remove ZONEMD from the calculation (apparently in -06), I no longer have any objections related to future proofing.

But, with the change, the text needs some additional clean up.

Instead of the current section 3 - use something like this:

>>
3. Updating the Zone for ZONEMD RRs

3.1 "Step 1 - remove any existing apex ZONEMD RR from the zone"

3.2 "Step 2 - for each scheme, form a canonical representation of the zone according to the scheme.=C2=A0 T= he canonical representation for the SIMPLE scheme is listed in <> below."

3.3S "Step 3 (SIMPLE):=C2=A0 For each digest type in the SIMPLE scheme, calculate the digest over the canonical representation and form the appropriate ZONEMD RR for later inclusion" [Note: Other Schemes may have other processing at thi= s point]
3.3O "Step 3(Other): For any other scheme/digest pair form the appropriate ZONEMD RRs and it them to the set for later inclusion.

3.4. "Step 4: Add each of the ZONEMD RRs formed in step 3 to the zone"

3.5. "Step 5 (Optional):=C2=A0 Sign the zone adjusting NSEC/NSEC3 records as appropriate to account for the existence of the ZONEMD RRSet".


4. Canonical representation and Digest Calculation for the SIMPLE scheme. (move the=C2=A0 old 3.3, 3.4 and 3= .5 sections under this heading).
>>


Note:=C2=A0=C2=A0 The presence or absence of provable DNSSEC for the ZONEMD RRs is irrelevant to whether or not the zonemd rr set can be verified.=C2=A0 It would seem to me that if you have a chain of DNSKEY RRs back to a trust point, you can verify the zonemd RR whether or not the zone claims the records should exist.=C2=A0=C2=A0=C2=A0=C2=A0 NSEC records say that the record SHOUL= D exist, but AFAICT NSEC records aren't actually checked if the records do exist.=C2=A0 That may have changed from the original model, but I mention it with respect to=C2=A0 section 4, first bullet which reads = as if the expectation is the important thing rather than actual signature data.

I'm still not a big fan of this as a standards track document as I don't feel it provides enough general benefit nor does it provide a standard and programmatic answer to "what do I do if it doesn't verify", but I= 9;m no longer adamant it needs to be experimental as it no longer forces a contract for future digesting models.

Later, Mike



On 3/9/2020 5:24 PM, Michael StJohns wrote:
=20
On 3/9/2020 4:46 PM, Wessels, Duane wrote:
Michael StJohns pointed out (Feb 25) that a verifier that do=
es not
recognise a particular
ZONEMD Scheme and/or Hash Algorithm may be unable to create the
required placeholders,
and therefore unable to perform a verification using any
(Scheme,Algorithm) at all.

I don't believe that to be the case.  For the unknown sche=
mes/algorithms
the recipient simply replaces how ever many octets the received ZONEMD dige=
st
had with all zeros.


As of right now, I don't believe the current format is future proofed.

Current encoding:

0x01 - simple
0x01 - SHA384
48 bytes of digest.

0x01 - simple
0x02 - SHA512
64 bytes of digest.

0x02 - Complex
0x00 - Ignored - mainly because I'm forced to have it here because of the SIMPLE scheme - it doesn't specify a digest type= .
[Opaque values that describe the complex scheme - e.g. btree description, partial hashes, selection matrix of RRs I actually care about etc]
[More opaque values that are the various digest(s)]

These are OPAQUE from a receiver that only understands SIMPLE.

For the latter scheme, I want to include the first part of the opaque values in the various hash calculations.=C2=A0=C2=A0 But the= SIMPLE scheme will set them to zero for its own calculations?=C2=A0=C2=A0 = And I have to do special things for scheme 1 to do my calculations.=C2=A0 AND I have to know that digest 0x02 requires 64 bytes of zero for the calculation even if I'm only able to verify SHA384 digests.=C2=A0 Any error in the formation of the digest 0x02 digest field or scheme 0x02 data field means that the 0x01 digest won'= t verify.=C2=A0 Ditto for any formation for the scheme 2 complex dige= st relative to the Scheme 1 digests.=C2=A0 This makes all digests interdependent which I believe was not desired.=C2=A0

I see no benefit to including the ZONEMD RR in any digest calculation with our without placeholdering it.

Just omit any ZONEMD RR from the calculation and be done with it.=C2=A0 Make ALL ZONEMD RRs independent from each other.





--000000000000a46cfd05a643e5e8-- From nobody Fri May 22 18:32:18 2020 Return-Path: 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 26CA73A0D57 for ; Fri, 22 May 2020 18:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 JQFPzZQx2z5M for ; Fri, 22 May 2020 18:32:14 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F03A0D56 for ; Fri, 22 May 2020 18:32:14 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id 5C305389EF0; Sat, 23 May 2020 01:32:12 +0000 (UTC) Date: Sat, 23 May 2020 01:32:12 +0000 From: dagon To: George Michaelson Cc: dnsop WG , George Kuo Message-ID: <20200523013212.GA10996@sudo.sh> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2020 01:32:17 -0000 On Fri, May 22, 2020 at 10:55:34AM +1000, George Michaelson wrote: > My Colleague George Kuo asked me for definitions of public DNS > service. not "public DNS" but the trigram "public DNS service" Is there room for this bike: 1) Policy: A "public DNS service" is a full DNS speaker outside of the end user's network and control. I.e., non-local recursion crosses one or more policy barriers---local network, carrier, state and international---with implications for integrity, resolution security, and privacy. For some enterprises, recursion against 'public DNS services' creates an audit criticism. A poorly selected public resolver may import censorship. Or a well selected resolver may evade (older) regional media controls by suggesting false locality to a media server, for those services unwilling to impose policy regional controls in their TCP multiplex. Given these explicit choices and surprise outcomes, "crossing policy barriers" is a fair partial description. 2) Latent RRsets requiring protocol changes. Public DNS servers are the most distant commercially viable DNS iterator from the end user. Resolvers mitigate distance-induced latency via anycasting and robust provisioning. Suboptimal RRset selections required fundamental protocol changes---e.g., exposing local octets to the iterative layer---accommodate what remains. (And hats off to the Tor exit nodes offering on-exit recursion, and injecting RFC 1918 addresses into the ECS payload.) "Distant" is a fair description. Users pay for this distance, in either latency, privacy, or protocol changes. 3) "Free with footnotes". No good deed goes unmonetized. Users should understand the trade offs in selecting a non-local resolver. The term "public" obscures stake holder interests. I suggest: "distant resolver outside of the user's policy oversight". -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Fri May 22 19:46:56 2020 Return-Path: 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 0387A3A0EE8 for ; Fri, 22 May 2020 19:46:54 -0700 (PDT) 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 rV0xJAi1Q6VC for ; Fri, 22 May 2020 19:46:52 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6655E3A0E2E for ; Fri, 22 May 2020 19:46:52 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8B87EB074A; Sat, 23 May 2020 02:46:51 +0000 (UTC) From: Paul Vixie To: dnsop WG Cc: Bill Woodcock Date: Sat, 23 May 2020 02:46:50 +0000 Message-ID: <16919731.mxCJBW68yc@linux-9daj> Organization: none In-Reply-To: <51096CAB-97BC-496D-8322-40BEB0F7334E@pch.net> References: <2487238.otjEU5M4pH@linux-9daj> <51096CAB-97BC-496D-8322-40BEB0F7334E@pch.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2020 02:46:54 -0000 On Friday, 22 May 2020 21:59:11 UTC Bill Woodcock wrote: > > On May 22, 2020, at 3:38 AM, Paul Vixie wrote: > > ... > > > > these services aren't public in any way, and should not be described as > > public. they are operated privately for private purposes > > True of Google and Cloudflare, not true of Quad9. > > > a county park is public. anycast RDNS is a business. > > Again, true of Google and Cloudflare, but not true of Quad9. there may be a distinction, but not a difference. ibm and pch and the other backers of quad9, and the security industry partners who participate, have solid personal reasons, just as google and cloudflare and opendns do, for running an open recursive name service. open recursion is novel concept, only 25 years or so old, and the internet functioned fine without it, and as shown by the PiHole project and others, the internet can still function fine without it. as much as the interested parties have bent the narrative toward their interests, open recursion remains a private service run for private reasons, and the name "public" would be misleading in the extreme. -- Paul From nobody Sat May 23 13:35:12 2020 Return-Path: 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 9CE3B3A0E51 for ; Sat, 23 May 2020 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s5bbOq2zQ9Ar for ; Sat, 23 May 2020 13:35:07 -0700 (PDT) Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342043A0DB8 for ; Sat, 23 May 2020 13:35:07 -0700 (PDT) X-Footer: cGNoLm5ldA== Received: from [10.19.48.14] ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for dnsop@ietf.org; Sat, 23 May 2020 13:35:03 -0700 From: Bill Woodcock Content-Type: multipart/signed; boundary="Apple-Mail=_F2C059EE-FC6E-47AD-AC76-1070AE91202D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 23 May 2020 22:34:57 +0200 References: <2487238.otjEU5M4pH@linux-9daj> <51096CAB-97BC-496D-8322-40BEB0F7334E@pch.net> <16919731.mxCJBW68yc@linux-9daj> To: dnsop WG In-Reply-To: <16919731.mxCJBW68yc@linux-9daj> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2020 20:35:09 -0000 --Apple-Mail=_F2C059EE-FC6E-47AD-AC76-1070AE91202D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 23, 2020, at 4:46 AM, Paul Vixie wrote: > ibm and pch and the other backers of quad9, and the security industry = partners who participate, have > solid personal reasons, just as google and cloudflare and opendns do, = for > running an open recursive name service. That=E2=80=99s a rhetorical fallacy. You=E2=80=99re conflating = supporters with =E2=80=9Crunners.=E2=80=9D If IBM or PCH or anybody = else run recursive nameservers, that=E2=80=99s fine. But that doesn=E2=80= =99t make them Quad9. Quad9 is a public-benefit not-for-profit = organization. I like Werner Herzog's movies, and pay to see them in the = theater; that doesn=E2=80=99t make me Werner Herzog, it doesn=E2=80=99t = make him my puppet, and it doesn=E2=80=99t mean that his movies are no = longer accessible by the public. There=E2=80=99s no path from the A to = the B that you=E2=80=99re attempting to argue. Quad9 exists at the behest of European privacy regulators and = data-protection officers, who are representatives of the public. It = provides service to the public. It is a public-benefit organization, = with no private beneficiaries. It answers to the California Secretary = of State for its existence, another representative of the public = interest. If you believe there=E2=80=99s a private interest there, = point it out, specifically and unambiguously enough that people can tell = what you=E2=80=99re trying to say. An unfalsifiable argument is just = feckless lip-flapping. If you can=E2=80=99t actually make the point that you=E2=80=99re = insinuating, then don=E2=80=99t try to tar Quad9 with the same brush as = Cloudflare and Google. -Bill --Apple-Mail=_F2C059EE-FC6E-47AD-AC76-1070AE91202D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEm6XJ0FdpKWJHso4lb6RwSyiLf4cFAl7JiPEACgkQb6RwSyiL f4fu5BAAo2hVhMLZFs7WWQaLj28yVVB3THfSxd8khNLHf+HqYO3SiITKANDMfjDE IGwmCikQBN7Bmbz+CH0EgQEWn4L7XSjKOaXws3SXgiS2xIiPPrpNSaKeDwe3unBm mQvRr1YBuUA4FTkV/U2bs5pgAio9rkY23f1H4vBMRqFs7onC+vU4OivGVh9vtcXA lXvNno3lxzGQI7WzZ+gt6LEhIq7GGlWgd/52XDPg6950tyIepDxDWaM+fXZYWiuG mNcsw4JU67j9sNkcZwFOqx3x/HzAY3R9QUav+W+pO4n8Z/4cKzffKNt+GoGJdNLI Z1cltXU4Wyw/CePM+ONPQsSDTq4KnFFNL6cM4QWIzBaCQma4Cv+hBk7WGc5NJGM+ xSyH0t1SlpggnYkYrILRGsuexVM3EzzQ8KATBnswByTa3OVKA1D3ya8c5NJXCnVE sPC/GGHfwFA9BzRAZBpVngqEUvJ3tYmr5IFUGQ3EnB9GKgtP/LHwNP01HSBx+Oxm EMVj0L7NHxUqpAfqviQnhPKn37OO1PKJiNYiaFK62o8jORkB/XX/pf49EAB4Q+zd t5x3c+nUdzkHyQ8xdl4u7nTQCjrLYAn0G4/d5+ULgc0Z2nZaX3iT4SdpHxYQFzB6 LqAeWbAOxWWVU8D6FHvSU0EshUZo+4UoiejXXjkX+qELIArgaUU= =39fj -----END PGP SIGNATURE----- --Apple-Mail=_F2C059EE-FC6E-47AD-AC76-1070AE91202D-- From nobody Sun May 24 02:47:22 2020 Return-Path: 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 AC9D73A07E5; Sun, 24 May 2020 02:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 QdgWAiVxmOVK; Sun, 24 May 2020 02:47:19 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 49C273A07DD; Sun, 24 May 2020 02:47:19 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id a68so11740488otb.10; Sun, 24 May 2020 02:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=isDsQYvr0Qm80nYo8ugZCrtIDGI7zFsKELaCsyMfHX8=; b=JzXx5qnJD7clsN/y+Rk6yVD4dirjEJZZTucaQ15BqT5+eUfuP/LFQ9N/6CI8MpsgvC HQercubFLiDNxaDyr4Q49dk3e8TX3eTaBWz2LnuYIPD4Jp80EuyzPgBBfaUSHHIIjGji sX+QmC2TMDuw8E8fPs+5iMqYciHjpZLv66fhFUw0jVofsR3pdG77wUU/XVkTp5aL8HM2 JR1Ymas+ppHPFNam1B2R5EM3l75vdR3TSjRxnpHxJAmGt3WOUhjJynZc4cRsw7QZaet+ 7kltjFz0vOFfc8PilcJ9eeAwCeb0vZD6yvfv5roaJltsgjbcLcJ3k/z0Ybiw8O74igor KKXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=isDsQYvr0Qm80nYo8ugZCrtIDGI7zFsKELaCsyMfHX8=; b=obqXzj2IGQuqrAcn1iDjDBCSHm+l53Ra5Yjw827X5U53jXr+1wYfcRizg3RZ22/A+t yU4V+goA0GDyU9t0zoB0QqHqc6BJ1NaVBhJLz8jgwmCiRhXn6M8U26YhT3ZIfiWY3Viq SX7AD+x79I5DvgA8ar+uBz21qDhzkYoUfHA/A99ZOGXCB9J981BADDsDDLMn/cPasYL8 QCR4cYlLtw+M6bX7QklnFGCbmyBEg/vaNoXu6NpGgJ3XwZiUiz1Fd6EKThN9U5mmcJO3 QipjM2LzlcOtULjIGUSvqviVAf3iDY2AuAeHzgqKu4ep4sij2KBRyTPKaC1IksJ0V5c+ sELA== X-Gm-Message-State: AOAM532eBW8M24nsu/ALCTNdV7lpPyGLQyglVBTgF8kbroPh4IL4ctXO Ey+WfhrTRTiKhyidA3kXmtC9jvDcp1vpPHUJTYPKa2Je X-Google-Smtp-Source: ABdhPJw74wTsKQc/9Qwf3g+/fqf+mZH7qDtf65dqjP3cWYTdYahgZBMqstLsUw/ZUyLOqYeHp2LWCVgauIhTHBjqVcQ= X-Received: by 2002:a05:6830:d3:: with SMTP id x19mr17701567oto.158.1590313638309; Sun, 24 May 2020 02:47:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Sun, 24 May 2020 05:47:07 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="0000000000007e345a05a661bfca" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 09:47:21 -0000 --0000000000007e345a05a661bfca Content-Type: text/plain; charset="UTF-8" Hi the Call for Adoption for this draft has completed, and there is strong consensus for DNSOP to work on this. Note: During the Call, a very valid point was raised whether this document should be Standards Track or not. The chairs don't worry what are on the documents before adoption, as we have faith that the working group will help provide the correct guidance. The authors are okay with adjusting RFC status. The chairs have been thinking about RFC status (real or imagined) of all adopted work. We do worry about the effect all our work has on the Camel. Thanks for your feedback. tim On Mon, May 11, 2020 at 1:41 PM Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > --0000000000007e345a05a661bfca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= br>
Hi

<= div class=3D"gmail_default" style=3D"font-family:monospace">the Call for Ad= option for this draft has completed, and there is strong consensus for DNSO= P to work on this.

Note:=C2=A0 During the Call, a very valid point was raised whether th= is document should be Standards Track or not.=C2=A0
The chairs don't worry what = are on the documents before adoption, as we have faith that the working gro= up=C2=A0
= will help provide the correct guidance.=C2=A0 The authors are okay with adj= usting RFC status.

The chairs have been thinking about RFC status (real or imagined) of = all adopted work.=C2=A0 We do worry
about the effect all our work has on the Camel.= =C2=A0=C2=A0

= Thanks for your=C2=A0feedback.=C2=A0=C2=A0

tim



On Mon, May 11, 2020 at 1:41 PM Tim Wicins= ki <tjw.ietf@gmail.com> wro= te:

All,<= br>
As we stated in the meeting and in our chairs actions, we're goi= ng to run
regular call for adoptions over next few months. =C2=A0
We = are looking for *explicit* support for adoption.


This starts a C= all for Adoption for draft-toorop-dnsop-dns-catalog-zones

The draft = is available here: https://datatracker.ietf.org/d= oc/draft-toorop-dnsop-dns-catalog-zones/

Please review this draf= t to see if you think it is suitable for adoption
by DNSOP, and comments= to the list, clearly stating your view.

Please also indicate if you= are willing to contribute text, review, etc.

This call for adoption= ends: 25 May 2020

Thanks,
tim wicinski
DNSOP co-chair

=

--0000000000007e345a05a661bfca-- From nobody Sun May 24 02:48:00 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1903A0A60; Sun, 24 May 2020 02:47:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159031367173.17856.9457447104282307711@ietfa.amsl.com> Date: Sun, 24 May 2020 02:47:51 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-toorop-dnsop-dns-catalog-zones in state "Adopted by a WG" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 09:47:59 -0000 The DNSOP WG has placed draft-toorop-dnsop-dns-catalog-zones in state Adopted by a WG (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ From nobody Sun May 24 02:51:40 2020 Return-Path: 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 C2DA83A07E6; Sun, 24 May 2020 02:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 DmMnoS_P_qRs; Sun, 24 May 2020 02:51:37 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 F217D3A041D; Sun, 24 May 2020 02:51:36 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id g25so11725834otp.13; Sun, 24 May 2020 02:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=yOfrNSUBaUR0xTs6NbUzgJK9LWxfaoBk032XoBQ3Xcw=; b=mIbf6+zu3WUdVpOEqCkCyHM0Ggut6TtgGoiTsriASJT+qJMk+SBpml4EjbdDqEwdeU j91Sbe2UiGNLuLixEa8xT2r0y2LAtqc5ndIRHrfCbD6BbE7KvEYG2vpSh6lPK4rAiw73 llmAibrvycdwRBULjNe7QRTnj63lQU+CCAAwwAovCbfx35jZ8GZDfy+g/vx2zMzmAgtx jQw6rDBCWp04fH2RyRSb+b/6+WtkiH9lyvVLEIpT7dvaSh/ty9bgs5vBcjoivsjGu7NI 1EZsF6jNZzg08x5LtO8N7pCdXVoYDYUCL4nLuwNDzTlr71fcPQquFag2yY7pQVAv9ySK 7URw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=yOfrNSUBaUR0xTs6NbUzgJK9LWxfaoBk032XoBQ3Xcw=; b=tvJxauergmu45hstPCrRQUPU4ZMF1luHWRj7Ne+Flyd05PP6TP8Zr3H+v54bUSH6BB qpgbx67eSW9fmuCFfM6Dp6cNyIsZUzXf6zunyATmH5vqa8FMR03/0LcF2/CNtCkBHfgc p1W65/6uXSJr/YU48aVtq7ZUW+JrI8q58nqanX8JGm1dRvwierLgy4q2sva1IKmzaJ4L Llra/s5xtu7oerAFinYbN4hmjBUZgP0834BQfkEzGCugG/l7Qb+dMPoQZ19v1Z/Kb3Ve s/U8v6/tbgViXV3zqLnBdja9aM7TPV0nTLB+lhaVxVAhAsZqT1G7Iq+WVon0tx3r4ga2 iPYA== X-Gm-Message-State: AOAM5337wF+eQlEa8ZnpvVlr/ndKNkmmb34Aa52vh4ZuO1g2cvYGLaCI oZSau9ytjbkwQG1CR2/pptlzWMKUuYPq3BufvuGr6WRLCc4= X-Google-Smtp-Source: ABdhPJxzlcyTNtWfiB1qyPoVE2at95lNWa0f7mA5ZIwNb/8+vDVx1v8nNiy6jOJ1j28aBanKihWtqjwtysyROda1wmU= X-Received: by 2002:a05:6830:3109:: with SMTP id b9mr13871197ots.41.1590313895329; Sun, 24 May 2020 02:51:35 -0700 (PDT) MIME-Version: 1.0 From: Tim Wicinski Date: Sun, 24 May 2020 05:51:24 -0400 Message-ID: To: dnsop Cc: dnsop-chairs Content-Type: multipart/alternative; boundary="000000000000d0028205a661ce9f" Archived-At: Subject: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 09:51:39 -0000 --000000000000d0028205a661ce9f Content-Type: text/plain; charset="UTF-8" All, As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation The draft is available here: https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 8 June 2020 Thanks, tim wicinski DNSOP co-chair --000000000000d0028205a661ce9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,

As we stated in the meeting and in our chairs actions, w= e're going to run regular call for adoptions over next few months.=C2= =A0 We are looking for *explicit* support for adoption.


This sta= rts a Call for Adoption for draft-huque-dnsop-ns-revalidation

The dr= aft is available here: https://datatracker.ietf.org/doc/draft-huque-dn= sop-ns-revalidation/

Please review this draft to see if you thin= k it is suitable for adoption by DNSOP, and comments to the list, clearly s= tating your view.

Please also indicate if you are willing to contrib= ute text, review, etc.

This call for adoption ends: 8 June 2020
<= br>Thanks,
tim wicinski
DNSOP co-chair
--000000000000d0028205a661ce9f-- From nobody Sun May 24 02:51:54 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 247D03A087D; Sun, 24 May 2020 02:51:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159031390607.26615.9357101602492746115@ietfa.amsl.com> Date: Sun, 24 May 2020 02:51:46 -0700 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-huque-dnsop-ns-revalidation in state "Call For Adoption By WG Issued" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 09:51:53 -0000 The DNSOP WG has placed draft-huque-dnsop-ns-revalidation in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ From nobody Sun May 24 16:13:43 2020 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2673A0DF0; Sun, 24 May 2020 16:13:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnsop@ietf.org Message-ID: <159036202112.3396.761149754473535981@ietfa.amsl.com> Date: Sun, 24 May 2020 16:13:41 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-update-timeout-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 23:13:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS TIMEOUT Resource Record Authors : Tom Pusateri Tim Wattenberg Filename : draft-ietf-dnsop-update-timeout-00.txt Pages : 18 Date : 2020-05-24 Abstract: This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records. It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-update-timeout/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-update-timeout-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-update-timeout-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 24 20:24:02 2020 Return-Path: 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 B561D3A0A62 for ; Sun, 24 May 2020 20:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 rSXe1JBjmOz4 for ; Sun, 24 May 2020 20:23:57 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 6DA7D3A0A63 for ; Sun, 24 May 2020 20:23:57 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id b91so13882984edf.3 for ; Sun, 24 May 2020 20:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HH8tnTFd4woB+SOvvXYxJxW0Dr47KetRuFkqh57Qe6E=; b=dLs4XkCeGSlBsdBLHuqY31yao6m9r78XQh7VMeQPGmuwAlQJ58pt+P/mIR/0LLYY2l zgEHQgh7Bc5Wop5p5syqxAgCqFlLPOqKojQw4atsEC4ZrR96veSNGLoqY+bfJroywTGR yntRjNdDHzmCI4qqmco2+/8VEjtAoNDvvAVbvwLmlcw2zPSt8rysNI1S0fmVpZ4Ert+o g1Jy1vPUmjiWq8KT2AxkDB/y39iVZtSXNEen8EnUjXKdyu0USpBLiDDXN0VJcc3ckW+s TaeEQlBmkuM2tVZUCEbC6Bkw8B3ei75nMqkYzFxzOpmcz2tbeavJQe76PoJQ02KPuqu2 eQug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HH8tnTFd4woB+SOvvXYxJxW0Dr47KetRuFkqh57Qe6E=; b=RgGlNelb0w64N5dBRgHLyHBbnxpn7EGh15RZ0uagptSt7pevWCI+G5hMm7v9gp4GIJ QKKSafoBP1E7ekrv5UC153a9jlKl7Qq8d21qRm+eEDFoiN0ASo+kYnIYSwu518Vmjxzw yMUf6yYAzEk4r9q9dQwmufD2BuMUUsdpucj/vlHDpCGC6rJ3wRj6GszzORaUm+CM+MyP jl/BcU63ZzU51jDCwVYIfbqLx/bPCzoZ+jl8WwHQzZjWMwY/4ObSE3zXCAIdJ1lMUMn/ 227jE4W9/Z0mDemta5RR4xYhpRhhmquyZbZ/4OyoD/TIctUPdO8IkwHKF3UOwQKdHlWI ptEg== X-Gm-Message-State: AOAM5324URmkDlidD594RCQgjamC7jaKToXJkGa4QGC+LmKllqXpPy5Z 0aJZwhIGRZORoh6MEGdKsGCZ8h28kDcUDkyHzeA= X-Google-Smtp-Source: ABdhPJw7KYjd/uyaTMF4bZBLxjzjb3ne98FXN/NHGtb41n+oiiu10WC9om3MVFfih/3YOZknlJqAx2U6rXojsJR1db4= X-Received: by 2002:aa7:d999:: with SMTP id u25mr13633861eds.339.1590377034709; Sun, 24 May 2020 20:23:54 -0700 (PDT) MIME-Version: 1.0 References: <7dd08da3-72f8-f25a-c6be-4ff7f76a4084@nic.cz> In-Reply-To: <7dd08da3-72f8-f25a-c6be-4ff7f76a4084@nic.cz> From: Shumon Huque Date: Sun, 24 May 2020 23:23:42 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000367cb205a670828d" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 03:24:00 -0000 --000000000000367cb205a670828d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 21, 2020 at 8:24 AM Petr =C5=A0pa=C4=8Dek = wrote: > > > > https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > I would appreciate a practical example of changes envisioned in the > following paragraph: > > > A common reason that zone owners want to ensure that resolvers place > > the authoritative NS RRset preferentially in their cache is that the > > TTLs may differ between the parent and child side of the zone cut. > > Some DNS Top Level Domains (TLDs) only support long fixed TTLs in > > their delegation NS sets, and this inhibits a child zone owner's > > ability to make more rapid changes to their nameserver configuration > > using a shorter TTL, if resolvers have no systematic mechanism to > > observe and cache the child NS RRset. > > Could someone please post an example in steps? Something like: > - time 0, NSSET parent =3D {P0}, NSSET child =3D {C0} > - time 1, NSSET parent =3D {P1}, NSSET child =3D {C1} > ... along with textual description what operator is hoping to achieve? > I'll try to come up with a step by step example later. But in the example cited, what the operator is trying to achieve is to change their nameserver configuration (e.g. switch to another set of nameservers for their zone) in such a way that (1) they can make that change visible to resolvers reasonably quickly, and (2) to make sure they are able to backout that change quickly if things go wrong. They can do this by lowering the TTL in the child NS set which is under their control -- assuming that resolvers are preferentially caching the child NS set, in accordance with the data rankin= g rules of the DNS protocol (the child NS set is authoritative). Ad 4. Delegation Revalidation: > > I agree with author's note "we would prefer to discard the extensive > mechanism" but the simple mechanism has simple description for me to > understand consequences. > I've heard the same from other implementers too. Paul V has mentioned that there are some subtle corner cases that are dealt with more precisely by the extensive algorithm (I can't recall the details right now, but maybe he will elaborate for us). Even if we end up on the simple path, it would be good to have a better understanding of those cases. > The simple mechanism: > > > > o Cap the time to cache the child NS RRset to the lower of child an= d > > parent NS RRset TTL. The normal iterative resolution algorithm > > will then cause delegation revalidation to naturally occur at the > > expiration of the capped child NS TTL, along with dispatching of > > the validation query to upgrade NS RRset credibility. > > So far so good, but it does not specify what should happen with RRsets > other than NS. Even if nothing is prescribed please state that explicitly= . > Thanks, yes I agree we should discuss all of these. Some quick thoughts for now .. Most importantly: > - Does the NS affect maximum TTL of _other_ data in the zone? > I think there are probably different views on what should happen here. Folks who want very prompt takedown of "bad" domains, will probably prefer a complete pruning of the cache at the delegation point at the revalidation interval, if the NS set has changed or disappeared. When this topic has come up in the past, there has been pushback from some implementers that it's difficult to do this because they use a non-tree data structure for the cache (a hash table most commonly). Most resolvers these days already enforce a max cache TTL parameter, so that typically prevents too much abuse. But at the very least, they should probably use the revalidation interval as a signal to stop "pre-fetching" records below the cut. - If it does, doesn't it increase risk of thundering herd behavior? > Possibly, depending on how popular the zone is, and what we decide is the answer to the previous question. At any rate, implementers should always employ strategies that bound how much work resolvers can be caused to do. It might be reasonable to suggest that resolvers enforce a lower limit on the child NS TTL (5 minutes?). If they see something less than that, it would be set to the limit instead. - If it does not, is it even worth the effort if attacker can put week long > TTL for A/AAAA and keep using that? > Answered above ... > - How should resolver handle RCODE=3DNXDOMAIN? Should it have different > effect than changing NS set to different set of servers? If resolvers are following RFC 8020 strictly, they are pruning their cache at the delegation - that would be the ideal. Otherwise, they should allow cached records below to live on, subject to max-cache TTL and disabling of pre-fetching. Or change in DS record value? > Which value? TTL or RDATA? DS TTL expiration would automatically trigger a revalidation of the child SEP keys at the parent. RFC 4035 says DS and delegating NS TTL SHOULD match, so NS revalidation should happen on the same time scale. In reality though, they are often different (COM/NET uses 2d for NS, 1d for DS). if NS > DS, a resolver could just decide to explicitly fetch the expiring DS first and wait out the delegating NS TTL if the DS rdata has not changed. But it seems much simpler to just say that if there is a secure delegation, then the DS TTL should be used as the NS revalidation interval too. For me personally mixing two problems (GHOST domains and NS inconsistency) > in single proposal does not help me to understand reasoning behind the > proposal and its intended effects. > Ok, we'll think about how to make this clearer. But the two topics are related. If resolvers prefer the authoritative child NS set, then timely revalidation of the delegation at the parent is also necessary. Shumon. --000000000000367cb205a670828d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 21, 2020 at 8:24 AM Petr =C5= =A0pa=C4=8Dek <petr.spacek@nic.cz<= /a>> wrote:
>
> =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-huque-dnsop-ns-revalidation-01

I would appreciate a practical example of changes envisioned in the followi= ng paragraph:

>=C2=A0 =C2=A0 A common reason that zone owners want to ensure that reso= lvers place
>=C2=A0 =C2=A0 the authoritative NS RRset preferentially in their cache = is that the
>=C2=A0 =C2=A0 TTLs may differ between the parent and child side of the = zone cut.
>=C2=A0 =C2=A0 Some DNS Top Level Domains (TLDs) only support long fixed= TTLs in
>=C2=A0 =C2=A0 their delegation NS sets, and this inhibits a child zone = owner's
>=C2=A0 =C2=A0 ability to make more rapid changes to their nameserver co= nfiguration
>=C2=A0 =C2=A0 using a shorter TTL, if resolvers have no systematic mech= anism to
>=C2=A0 =C2=A0 observe and cache the child NS RRset.

Could someone please post an example in steps? Something like:
- time 0, NSSET parent =3D {P0}, NSSET child =3D {C0}
- time 1, NSSET parent =3D {P1}, NSSET child =3D {C1}
... along with textual description what operator is hoping to achieve?
<= /blockquote>

I'll try to come up with a step by step= example later. But in the example
cited, what the operator is tr= ying to achieve is to change their nameserver
configuration (e.g.= switch to another set of nameservers for their zone) in
such a w= ay that (1) they can make that change visible to resolvers=C2=A0
= reasonably quickly, and (2) to make sure they are able to backout that
change quickly if things go wrong. They can do this by lowering the T= TL
in the child NS set which is under their control -- assuming t= hat resolvers are
preferentially caching the child NS set, in acc= ordance with the data ranking
rules of the DNS protocol (the chil= d NS set is authoritative).

Ad 4.=C2=A0 Delegation Revalidation:

I agree with author's note "we would prefer to discard the extensi= ve mechanism" but the simple mechanism has simple description for me t= o understand consequences.

I've hea= rd the same from other implementers too. Paul V has mentioned that there ar= e some subtle corner cases that are dealt with more precisely by the extens= ive algorithm (I can't recall the details right now, but maybe he will = elaborate for us). Even if we end up on the simple path, it would be good t= o have a better understanding of those cases.

>=C2=A0 =C2=A0 The simple mechanism:
>
>=C2=A0 =C2=A0 o=C2=A0 Cap the time to cache the child NS RRset to the l= ower of child and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0parent NS RRset TTL.=C2=A0 The normal iterat= ive resolution algorithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0will then cause delegation revalidation to n= aturally occur at the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expiration of the capped child NS TTL, along= with dispatching of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the validation query to upgrade NS RRset cre= dibility.

So far so good, but it does not specify what should happen with RRsets othe= r than NS. Even if nothing is prescribed please state that explicitly.
<= /blockquote>

Thanks, yes I agree we should discuss all o= f these. Some quick thoughts for now ..

Most importantly:
- Does the NS affect maximum TTL of _other_ data in the zone?

I think there are probably different views on what s= hould happen here. Folks who want very prompt takedown of "bad" d= omains, will probably prefer a complete pruning of the cache at the delegat= ion point at the revalidation interval,=C2=A0if the NS set has changed or d= isappeared. When this topic has come up in the past, there has been pushbac= k from some implementers that it's difficult to do this because they us= e a non-tree data structure for the cache (a hash table most commonly). Mos= t resolvers these days already enforce a max cache TTL parameter, so that t= ypically prevents too much abuse. But at the very least, they should probab= ly use the revalidation interval as a signal to stop "pre-fetching&quo= t; records below the cut.

- If it does, doesn't it increase risk of thundering herd behavior?
=

Possibly, depending on how popular the zon= e is, and what we decide is the answer to the previous question. At any rat= e, implementers should always employ strategies that bound how much work re= solvers can be caused to do.

It might be reasonabl= e to suggest that resolvers enforce a lower limit on the child NS TTL (5 mi= nutes?). If they see something less than that, it would be set to the limit= instead.

- If it does not, is it even worth the effort if attacker can put week long= TTL for A/AAAA and keep using that?

An= swered above ...=C2=A0
=C2=A0
- How should resolver handle RCODE=3DNXDOMAIN? Should it have different eff= ect than changing NS set to different set of servers?

=
If resolvers are following RFC 8020 strictly, they are pruning t= heir cache at the delegation - that would be the ideal. Otherwise, they sho= uld allow cached records below to live on, subject to max-cache TTL and dis= abling of pre-fetching.

Or change in DS record value?

<= /div>
Which value? TTL or RDATA?

DS TTL expira= tion would automatically trigger a revalidation of the child SEP keys at th= e parent. RFC 4035 says DS and delegating NS TTL SHOULD match, so NS revali= dation should happen on the same time scale. In reality though, they are of= ten different (COM/NET uses 2d for NS, 1d for DS). if NS > DS, a resolve= r could just decide to explicitly fetch the expiring DS first and wait out = the delegating NS TTL if the DS rdata has not changed. But it seems much si= mpler to just say that=C2=A0 if there is a secure delegation, then the DS T= TL should be used as the NS revalidation interval too.

=
For me personally mixing two problems (GHOST domains and NS inconsistency) = in single proposal does not help me to understand reasoning behind the prop= osal and its intended effects.

Ok, we&#= 39;ll think about=C2=A0how to make this clearer. But the two topics are rel= ated. If resolvers prefer the authoritative child NS set, then timely reval= idation of the delegation at the parent is also necessary.

Shumon.

--000000000000367cb205a670828d-- From nobody Sun May 24 23:18:22 2020 Return-Path: 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 D5AA43A0C26 for ; Sun, 24 May 2020 23:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 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, MISSING_HEADERS=1.021, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 BmuKtMdnrqiT for ; Sun, 24 May 2020 23:18:18 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2053.outbound.protection.outlook.com [40.107.22.53]) (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 DBD1A3A0C25 for ; Sun, 24 May 2020 23:18:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GvAkiUvfvXpHGKi0Z6EBI/OugQcKv0hXEJPHZqSILMMkwTfI1quu/1lMMNlo5ULOGk1gRwIv/GwVBqbGdFLz7mcOe+gWLbkWIsEznJRG+PZZO5tkJBDAuoJbcJZJGgcJBvv0zcSYyT2qGi5MWcKL0zjz3Qa+gFTnj4alGaiGfUK5RhtMi1BX9HHcEbtwiOSeqmQEyn4X4gH785vpPpSUhj8Ahqt0masZcWZtjhJI18iNGO41fAKAPSRCUWhgANDbfHmZh8htsDNBkU96pp5CNU79I+3/htQmtimdEIbGmVr2mjBlUrJJ9MMJ8YD+SKVGoS12AmPm+W0ndn3G0RZ7VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fBAeM7JbqaVasRuFqB8GyHGcP1YZ0YdGkLdJPFpwqBo=; b=Xvht6FmU6yYc+15NC8L7CqmtG/z8L7XZeh6LWZlobda2AEbmM+GcdU/W3M8gxBnC8VbuPMKnvDDJo4gQGufLt1qI2T1+AaGZTumcEDZHGF76Aq5KTWuxbR9NSD4ftS040gwGEZ3+PmBe4Em7f3m9fh+s0sFADVw3+DPKrd0EHLKbFIgdxkhNH8f0oflWGDNTXm2lGQFIDNhw1rUu+o9mBtNIdVH/obiyT24/9fKejJLziJBjuvq4/JTtVYI/41QS+pVSKCw7lhn2hUv7U6oOaXOeCoF7wS2qXTUUfFoo0JWN8ut+eMUaAmedgGXdZCXJJ2igHLyZ8LFP+QWxsqFsOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fBAeM7JbqaVasRuFqB8GyHGcP1YZ0YdGkLdJPFpwqBo=; b=olIkJ+WQ8f+nWKJwmImZfnJj7lTgRHezbCOOLkKd/+s05OiibpZPcdo7VBghN59U6PKQ6PSmXJUIMbZXagL3HFfPJpvv6U+B2vH4gDEyTSQsaU3FTigWGLiaUERvwxo3E0R52fRW7MyTWyp+jXOnLchC2wdLClFh/aRXpf1uSzY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=sidn.nl; Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM0P194MB0513.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:16e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Mon, 25 May 2020 06:18:14 +0000 Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::40dc:96f0:d873:6848]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::40dc:96f0:d873:6848%6]) with mapi id 15.20.3021.029; Mon, 25 May 2020 06:18:14 +0000 Cc: IETF DNSOP WG References: <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> From: "Giovane C. M. Moura" Autocrypt: addr=giovane.moura@sidn.nl; keydata= mQINBF14qwEBEAC7A6IGvwbFinLND4AFjFycPiM5Y3qudODE0kiYBPy5d4NIT4uAthSm2FPp 3kUNxMtlZI5NR0Ie/kI2NLdpS6MLpkKtO30D2GIQjaQ58emUnWAxkH94RDB5cJ69mmVxIUnv cpZEOrCvBcJU3SIhnXTfga8AFEct5Sb6XRYy8kblGXcH/6W1XTckcb4g/SejszC2oiiV3cZH HS3UCJvMfY1/6ojq6Cot6jgs/3M56PZI9odsYATu84JNaKqFv1rbD1lf7hYOM5sri6OqrPad qBOCT5DWbdxHvi6JzLNhuxxag/BtJPfLxMFDm+C6P0FKSjY78EzY6Ne2MKlLSDGQWyAHXZae X9RO/0t64LEWBLXmVS1KtIAPt0TgGodhr5d7jXP2maFmgO2+rWhGBBEeC9y9oRRJuBGFzl8w 0wMp1RDNipomtjWPZIIsuWiNKAF/iaPcTr6ZjaNOhnX+Kuqh3X7rr546RYtDDCVWVDpLKZmn 1scrRGKnhvPQsBiuICp5Up6sHNxh30c0n2PJeUZYlhLiZTuzG3rUSg7TLx7d39V4/XyjNr1p ordddIzM2zcGCNP0IgyjdMzjFljL01liMhENXmSagwDLQsOuExcZfawWviPEB2Rzz39obuxi L08RPrtnptcjkx0n6JFtkQUBOLGodtWWLs9cVF4Lic7aJswg6wARAQABtCtHaW92YW5lIEMu IE0uIE1vdXJhIDxnaW92YW5lLm1vdXJhQHNpZG4ubmw+iQJOBBMBCAA4FiEEkUlxD1iA/bYW 8LYoeMuqlaSXxY4FAl14qwECGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeMuqlaSX xY7A/w/9FSp5N5rGcWe9bK8+k06e5dcxYRphMMHpC6hnrvyfgZgvepkhx9jK8HOevF1xk/Xa 8MR53fP0wo+2ZXSPJNgkzITFFypHfM2LLxh1/Lm2KnwR58OuX/E1juvOx5FseDrVjcmOL1s/ vtm0s4nlbzCSwrvBfnpsSXmQvseQHcm82Oto78p7YxgUNoxjPkaUkmekDMm8TWwctTummYfM vHzKgKSVCCBNJayRRR6+pw+UG5mnlvUgv96AwK7CUF2pjlwIFKx6cVDDD3M17ZUP6zsPQ+HB 8m0DtQFtAu1mU/OXeNk54jKm4b2A1gXwNnh11e7uPzS5hrjz9znwyTLLw1fJPySYUVMDhuu4 EI+L2Goi1DrhLunQ72YRIKHF3jVjDd6eHenk9Qq44WfuYOE1PSdIKjhS0DfOZgy/C4DWkot/ XfZ40dlaV1eLb/fjWw1/GY3FYZIxxPvFV5tg+Fjn4pqiqy2XvCBrIzMYG0X4u3A4Kvjnblh0 9G/bD8lzx6mUymDvZ/PHk8+mhp9obA+LcmLHt+lkNyR73vT1ZTrQWqrzMTlXN7guFWSOrCOm toWgVu63L9LsFKiUllkctXGhFzaERQT85h6ugovq7Bk0Qf0NBvHcwxgBdUa/uqp9Frcm4gT3 pZFepXY4Q63nL/y3Ay65rouurVPsSUTghuzgRaZ1ePq5Ag0EXXirAQEQANJeW4E1yFJ8RIdH /LUp7ZjLSQZjxLi0J6Jz8q60ZCFOEBh++i0nmYljEHG1HHqvMzv7x7EEg2ZaQmk6l8ZF4CuG oy8xjKLyM1v7k3i/GPwHEmWAKR6VxwBflE4ISL0bwecOuBubemSsQYaHBvydTg/sSkCz2YcF inec4o4Ertu4HCo0c+LlzcWWcb1/O6vUaOGCH0LBXT2btbDMzOgSBTeRCHP/aLIClkjNmvRc mQIszCCriuqlapNWTzIm8WVfD5Ho/ZyrtgeSbqk5I4by9eyAJNDKi05NgR1vY85tQ/hNIN90 8RcVK7OvGrQ9NgJpk3oFeaCkAXbhq5HfAI2tWnj3lrPLa7FP//YoYVY/Teqb+Ehp1CiVkeHf F2yGRsSWa+99Ii3nM3E8CpJu+SS/M1zbQlBgvGT+liXMfvJ/7wzAivTdIsy94uiWbLvrmF6V g6Iwq6d9O+/3j8gvcl0OXvUzNO9Qjb3+dL9hoKZ4GPUN9nYP34KcGLgdeyi0/DeKTLDODbXA scoQ+V96JmJzMW+UXkIyfq27MVyZLnJMtwD9On2/vSaNjXD2imfUbtHU0+7FvET8qzzJUBII IYz0dA5UmQx2/PKqDLh5DWdaWZa1cf6RqQ+FE10ePot+RjTU3ojiYqbzJ9Nm8WazV2ibAMg9 gozAb/oRmp7vzZURc21PABEBAAGJAjYEGAEIACAWIQSRSXEPWID9thbwtih4y6qVpJfFjgUC XXirAQIbDAAKCRB4y6qVpJfFjo9sD/9iqHO8MMaMBhefBJs5imU+TMarHto+OLfsnGTQarqH GfyvCB6LmY0ZP92jXtMe9hx0dt8SrlGOtwsFoqcvSk5L5yaFde1aG2o3a21mlcyMRhljzME9 RgnN61pB/rfg8yjbxNbhBgKjQCO/2fyJIcp9Er2qKmJYGV7UkP3Fl5SHMs6Z9IiDhRQjhpKZ iXRpQUofHggErvV7//j8ALLEReVjfEg049EZ1U5VQosroXzkbSPfpAHjW4d+MdCM38WYC3Ap fk7qY1vZV3YTj/eD7j4b772xMMlUdPm6Vl83sAY/OP5ZFCe/f8HUwaRYm6zwhnRug8tI2g05 N3/yBVbmc047gtXTFuW0ZhHkN26rSl6e+gtfhoh0CigfixHRFI6TWrtF5APVxW+WJ1N990w1 RXXHCn8ZGVJ9u8sglWPSWwK8vVhhbZQVtPUkUegN0Zj7nqHz+5nHtqsF6ddIN65akf+CqArU /iVwvA5gsvid2vyunM88MlUplJBmAXtMEyCpvTyfDTT7jYY15ZpaO3jlHyiagwVhVrxgsw+B N0RmT/zoqKN33zuhSmrxw0+vU+gq2BZLjpjZRnnjeoFwKo3qNWKx7BRTxzOG5eMoGzrvO7dF Xt5QjjOQ4cFtq4ryW8qDfmDd4mLYyMcRO/hOPPq30pW9emtiXFABb8JvwfEusod+mQ== Message-ID: Date: Mon, 25 May 2020 08:18:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR02CA0018.eurprd02.prod.outlook.com (2603:10a6:208:3e::31) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2a00:d78:0:711:a894:71ff:fe88:a610] (2a00:d78:0:711:a894:71ff:fe88:a610) by AM0PR02CA0018.eurprd02.prod.outlook.com (2603:10a6:208:3e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.25 via Frontend Transport; Mon, 25 May 2020 06:18:14 +0000 X-Originating-IP: [2a00:d78:0:711:a894:71ff:fe88:a610] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1343d94-a4d7-409d-3cb9-08d80073684c X-MS-TrafficTypeDiagnostic: AM0P194MB0513: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 0414DF926F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5m6e/WCGUR8M378AC893lu4d3mKC+PiasczmemCnb052XPBrR4oECQleUtQc4dXNL0xS8U0Bo6RNGqg8h+H9cgq6/QwbwfKbxEPAXbzAqcO92LbcyTba2dchb2Ujc+AiZnjzaQZgpr4K9I5dL8xk/HfZ/ppOswJ53a5Q4bzasuyXsPIKYEN9GSTtIVLzkqnqh6EZ0YP9KQNOoW4CnIJlomaF3BnHxGlEnssPKDFXgwREEZ+c7P7sLfVHspAlTyHuR0p6NyatgJH8QAVGDTYAReV7p1a5djl1hDejyqWK+09Es6NnpS+F7HhrHGfHH0mswc/U1FHs2hNybP1xJ8rl/OS/49RU0f8hjCgiWgbEK5vDeIeI2KkQxaa/vhaMWiKT X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(39840400004)(396003)(346002)(366004)(31686004)(8936002)(186003)(16526019)(478600001)(86362001)(109986005)(2906002)(36756003)(4744005)(4326008)(31696002)(52116002)(316002)(2616005)(66946007)(5660300002)(66476007)(66556008)(6486002)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 4k95MpME8fMFkuqEKheiDBZpBxz3q2uVt1vwUzKcD1VfFQyUWTyydWliKyDD3Y0LQ8DnUz8tNaTjI0hrKmtjOyFj6+12lvlXMw/i0mrfTS5RU5GwOwQx+UvdAAHVwWV8ek9umHetmZbDbS5b0N+Jiy0SbgTVJsYy+jIq2BPVABpP1bNWsKI1tiY6xrAP+sPUMZwOPvLOppUJmopFYAp6USDBisYzPilSNDsyLG4T4gO4x/eV+A9fN/OkkeLE6kOxht3+nauR/o1ZSAtDi7Tj6acoFWcQppYnS/fTXYoNSFgQ6YL3NSdTQmlajls1do+067mm+GVWsQddCwVHB2PuNLeS3Wqv2mH4cOjIJGYV2YzS7awibzraWR/n6hSemliAtxoF893pMNxOZjT9Da4Z1VesaFUa04ppJ/QlIesRl3KEbTMNgjW6hn7eYLnmSz/nQbjQrD1hvmzZcd4Dqt91ed4200HyM4SmmmEDJEGZ79+vPnIYvQcKJvcuzzH3f3MsE+1D3ELH0EwZHo1ZXw62WEU6fZXj14OonEydaCCauao= X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: c1343d94-a4d7-409d-3cb9-08d80073684c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2020 06:18:14.6499 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gTzcdEK+6gurFrYHIX38xBiDHs2Koy6Ws3i74AggzBKkbRZkVgOtGEitP6VrS7rO+nt2pAJ7ZBo2ywtO4g2a7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0513 Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 06:18:21 -0000 Hi Shumon, > Thanks Giovane (and Marco)! Sure thing. > The HTTPS site goes to a different and mostly empty page - and > Chrome doesn't like the certificate because it has a wildcard Subject > CN. Are you planning to fix that? fixed. > I know DNSSEC is likely not the focus of your experiment, but the > zones do seem to be signed - but with algorithm 16 (Ed448), which > not a lot of resolvers or debugging tools support yet. Any reason you > didn't choose a more widely supported algorithm? No particular reason, we can also change later on. /giovane From nobody Mon May 25 02:06:23 2020 Return-Path: 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 596AB3A07C5 for ; Mon, 25 May 2020 02:06:21 -0700 (PDT) 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=open-xchange.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 fHVacR97QLfG for ; Mon, 25 May 2020 02:06:20 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 DE2D63A07BD for ; Mon, 25 May 2020 02:06:19 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id B52F26A2FF; Mon, 25 May 2020 11:06:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1590397577; bh=CPLTswYqVZrl0XM0RYyGb3eCBykg4hmWQMp5ig7Dhcc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=xi5iD7bFioxmq+vfVk8CPBZGUGojZDT/vLyyKfPlg++0ZnpZDmWe9tQgEos9qw8ah LVbHTn6c8/tZ2qY512zDHO0zodahpHdyVck/0gCyIMTwEBQIuzohWHA7B68YNvv+ZE 6zIQeCae4AoMkzytVDLpCy3Lm7FuKD/OxYC8qSGdftL9dbok2r8r9Hta27ZYzhyEmi KjjvhfHmlf3WVsLIKrBruE3VfjaHBPihqWcyyUvzwnEKnA7KawKcSUft57fTsyA4Od FhHbMkwHv7N7A0Vva9ACrQZoImRMinZA14QfW3Kg12ZbCdFGllRgg6Qa6QCVA18+Na KhApSBkwJZnxA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A5D9B3C07D4; Mon, 25 May 2020 11:06:17 +0200 (CEST) Date: Mon, 25 May 2020 11:06:17 +0200 (CEST) From: Vittorio Bertola To: Tony Finch Cc: George Kuo , dnsop WG Message-ID: <189033692.11260.1590397577578@appsuite-gw1.open-xchange.com> In-Reply-To: References: <2487238.otjEU5M4pH@linux-9daj> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev8 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 09:06:21 -0000 > Il 22/05/2020 18:59 Tony Finch ha scritto: > > I think despite what Paul H. said this is already covered in RFC 8499: > > Open resolver: A full-service resolver that accepts and processes > queries from any (or nearly any) client. This is sometimes also > called a "public resolver", although the term "public resolver" is > used more with open resolvers that are meant to be open, as > compared to the vast majority of open resolvers that are probably > misconfigured to be open. Open resolvers are discussed in > [RFC5358]. I think this definition is good - perhaps what we need is just to agree to use "open resolver" instead of "public resolver". If you wanted to convey the nuance that it's not just open, but open on purpose and meant to attract users from the entire Internet, you could add "global": "open global resolver". Or, as an alternative, you could use the term "platform", which is increasingly being used to identify Internet-wide global companies that provide multiple consumer services. "Platform resolver" would also convey the idea that these resolvers are going to be distributed and ubiquitously available. "Cloud resolver" could have a similar meaning. But, as for any terminological bikeshedding effort, you cannot force others to use the "most correct" term, so it's possibly just a waste of time. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Mon May 25 08:35:28 2020 Return-Path: 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 234093A0DAE for ; Mon, 25 May 2020 08:34:51 -0700 (PDT) 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=unavailable 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 U2oIGPothcjK for ; Mon, 25 May 2020 08:34:48 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1B43A0D90 for ; Mon, 25 May 2020 08:34:41 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 465FFB074A; Mon, 25 May 2020 15:34:39 +0000 (UTC) From: Paul Vixie To: Tony Finch , dnsop@ietf.org Cc: dnsop WG , George Kuo , Vittorio Bertola Date: Mon, 25 May 2020 15:34:38 +0000 Message-ID: <3261748.qd5D8ZHc2X@linux-9daj> Organization: none In-Reply-To: <189033692.11260.1590397577578@appsuite-gw1.open-xchange.com> References: <189033692.11260.1590397577578@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 15:34:58 -0000 On Monday, 25 May 2020 09:06:17 UTC Vittorio Bertola wrote: > > Il 22/05/2020 18:59 Tony Finch ha scritto: > > > > I think despite what Paul H. said this is already covered in RFC 8499: > > Open resolver: A full-service resolver that accepts and processes > > > > queries from any (or nearly any) client. This is sometimes also > > called a "public resolver", although the term "public resolver" is > > used more with open resolvers that are meant to be open, as > > compared to the vast majority of open resolvers that are probably > > misconfigured to be open. Open resolvers are discussed in > > [RFC5358]. > > I think this definition is good - perhaps what we need is just to agree to > use "open resolver" instead of "public resolver". > > If you wanted to convey the nuance that it's not just open, but open on > purpose and meant to attract users from the entire Internet, you could add > "global": "open global resolver". > > Or, as an alternative, you could use the term "platform", which is > increasingly being used to identify Internet-wide global companies that > provide multiple consumer services. "Platform resolver" would also convey > the idea that these resolvers are going to be distributed and ubiquitously > available. "Cloud resolver" could have a similar meaning. not that it will matter, but i find those names unprovocative and descriptive. > But, as for any terminological bikeshedding effort, you cannot force others > to use the "most correct" term, so it's possibly just a waste of time. i don't think we'll be able to improve on dagon's "more correct" suggestion: > I suggest: "distant resolver outside of the user's policy oversight". -- Paul From nobody Mon May 25 09:34:40 2020 Return-Path: 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 9D5DB3A0DAD for ; Mon, 25 May 2020 09:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 7CEhHz4r8uGk for ; Mon, 25 May 2020 09:34:16 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 EFC9C3A0DE3 for ; Mon, 25 May 2020 09:34:15 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id n141so5503036qke.2 for ; Mon, 25 May 2020 09:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xyh/qTFuOPMk1I4jOZrd6HevPN4s1WSly3rwDVhgxk8=; b=vGhXa47EgnK9qod2hkDYBbNdGhz9FQ6LuCKqLGTg+hBcQX4RmOjwHViit7xSrL9w8G Rmqt1cuP3LlpeZk8hpIITDaWppRrN7i8TRbkKIY2p4dbxF+2jp4fesuPp/EKEzny2Rt8 oJf54lyqrRtzM06ZhzeOVy4B11/Od2OOSfKkdtO7acIFFxLqrko/hDJGGlJPjtq88Eza 7iEaUtCzDOgI1vhMKIxS5T5mJ0niusaYQ1dTOBg+mEmBTqj6rI5FxzYlHUP9v+YTQMBD H5OGqG0eU89Et/0BI4155Ul86nzRmjXxWZ0JratfCBwKSNc8k4F5jsca5qOBKgpRwgnh SE3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xyh/qTFuOPMk1I4jOZrd6HevPN4s1WSly3rwDVhgxk8=; b=UDgptJ0VoD+J0nZDmVmIPAaffhR7SKtyIgF+z5SWJPBrLD41c2JrgnDhjgYipvtDGu 0ef/hXh8DGzbpiZzu5cNWPZEXiEMdiSoLlncmL7nMOw8B4LfSDe3ilHpqU4MIsvMVcjw XJ6r38FIbY0kOeW3AuxkGgIfV/kOw6SnfVQXX1JFkTr6bndNJAw3b4VvDTuauFmPP+mZ YUvIL2DaMCOUC9lJZj0oBAUCnNZjTC4iWNuIL/qQ97NRB7YoOshJnKG8Fy0/VYtNq6pa 6aCoWzmNCuoRTQL+eCYxgI4nudiKmN1z99pyfDroqjz0kzvtC18q01TBaXUaW8ecOa64 +OIg== X-Gm-Message-State: AOAM530SCqChH+ZdsKOlc6wiJ+VBiLWh0nZnhut2p7qYBQUEXfBAXGlk ceaCZ4TWCX0kN8G96FNOvO+Pje+Htq6j8OPJFBs= X-Google-Smtp-Source: ABdhPJy3Be9UCYvmtktkAHOe/Z4NbfFR/nPXUwzJ4j5rYMrs0zRnMnNG4FVntwvh2snBHKKhoT9zBMemIvFKY9cbzaE= X-Received: by 2002:a05:620a:142e:: with SMTP id k14mr27146348qkj.414.1590424454950; Mon, 25 May 2020 09:34:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lanlan Pan Date: Tue, 26 May 2020 00:34:01 +0800 Message-ID: To: Shumon Huque Cc: Joe Abley , dnsop Content-Type: multipart/alternative; boundary="000000000000adf2c705a67b8c53" Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 16:34:23 -0000 --000000000000adf2c705a67b8c53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Shumon Huque =E4=BA=8E2020=E5=B9=B45=E6=9C=8822=E6=97=A5= =E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8811:00=E5=86=99=E9=81=93=EF=BC=9A > On Fri, May 22, 2020 at 10:52 AM Joe Abley wrote: > >> On 21 May 2020, at 16:07, Warren Kumari wrote: >> >> > What does all of this *mean*? >> > .. >> > .. >> > .. >> > Sorry, I haven't a clue, other than maybe: >> > The DNS is weird. >> >> In your experiment it seems clear that all the glue records you are >> looking for are being returned from the involved authority-only servers = in >> the additional section, and since for the COM zone that's a >> well-constrained monoculture of software it seems reasonable to imagine >> that's not where to look. >> > > Indeed. Since the COM referral response to glue queries is correct, this > means that some resolvers the Atlas probes are using are promoting glue t= o > answers. > > Has anyone surveyed which of the following category of things are > promoting glue to answer: (1) other TLD authoritative services, (2) > authoritative server software implementations, (3) "public" (contentious > term I know) resolvers, and (4) resolver software implementations? > some resolvers send the NS_DOMAIN A query to glue ns ip, get the response from authority, and overwrite the glue. the TTL of the authority response is shorter than the glue. > > That would be an interesting but possibly very time consuming project - > but we could focus on the major ones. > > Shumon. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000adf2c705a67b8c53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Shumon Huque <shuque@gmail.com> =E4=BA=8E2020=E5= =B9=B45=E6=9C=8822=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8811:00=E5=86= =99=E9=81=93=EF=BC=9A
On Fri, May 22, 2020 at 10:52 AM Jo= e Abley <jabley@= hopcount.ca> wrote:
On 21 May 2020, at 16:07, Warren Kuma= ri <warren@kumari= .net> wrote:

> What does all of this *mean*?
> ..
> ..
> ..
> Sorry, I haven't a clue, other than maybe:
> The DNS is weird.

In your experiment it seems clear that all the glue records you are looking= for are being returned from the involved authority-only servers in the add= itional section, and since for the COM zone that's a well-constrained m= onoculture of software it seems reasonable to imagine that's not where = to look.

Indeed. Since the COM referral= response to glue queries is correct, this means that some resolvers the At= las probes are using are promoting glue to answers.

Has anyone surveyed which of the following category of things are promoti= ng glue to answer: (1) other TLD authoritative services, (2) authoritative = server software implementations, (3) "public" (contentious term I= know) resolvers, and (4) resolver software implementations?
some resolvers send the NS_DOMAIN A query t= o glue ns ip, get the response from authority,=C2=A0 and overwrite the glue= .
the TTL of the authority response=C2=A0 is shorter than th= e glue.

That would be an in= teresting but possibly very time consuming project - but we could focus on = the major ones.

Shumon.

=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000adf2c705a67b8c53-- From nobody Mon May 25 15:49:05 2020 Return-Path: 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 8C2F53A0B13 for ; Mon, 25 May 2020 15:49:03 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 gxIebJ5E_Z1H for ; Mon, 25 May 2020 15:48:58 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 985303A0B16 for ; Mon, 25 May 2020 15:48:58 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id c16so20069027iol.3 for ; Mon, 25 May 2020 15:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lNTl7TSLUjpnH3OGIuI5sfz4hC8pciH32kgvxhoOZ0c=; b=nFW4/yg95hbE1Owbnj29tAeAnsJwCATQs+e/ayMroAwlc4foxxk1pTx4vsr2dN++yB aVEaO6BKeY+1ohkEnDk5xzgTLo5r2ZOdRYIxdnd+ZBrAmdy4zDvPmDsKWao/T0tw5ko0 5bBAYoXN5xoGNTn+beuVIJLcqPKqsfmbo9hE04aksfAsjtuGXrejdtGiknJjw6sTEPaO VcCWK1MBlCGgMOKuRD2kINzAah+ukRM5Tm5ntOCTxy7eHLHMvUKifOp9lrN+JdNnoysM RSEua1NpfFOGyoOE6oXAuWdnqPKNrT8wZ2NdlFiBeUfOoKxPCLtJVrKM/HFIQk+hEhqL 7ANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lNTl7TSLUjpnH3OGIuI5sfz4hC8pciH32kgvxhoOZ0c=; b=SxcVL0z8jimMIGPEMXRKsLYWwcd8gup6Yi8lvAso/6IKm8uYglTB7Gu8GS4vjMsLh1 2WEISm0ukaZ+kdUX672vwW4SRWDJNeIbTloWl6OD4umWd3mfMnYPo6wE6ErCOFlSVMzs gyWISbU7lV2d2jJduZHv1F1PEJMUKMiCbrQXaTv71wU2TYDIVLAvJNF1zBWthR7lLCUe SWEGSAGSNroM8Dqea9sAN2VNu/191Rz2rUq4HzBL335f3Qnaj/83IaFWqL/+hu23HItu LeumrRzmLmi7fDrVSm7YK1heOJM0JJM7u9wY/GyYeI15D+BILRhasb5VSiREOXaUM98d kOxQ== X-Gm-Message-State: AOAM530pOerjw10aY+ifWqsNy0kh0Z1Gffy+g3ZHSg4f+rXcHDeCqBMF yowvTdqkgUDA1A+4WvCFKD1sdabBReXi0m7q7WprOo6dp1vqLQ== X-Google-Smtp-Source: ABdhPJwVpO8LWrqO2ueOiFyl2nkcKh40r4ucqFAKSbcU0W/NSaJ/X9w3HQDxD1z5r3MVRbKHQCqW/FrT9hVVRsVFlUU= X-Received: by 2002:a02:6d46:: with SMTP id e6mr12492398jaf.43.1590446936795; Mon, 25 May 2020 15:48:56 -0700 (PDT) MIME-Version: 1.0 References: <2487238.otjEU5M4pH@linux-9daj> <189033692.11260.1590397577578@appsuite-gw1.open-xchange.com> In-Reply-To: <189033692.11260.1590397577578@appsuite-gw1.open-xchange.com> From: George Michaelson Date: Tue, 26 May 2020 08:48:45 +1000 Message-ID: To: Vittorio Bertola Cc: Tony Finch , dnsop WG , George Kuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] definitions of "public DNS Service" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 22:49:04 -0000 On Mon, May 25, 2020 at 7:06 PM Vittorio Bertola wrote: > > If you wanted to convey the nuance that it's not just open, but open on p= urpose and meant to attract users from the entire Internet, you could add "= global": "open global resolver". > > Or, as an alternative, you could use the term "platform", which is increa= singly being used to identify Internet-wide global companies that provide m= ultiple consumer services. "Platform resolver" would also convey the idea t= hat these resolvers are going to be distributed and ubiquitously available.= "Cloud resolver" could have a similar meaning. > > But, as for any terminological bikeshedding effort, you cannot force othe= rs to use the "most correct" term, so it's possibly just a waste of time. You make a useful important point here: an "open resolver" is the superset of "deliberate" and "abused" ones. The concept here is that the intent is deliberate, we need some way to say so. if the intent is not there and is being abused we need some way to say so. I started typing this as "good" and "bad" but we know not everyone believes open public resolver services deliberately deployed ARE a public good, all the time. So I went to deliberate and abused, because there is "I do this by intent" and "it is being done by accident" -G From nobody Mon May 25 16:08:42 2020 Return-Path: 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 AF5223A0B39 for ; Mon, 25 May 2020 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 Z5kJhU_Iosr9 for ; Mon, 25 May 2020 16:08:38 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 C3B0C3A0B38 for ; Mon, 25 May 2020 16:08:38 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id w4so17200659oia.1 for ; Mon, 25 May 2020 16:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YqlXIArSG/flJkPV09cOr7/W+DiFHzBHtf5nqcnDJK4=; b=hA6SQyyhDzgXXxCNzQPdfy0OUQB54hl2uueFniazcg7SkZzm6ACUDUZDf1wagNGFMs WfMfNKo2Ea9WKvLHSgqyjxqkY7WW4j37i3QjVahfNdmWLz+VU5KUJ/Rg/6infuzrfMV6 fiuXzKEhYlSOvaF1Q60Ie19RaxsjRgVkmwc8NZgeBv5q8N6TNzU0ZrV+NR6cELhWRvZ2 ZSAqhUsgvpa9xtWjGnoHF6s2FOOKBO7OAUMjOBfRc1QLanbDKdC1MNyxEJppnDT9wFL2 5ar3rzDIRAlaWn+x2VLUXlaC4BFcQzC756z8AZDGOcu3EBnPftB5Z9HVAy6rIk8ZgYFC LulA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YqlXIArSG/flJkPV09cOr7/W+DiFHzBHtf5nqcnDJK4=; b=Pz0C2WDPAItEDSQjmyPHphVgxf5DD1S+eyZMQqwOPs8zAXAB27vIfet2u8Vi1eqxaU pGZ3Ry2slxM+PTeIgGV/zHbTbvnryr4HtNeSZoXijn2/7DrFET8rOI7xvTU35CTU4cbN T2xkZnj14Bz2tZJf52qBe3kPR0LnCvqYCTnBAD0XXQoDIOQG/ktsvx/8Itqu3SpPfQnQ BxZt2jkvh7WjEDs3094VBj4hSQOXSYCT9CMCkds+2AxqCh61jbrF23nqdgLNPvaMDzOL lS2QMZ6kEhw5sXp0hjYnm0iGJMMs+hiiLt3LKPjmZYGEh13tLE6nbJWhnZ6PYdznHrFS RTkA== X-Gm-Message-State: AOAM532N749aESv78k8pe3zYRzw1y9pg6Or/+wABykPt2gaEbI4LD/jo msDmxCB9n5kU3MdUaXzaDdzm/qLu4PiFDGR6k8I= X-Google-Smtp-Source: ABdhPJyh2NIBPY1mqtzKV7oBrDMlZL6nw6V3is0IBTSasIIVBkrV4LcKxhUxmGD9ESNfCXbQ1ECn6naG20zxCjWjd8g= X-Received: by 2002:aca:c590:: with SMTP id v138mr7880319oif.132.1590448116359; Mon, 25 May 2020 16:08:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 25 May 2020 19:08:25 -0400 Message-ID: To: Lanlan Pan Cc: Shumon Huque , dnsop , Joe Abley Content-Type: multipart/alternative; boundary="00000000000002681005a6810f5e" Archived-At: Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 23:08:41 -0000 --00000000000002681005a6810f5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 25, 2020 at 12:34 PM Lanlan Pan wrote: > > > Shumon Huque =E4=BA=8E2020=E5=B9=B45=E6=9C=8822=E6=97= =A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8811:00=E5=86=99=E9=81=93=EF=BC=9A > >> On Fri, May 22, 2020 at 10:52 AM Joe Abley wrote: >> >>> On 21 May 2020, at 16:07, Warren Kumari >> > wrote: >>> >>> Has anyone surveyed which of the following category of things are >> promoting glue to answer: (1) other TLD authoritative services, (2) >> authoritative server software implementations, (3) "public" (contentious >> term I know) resolvers, and (4) resolver software implementations? >> > some resolvers send the NS_DOMAIN A query to glue ns ip, get the response > from authority, and overwrite the glue.. > the TTL of the authority response is shorter than the glue. > (With no hats) While in general the TTL of the authority response is shorter than the glue, I can personally attest to domains out in the wild, that at one point had authority TTL much larger than the glue TTL. tim --00000000000002681005a6810f5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 25, 2020 at 12:34 PM Lanlan Pan &= lt;abbypan@gmail.com> wrote:
<= div dir=3D"ltr">

Shumon Huque <shuque@gmail.com> =E4=BA=8E2020=E5=B9=B45=E6=9C=8822= =E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8811:00=E5=86=99=E9=81=93=EF=BC= =9A
On Fri, May 22, 2020 at 10:52 AM Joe Abley <jabley@hopcount.ca>= ; wrote:
On 21 May 2020, at 16:07, Warren Kumari <warren@kumari..net> wrot= e:

Has anyone surveyed which of the following category o= f things are promoting glue to answer: (1) other TLD authoritative services= , (2) authoritative server software implementations, (3) "public"= (contentious term I know) resolvers, and (4) resolver software implementat= ions?
some resolvers send the= NS_DOMAIN A query to glue ns ip, get the response from authority,=C2=A0 an= d overwrite the glue..
the TTL of the authority response=C2= =A0 is shorter than the glue.

=
(With no hats)=

While in gen= eral the TTL of the authority response is shorter than the glue, I can pers= onally attest to domains=C2=A0
out in the wild, that at one point had authority TTL = much larger than the glue TTL.=C2=A0

tim
--00000000000002681005a6810f5e-- From nobody Tue May 26 04:45:55 2020 Return-Path: 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 2AFD73A07B1 for ; Tue, 26 May 2020 04:45:52 -0700 (PDT) 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 cN7UCLiO1usm for ; Tue, 26 May 2020 04:45:50 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 0E9DD3A07BC for ; Tue, 26 May 2020 04:45:50 -0700 (PDT) Received: from PFE112-VA-2.pexch112.icann.org (out.east.pexch112.icann.org [162.216.194.10]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 04QBjl34008470 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 26 May 2020 11:45:48 GMT Received: from PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) by PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 07:45:44 -0400 Received: from PMBX112-E1-VA-1.pexch112.icann.org ([162.216.194.24]) by PMBX112-E1-VA-1.PEXCH112.ICANN.ORG ([162.216.194.24]) with mapi id 15.00.1497.006; Tue, 26 May 2020 07:45:44 -0400 From: Roy Arends To: Joe Abley CC: dnsop Thread-Topic: [DNSOP] new version submitted for draft-arends-private-use-tld Thread-Index: AQHWM1MwF1BHt0VSg0m2gWo5YhA8Fg== Date: Tue, 26 May 2020 11:45:44 +0000 Message-ID: <76460227-329B-40C8-BD1B-238D77DA8DCD@icann.org> References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> In-Reply-To: <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> 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.47.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_5AA87459-CF3B-40DF-8201-6B3496FC83C1"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-26_02:2020-05-26, 2020-05-26 signatures=0 Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 11:45:53 -0000 --Apple-Mail=_5AA87459-CF3B-40DF-8201-6B3496FC83C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joe, thanks for your thoughtful comments. > On 6 May 2020, at 02:18, Joe Abley wrote: >=20 > Hi Roy, >=20 > I have read this document and I like it. >=20 > There have been other proposals to make recommendations like this in = the past that I have not been very enthusiastic about. The reason I like = this draft-arends proposal more is that it neatly avoids the problem of = who gets to make policy about this stuff by pointing out that suitable = policies already exist and that hence the problem is already solved. >=20 > I also like the happy accident that the names on the user-assigned = list are all pretty much equally arbitrary in every language in which = US-ASCII labels have the potential to have semantic meaning. This seems = better than choosing a label that is a recognisable word in some = languages but not others. >=20 > I have two suggestions for the document. I have some doubt about the = second suggestion, but the first one seems definitely great. :-) >=20 > 1. While this document currently includes instructions to the IANA = that could be viewed as specifying TLD naming policy, it might be = possible to avoid that particular hidden foot-operated explosive device = with some re-wording. >=20 > This document could simply make the observation that since existing = ccTLD label policy is to defer completely to ISO-3166 alpha-2 (citation = needed) and since ISO-3166 alpha-2 includes user-assigned codes that = will never be assigned to a territory (citation needed) then it is = consistent with existing policies that those user-assigned codes will = never be delegated from the root zone in the DNS and, for that reason, = will never give rise to collisions with any future new TLD. >=20 > That would leave this document simply as a clarifying description of = existing policy, instead of appearing to have ambitions to change or = specify policy in the root zone (which is the kind of thing that ICANN = is also plausibly responsible for). The consequence of that small change = might be (is, I think) to make this document completely uncontroversial = whilst preserving the core advice. No worm containment failure required. That is good advice. I=E2=80=99ll take it. This will be reflected in = version -02, which will drop shortly. > 2. The document stops short of making a clear recommendation in = section 5. While the decision to anchor a private namespace in something = that looks like a TLD is not necessarily the only plausible answer (I = could anchor such a namespace at a domain that I reserve through normal = domain registration, for example) the document *could* say "for = applications that require a private namespace anchored at something that = looks like a TLD, our recommendation is to do this". >=20 > It is possible, of course, that a clear recommendation might have an = XKCD-927 effect (which would be unfortunate but perhaps tolerable) or no = effect whatsoever (which at least seems benign, but which is also a bit = useless). However, if the document is not going to make any clear = recommendation, I'm not sure what the point of publishing it is. Good point, I=E2=80=99ll take this into consideration. I will have new = and improved wording in version -02. Roy= --Apple-Mail=_5AA87459-CF3B-40DF-8201-6B3496FC83C1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Aw ggWaMIIEgqADAgECAhAC8rGsZZEVwDggOu7Mu2E3MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xOTAxMTcwMDAwMDBaFw0yMjAx MTcxMjAwMDBaMIG7MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUm95IEFyZW5kcyAoMjAxOTAxMTcpMSMwIQYJKoZI hvcNAQkBFhRyb3kuYXJlbmRzQGljYW5uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALIUjLA9qXUR1zgYOLSdC8rPQqrXJlVnshs8UWZfAu1Iwuj5jALoUWuvF+YWEBZZkgFuLbY5 ocPBgrnxv3l8rgCyoJMtf89edKCFOdHEsv+K3/9EG+gqlYm9GRg+cxqCq7WIPhbnawBOkSkpoT/J MxEMTIBLKEroumaZsM7XcY1vgr+vOxbBJ/+aO16BynB3/YbqR4zvQR8xOiPhfgl/Brg6fRtGm47h gU0DKrQ8MQqKaHhrWXjvQvnr0VzGnxANbjUK1ggVFXkIO4+7szB56Acp7ERrmxCYqYVK+7en9GNx IBnmN6lnERmvcfRyb0H8HPgWLkKH8BI4m/Zsko5JyP0CAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBSxk+GbMVrJevh7fdqWM6pZVXFyjTAMBgNV HRMBAf8EAjAAMB8GA1UdEQQYMBaBFHJveS5hcmVuZHNAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB5pbggxD+KqyTcLnhSvXAI 0f3pRnss8vUiAuNM1coPPDTPa3O8z9mPKFYCzIiZ7yUcSFHwJGzmvpYHCm7cy7yhG9YKDl6TBgAi tbBMQa1WJ1bPViAMQrxVPVXZ2xJO8mWRGZzK/64r2+azahVS9c0Szu73LSgJReoTraJnZqYUfRlF Uvz+e1XA3ClFmcXTH2ufUQsMhQ94f2j5p2WZtNDBAKkVBQYw2zrVn9doNSMQGfDg5eNJrj1iRo0g sVAvVlgsTlt/wuWnEnz4D491ToWE/biLxS3DL7DrqWgixBid3MFpz575Xdg1mBFFSXCs8vQItF2p Ebs5HeLkGxdhkY6/MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAykwggMlAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAC8rGsZZEVwDggOu7Mu2E3MA0G CWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0yMDA1MjYxMTQ1NDNaMC8GCSqGSIb3DQEJBDEiBCB+bBXcsSDYxWJ+YKyedE46vmqbk/hl1MW0 0KxfS0t50DCBiAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl cnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7YTcwgYoGCyqGSIb3DQEJEAILMXugeTBlMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7 YTcwDQYJKoZIhvcNAQEBBQAEggEAY+FNP5+U4UxzD9kdIFFdDdwldQcqW1NsmSJUfu9QNUEvT3v9 JdNFCkcvhRNPyHMILonCCTEp+sf9Ev7qrL4SRTg4igEiRb24VhwXl9zJf3pf5UZTHMOaJbF9+rEl S/jMCWE/NYeA3MNMt101ooiUyxhgLWKwJfhl8nLVH+pXi72l8FWRuVHy8+WFDsAj5eb/euLpzKIk N/H+ip8lu93b5itu8zBWVdEesYrIgjAXeekCEeIhy0n2eZot0zDQuch16cX7sNmU2Iou4aqhWext MEOmI6Lx4erP/hB+TEB2oCBg81taSe7aEwgrG+WRIUZE+NZ8WSwn1PxsNZxyy/fPiAAAAAAAAA== --Apple-Mail=_5AA87459-CF3B-40DF-8201-6B3496FC83C1-- From nobody Tue May 26 04:54:25 2020 Return-Path: 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 0C5D83A0E75 for ; Tue, 26 May 2020 04:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec 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 j5725D03WP1c for ; Tue, 26 May 2020 04:54:20 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4DBA43A0E78 for ; Tue, 26 May 2020 04:54:20 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id q8so3715534qkm.12 for ; Tue, 26 May 2020 04:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zx4i9krkbtsHQzjouAenoMqufL145VZAGQiKJLM9YHk=; b=Z87K9lHQvhHQK43wXPSYhU7omCq4EJPchrFmz07p15lOOqI9gHFE6WSUZ9BpV84fqE 6+KC7iCXHZoCZ5O/Q/3y1TbyqUjvx/W4ifZnz3su5aCW5TQAxJe3BipBKpBLrE8wCtRm hXIe4PsPllds8gs9WxXqwOfhWpTecdPkjKqys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zx4i9krkbtsHQzjouAenoMqufL145VZAGQiKJLM9YHk=; b=eHKnUlVKskBAKDhF/kTSloBX1moaE2VwnM5PRo3LTAUIRPLq0+No0b7gy61kWMdLAz SMoWWRnRBNJRzZHEuzKWMzr2w77C0rrQUR46jaWkhqWsY1laoCJIHp03VGJJpfN9VzvZ CYKpZjwM0g0in2270jWv/A/rHWqaKqu0neqR7nKXXmCTFMgZCJwUHp2rftqClvU1a+Ut 4ZAC2C44g6izbT243lNgV8yT0sZaMudxzT7Bbms3791UBZI08qzGmSTaVkTedvZSUp2W ZXlXhntw5HlHSynnc9UirJJ3kLTnATrrszjsRgRi8bQ2ujkZjePDS2bbSL7sitatWcrF a5rQ== X-Gm-Message-State: AOAM533BdCN1vakfxHtHd3Vc9eZ2sTMCxXZzrpkdtUQ8WnBgV0CqPzdu g7iD3qCctYFKWeo6EC7SmNh24w== X-Google-Smtp-Source: ABdhPJxiSt5BGNQviRGpkMa+dwzYBv7k8Q3lxEY1/+gVsVnBkP1OE/Pj3RInc7yLY53Mn638NwQHrw== X-Received: by 2002:a37:7143:: with SMTP id m64mr783328qkc.27.1590494059196; Tue, 26 May 2020 04:54:19 -0700 (PDT) Received: from [192.168.1.64] (host86-190-124-160.range86-190.btcentralplus.com. [86.190.124.160]) by smtp.gmail.com with ESMTPSA id 188sm16322640qki.35.2020.05.26.04.54.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 04:54:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Roy Arends In-Reply-To: <20200506025735.920A518D0160@ary.qy> Date: Tue, 26 May 2020 12:54:16 +0100 Cc: dnsop@ietf.org, jabley@hopcount.ca Content-Transfer-Encoding: quoted-printable Message-Id: <46F43925-37FB-466D-B1A4-C4EF82811364@dnss.ec> References: <20200506025735.920A518D0160@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 11:54:22 -0000 Hi John, > On 6 May 2020, at 03:57, John Levine wrote: >=20 > In article <5D255EEE-4CAB-44D6-8C47-BBE9C7F5CF22@hopcount.ca> you = write: >>> It contains plenty of examples of how user-assigned code elements = are used in the field, including >> other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself. >=20 > I also think it's an improvement, and concur with Joe's advice not to = tell IANA to do anything > since they're already doing it. Thanks. I=E2=80=99ll reflect this in version .02 >=20 > R's, > John >=20 > PS: I don't suppose there's any chance that the IETF could mount an > expedition to Western Sahara or Palmyra atoll and claim .EH or .UM? The delegation of =E2=80=9C.eh=E2=80=9D and =E2=80=9C.um=E2=80=9D has = been discussed in the past and more information can be found here: =E2=80=9C.eh=E2=80=9D: = https://www.icann.org/resources/board-material/prelim-report-2007-10-16-en= =E2=80=9C.um=E2=80=9D: = https://www.iana.org/reports/2007/um-report-10jan2007.html Warmly, Roy=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue May 26 04:57:16 2020 Return-Path: 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 908F93A0E7F for ; Tue, 26 May 2020 04:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec 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 C_Sr5dA-mK6q for ; Tue, 26 May 2020 04:57:12 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4A22A3A0E7A for ; Tue, 26 May 2020 04:57:12 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id i68so15843409qtb.5 for ; Tue, 26 May 2020 04:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c9TE7nYfL9/4yE3ktfUAA4RbfcJNfF3MgZw1H1chyQM=; b=fRhNs9QOVOZyJjroQE4YU2Oxa7vuvd8K9ZAG/l7Bl2HqhkkCS/fr3mR8h9s4jmfsir o8XQ2i9MM1i8YqsyLaIfQW+JCH+0Hc17KX/cQU+PABbqEz4IgBSxpnUTFiU6lpBdjZf3 kH8we7f7784bLeT7Gzw0f3Aklrcr/Dkh1KNM8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c9TE7nYfL9/4yE3ktfUAA4RbfcJNfF3MgZw1H1chyQM=; b=AWt90QWpHwfbnYSgHfHCZ7vQvMJCZxQFdg+VnufpB9AmRmHkhfNWIKMOjZ4vb1SaFd GiOnDgGiTY+l/uNEtKTKqpEYOla+YKwinH3vs+usVpRA1DyJ+0m5DadUKHRkwpdAMgqj AJxF3Q8EXwRop5JWzB3dgGNQDOgRRRbpOyj6SSxQVI/gthub2ffkCIS1Sj02AtOD5k8e WI+19m6h28YkDWvaKiGf5HU3NX2Z9eG0BiXNEfPxoxychhqExdo6YaeZ1MY7c+hwcTil 6ddTy3Y3qyptI/aIDx+XolHffm4DLofqZ8jy3Rq5TkVBPosqLixuQ07GHQPR66n9HJ92 +WNg== X-Gm-Message-State: AOAM5321yrLqmSDpri6maxLif82aYq13GuJ5GIBw6SgdNKatp9gg0Bmj Qo7obwlfHeI5dc44NfQhF7aMtQ== X-Google-Smtp-Source: ABdhPJxebkhmIiWjSFvlLOkpaIanVHu3kJ9zbWXca8zkkiVy47RALDbMWMPik2y1/UbSopvtPdBWgQ== X-Received: by 2002:aed:37e7:: with SMTP id j94mr798705qtb.57.1590494231216; Tue, 26 May 2020 04:57:11 -0700 (PDT) Received: from [192.168.1.64] (host86-190-124-160.range86-190.btcentralplus.com. [86.190.124.160]) by smtp.gmail.com with ESMTPSA id e34sm17214211qtb.21.2020.05.26.04.57.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 04:57:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Roy Arends In-Reply-To: <7df431dd-1f07-3817-dd40-27985a3d03fc@uniregistry.com> Date: Tue, 26 May 2020 12:57:08 +0100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <09DE113D-C660-447B-9CC1-C5790B2D5060@dnss.ec> References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> <7df431dd-1f07-3817-dd40-27985a3d03fc@uniregistry.com> To: Patrick Mevzek X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 11:57:15 -0000 Hi Partick > On 7 May 2020, at 19:40, Patrick Mevzek = wrote: >=20 > On 02/05/2020 09:09, Roy Arends wrote: >> Hi, >>=20 >> Ed and I just submitted a new version of our private-use TLD draft.=20= >>=20 >> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >=20 > While I do not have hard facts but just a gut feeling, I would feel > safer if "xn" is excluded from the possible list of private labels to = be > used in the DNS, as it is used for prefix of IDNs. That is a good point. I won=E2=80=99t go as far as excluding it, but I = will add a warning. >=20 > Some, probably buggy, software could match on "xn" instead of "xn--" = as > prefix to search for IDNs, and hence having "example.xn" could lead to > problems. I agree. >=20 >> This draft has substantial more information than the first draft. It = explains that a private-use namespace does not exist, why it is needed, = and how a namespace aligned with the user-assigned alpha-2 code elements = in the ISO-3166-1 standard can be used as private-use namespace. >>=20 >> It contains plenty of examples of how user-assigned code elements are = used in the field, including other ISO standards, the UN, UNICODE, = CAB/forum, and the IETF itself. >>=20 >> This new version came about after fruitful discussions with peers = inside and outside the IETF. Most discussions were productive. This has = lead to the removal of the advice/example to use ZZ, as it was = distracting from the point of the draft: these two-letter top level = domains are available for private-use.=20 >=20 > Thanks for the new draft version, the new content is useful indeed. Thanks Patrick. Warmly, Roy >=20 > --=20 > Patrick Mevzek >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue May 26 08:11:56 2020 Return-Path: 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 B01D13A03F7 for ; Tue, 26 May 2020 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 IkeA6ORMKhZ6 for ; Tue, 26 May 2020 08:08:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 6F0923A053E for ; Tue, 26 May 2020 08:06:29 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id 4959F14054A; Tue, 26 May 2020 17:06:27 +0200 (CEST) To: dnsop@ietf.org References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Cc: Roy Arends Message-ID: <2ed8bf72-565a-3e2c-0758-87f4a7935b88@nic.cz> Date: Tue, 26 May 2020 17:06:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 15:08:25 -0000 On 02. 05. 20 16:09, Roy Arends wrote: > Hi, > > Ed and I just submitted a new version of our private-use TLD draft. > > https://www.ietf.org/id/draft-arends-private-use-tld-01.txt > > This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace. I think this is clever hack and should be documented, thank you! Personally I'm bit torn because I've spent my whole professional career explaining people how bad idea it is to use non-delegated/non-unique names so I would really like to people from overusing this... Would you be willing to add at least one paragraph with caution? Something along lines "private TLD should be used as _option of last resort_", or more verbose "these special TLDs should be used only when other options, e.g. private subtree under a properly delegated name, were considered and refused." Thank you. -- Petr Å paÄek @ CZ.NIC From nobody Tue May 26 09:00:33 2020 Return-Path: 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 192893A0786 for ; Tue, 26 May 2020 09:00:29 -0700 (PDT) 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 b7IIm43DKJEh for ; Tue, 26 May 2020 09:00:26 -0700 (PDT) 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 5F79F3A077D for ; Tue, 26 May 2020 09:00:26 -0700 (PDT) Received: from PFE112-VA-2.pexch112.icann.org (out.east.pexch112.icann.org [162.216.194.10]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 04QG0OSJ027853 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 26 May 2020 16:00:24 GMT Received: from PMBX112-E1-VA-1.pexch112.icann.org (162.216.194.24) by PMBX112-E1-VA-2.pexch112.icann.org (162.216.194.26) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 May 2020 12:00:21 -0400 Received: from PMBX112-E1-VA-1.pexch112.icann.org ([162.216.194.24]) by PMBX112-E1-VA-1.PEXCH112.ICANN.ORG ([162.216.194.24]) with mapi id 15.00.1497.006; Tue, 26 May 2020 12:00:21 -0400 From: Roy Arends To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] new version submitted for draft-arends-private-use-tld Thread-Index: AQHWM3bCvfDKzd01v0+7fE/DFwrA/g== Date: Tue, 26 May 2020 16:00:21 +0000 Message-ID: References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> <2ed8bf72-565a-3e2c-0758-87f4a7935b88@nic.cz> In-Reply-To: <2ed8bf72-565a-3e2c-0758-87f4a7935b88@nic.cz> 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.47.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_C3AF375E-0A57-4145-A6DC-A24230F0ABC5"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-26_02:2020-05-26, 2020-05-26 signatures=0 Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 16:00:30 -0000 --Apple-Mail=_C3AF375E-0A57-4145-A6DC-A24230F0ABC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 May 2020, at 16:06, Petr =C5=A0pa=C4=8Dek = wrote: >=20 > On 02. 05. 20 16:09, Roy Arends wrote: >> Hi, >>=20 >> Ed and I just submitted a new version of our private-use TLD draft.=20= >>=20 >> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >>=20 >> This draft has substantial more information than the first draft. It = explains that a private-use namespace does not exist, why it is needed, = and how a namespace aligned with the user-assigned alpha-2 code elements = in the ISO-3166-1 standard can be used as private-use namespace. >=20 > I think this is clever hack and should be documented, thank you! Any time, thanks! > Personally I'm bit torn because I've spent my whole professional = career explaining people how bad idea it is to use = non-delegated/non-unique names so I would really like to people from = overusing this... >=20 > Would you be willing to add at least one paragraph with caution? = Something along lines "private TLD should be used as _option of last = resort_", or more verbose "these special TLDs should be used only when = other options, e.g. private subtree under a properly delegated name, = were considered and refused." I=E2=80=99m not sure about ranking different methods of deployment as = each has its own little idiosyncrasies that may be useful to the = deployment scenario. How about I add a section that details the additional complexities and = adds caution in using this specific method, such as =E2=80=9CUsing a = private use top level domain is not =E2=80=98more secure=E2=80=99 or = =E2=80=98more private=E2=80=99 than using a public domain; it requires = additional complexity in resolving and signing, etc, etc=E2=80=9D Does that work for you? Thanks, Roy >=20 > Thank you. >=20 > --=20 > Petr =C5=A0pa=C4=8Dek @ CZ.NIC >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_C3AF375E-0A57-4145-A6DC-A24230F0ABC5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Aw ggWaMIIEgqADAgECAhAC8rGsZZEVwDggOu7Mu2E3MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xOTAxMTcwMDAwMDBaFw0yMjAx MTcxMjAwMDBaMIG7MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUm95IEFyZW5kcyAoMjAxOTAxMTcpMSMwIQYJKoZI hvcNAQkBFhRyb3kuYXJlbmRzQGljYW5uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALIUjLA9qXUR1zgYOLSdC8rPQqrXJlVnshs8UWZfAu1Iwuj5jALoUWuvF+YWEBZZkgFuLbY5 ocPBgrnxv3l8rgCyoJMtf89edKCFOdHEsv+K3/9EG+gqlYm9GRg+cxqCq7WIPhbnawBOkSkpoT/J MxEMTIBLKEroumaZsM7XcY1vgr+vOxbBJ/+aO16BynB3/YbqR4zvQR8xOiPhfgl/Brg6fRtGm47h gU0DKrQ8MQqKaHhrWXjvQvnr0VzGnxANbjUK1ggVFXkIO4+7szB56Acp7ERrmxCYqYVK+7en9GNx IBnmN6lnERmvcfRyb0H8HPgWLkKH8BI4m/Zsko5JyP0CAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBSxk+GbMVrJevh7fdqWM6pZVXFyjTAMBgNV HRMBAf8EAjAAMB8GA1UdEQQYMBaBFHJveS5hcmVuZHNAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB5pbggxD+KqyTcLnhSvXAI 0f3pRnss8vUiAuNM1coPPDTPa3O8z9mPKFYCzIiZ7yUcSFHwJGzmvpYHCm7cy7yhG9YKDl6TBgAi tbBMQa1WJ1bPViAMQrxVPVXZ2xJO8mWRGZzK/64r2+azahVS9c0Szu73LSgJReoTraJnZqYUfRlF Uvz+e1XA3ClFmcXTH2ufUQsMhQ94f2j5p2WZtNDBAKkVBQYw2zrVn9doNSMQGfDg5eNJrj1iRo0g sVAvVlgsTlt/wuWnEnz4D491ToWE/biLxS3DL7DrqWgixBid3MFpz575Xdg1mBFFSXCs8vQItF2p Ebs5HeLkGxdhkY6/MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAykwggMlAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAC8rGsZZEVwDggOu7Mu2E3MA0G CWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0yMDA1MjYxNjAwMjBaMC8GCSqGSIb3DQEJBDEiBCDq3CezSHwVhN/tBPOCyhMRA18rNENk28jP zuKEJalWFzCBiAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl cnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7YTcwgYoGCyqGSIb3DQEJEAILMXugeTBlMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEALysaxlkRXAOCA67sy7 YTcwDQYJKoZIhvcNAQEBBQAEggEAanFDJxRZXL79YAeh5MV/3EbdgllDD7xkow3HruDztbIcYJDn KutAS4+AQrqn6fySuHl01wjxROO68zrmWz80i+L0jUthDHGRLAw8HjAj8l00g5VP+9hGmCf7y3KY PNqyU+dyK/mtHF2ABW+4BNm42uBqDfmyN24c8qrU6hH6siJrApcGdKWOHtvYTve/bpLiSAzuV5Al iZtSk4Vd+k5E/aM9ZBQRt/G81n4vgtqFwSgUMm8KEU2MtU3PzurI+4MLmRYYjgNASTQ1oK58H2Jv N6zpjMJEnnBKh2hxkJtGobaAHLktEW5UuLni0kXh4OljglcwS2l67zuuCziJGEF19QAAAAAAAA== --Apple-Mail=_C3AF375E-0A57-4145-A6DC-A24230F0ABC5-- From nobody Tue May 26 09:08:00 2020 Return-Path: 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 198243A0916 for ; Tue, 26 May 2020 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 PvhBi1u8TAjd for ; Tue, 26 May 2020 09:06:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 6C9633A0A36 for ; Tue, 26 May 2020 09:05:38 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id 29AD613FCA3; Tue, 26 May 2020 18:05:36 +0200 (CEST) To: Roy Arends Cc: "dnsop@ietf.org" References: <91A33B60-7B70-4231-8ED8-662CFBB70445@icann.org> <2ed8bf72-565a-3e2c-0758-87f4a7935b88@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: Date: Tue, 26 May 2020 18:05:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 16:06:29 -0000 On 26. 05. 20 18:00, Roy Arends wrote: > >> On 26 May 2020, at 16:06, Petr Å paÄek wrote: >> >> On 02. 05. 20 16:09, Roy Arends wrote: >>> Hi, >>> >>> Ed and I just submitted a new version of our private-use TLD draft. >>> >>> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >>> >>> This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace. >> >> I think this is clever hack and should be documented, thank you! > > Any time, thanks! > >> Personally I'm bit torn because I've spent my whole professional career explaining people how bad idea it is to use non-delegated/non-unique names so I would really like to people from overusing this... >> >> Would you be willing to add at least one paragraph with caution? Something along lines "private TLD should be used as _option of last resort_", or more verbose "these special TLDs should be used only when other options, e.g. private subtree under a properly delegated name, were considered and refused." > > I’m not sure about ranking different methods of deployment as each has its own little idiosyncrasies that may be useful to the deployment scenario. > > How about I add a section that details the additional complexities and adds caution in using this specific method, such as “Using a private use top level domain is not ‘more secure’ or ‘more private’ than using a public domain; it requires additional complexity in resolving and signing, etc, etc†> > Does that work for you? Yes, that would be ideal, I just did not want to delve into details so much. Basically the message I wanted to convey is "usually it is less work and more robust to use a delegated name instead of your own TLD". If you want to add longer explanation I'm happy to review it! -- Petr Å paÄek @ CZ.NIC From nobody Tue May 26 12:43:44 2020 Return-Path: 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 34C843A0F86 for ; Tue, 26 May 2020 12:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xZfenH3ibYN5 for ; Tue, 26 May 2020 12:43:41 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 C131B3A0F85 for ; Tue, 26 May 2020 12:43:40 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id q11so9527920wrp.3 for ; Tue, 26 May 2020 12:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=t2zPbXOf7zhBnr3Js3qWazvOxjlqnIbh1OLWCuymAe0=; b=MRxv+ATvIu41vhEE+NpwB1VOq/Okr6TqqZqORHkHQQQrjmCENx+9MwAKXQu0GRIZqX lfgntz77VKD2q9hAZIONZK3/WLtKlrjzOJq/I9ssL+MQ71zw1juBlK2s81DbReeZBOwp vBXsDuB5OkDhC/2LeJUeru7iJSkZwLIVVepwvKTq8gNNOtZit6uo02GO7kbnh9oZ15aD jFgktRNPX/qoQYfHcxLFRmJKVpHmGk9sNo7n8B+s/rE2h1pEPc2xHPFbyzvab6SuP4PX qdc7XlSgG7oaLKCHRGA/tUHR5K5vayZ06vexDLbDAli1FQJTycgjQwq17Z/ikS78BVgY cxJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t2zPbXOf7zhBnr3Js3qWazvOxjlqnIbh1OLWCuymAe0=; b=Y9dIIlpjqDNQ57Tfb5qfyZ2bp1JbK38GNwf1dSMuyDmHyQ/6b5m5Q3pDyyrsPHP8b9 sKcC5mBGIWEagzHeaBmXvXeab7qGNv5AAZHP5YiLxhEAzSxEtmXJBIMkxY9a5VFtwv5V V6KhpYtzAu+qyt/Dwu5sWSjy47VIJi9PXOmaGRm+fUygG+Fm0FggxPVRSS8hQj5uYOiD xfS79vIdoyPHsT1ui1tDGg+GraZRG95srFSw3aDg0CwhgrLh6Qaz3DEgEzWVKRY522rj jTSuk+KSL9sgKXSdnr/zkb7pD1T/fC2nbbP/m7EOWWsE+gdHzKVZXzFdIFaxzZuc6Gw9 YwsA== X-Gm-Message-State: AOAM533bl5XFG4glHRNCpfM6/Fd2h0j7PQILqjaQqcoe7ohvq3KEHGUv Wkkdqc240CoNUiQFo1ZQCA2tW5i49BXxQD9Ye4PTttgp X-Google-Smtp-Source: ABdhPJxbgADxl3LNp+Vkh24iSHEEDescdzqxYdrkYdr5lWjZ4oqdU1MCOs/wRFr7+fGpuv8eebGUXysi1+GATpXP4Ug= X-Received: by 2002:adf:ab4e:: with SMTP id r14mr10645684wrc.147.1590522218666; Tue, 26 May 2020 12:43:38 -0700 (PDT) MIME-Version: 1.0 From: Eric Orth Date: Tue, 26 May 2020 15:43:27 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="000000000000da7dd305a6924fa8" Archived-At: Subject: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 19:43:42 -0000 --000000000000da7dd305a6924fa8 Content-Type: text/plain; charset="UTF-8" One of my colleagues recently brought up the idea of suggesting recursives add additional HTTPSSVC records into responses for A/AAAA queries as a way to make HTTPSSVC more available for cases where a stub is hesitant to make additional queries out of concern for bad behavior from bad middleboxes (a frequent concern for Chrome when not using DoH). My initial impression is that it's not a reasonable idea, but I wanted to bring it here to DNSOP in case anybody has further ideas to make it workable. So any relevant thoughts or concerns from anybody here? The obvious problems I could think of (all basically along the theme of it not being ideal when the stub might not even care about HTTPSSVC): - Performance implications if the recursive has to retrieve HTTPSSVC or follow alias chains. Maybe not as bad if only done opportunistically when the recursive happens to already have everything in cache. - Polluting DNS for non-browsers. Maybe not as bad if SVCB instead of HTTPSSVC, but this would likely only be of use for web browsers which are obviously not the only queryers of A/AAAA. - Could lead to lots of unnecessary truncation, especially for large records containing ESNI data. --000000000000da7dd305a6924fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of my colleagues recently brought up the idea of sugge= sting recursives add additional HTTPSSVC records into responses for A/AAAA = queries as a way to make HTTPSSVC more available for cases where a stub is = hesitant to make additional queries out of concern for bad behavior from ba= d middleboxes (a frequent concern for Chrome when not using DoH).=C2=A0 My = initial impression is that it's not a reasonable idea, but I wanted to = bring it here to DNSOP in case anybody has further ideas to make it workabl= e.=C2=A0 So any relevant thoughts or concerns from anybody here?

The obvious problems I could think of (all basically along the the= me of it not being ideal when the stub might not even care about HTTPSSVC):=
  • Performance implications if the recursive=C2=A0has to re= trieve HTTPSSVC or follow alias chains.=C2=A0 Maybe not as bad if=C2=A0only= done opportunistically=C2=A0when the recursive=C2=A0happens to already hav= e everything in cache.
  • Polluting DNS for non-browsers.=C2=A0 Maybe = not as bad if SVCB instead of HTTPSSVC, but this would likely only be of us= e for web browsers which are obviously not the only queryers=C2=A0of A/AAAA= .
  • Could lead to lots of unnecessary truncation, especially for larg= e records containing ESNI data.
--000000000000da7dd305a6924fa8-- From nobody Tue May 26 16:05:42 2020 Return-Path: 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 D54F53A0B82 for ; Tue, 26 May 2020 16:05:40 -0700 (PDT) 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 u9fNwVwRNLHg for ; Tue, 26 May 2020 16:05:38 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF973A0B81 for ; Tue, 26 May 2020 16:05:38 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D49C1B074A; Tue, 26 May 2020 23:05:35 +0000 (UTC) From: Paul Vixie To: dnsop Cc: Eric Orth Date: Tue, 26 May 2020 23:05:34 +0000 Message-ID: <1852098.ajqZCkXiOD@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 23:05:41 -0000 On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote: > One of my colleagues recently brought up the idea of suggesting recursives > add additional HTTPSSVC records into responses for A/AAAA queries as a way > to make HTTPSSVC more available for cases where a stub is hesitant to make > additional queries out of concern for bad behavior from bad middleboxes (a > frequent concern for Chrome when not using DoH). My initial impression is > that it's not a reasonable idea, but I wanted to bring it here to DNSOP in > case anybody has further ideas to make it workable. So any relevant > thoughts or concerns from anybody here? proposals exist going way back to add AAAA to additional data for answers of type A, and to add A to additional data for answers of type AAAA. this is not different from adding A and AAAA to additional data for answers of MX and SRV, which already happens. your proposal fits the same mold, which is that the spec neither requires nor prohibits it. however, the client API likely does not have a way to benefit from the additional data in a stub response. see getdnsapi.net for a representative example of something that can only tell you answers to the question you asked, even if it knows more, and won't keep the response in state just in case your next question could also be answered by it. getdnsapi has a return_both_v4_and_v6 extension but would need another API change to support HTTPSSVC. for SMTP senders to benefit from the additional AAAA/A data in MX answers, they have to call a lower level API such as res_nsend() and then walk through the response to see what they actually got, in hopes of not needing to make a second query for addresses (or a second and third, if V6 and V4 are available.) so, this way lies madness, and the solution we see most often is a host-level cache of DNS results. the old INN (usenet net news) server had one of these, and all modern browsers have one. many of us simply run a validating iterative caching recursive resolver on our hosts, since it's not much code by modern standards. but in all such cases we don't have a good way to retrieve more than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not well defined and is broadly unimplemented. various other multiple-questions proposals have been made but nothing gets traction. > The obvious problems I could think of (all basically along the theme of it > not being ideal when the stub might not even care about HTTPSSVC): > > - Performance implications if the recursive has to retrieve HTTPSSVC or > follow alias chains. Maybe not as bad if only done opportunistically > when the recursive happens to already have everything in cache. > - Polluting DNS for non-browsers. Maybe not as bad if SVCB instead of > HTTPSSVC, but this would likely only be of use for web browsers which are > obviously not the only queryers of A/AAAA. > - Could lead to lots of unnecessary truncation, especially for large > records containing ESNI data. your self-criticisms are all valid in my opinion. however, i think it would be fine to recommend in the HTTPSSVC draft that the necessary subsidiary data like AAAA or A or SVCB all be sent, both in authoritative and non- authoritative responses, when the qtype is HTTPSSVC and the responder knows the additional data (that is, it should not make extra queries to find it just for additional data reasons.) this will push UDP/53 DNS into either TCP/53 DNS (via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or even TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ). long answers are our future. if this data is going to be nec'y to make the primary answer useful, then pre-seeding it is a net good. some day our descendants will break the tyranny of MTU 1500, and thank us for any prework that brought the data their apps needed closer and with fewer round trips. -- Paul From nobody Tue May 26 16:56:48 2020 Return-Path: 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 50C483A0BED for ; Tue, 26 May 2020 16:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5pmhBQxU4FpL for ; Tue, 26 May 2020 16:56:44 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 4B7443A0BEE for ; Tue, 26 May 2020 16:56:44 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id h4so1343708wmb.4 for ; Tue, 26 May 2020 16:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tIcX9X7NrQad5eOy0BS9UUmbZoDiv++d1L7TZQaP6ps=; b=aAUIBbm3zceWFzzTLjiJoZn4AkZDrF/8vzZGShJvPZKwdsZdto62Ib8nMbg6d3g8dE ISBFzA2tJMvVxpGynqdoXNifSzYHeRpvWHuDf9QiziiKNEt/LGF5j0UTfaY/jp1pf8ZB 61o+GWdRwRc7M77Eu7JdkzJkQHAi5ZdjvcnOmrdO4MwwepJbZhgyh719jrwbR4nfu2rK gpY/NH1nlYkpobIv84XugshKju05nPkZ58kc+jrBvYlotqY/n1p0+Wmm/4fn6wiYnDeV Yk5p5hCTK5gh15m+KKu/Bq7EAduYBTVb+93MTWeeLG6yc8YDsFnJujpZCu1n+oEOXqFf +eoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tIcX9X7NrQad5eOy0BS9UUmbZoDiv++d1L7TZQaP6ps=; b=I0DQiMQc6N/OKCDhkXlc+ui65CXE5p2+EV5cRpqRFwYG9TxIDqTjJb0zX4dRksLw/V fPmp+PJfh9/zfYy5phS51o4wfsKZdfTPulPbUjyBZTZSzpypdlP76OjZDiTSTnBkxV4N /YVZFnmfbe8+VRZkfFK2ggWf3Sw11WLGk5bAIk3rLj1iNZWtl27DN7DNlFCcOZ56JVgL St1m2Ij1bCRZ8Md6RbXKu1DBW2cIWkwfCIvtPy6WhTxu+zUliRiRyBVmfojHivNjx/eF +a17yfRPIMVANy+ISqAlA+H67mTdn3hxECOzjioes/1U3J//F0HszI2jwtxcfI78wlvV hiPg== X-Gm-Message-State: AOAM533U0A9w90vD6UGVy6AlNVP2x2d0BIZJjnOhDcNm+nWI8hWpQ9fF SpsykYl7ALo+Xo5LmAC88fMh7Mz3oVzaPgYnrQ8/OBq2OAuqIQ== X-Google-Smtp-Source: ABdhPJy7P5TIVg/SZyf4HI8292oQs94tTghBUzYgOmpKRh4ccPmNEN9Q2Z9JLjSgOD5gWI6WllcN7bXw/L1Mj+k0yqQ= X-Received: by 2002:a1c:7714:: with SMTP id t20mr1428618wmi.132.1590537402408; Tue, 26 May 2020 16:56:42 -0700 (PDT) MIME-Version: 1.0 References: <1852098.ajqZCkXiOD@linux-9daj> In-Reply-To: <1852098.ajqZCkXiOD@linux-9daj> From: Ben Schwartz Date: Tue, 26 May 2020 19:56:30 -0400 Message-ID: To: Paul Vixie Cc: dnsop , Eric Orth Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e67f5e05a695d8e9" Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 23:56:47 -0000 --000000000000e67f5e05a695d8e9 Content-Type: multipart/alternative; boundary="000000000000dfc0c705a695d8c0" --000000000000dfc0c705a695d8c0 Content-Type: text/plain; charset="UTF-8" On Tue, May 26, 2020 at 7:06 PM Paul Vixie wrote: ... > however, i think it would be > fine to recommend in the HTTPSSVC draft that the necessary subsidiary data > like AAAA or A or SVCB all be sent, both in authoritative and non- > authoritative responses, when the qtype is HTTPSSVC FWIW, this is pretty much what the HTTPSSVC draft currently says. and the responder knows > the additional data (that is, it should not make extra queries to find it > just > for additional data reasons.) The current text does not have this caveat: it recommends that the recursive perform those extra queries before replying, because they will otherwise have to be performed by the client at higher cost. However, it also says "recursive resolvers MAY ... produce a reply that omits some of the associated RRSets ... when responding before fully chasing dependencies would improve performance", so a compliant recursive resolver could certainly implement the behavior you're describing. --000000000000dfc0c705a695d8c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 26, 2020 at 7:06 PM Paul = Vixie <paul@redbarn.org> wrot= e:
...
however, i think it would be
fine to recommend in the HTTPSSVC draft that the necessary subsidiary data =
like AAAA or A or SVCB all be sent, both in authoritative and non-
authoritative responses, when the qtype is HTTPSSVC

FWIW, this is pretty much what the HTTPSSVC draft currently says.<= /div>

and = the responder knows
the additional data (that is, it should not make extra queries to find it j= ust
for additional data reasons.)

The current t= ext does not have this caveat: it recommends that the recursive perform tho= se extra queries before replying, because they will otherwise have to be pe= rformed by the client at higher cost.=C2=A0 However, it also says "rec= ursive resolvers MAY ... produce a reply that omits some of the associated = RRSets ... when responding before fully chasing dependencies would improve = performance", so a compliant recursive=C2=A0resolver could certainly i= mplement the behavior you're describing.
--000000000000dfc0c705a695d8c0-- --000000000000e67f5e05a695d8e9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCBMV0ikCDvMkjq2g4RZgOLDj+b0vNdyzHwTAv8/ksCNLTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjYyMzU2NDJaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAtU9o5ccg/lnQRRQKYgc8RkDQe9Exp0xvEWjZEbzRZ8qXNPbbqZtX600pmk0hIS5FmJnp7h+l BWWMLijdijNsERg5M5PcyOlXUgdCffVXP2FnX7UrvLoAG/d9g9aBL9iKuuUJqWw4Rfl0TAr8XFBs eh1ekcDCZWOsAIqXTsa2ZvoabtqA1rBATslvkLEW8RQ2rgMhGOBBW+30Zwg5RespXJK0TRUid3w8 yOOEy9Lc/2nKConucGlVGpQ956QRUD7xazvSv5Jd7fjDG/URFfFgIQm8F76rT0b9X0WdMwhVQWsV G0ArwfGt6BlHXB/QyrwS4oo3JZ/UuUwWy9IxRWAnCA== --000000000000e67f5e05a695d8e9-- From nobody Tue May 26 17:00:40 2020 Return-Path: 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 C34783A0BED for ; Tue, 26 May 2020 17:00:22 -0700 (PDT) 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 plWxjMkOM-3K for ; Tue, 26 May 2020 17:00:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131133A0BDA for ; Tue, 26 May 2020 17:00:21 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C18BCB074A; Wed, 27 May 2020 00:00:19 +0000 (UTC) From: Paul Vixie To: Ben Schwartz Cc: dnsop , Eric Orth Date: Wed, 27 May 2020 00:00:19 +0000 Message-ID: <1687531.9LHNgfQPbD@linux-9daj> Organization: none In-Reply-To: References: <1852098.ajqZCkXiOD@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 00:00:23 -0000 On Tuesday, 26 May 2020 23:56:30 UTC Ben Schwartz wrote: > On Tue, May 26, 2020 at 7:06 PM Paul Vixie wrote: > ... > > > and the responder knows > > the additional data (that is, it should not make extra queries to find it > > just > > for additional data reasons.) > > The current text does not have this caveat: it recommends that the > recursive perform those extra queries before replying, because they will > otherwise have to be performed by the client at higher cost. i think that's overly prescriptive. the client may already have the data in private cache from its prior work, or it may be striping its DNS queries across several full resolvers and therefore able to get the data faster if you don't provide it than if you take the time to fetch it before you answer. > However, it > also says "recursive resolvers MAY ... produce a reply that omits some of > the associated RRSets ... when responding before fully chasing dependencies > would improve performance", so a compliant recursive resolver could > certainly implement the behavior you're describing. nice. that's all the rope i'd ask for. -- Paul From nobody Tue May 26 17:18:24 2020 Return-Path: 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 E3A853A0C06; Tue, 26 May 2020 17:18:19 -0700 (PDT) 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 CGbkYdLKS9D7; Tue, 26 May 2020 17:18:18 -0700 (PDT) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 9F35B3A0C09; Tue, 26 May 2020 17:18:18 -0700 (PDT) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 04R0IGhH002621 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 May 2020 00:18:16 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; Tue, 26 May 2020 17:18:14 -0700 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; Tue, 26 May 2020 17:18:14 -0700 From: Paul Hoffman To: Eric Orth CC: dnsop Thread-Topic: [Ext] [DNSOP] unsolicited HTTPSSVC responses Thread-Index: AQHWM5X9HzEeCY3iOkiY+OokM0NOl6i7hsuA Date: Wed, 27 May 2020 00:18:14 +0000 Message-ID: References: In-Reply-To: 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=_EF4CB064-F83E-45BD-845F-6BCDFA3B76DD"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-26_02:2020-05-26, 2020-05-26 signatures=0 Archived-At: Subject: Re: [DNSOP] [Ext] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 00:18:20 -0000 --Apple-Mail=_EF4CB064-F83E-45BD-845F-6BCDFA3B76DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 26, 2020, at 12:43 PM, Eric Orth = wrote: > One of my colleagues recently brought up the idea of suggesting = recursives add additional HTTPSSVC records into responses for A/AAAA = queries Add where in the response? In the Answer section or in the Additional = section? The semantics and usefulness are wildly different for those = two. --Paul Hoffman= --Apple-Mail=_EF4CB064-F83E-45BD-845F-6BCDFA3B76DD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNTI3MDAxODEzWjAvBgkqhkiG9w0BCQQxIgQgW1lWxVKC3bjiS0+GuQJ27FmKv7Vd QHAL3NZlNI1WgzcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAGK44YlZjSChopAmazYSXEMF2/bIXc4588xqBvt7L58U g+8/qLwi33vHSBH0dAsB2w3GrGfvjRVLgl+iS2cFqVpyqFIn7H33qnHOsmdKM322Wgmg4VD6fqH8 yiFEc5qBE/WijF43nlEQMb6pFEpAgf5sfy3Mcoc6/65NVdAGPVaqW8sEfx/1iXZb94fMW6PFIwHy OZrS524IiU+h3NAzADjf0nWaz1szDxW8ZcZD7EsCc6SMLLam0eUsAx7cctyRKDIKAndfS7J2pBso cVTxfqeXwT7XfgYrrf/Ms1qbHE0Y2Af8NIkocm+ppE8Pwu1gd2Kyd3FwEfW8iH5mkskX+wwAAAAA AAA= --Apple-Mail=_EF4CB064-F83E-45BD-845F-6BCDFA3B76DD-- From nobody Tue May 26 23:34:05 2020 Return-Path: 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 7757D3A078A for ; Tue, 26 May 2020 23:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8EkOG6hbNJof for ; Tue, 26 May 2020 23:34:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 DB9F43A05A4 for ; Tue, 26 May 2020 23:34:00 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id 66AEF14056C for ; Wed, 27 May 2020 08:33:57 +0200 (CEST) To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: Date: Wed, 27 May 2020 08:33:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <1852098.ajqZCkXiOD@linux-9daj> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 06:34:04 -0000 On 27. 05. 20 1:05, Paul Vixie wrote: > so, this way lies madness, and the solution we see most often is a host-level > cache of DNS results. the old INN (usenet net news) server had one of these, > and all modern browsers have one. many of us simply run a validating iterative > caching recursive resolver on our hosts, since it's not much code by modern > standards. but in all such cases we don't have a good way to retrieve more > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not > well defined and is broadly unimplemented. various other multiple-questions > proposals have been made but nothing gets traction. I would much rather spent time on https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 That would bring benefit to broader set of clients and has advantage that server does not send back data nobody asked for (thus wasting resources on unnecessary work). I feel that nowadays web browsers have better communication with OS vendors/stub resolvers (Android and Chrome come to mind). Can we stub resolvers on board, pretty please? -- Petr Å paÄek @ CZ.NIC From nobody Wed May 27 01:30:38 2020 Return-Path: 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 44E283A0B68 for ; Wed, 27 May 2020 01:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=portfast.net 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 5YfTmlvcXGYb for ; Wed, 27 May 2020 01:30:35 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 06D8B3A0B69 for ; Wed, 27 May 2020 01:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lwJ+kxsEsV+TWQbX/pQwzU3OrI9DBccZBlQvoqo6c0Q=; b=gDjEOmgBMOkMTOTNYfBfmQqOmR k1jXiDONgwh5omePmft+X0pE3GfsY/JZn7fu5gIKgdt09XA1FGdV+EFqGuhC8ZNoeGF9JtfgdSWnW Hz6LAeqb7tCI/bkYCz1HlyAKIgwULGNuMk4kjYsY9v1yE8DrCDQQE3whT6c7xuEd6xfQ=; Received: from [88.212.170.130] (port=60689 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jdrSK-0008BV-8E (Exim 4.89) for dnsop@ietf.org (return-path ); Wed, 27 May 2020 09:30:32 +0100 To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> From: Ray Bellis Autocrypt: addr=ray@bellis.me.uk; keydata= mQENBFvQpEEBCADBbsjhl44JARZXZoAZXoAxsd/227/ItxFHmo+cogL0qhIvn1F++OozY3mR S6ut5iuI1XMGCz2/ewqfp43k2f+o9DxjIBEqKA+M1hg8ivBMWD8//yo8S80DT2Y6GmLnRz64 sRpw0Z3LcmKULKKDU3lD9Uo05s8c2xUzJTxwxFfpjqA108nEemGnu549qV38Jz1OeuD+7P4R 3du97DyaaW5gyj/ggtiQxQtkbHG9aFRn0ASGON0uu49vRxaeuKwaGExb6FWYXJJSQLScfJ3i 356RdwaO/KezCGAhRiJ06AbPTxq2j9cvnShVb1IsxXQn73JgHVsPKDjdYo98ePWYuHWPABEB AAG0HVJheSBCZWxsaXMgPHJheUBiZWxsaXMubWUudWs+iQFUBBMBCAA+AhsDBQsJCAcCBhUK CQgLAgQWAgMBAh4BAheAFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0P8ACgkQ lD9Tw3qX+kJ+MwgAoW1eeAyyDqykaFO+N9XWMcQeFQamm1hWhjNRCOFuygycbwAe0oJPYn+i VsDoooJ/5zoHPdRV6boG8jEq8JcFwNHd5AXBPpAY9VA44ro83K7BSLMQRSfXB/OXCf5uSpb7 6DZQzem3wFys5g4bYqdSzFRiN42SjhSNxyi8KGrcEpqHgrnOBLUh+aPUgcTeFd3Dwxa21Hb/ qpOZvlKwQ7XjnAA6sMqPOmVJF4bg9D5Jg1jUOexPmwtZ1HN1wbpPZWqy3nGPXaHxHCVBp08M 7ZAIKf4QTVXcHbNxLwZtFO0TU7SK35xhzx4oy3faQIVh8K+CUMPQGU8TA3o78SefoPI8DrkB DQRb0KRXAQgAvveTWC0LkjJ2qTJcYqu0ksRKY44UCHyBNy+SfylH7cGd3FTG5qgPnOAhRAfP p7q+rxAep2adQCY4odd0CWQpmg3KhBf1qARW4HqUKMjff8+Gv7YZTiolsH+P8qQamCNemhSa 8+/vsY0roS25ZWHaHDVSIyyvHU6MsDVX8Z1nc1PwNUEqZST3I5ERVUWY/SQOTJp3fVeaU1Mo X3Bmk+7ugmUfb8Ztr63Fv3OrdEVk4ivHD8KP5c49UD9yTsVksfHqV2LN6/zdTU0CvW4SIEtX f7xQNG/o2/J50yW4e7g59ElYQZJxCjJwKusIV61aAmCe3OLLN05Kp23RrX4AwY26ewARAQAB iQE8BBgBCAAmAhsMFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0OkACgkQlD9T w3qX+kKHIggAncjGFT/LRZncAnX1IBwJfqzOzYWLOG4QHPMoHkaxrb+q3GAHXd6RAWgc8UIR fLJDowI1f2oMXh/PvqZkiVdy0qNPwhNP+i7r8OE8Co3Q1VA9Cw3Ysj2UGF5TQ2cF36XjuH9H uMp8Qy0k3lmHZgf7E/hu8u+O3AoBFG5FQ61fJjKTBazRqZmyxcbVyHHAVoAbOYJU+Mb3vfmy UlDa0FHxLHI6+pYEe7IQxzv22lGzdSgr7oVJnAz2V9sodeB2ALs+Jjh2kR0+SVPg+ED+zXWe p5alounzwhu2brS/vAJwXQXSb1R/65L4HliZk4poaC7UxC+6j0Fu7ICZa2IR9JpNnA== Message-ID: <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> Date: Wed, 27 May 2020 09:30:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 08:30:37 -0000 On 27/05/2020 07:33, Petr Å paÄek wrote: > I would much rather spent time on > https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 > > That would bring benefit to broader set of clients and has advantage > that server does not send back data nobody asked for (thus wasting > resources on unnecessary work). I'd be very happy to revive that work if there's interest. Ray From nobody Wed May 27 09:07:30 2020 Return-Path: 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 EE2413A0F02 for ; Wed, 27 May 2020 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 07_pi7FISiED for ; Wed, 27 May 2020 09:07:19 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 D718F3A0EFC for ; Wed, 27 May 2020 09:07:18 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id s8so24512795wrt.9 for ; Wed, 27 May 2020 09:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2iPTOCcpZ653vNvnoLt1+NEqNIJnPGkx7HfTpZJ2tOY=; b=sQp/hYtiq76Exalu4iFljVrzY/hpWIzyhA7TFdAE4tLJN104XjEC1A+sChfdTfyoMa n0734vYJcCvE3aV6zVMAxrVJob0Tlpx9jqJ7OrDQkFHv9rRZgOkTi8prE82uvctzWvlP 07RAYM6PmyE58Z/KcbYQ3WZ81h9p2VuMi6Rzq6TXn+1yvskIhYEfQpS9I5IhOPbq47q2 jIrhfGB6LEaA0IkZfKgStO1I9K+0o8y7pYiUcEWi88sWQZzXCV3sSr6qCx+D1mDOEbCP dCgWPQw9oQARKTNAGbCXt7gxS5LvR+kPfuNo4FWXaXiXH9NsEgLH2mKOjJRsy59n/5BJ V6Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2iPTOCcpZ653vNvnoLt1+NEqNIJnPGkx7HfTpZJ2tOY=; b=m/IvrFy1bqawDFsNsuePU9atbraDWkLjTv4xEtQ3sCwwnRQOFVJeRPN27UIpdm5KTC 8z92edPTHaA1C03zPD6ketS2IeFyNQMzml8jKXFooU+EgSwOr1++hcCtkebzfbOgos15 Kz380Dh8gC+nYadJriNN/9kG7qN8SrbmA/HIK1Hh/TcA8ZvOOUOgurcxA48HCBCaiavr bUNjYWau+UQB1y8CBJuY4Ef5MIuBS4uyXmp7OIZ/YlDn6bGmzgYDa91nzMESzfnasArr qt04ZDUoyinS9r8VszcRk8/F/O1He9kC0wQJsU1mJCia54RjD1TjlCOdQX883EQJeYQm CCeQ== X-Gm-Message-State: AOAM533pRy+8Q0g2qJMv2Yzp/KG4LLa9qjyEFTVHLyuRUMMtje9fQTFW syvc0uiaeee5TOvPXL/9dOmV+vvYM1prc5Z37FpdHGL0 X-Google-Smtp-Source: ABdhPJwh3krSdtNXHtdGxwtnOblmGosQQABxMx+EeZYZ9/9lsVZcODHtq1jN3enR8bFHn7AmLylTZDWm4IMPNIBOGLg= X-Received: by 2002:adf:e64b:: with SMTP id b11mr24535693wrn.402.1590595636971; Wed, 27 May 2020 09:07:16 -0700 (PDT) MIME-Version: 1.0 References: <1852098.ajqZCkXiOD@linux-9daj> In-Reply-To: <1852098.ajqZCkXiOD@linux-9daj> From: Eric Orth Date: Wed, 27 May 2020 12:07:06 -0400 Message-ID: To: Paul Vixie Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000ecc88c05a6a36730" Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 16:07:29 -0000 --000000000000ecc88c05a6a36730 Content-Type: text/plain; charset="UTF-8" On Tue, May 26, 2020 at 7:05 PM Paul Vixie wrote: > On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote: > > One of my colleagues recently brought up the idea of suggesting > recursives > > add additional HTTPSSVC records into responses for A/AAAA queries as a > way > > to make HTTPSSVC more available for cases where a stub is hesitant to > make > > additional queries out of concern for bad behavior from bad middleboxes > (a > > frequent concern for Chrome when not using DoH). My initial impression > is > > that it's not a reasonable idea, but I wanted to bring it here to DNSOP > in > > case anybody has further ideas to make it workable. So any relevant > > thoughts or concerns from anybody here? > > proposals exist going way back to add AAAA to additional data for answers > of > type A, and to add A to additional data for answers of type AAAA. this is > not > different from adding A and AAAA to additional data for answers of MX and > SRV, > which already happens. your proposal fits the same mold, which is that the > spec neither requires nor prohibits it. however, the client API likely > does > not have a way to benefit from the additional data in a stub response. Not a blocking concern for Chrome because in many cases it uses a built-in stub resolver that could easily read anything it wants out of the responses. But it certainly limits whether or not we would try to convince recursive operators to do this if it is likely to only be of benefit to Chrome. Also exacerbates all the concerns around things not being ideal if the stub is not going to use the HTTPSSVC if even less stubs are able to use it. > see > getdnsapi.net for a representative example of something that can only > tell you > answers to the question you asked, even if it knows more, and won't keep > the > response in state just in case your next question could also be answered > by > it. getdnsapi has a return_both_v4_and_v6 extension but would need another > API > change to support HTTPSSVC. > > for SMTP senders to benefit from the additional AAAA/A data in MX answers, > they have to call a lower level API such as res_nsend() and then walk > through > the response to see what they actually got, in hopes of not needing to > make a > second query for addresses (or a second and third, if V6 and V4 are > available.) > > so, this way lies madness, and the solution we see most often is a > host-level > cache of DNS results. the old INN (usenet net news) server had one of > these, > and all modern browsers have one. many of us simply run a validating > iterative > caching recursive resolver on our hosts, since it's not much code by > modern > standards. but in all such cases we don't have a good way to retrieve more > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is > not > well defined and is broadly unimplemented. various other > multiple-questions > proposals have been made but nothing gets traction. > > > The obvious problems I could think of (all basically along the theme of > it > > not being ideal when the stub might not even care about HTTPSSVC): > > > > - Performance implications if the recursive has to retrieve HTTPSSVC > or > > follow alias chains. Maybe not as bad if only done opportunistically > > when the recursive happens to already have everything in cache. > > - Polluting DNS for non-browsers. Maybe not as bad if SVCB instead of > > HTTPSSVC, but this would likely only be of use for web browsers which > are > > obviously not the only queryers of A/AAAA. > > - Could lead to lots of unnecessary truncation, especially for large > > records containing ESNI data. > > your self-criticisms are all valid in my opinion. however, i think it > would be > fine to recommend in the HTTPSSVC draft that the necessary subsidiary data > like AAAA or A or SVCB all be sent, both in authoritative and non- > authoritative responses, when the qtype is HTTPSSVC and the responder > knows > the additional data (that is, it should not make extra queries to find it > just > for additional data reasons.) this will push UDP/53 DNS into either TCP/53 > DNS > (via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or > even > TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ). > > long answers are our future. if this data is going to be nec'y to make the > primary answer useful, then pre-seeding it is a net good. some day our > descendants will break the tyranny of MTU 1500, and thank us for any > prework > that brought the data their apps needed closer and with fewer round trips. > > -- > Paul > > > --000000000000ecc88c05a6a36730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 26, 2020 at 7:05 PM Paul = Vixie <paul@redbarn.org> wrot= e:
On Tuesday, 2= 6 May 2020 19:43:27 UTC Eric Orth wrote:
> One of my colleagues recently brought up the idea of suggesting recurs= ives
> add additional HTTPSSVC records into responses for A/AAAA queries as a= way
> to make HTTPSSVC more available for cases where a stub is hesitant to = make
> additional queries out of concern for bad behavior from bad middleboxe= s (a
> frequent concern for Chrome when not using DoH).=C2=A0 My initial impr= ession is
> that it's not a reasonable idea, but I wanted to bring it here to = DNSOP in
> case anybody has further ideas to make it workable.=C2=A0 So any relev= ant
> thoughts or concerns from anybody here?

proposals exist going way back to add AAAA to additional data for answers o= f
type A, and to add A to additional data for answers of type AAAA. this is n= ot
different from adding A and AAAA to additional data for answers of MX and S= RV,
which already happens. your proposal fits the same mold, which is that the =
spec neither requires nor prohibits it. however, the client API likely does=
not have a way to benefit from the additional data in a stub response.

Not a blocking concern for Chrome because in ma= ny cases it uses a built-in stub resolver that could easily read anything i= t wants out of the responses.=C2=A0 But it certainly limits whether or not = we would try to convince recursive operators to do this if it is likely to = only be of benefit to Chrome.=C2=A0 Also exacerbates all the concerns aroun= d things not being ideal if the stub is not going to use the HTTPSSVC if ev= en less stubs are able to use it.
=C2=A0
see
getdn= sapi.net for a representative example of something that can only tell y= ou
answers to the question you asked, even if it knows more, and won't kee= p the
response in state just in case your next question could also be answered by=
it. getdnsapi has a return_both_v4_and_v6 extension but would need another = API
change to support HTTPSSVC.

for SMTP senders to benefit from the additional AAAA/A data in MX answers, =
they have to call a lower level API such as res_nsend() and then walk throu= gh
the response to see what they actually got, in hopes of not needing to make= a
second query for addresses (or a second and third, if V6 and V4 are
available.)

so, this way lies madness, and the solution we see most often is a host-lev= el
cache of DNS results. the old INN (usenet net news) server had one of these= ,
and all modern browsers have one. many of us simply run a validating iterat= ive
caching recursive resolver on our hosts, since it's not much code by mo= dern
standards. but in all such cases we don't have a good way to retrieve m= ore
than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is = not
well defined and is broadly unimplemented. various other multiple-questions=
proposals have been made but nothing gets traction.

> The obvious problems I could think of (all basically along the theme o= f it
> not being ideal when the stub might not even care about HTTPSSVC):
>
>=C2=A0 =C2=A0 - Performance implications if the recursive has to retrie= ve HTTPSSVC or
>=C2=A0 =C2=A0 follow alias chains.=C2=A0 Maybe not as bad if only done = opportunistically
> when the recursive happens to already have everything in cache.
>=C2=A0 =C2=A0 - Polluting DNS for non-browsers.=C2=A0 Maybe not as bad = if SVCB instead of
>=C2=A0 =C2=A0 HTTPSSVC, but this would likely only be of use for web br= owsers which are
> obviously not the only queryers of A/AAAA.
>=C2=A0 =C2=A0 - Could lead to lots of unnecessary truncation, especiall= y for large
>=C2=A0 =C2=A0 records containing ESNI data.

your self-criticisms are all valid in my opinion. however, i think it would= be
fine to recommend in the HTTPSSVC draft that the necessary subsidiary data =
like AAAA or A or SVCB all be sent, both in authoritative and non-
authoritative responses, when the qtype is HTTPSSVC and the responder knows=
the additional data (that is, it should not make extra queries to find it j= ust
for additional data reasons.) this will push UDP/53 DNS into either TCP/53 = DNS
(via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or ev= en
TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ).

long answers are our future. if this data is going to be nec'y to make = the
primary answer useful, then pre-seeding it is a net good. some day our
descendants will break the tyranny of MTU 1500, and thank us for any prewor= k
that brought the data their apps needed closer and with fewer round trips.<= br>
--
Paul


--000000000000ecc88c05a6a36730-- From nobody Wed May 27 09:15:36 2020 Return-Path: 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 6A8CC3A0EE8 for ; Wed, 27 May 2020 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fn1h70egyJGb for ; Wed, 27 May 2020 09:15:33 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 807943A0EBA for ; Wed, 27 May 2020 09:15:14 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id r15so3633091wmh.5 for ; Wed, 27 May 2020 09:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hsb1kdI+0YUXOSE91QphXQA0TnNYNSjz/2oNu55poM=; b=JOdaLs936y2WA6GhQLG+gpK4qvidTve+/PBpJ7INZ665Dy20aEV4yUIrLv65HqN2S1 xG6yX0MILq9V+gciZ7syA4mxT5Q4ivlykNOHoC6AKAh6FCyONxZ2cwQ3d+l0Cgb03ces juHrZQrRm/5RfAUFiK6boqGm7Z4Rur7u5danH/jJbWHwk1qFV5Ek2cHmMW7Q2BZ9TSbS FerRw9pUQdmPHxWfFNxG94S/WyoSGmJJF2dryIulgdZ+ORfV0Ib5qkeXaZLw/t2loTCl VR9kbn0u7q99dAgPNvnzPmTrGN5dg1l2m9aUt6Fm6NRLhB0rpXU7a3MQ3hk5Zwn4Sjlq l9gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hsb1kdI+0YUXOSE91QphXQA0TnNYNSjz/2oNu55poM=; b=EZ065dbGyX1LZJ4oBVxiw9Gxq9iob2FGGVYZjhJeF6xED+0TfzndREPkLgtr0xMJnT Nn4XmRzTQ7SMnez5GZRFeKRWxv8Y4L50DrIGuPad+6hF4pT9Z5jh2DFAnHRACIt2a1sA fqPVLps23hroBGjN9LrmHFBwezzlyTworeiR0ufuzdLZnWTIW7LFvvq+YZ9F2Ttr9RQR MRCMVMJ5QfbBp+PMwpNbZfdoavVV/GT4ht+++tKvYzxWjZcnhuEW6ngqAtmMOBHwZLLZ pQAdjyQjmj68jhTUcvWro8zPMLXEikjyzY8LkkUIrRjn9nGIZnzhEO7OFxgjZzcULztW CYYw== X-Gm-Message-State: AOAM533dfMX254lhGr6r0P++M99ziQOETn6qY9FZ9Gw/zYXZQH1+2uiQ qqFwdEscfv9963lO3kUyW5LrI+T+gUQ+hDyUMBi7B3P/ X-Google-Smtp-Source: ABdhPJwkjrGtQXj600iZd+ADSf0pVjNH/rgPoEBzu5jmN8N5MZ3j0OnxaSHZjz5WbZle3YSEQZDqIyYdgLao6VHSpRg= X-Received: by 2002:a1c:7e03:: with SMTP id z3mr4962193wmc.89.1590596112830; Wed, 27 May 2020 09:15:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Wed, 27 May 2020 12:15:01 -0400 Message-ID: To: Paul Hoffman Cc: dnsop Content-Type: multipart/alternative; boundary="00000000000049975d05a6a3847c" Archived-At: Subject: Re: [DNSOP] [Ext] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 16:15:34 -0000 --00000000000049975d05a6a3847c Content-Type: text/plain; charset="UTF-8" On Tue, May 26, 2020 at 8:18 PM Paul Hoffman wrote: > On May 26, 2020, at 12:43 PM, Eric Orth 40google.com@dmarc.ietf.org> wrote: > > One of my colleagues recently brought up the idea of suggesting > recursives add additional HTTPSSVC records into responses for A/AAAA queries > > Add where in the response? In the Answer section or in the Additional > section? The semantics and usefulness are wildly different for those two. > I assume Additional, but I honestly don't have much personal perspective on the implications of which section is used since from the perspective of the stub code I deal with, it's not an issue to look for HTTPSSVC records in either section. > > --Paul Hoffman --00000000000049975d05a6a3847c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000049975d05a6a3847c-- From nobody Wed May 27 09:40:41 2020 Return-Path: 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 994CE3A0F0A for ; Wed, 27 May 2020 09:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7M4Yunl4DaMj for ; Wed, 27 May 2020 09:40:38 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 703B53A07C8 for ; Wed, 27 May 2020 09:40:38 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id u12so40339wmd.3 for ; Wed, 27 May 2020 09:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x3HSE3SpBHfrI0kw5W4hodlc/TTjQ46bUCB5EVM96ls=; b=BK6HUI0JFcVLEMYsr51CaDsj47avJercNrLPqJbdhHoYzFYMpaBUs6FyEHesr9QA7c NGTzZDF0t+HSnxXYNjt/2rNk98FT6ftH3f63AWM0X5zWoIcKGj8XfaZC1VCJ4GN7/mD9 GOKklnn4AW5yk3xBzTmvWEdD4/MLuaL0TLodPkeNufTPQLcasSRwSiEcf0K9ox2Hjmi0 cIFN8/beOLwi5fWjMc+lonOFdcj+RGMBbfJLSjmNEYizFXwywoE1ydfSkBxFjFBXuTxO a4KnOrpvo5jhtn2fkwjfjwFfik4ns8Z/7UMUZ+OHZTXVmcWRYIgioFjxSAs8w5MylOqc Xb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x3HSE3SpBHfrI0kw5W4hodlc/TTjQ46bUCB5EVM96ls=; b=UtiTbJeT4qz77iHXErZSwehYJAuheyA6xcd+KbZNybAEvoINkdIwlrkoKuIDyJuo05 j2EYTyEZ035eGgch1NpMA6KLs/Vv/NKSZcppUs6tpjwMu2OVpxvanm7o/686jkGzeZS0 zaOs9dlYcW1wPjNDck0OAwb/Qdndz5EaJZfsm2pdAG113nzT3d6eJHs9ghzxTg2f6K76 sZsjZV8oPAkORoF+gHPRuGqYqmh1G61MghPlRBOmIGAIXsMjONAPN61gPsa4zzJzCIj3 oCqpBNyyU8mV93bHX04GZzKSxI72QuuBevMVfJMwzDkWQ+g9t8KoAbtrfvhIypSyH8zG hE+g== X-Gm-Message-State: AOAM531eLz/gEiz6xvftHbcINVQjz69lOHdDMYL9AMhP7vgJCVaavxCl cw5XOXm5M+iZQL1SypVRqD0l1Vnew41kWdSvar1opcNl X-Google-Smtp-Source: ABdhPJxIvatsYYNg+TatVAPjQwYuiCqkt2jIIcNsa/n/2m4rmpZ4YEhbaC4O7979WSIqibkunIv7lbjiRqxkjI3Hr2Q= X-Received: by 2002:a1c:7e03:: with SMTP id z3mr5063422wmc.89.1590597636796; Wed, 27 May 2020 09:40:36 -0700 (PDT) MIME-Version: 1.0 References: <1852098.ajqZCkXiOD@linux-9daj> In-Reply-To: From: Eric Orth Date: Wed, 27 May 2020 12:40:25 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop Content-Type: multipart/alternative; boundary="0000000000001f6deb05a6a3df8b" Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 16:40:41 -0000 --0000000000001f6deb05a6a3df8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2020 at 2:34 AM Petr =C5=A0pa=C4=8Dek = wrote: > On 27. 05. 20 1:05, Paul Vixie wrote: > > so, this way lies madness, and the solution we see most often is a > host-level > > cache of DNS results. the old INN (usenet net news) server had one of > these, > > and all modern browsers have one. many of us simply run a validating > iterative > > caching recursive resolver on our hosts, since it's not much code by > modern > > standards. but in all such cases we don't have a good way to retrieve > more > > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is > not > > well defined and is broadly unimplemented. various other > multiple-questions > > proposals have been made but nothing gets traction. > > I would much rather spent time on > https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 > > That would bring benefit to broader set of clients and has advantage that > server does not send back data nobody asked for (thus wasting resources o= n > unnecessary work). > Maybe a better solution, but considering that the issue I'm dealing with is when the stub is unwilling to send additional queries or queries for new types out of concerns of middlebox ossificiation (especially from older home routers) on additional queries or unknown query types, does anybody have any data to show that the multiple qtype EDNS option won't cause similar issues? But in other cases without as much ossifciation concern, especially when using DoH, I'm supportive of any effort to allow querying multiple types in the same request. Would significantly help with some of the security concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by identifying and blocking the packets just for the HTTPSSVC records. If A/AAAA/HTTPSSVC are all in the same request/response, you can't block any of it without blocking all of it. My one concern of that specific proposal is that if the client doesn't know that the server will respond for the additional queries, it still has to make separate queries for all three, leading to lots of redundant responses when the additional types are handled. > > I feel that nowadays web browsers have better communication with OS > vendors/stub resolvers (Android and Chrome come to mind). Can we stub > resolvers on board, pretty please? > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000001f6deb05a6a3df8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 27, 2020 at 2:34 AM Petr = =C5=A0pa=C4=8Dek <petr.spacek@nic.= cz> wrote:
https://tools.ietf.org/html/draft-bel= lis-dnsext-multi-qtypes-03

That would bring benefit to broader set of clients and has advantage that s= erver does not send back data nobody asked for (thus wasting resources on u= nnecessary work).

Maybe a better soluti= on, but considering that the=C2=A0issue I'm dealing with is when the st= ub is unwilling to send additional queries or queries for new types out of = concerns of middlebox ossificiation=C2=A0(especially from older home router= s) on additional queries or unknown query types, does anybody have any data= to show that the multiple qtype EDNS option won't cause similar issues= ?

But in other cases without as much ossifciation= =C2=A0concern, especially when using DoH, I'm supportive of any effort = to allow querying multiple types in the same request.=C2=A0 Would significa= ntly help with some of the security concerns in ESNI/HTTPSSVC where an atta= cker could try to block ESNI by identifying and blocking the packets just f= or the HTTPSSVC records.=C2=A0 If A/AAAA/HTTPSSVC are all in the same reque= st/response, you can't block any of it without blocking all of it.=C2= =A0 My one concern of that specific proposal is that if the client doesn= 9;t know that the server will respond for the additional queries, it still = has to make separate queries for all three, leading to lots of redundant re= sponses when the additional types are handled.
=C2=A0

I feel that nowadays web browsers have better communication with OS vendors= /stub resolvers (Android and Chrome come to mind). Can we stub resolvers on= board, pretty please?

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000001f6deb05a6a3df8b-- From nobody Wed May 27 10:48:41 2020 Return-Path: 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 2DAF73A0795 for ; Wed, 27 May 2020 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bFtoCGvM; dkim=pass (1536-bit key) header.d=taugh.com header.b=tJDyFAIe 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 Qc1Sks5mabVU for ; Wed, 27 May 2020 10:48:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 81C5D3A064C for ; Wed, 27 May 2020 10:48:36 -0700 (PDT) Received: (qmail 98237 invoked from network); 27 May 2020 17:48:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=17fbb.5ecea7f0.k2005; i=johnl-iecc.com@submit.iecc.com; bh=GQwB7pjuSoq6AdMb4aAbOBii+Bwd0ELsN2gs12I3jbg=; b=bFtoCGvMvbkM7EYFQjUS7UlaiNpvT2TuQpsqqDVEcu8iaC67X8v8bdup/u91qFaB68KsVG7NtC/zB2j7r0IOVgXvX4ziiDZtXp68wwRhbdepKzIlGapMmrH4xBadi6gBYOcUQ6mUvF1MQKat13nydeBK8OAI9GzW3lw+FV2UY9RTx95ikztU9jpFjDAy1OwEd5P8zlAB1vVhhVXtXl2LIghftboTI0YNwH1AL01XqXB0xSWHFY9YnaLqk1tVNkIQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=17fbb.5ecea7f0.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=GQwB7pjuSoq6AdMb4aAbOBii+Bwd0ELsN2gs12I3jbg=; b=tJDyFAIeo0NAYlsHTS56fv/fIMB4wmrDCWcz+HOGb7Pf8+IrTAfzwdtQw7t6JQXvdRRHkbpDH7B1CeB56soqkzyP5mAX+z04yYOZTpsElHQSGYa2Xb3G+uYw+HKgv37l2XlQUjjj6mdwinPmUdwhtZIYw6o+DckwNjzx4ZOF5mS8z6EbH21hyYnIXcoFY2UOSRmu+bofa7REJncBvGlTbKG1opZhnNbREQbvYwB3eH1i3s8Yqq6CuQ8guUxFR2zd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2020 17:48:32 -0000 Date: 27 May 2020 13:48:32 -0400 Message-ID: From: "John R Levine" To: dnsop@ietf.org User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1195530771-1590601712=:35268" Archived-At: Subject: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 17:48:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1195530771-1590601712=:35268 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT While I should have been doing something else, I made a rather long CNAME chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I warmed up my cache five links at a time by looking for chain5, chain10, chain15, and so forth, it worked. At least it worked in "dig" and "host". When I try and look up http://chain.examp1e.com, Chrome waits a while and says not found, Firefox waits a while and says "Hmm. We’re having trouble finding that site." and Safari on my Mac hangs. (Feel free to try it yourself.) I realize the answer to most questions like this can be summarized as "don't do that", but is there any consensus as to the maximum CNAME chain length that works reliably, and what happens if the chain is too long? Hanging seems sub-optimal. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly $ dig chain.examp1e.com A ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;chain.examp1e.com. IN A ;; ANSWER SECTION: chain.examp1e.com. 3371 IN CNAME chain100.examp1e.com. chain100.examp1e.com. 3371 IN CNAME chain99.examp1e.com. chain99.examp1e.com. 3371 IN CNAME chain98.examp1e.com. chain98.examp1e.com. 3371 IN CNAME chain97.examp1e.com. chain97.examp1e.com. 3371 IN CNAME chain96.examp1e.com. chain96.examp1e.com. 3372 IN CNAME chain95.examp1e.com. chain95.examp1e.com. 3372 IN CNAME chain94.examp1e.com. chain94.examp1e.com. 3372 IN CNAME chain93.examp1e.com. chain93.examp1e.com. 3372 IN CNAME chain92.examp1e.com. chain92.examp1e.com. 3589 IN CNAME chain91.examp1e.com. chain91.examp1e.com. 3589 IN CNAME chain90.examp1e.com. chain90.examp1e.com. 3583 IN CNAME chain89.examp1e.com. chain89.examp1e.com. 3583 IN CNAME chain88.examp1e.com. chain88.examp1e.com. 3583 IN CNAME chain87.examp1e.com. chain87.examp1e.com. 3583 IN CNAME chain86.examp1e.com. chain86.examp1e.com. 3583 IN CNAME chain85.examp1e.com. chain85.examp1e.com. 3577 IN CNAME chain84.examp1e.com. chain84.examp1e.com. 3578 IN CNAME chain83.examp1e.com. chain83.examp1e.com. 3578 IN CNAME chain82.examp1e.com. chain82.examp1e.com. 3578 IN CNAME chain81.examp1e.com. chain81.examp1e.com. 3579 IN CNAME chain80.examp1e.com. chain80.examp1e.com. 3570 IN CNAME chain79.examp1e.com. chain79.examp1e.com. 3571 IN CNAME chain78.examp1e.com. chain78.examp1e.com. 3571 IN CNAME chain77.examp1e.com. chain77.examp1e.com. 3571 IN CNAME chain76.examp1e.com. chain76.examp1e.com. 3572 IN CNAME chain75.examp1e.com. chain75.examp1e.com. 3564 IN CNAME chain74.examp1e.com. chain74.examp1e.com. 3564 IN CNAME chain73.examp1e.com. chain73.examp1e.com. 3564 IN CNAME chain72.examp1e.com. chain72.examp1e.com. 3564 IN CNAME chain71.examp1e.com. chain71.examp1e.com. 3564 IN CNAME chain70.examp1e.com. chain70.examp1e.com. 3519 IN CNAME chain69.examp1e.com. chain69.examp1e.com. 3519 IN CNAME chain68.examp1e.com. chain68.examp1e.com. 3519 IN CNAME chain67.examp1e.com. chain67.examp1e.com. 3519 IN CNAME chain66.examp1e.com. chain66.examp1e.com. 3519 IN CNAME chain65.examp1e.com. chain65.examp1e.com. 3519 IN CNAME chain64.examp1e.com. chain64.examp1e.com. 3520 IN CNAME chain63.examp1e.com. chain63.examp1e.com. 3520 IN CNAME chain62.examp1e.com. chain62.examp1e.com. 3520 IN CNAME chain61.examp1e.com. chain61.examp1e.com. 3554 IN CNAME chain60.examp1e.com. chain60.examp1e.com. 3549 IN CNAME chain59.examp1e.com. chain59.examp1e.com. 3549 IN CNAME chain58.examp1e.com. chain58.examp1e.com. 3549 IN CNAME chain57.examp1e.com. chain57.examp1e.com. 3549 IN CNAME chain56.examp1e.com. chain56.examp1e.com. 3549 IN CNAME chain55.examp1e.com. chain55.examp1e.com. 3535 IN CNAME chain54.examp1e.com. chain54.examp1e.com. 3536 IN CNAME chain53.examp1e.com. chain53.examp1e.com. 3536 IN CNAME chain52.examp1e.com. chain52.examp1e.com. 3536 IN CNAME chain51.examp1e.com. chain51.examp1e.com. 3536 IN CNAME chain50.examp1e.com. chain50.examp1e.com. 3536 IN CNAME chain49.examp1e.com. chain49.examp1e.com. 3536 IN CNAME chain48.examp1e.com. chain48.examp1e.com. 3536 IN CNAME chain47.examp1e.com. chain47.examp1e.com. 3536 IN CNAME chain46.examp1e.com. chain46.examp1e.com. 3541 IN CNAME chain45.examp1e.com. chain45.examp1e.com. 3531 IN CNAME chain44.examp1e.com. chain44.examp1e.com. 3531 IN CNAME chain43.examp1e.com. chain43.examp1e.com. 3531 IN CNAME chain42.examp1e.com. chain42.examp1e.com. 3531 IN CNAME chain41.examp1e.com. chain41.examp1e.com. 3531 IN CNAME chain40.examp1e.com. chain40.examp1e.com. 3525 IN CNAME chain39.examp1e.com. chain39.examp1e.com. 3526 IN CNAME chain38.examp1e.com. chain38.examp1e.com. 3526 IN CNAME chain37.examp1e.com. chain37.examp1e.com. 3526 IN CNAME chain36.examp1e.com. chain36.examp1e.com. 3526 IN CNAME chain35.examp1e.com. chain35.examp1e.com. 3513 IN CNAME chain34.examp1e.com. chain34.examp1e.com. 3513 IN CNAME chain33.examp1e.com. chain33.examp1e.com. 3513 IN CNAME chain32.examp1e.com. chain32.examp1e.com. 3513 IN CNAME chain31.examp1e.com. chain31.examp1e.com. 3513 IN CNAME chain30.examp1e.com. chain30.examp1e.com. 3508 IN CNAME chain29.examp1e.com. chain29.examp1e.com. 3508 IN CNAME chain28.examp1e.com. chain28.examp1e.com. 3508 IN CNAME chain27.examp1e.com. chain27.examp1e.com. 3508 IN CNAME chain26.examp1e.com. chain26.examp1e.com. 3508 IN CNAME chain25.examp1e.com. chain25.examp1e.com. 3499 IN CNAME chain24.examp1e.com. chain24.examp1e.com. 3499 IN CNAME chain23.examp1e.com. chain23.examp1e.com. 3500 IN CNAME chain22.examp1e.com. chain22.examp1e.com. 3500 IN CNAME chain21.examp1e.com. chain21.examp1e.com. 3500 IN CNAME chain20.examp1e.com. chain20.examp1e.com. 3447 IN CNAME chain19.examp1e.com. chain19.examp1e.com. 3447 IN CNAME chain18.examp1e.com. chain18.examp1e.com. 3447 IN CNAME chain17.examp1e.com. chain17.examp1e.com. 3448 IN CNAME chain16.examp1e.com. chain16.examp1e.com. 3448 IN CNAME chain15.examp1e.com. chain15.examp1e.com. 3448 IN CNAME chain14.examp1e.com. chain14.examp1e.com. 3448 IN CNAME chain13.examp1e.com. chain13.examp1e.com. 3448 IN CNAME chain12.examp1e.com. chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. chain0.examp1e.com. 3460 IN A 64.57.183.119 ;; Query time: 2 msec ;; SERVER: 192.168.80.2#53(192.168.80.2) ;; WHEN: Wed May 27 13:31:17 EDT 2020 ;; MSG SIZE rcvd: 2275 --0-1195530771-1590601712=:35268-- From nobody Wed May 27 11:08:51 2020 Return-Path: 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 697A53A083B for ; Wed, 27 May 2020 11:08:50 -0700 (PDT) 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 HVZcvBT3DTGm for ; Wed, 27 May 2020 11:08:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 EDBB33A083F for ; Wed, 27 May 2020 11:08:47 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.1.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F2DE13AB000; Wed, 27 May 2020 18:08:46 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id E73463F2C6; Wed, 27 May 2020 18:08:46 +0000 (UTC) Date: Wed, 27 May 2020 18:08:46 +0000 From: Evan Hunt To: John R Levine Cc: dnsop@ietf.org Message-ID: <20200527180846.GA51895@isc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 18:08:50 -0000 On Wed, May 27, 2020 at 01:48:32PM -0400, John R Levine wrote: > is there any consensus as to the maximum CNAME chain length > that works reliably, and what happens if the chain is too long? Hanging > seems sub-optimal. BIND cuts CNAME chains off at 16. As far as I know that was an arbitrarily- selected value, but it's been in the code since 1999 and so far as I can recall, no one's complained. The maximum reliable chain length won't be any longer than that; it might be shorter. When a chain is too long, I think BIND just returns a response with the 16 CNAMEs it's found so far, and without a final answer. The client can start a new query from where the response left off, but I would expect most to treat it as a non-answer. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Wed May 27 11:48:44 2020 Return-Path: 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 4C7933A0857 for ; Wed, 27 May 2020 11:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SCFZpnTM; dkim=pass (1536-bit key) header.d=taugh.com header.b=KCm3Zqiy 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 IYgMWESjzDQi for ; Wed, 27 May 2020 11:48:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E8EEF3A0844 for ; Wed, 27 May 2020 11:48:40 -0700 (PDT) Received: (qmail 12602 invoked from network); 27 May 2020 18:48:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3138.5eceb606.k2005; i=johnl-iecc.com@submit.iecc.com; bh=ZgSE7alhKWjFMrKfgY65Gv9YyeIMOWm1CuzMFwmsIgg=; b=SCFZpnTM7KxUtfenVyKrgdrX6U3xZn8izrPu36RZVAbf7G4FeAmgV5tEzZoqIo6/MjXs1DPaW81TpSIukmOJsKLZOq2n39E7vzUppjOyQ9MekavXTkLn66NQRBSpG1kJqGg6BJKEdZ6ya4ToFKecYMJJ+PUAOkpup+jNkpL1LE/cu5pRkfP1vUGOsX3DyMijsNZ6gC8wUGeiGspQXalxVHz4B3tefZXYDv8wCxsqV7Kn4xJVZGHTrqyRmn7Rx5QI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3138.5eceb606.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=ZgSE7alhKWjFMrKfgY65Gv9YyeIMOWm1CuzMFwmsIgg=; b=KCm3ZqiyCuIF+zUxI/VFtCtQZXK5P6Shwufo2ojFy8y9Ltpggie4VR9QfMDWahBcx/5yWFX5FXR6FAzBMLzqBSQUZcU9n9uQIUtg+V2SKlIizmjPcZeoS/eMXfmzgEihvXlihsmoVzEK5H2Ihx2VqfnCTJMKNVTxtbp2Hal/3N9CQuI+yrLMKtey7va+PPwNts1/p4AtISZVaQycPBnpDr1cAKCgo8fbn3thJTXpj6RPMH3Op60FddX1xh7Jb1RE Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2020 18:48:38 -0000 Date: 27 May 2020 14:48:38 -0400 Message-ID: From: "John R Levine" To: dnsop@ietf.org In-Reply-To: References: User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-936893982-1590605318=:35546" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 18:48:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-936893982-1590605318=:35546 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 27 May 2020, John R Levine wrote: > While I should have been doing something else, I made a rather long CNAME > chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I > warmed up my cache five links at a time by looking for chain5, chain10, > chain15, and so forth, it worked. At least it worked in "dig" and "host". > When I try and look up http://chain.examp1e.com, Chrome waits a while and > says not found, Firefox waits a while and says "Hmm. We’re having trouble > finding that site." and Safari on my Mac hangs. (Feel free to try it > yourself.) FWIW, the cache is unbound 1.10.1. R's, John > I realize the answer to most questions like this can be summarized as "don't > do that", but is there any consensus as to the maximum CNAME chain length > that works reliably, and what happens if the chain is too long? Hanging seems > sub-optimal. --0-936893982-1590605318=:35546-- From nobody Wed May 27 12:03:43 2020 Return-Path: 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 BD0753A087F for ; Wed, 27 May 2020 12:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.79 X-Spam-Level: X-Spam-Status: No, score=-14.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, FSL_BULK_SIG=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lktN8nA9LlOl for ; Wed, 27 May 2020 12:03:39 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 265343A0877 for ; Wed, 27 May 2020 12:03:39 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id l26so562211wme.3 for ; Wed, 27 May 2020 12:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KPjnIRMe28ms8RbcSDUsT7amwzAfU9pfE83RlBeTLBc=; b=QsCUyHR/tSw2EOGplBFw5zAGP9yVRf+sfwo7ROXgwdN2+nQYOT3UU07spGXxutgkkV zOM2R6RAdDz5/kutHDuc7EOWJue5IIzoq4QyKyhyjp2RjbWTqw3+StmR3wPQxBkuINCA 808VjIKwBfg953HcuRhE9SJGaEXlJHI9d7pLhnDVJq3jT44QL1zHw0xTFfJCFZF69uCV UENeSNjuiD4nvY6QsjUyd3EeyFIl0xcj+rVw2G1U5BKuB3l0Y6JmClJub+9KIf2zFhlQ FGDyHrvIkStHjBrioa6S4Mjxkb/nvfR6tCl7+Y2mQ41+EbpeJb2ZtV7x2YWe6IqpBMii AZVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KPjnIRMe28ms8RbcSDUsT7amwzAfU9pfE83RlBeTLBc=; b=tvAejHK6U5GJWy8tMA9ZUw7pCZPZgMCYXtghJMR92r45m77UJ/9PrnoA/J1sA1YyCB 9CTKncAKSfTGNu/BqS1g/tNZJA6328UtbeyJbqGS5uswAv1zui4b1o0KpXq4Nymj2sqM W+z2VZaDcIpCSKs9lJPNAFHXgc33FWMg42LpmE4hgCMqLQr8KR4J9XhOLTosbMwVeg2W s2ZsO0OlMPHBwd+ItNwetlR05F+eNbYB3OoyKduSuVIeSH0gJpWqgqLmmVWyd15aknJ7 gxSATL6p4ZuXmNbty/SgjVJ15xxbyk7wR73VquOqxqSbVFRqY6FYTsUPs45QQBDYr34g oo1g== X-Gm-Message-State: AOAM533tVIwZJ7Q9C/bqj/a3AFd01mL6z1Z40jUZkVguECb0UH+ayaOp WjjF4SXcPzV2E1bX7bXtRuTz/sbqc5gzLY9Z9HRk2z+w X-Google-Smtp-Source: ABdhPJyoNWz8wmNpLI5YzPfAwVzDxV9eIDudFpb+tDam4A/P4YjhDsrbnwWSfWfRT3VgvYG5Mi3IwL0ltWFrbWw8zZs= X-Received: by 2002:a05:600c:206:: with SMTP id 6mr5558477wmi.170.1590606217187; Wed, 27 May 2020 12:03:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Wed, 27 May 2020 15:03:26 -0400 Message-ID: To: John R Levine Cc: dnsop Content-Type: multipart/alternative; boundary="0000000000008df28305a6a5dee5" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 19:03:42 -0000 --0000000000008df28305a6a5dee5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2020 at 1:49 PM John R Levine wrote: > While I should have been doing something else, I made a rather long CNAME > chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I > warmed up my cache five links at a time by looking for chain5, chain10, > chain15, and so forth, it worked. At least it worked in "dig" and "host"= . > When I try and look up http://chain.examp1e.com, Chrome waits a while > and says not found, If Chrome is using its built-in stub, there's not expected to be a limit (other than the overall message size limits), but nothing tests chains this long other than security fuzzers that are only looking for crashes or memory issues. > Firefox waits a while and says "Hmm. We=E2=80=99re having > trouble finding that site." and Safari on my Mac hangs. (Feel free to tr= y > it yourself.) > > I realize the answer to most questions like this can be summarized as > "don't do that", but is there any consensus as to the maximum CNAME chain > length that works reliably, and what happens if the chain is too long? > Hanging seems sub-optimal. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > $ dig chain.examp1e.com A > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;chain.examp1e.com. IN A > > ;; ANSWER SECTION: > chain.examp1e.com. 3371 IN CNAME chain100.examp1e.com. > chain100.examp1e.com. 3371 IN CNAME chain99.examp1e.com. > chain99.examp1e.com. 3371 IN CNAME chain98.examp1e.com. > chain98.examp1e.com. 3371 IN CNAME chain97.examp1e.com. > chain97.examp1e.com. 3371 IN CNAME chain96.examp1e.com. > chain96.examp1e.com. 3372 IN CNAME chain95.examp1e.com. > chain95.examp1e.com. 3372 IN CNAME chain94.examp1e.com. > chain94.examp1e.com. 3372 IN CNAME chain93.examp1e.com. > chain93.examp1e.com. 3372 IN CNAME chain92.examp1e.com. > chain92.examp1e.com. 3589 IN CNAME chain91.examp1e.com. > chain91.examp1e.com. 3589 IN CNAME chain90.examp1e.com. > chain90.examp1e.com. 3583 IN CNAME chain89.examp1e.com. > chain89.examp1e.com. 3583 IN CNAME chain88.examp1e.com. > chain88.examp1e.com. 3583 IN CNAME chain87.examp1e.com. > chain87.examp1e.com. 3583 IN CNAME chain86.examp1e.com. > chain86.examp1e.com. 3583 IN CNAME chain85.examp1e.com. > chain85.examp1e.com. 3577 IN CNAME chain84.examp1e.com. > chain84.examp1e.com. 3578 IN CNAME chain83.examp1e.com. > chain83.examp1e.com. 3578 IN CNAME chain82.examp1e.com. > chain82.examp1e.com. 3578 IN CNAME chain81.examp1e.com. > chain81.examp1e.com. 3579 IN CNAME chain80.examp1e.com. > chain80.examp1e.com. 3570 IN CNAME chain79.examp1e.com. > chain79.examp1e.com. 3571 IN CNAME chain78.examp1e.com. > chain78.examp1e.com. 3571 IN CNAME chain77.examp1e.com. > chain77.examp1e.com. 3571 IN CNAME chain76.examp1e.com. > chain76.examp1e.com. 3572 IN CNAME chain75.examp1e.com. > chain75.examp1e.com. 3564 IN CNAME chain74.examp1e.com. > chain74.examp1e.com. 3564 IN CNAME chain73.examp1e.com. > chain73.examp1e.com. 3564 IN CNAME chain72.examp1e.com. > chain72.examp1e.com. 3564 IN CNAME chain71.examp1e.com. > chain71.examp1e.com. 3564 IN CNAME chain70.examp1e.com. > chain70.examp1e.com. 3519 IN CNAME chain69.examp1e.com. > chain69.examp1e.com. 3519 IN CNAME chain68.examp1e.com. > chain68.examp1e.com. 3519 IN CNAME chain67.examp1e.com. > chain67.examp1e.com. 3519 IN CNAME chain66.examp1e.com. > chain66.examp1e.com. 3519 IN CNAME chain65.examp1e.com. > chain65.examp1e.com. 3519 IN CNAME chain64.examp1e.com. > chain64.examp1e.com. 3520 IN CNAME chain63.examp1e.com. > chain63.examp1e.com. 3520 IN CNAME chain62.examp1e.com. > chain62.examp1e.com. 3520 IN CNAME chain61.examp1e.com. > chain61.examp1e.com. 3554 IN CNAME chain60.examp1e.com. > chain60.examp1e.com. 3549 IN CNAME chain59.examp1e.com. > chain59.examp1e.com. 3549 IN CNAME chain58.examp1e.com. > chain58.examp1e.com. 3549 IN CNAME chain57.examp1e.com. > chain57.examp1e.com. 3549 IN CNAME chain56.examp1e.com. > chain56.examp1e.com. 3549 IN CNAME chain55.examp1e.com. > chain55.examp1e.com. 3535 IN CNAME chain54.examp1e.com. > chain54.examp1e.com. 3536 IN CNAME chain53.examp1e.com. > chain53.examp1e.com. 3536 IN CNAME chain52.examp1e.com. > chain52.examp1e.com. 3536 IN CNAME chain51.examp1e.com. > chain51.examp1e.com. 3536 IN CNAME chain50.examp1e.com. > chain50.examp1e.com. 3536 IN CNAME chain49.examp1e.com. > chain49.examp1e.com. 3536 IN CNAME chain48.examp1e.com. > chain48.examp1e.com. 3536 IN CNAME chain47.examp1e.com. > chain47.examp1e.com. 3536 IN CNAME chain46.examp1e.com. > chain46.examp1e.com. 3541 IN CNAME chain45.examp1e.com. > chain45.examp1e.com. 3531 IN CNAME chain44.examp1e.com. > chain44.examp1e.com. 3531 IN CNAME chain43.examp1e.com. > chain43.examp1e.com. 3531 IN CNAME chain42.examp1e.com. > chain42.examp1e.com. 3531 IN CNAME chain41.examp1e.com. > chain41.examp1e.com. 3531 IN CNAME chain40.examp1e.com. > chain40.examp1e.com. 3525 IN CNAME chain39.examp1e.com. > chain39.examp1e.com. 3526 IN CNAME chain38.examp1e.com. > chain38.examp1e.com. 3526 IN CNAME chain37.examp1e.com. > chain37.examp1e.com. 3526 IN CNAME chain36.examp1e.com. > chain36.examp1e.com. 3526 IN CNAME chain35.examp1e.com. > chain35.examp1e.com. 3513 IN CNAME chain34.examp1e.com. > chain34.examp1e.com. 3513 IN CNAME chain33.examp1e.com. > chain33.examp1e.com. 3513 IN CNAME chain32.examp1e.com. > chain32.examp1e.com. 3513 IN CNAME chain31.examp1e.com. > chain31.examp1e.com. 3513 IN CNAME chain30.examp1e.com. > chain30.examp1e.com. 3508 IN CNAME chain29.examp1e.com. > chain29.examp1e.com. 3508 IN CNAME chain28.examp1e.com. > chain28.examp1e.com. 3508 IN CNAME chain27.examp1e.com. > chain27.examp1e.com. 3508 IN CNAME chain26.examp1e.com. > chain26.examp1e.com. 3508 IN CNAME chain25.examp1e.com. > chain25.examp1e.com. 3499 IN CNAME chain24.examp1e.com. > chain24.examp1e.com. 3499 IN CNAME chain23.examp1e.com. > chain23.examp1e.com. 3500 IN CNAME chain22.examp1e.com. > chain22.examp1e.com. 3500 IN CNAME chain21.examp1e.com. > chain21.examp1e.com. 3500 IN CNAME chain20.examp1e.com. > chain20.examp1e.com. 3447 IN CNAME chain19.examp1e.com. > chain19.examp1e.com. 3447 IN CNAME chain18.examp1e.com. > chain18.examp1e.com. 3447 IN CNAME chain17.examp1e.com. > chain17.examp1e.com. 3448 IN CNAME chain16.examp1e.com. > chain16.examp1e.com. 3448 IN CNAME chain15.examp1e.com. > chain15.examp1e.com. 3448 IN CNAME chain14.examp1e.com. > chain14.examp1e.com. 3448 IN CNAME chain13.examp1e.com. > chain13.examp1e.com. 3448 IN CNAME chain12.examp1e.com. > chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. > chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. > chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. > chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. > chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. > chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. > chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. > chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. > chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. > chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. > chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. > chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. > chain0.examp1e.com. 3460 IN A 64.57.183.119 > > ;; Query time: 2 msec > ;; SERVER: 192.168.80.2#53(192.168.80.2) > ;; WHEN: Wed May 27 13:31:17 EDT 2020 > ;; MSG SIZE rcvd: 2275 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000008df28305a6a5dee5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 27, 2020 at 1:49 PM John = R Levine <johnl@taugh.com> wro= te:
While I shou= ld have been doing something else, I made a rather long CNAME
chain.=C2=A0 When I looked up chain.examp1e.com it got SERVFAIL, but aft= er I
warmed up my cache five links at a time by looking for chain5, chain10, chain15, and so forth, it worked.=C2=A0 At least it worked in "dig&quo= t; and "host".
When I try and look up http://chain.examp1e.com, Chrome waits a while and says not found,

If Chrome is using its = built-in stub, there's not expected to be a limit (other than the overa= ll message size limits), but nothing tests chains this long other than secu= rity fuzzers that are only looking for crashes or memory issues.
= =C2=A0
Firefox waits= a while and says "Hmm. We=E2=80=99re having
trouble finding that site." and Safari on my Mac hangs.=C2=A0 (Feel fr= ee to try
it yourself.)

I realize the answer to most questions like this can be summarized as
"don't do that", but is there any consensus as to the maximum= CNAME chain
length that works reliably, and what happens if the chain is too long?
Hanging seems sub-optimal.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

$ dig chain.examp1e.com A
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.6 <<>> chain.examp1e.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;= chain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IN=C2= =A0 =C2=A0 =C2=A0 A

;; ANSWER SECTION:
c= hain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0= =C2=A0 CNAME=C2=A0 =C2=A0chain100.examp1e.com.
chain100.examp1e.com.=C2=A0 =C2=A03371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain99.examp1e.com.
chain99.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain98.examp1e.com.
chain98.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain97.examp1e.com.
chain97.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain96.examp1e.com.
chain96.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain95.examp1e.com.
chain95.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain94.examp1e.com.
chain94.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain93.examp1e.com.
chain93.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain92.examp1e.com.
chain92.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain91.examp1e.com.
chain91.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain90.examp1e.com.
chain90.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain89.examp1e.com.
chain89.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain88.examp1e.com.
chain88.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain87.examp1e.com.
chain87.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain86.examp1e.com.
chain86.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain85.examp1e.com.
chain85.examp1e.com.=C2=A0 =C2=A0 3577=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain84.examp1e.com.
chain84.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain83.examp1e.com.
chain83.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain82.examp1e.com.
chain82.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain81.examp1e.com.
chain81.examp1e.com.=C2=A0 =C2=A0 3579=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain80.examp1e.com.
chain80.examp1e.com.=C2=A0 =C2=A0 3570=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain79.examp1e.com.
chain79.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain78.examp1e.com.
chain78.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain77.examp1e.com.
chain77.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain76.examp1e.com.
chain76.examp1e.com.=C2=A0 =C2=A0 3572=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain75.examp1e.com.
chain75.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain74.examp1e.com.
chain74.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain73.examp1e.com.
chain73.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain72.examp1e.com.
chain72.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain71.examp1e.com.
chain71.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain70.examp1e.com.
chain70.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain69.examp1e.com.
chain69.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain68.examp1e.com.
chain68.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain67.examp1e.com.
chain67.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain66.examp1e.com.
chain66.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain65.examp1e.com.
chain65.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain64.examp1e.com.
chain64.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain63.examp1e.com.
chain63.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain62.examp1e.com.
chain62.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain61.examp1e.com.
chain61.examp1e.com.=C2=A0 =C2=A0 3554=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain60.examp1e.com.
chain60.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain59.examp1e.com.
chain59.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain58.examp1e.com.
chain58.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain57.examp1e.com.
chain57.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain56.examp1e.com.
chain56.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain55.examp1e.com.
chain55.examp1e.com.=C2=A0 =C2=A0 3535=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain54.examp1e.com.
chain54.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain53.examp1e.com.
chain53.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain52.examp1e.com.
chain52.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain51.examp1e.com.
chain51.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain50.examp1e.com.
chain50.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain49.examp1e.com.
chain49.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain48.examp1e.com.
chain48.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain47.examp1e.com.
chain47.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain46.examp1e.com.
chain46.examp1e.com.=C2=A0 =C2=A0 3541=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain45.examp1e.com.
chain45.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain44.examp1e.com.
chain44.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain43.examp1e.com.
chain43.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain42.examp1e.com.
chain42.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain41.examp1e.com.
chain41.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain40.examp1e.com.
chain40.examp1e.com.=C2=A0 =C2=A0 3525=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain39.examp1e.com.
chain39.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain38.examp1e.com.
chain38.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain37.examp1e.com.
chain37.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain36.examp1e.com.
chain36.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain35.examp1e.com.
chain35.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain34.examp1e.com.
chain34.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain33.examp1e.com.
chain33.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain32.examp1e.com.
chain32.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain31.examp1e.com.
chain31.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain30.examp1e.com.
chain30.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain29.examp1e.com.
chain29.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain28.examp1e.com.
chain28.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain27.examp1e.com.
chain27.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain26.examp1e.com.
chain26.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain25.examp1e.com.
chain25.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain24.examp1e.com.
chain24.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain23.examp1e.com.
chain23.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain22.examp1e.com.
chain22.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain21.examp1e.com.
chain21.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain20.examp1e.com.
chain20.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain19.examp1e.com.
chain19.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain18.examp1e.com.
chain18.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain17.examp1e.com.
chain17.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain16.examp1e.com.
chain16.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain15.examp1e.com.
chain15.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain14.examp1e.com.
chain14.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain13.examp1e.com.
chain13.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain12.examp1e.com.
chain12.examp1e.com.=C2=A0 =C2=A0 3449=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain11.examp1e.com.
chain11.examp1e.com.=C2=A0 =C2=A0 3486=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain10.examp1e.com.
chain10.examp1e.com.=C2=A0 =C2=A0 3455=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain9.examp1e.com.
= chain9.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain8.examp1e.com.
= chain8.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain7.examp1e.com.
= chain7.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain6.examp1e.com.
= chain6.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain5.examp1e.com.
= chain5.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain4.examp1e.com.
= chain4.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain3.examp1e.com.
= chain3.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain2.examp1e.com.
= chain2.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain1.examp1e.com.
= chain1.examp1e.com.=C2=A0 =C2=A0 =C2=A03466=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain0.examp1e.com.
= chain0.examp1e.com.=C2=A0 =C2=A0 =C2=A03460=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A064.57.183.119

;; Query time: 2 msec
;; SERVER: 192.168.80.2#53(192.168.80.2)
;; WHEN: Wed May 27 13:31:17 EDT 2020
;; MSG SIZE=C2=A0 rcvd: 2275
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000008df28305a6a5dee5-- From nobody Wed May 27 12:05:53 2020 Return-Path: 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 3F9DF3A087F for ; Wed, 27 May 2020 12:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.79 X-Spam-Level: X-Spam-Status: No, score=-14.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, FSL_BULK_SIG=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 bvFtcqOU_8ao for ; Wed, 27 May 2020 12:05:49 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 AC8C73A0877 for ; Wed, 27 May 2020 12:05:48 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id j16so12774535wrb.7 for ; Wed, 27 May 2020 12:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kv4/VF7Bbnymy/A8VScFgegfZ3hMCuIQ/6ssbKZrzQo=; b=cfm/3jUJ8Py60RNClk69saKbJ2HfFaYUh/4dSvGYROz16RQXmYXr7FoflC9Y8swvV/ e9LJTkSxl7SDDm4UcJiUtOfXMjgaKTquo04vlQl3PYCvYaRqGA5mWzG1IJrkOHA0fnrA 1VILvOM8hdA8/+ZvRpmgG9a/JM9zbUjIGjnUe8DGy3k6BhOM70oNO/PkM59fNylvlA2o PaneS+g+S1K6dt7yMnDv00V7bRjVkJ+szL4w0VobGqBzlhMd/O9lFOMEgj/DZk0Ih6st 61n6zoLodBhv63S5dkZVgZhmcIsJp8WKNii+bs4gxOSUGUkkLRHejpcHxdIWp52CdUBT weuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kv4/VF7Bbnymy/A8VScFgegfZ3hMCuIQ/6ssbKZrzQo=; b=S+pvJBu4+yKip3m5agYAEetl+xYXJ6F0LOYJoobHVY2dd6yX06RloFuDL9aeoCYuBy n+JuT89D9IC3+DxsaqjgSb4mUwblTm5TAM6KrVkpl8A4Y0rXvUwcgqxw20WzYqfhgNxP XLv3Ae3GvIgQTsurWV1NdKW0CnmhkRia0CV9f0qrHc4svER4hsBUMlGxtwImPG6E1T7l OpDZ9PcDx52RqtvYRZ/W0VDIIaEwAPX7TzEMhJkAEWod+EFPuZJ+UEKPRIMOegbsGLLR dHg1U8e5GOJ+WdOPcDTeh0PW0jU5KgChCGzcu/go7qohRdgAKyz2uWN9X2jvdaBgXOdf Ly+A== X-Gm-Message-State: AOAM5306C3flXU/Bak40wfqAaizamRS+juX3TtVO2hCtET4gAX2erlFX 3xIFgwkWyep9Xykr/vkt84mqx8FsmAfNHC6dypYYIg== X-Google-Smtp-Source: ABdhPJwQZTOndOswoznr4jIdbifDR0MYz9RpPxhjf7IzSWUSiuJuCvbnhhfpLLB8iyv5Z6bYZhTy4aj9n/pA0Bs95D8= X-Received: by 2002:a5d:4390:: with SMTP id i16mr22439040wrq.186.1590606346792; Wed, 27 May 2020 12:05:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Wed, 27 May 2020 15:05:35 -0400 Message-ID: To: John R Levine Cc: dnsop Content-Type: multipart/alternative; boundary="00000000000047968405a6a5e63a" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 19:05:51 -0000 --00000000000047968405a6a5e63a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should also note though that Chrome's built-in stub won't do any followup queries if the full chain is not in the response from the recursive. On Wed, May 27, 2020 at 3:03 PM Eric Orth wrote: > > > On Wed, May 27, 2020 at 1:49 PM John R Levine wrote: > >> While I should have been doing something else, I made a rather long CNAM= E >> chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I >> warmed up my cache five links at a time by looking for chain5, chain10, >> chain15, and so forth, it worked. At least it worked in "dig" and >> "host". >> When I try and look up http://chain.examp1e.com, Chrome waits a while >> and says not found, > > > If Chrome is using its built-in stub, there's not expected to be a limit > (other than the overall message size limits), but nothing tests chains th= is > long other than security fuzzers that are only looking for crashes or > memory issues. > > >> Firefox waits a while and says "Hmm. We=E2=80=99re having >> trouble finding that site." and Safari on my Mac hangs. (Feel free to >> try >> it yourself.) >> >> I realize the answer to most questions like this can be summarized as >> "don't do that", but is there any consensus as to the maximum CNAME chai= n >> length that works reliably, and what happens if the chain is too long? >> Hanging seems sub-optimal. >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.l= y >> >> $ dig chain.examp1e.com A >> ;; Truncated, retrying in TCP mode. >> >> ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: = 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;chain.examp1e.com. IN A >> >> ;; ANSWER SECTION: >> chain.examp1e.com. 3371 IN CNAME chain100.examp1e.com. >> chain100.examp1e.com. 3371 IN CNAME chain99.examp1e.com. >> chain99.examp1e.com. 3371 IN CNAME chain98.examp1e.com. >> chain98.examp1e.com. 3371 IN CNAME chain97.examp1e.com. >> chain97.examp1e.com. 3371 IN CNAME chain96.examp1e.com. >> chain96.examp1e.com. 3372 IN CNAME chain95.examp1e.com. >> chain95.examp1e.com. 3372 IN CNAME chain94.examp1e.com. >> chain94.examp1e.com. 3372 IN CNAME chain93.examp1e.com. >> chain93.examp1e.com. 3372 IN CNAME chain92.examp1e.com. >> chain92.examp1e.com. 3589 IN CNAME chain91.examp1e.com. >> chain91.examp1e.com. 3589 IN CNAME chain90.examp1e.com. >> chain90.examp1e.com. 3583 IN CNAME chain89.examp1e.com. >> chain89.examp1e.com. 3583 IN CNAME chain88.examp1e.com. >> chain88.examp1e.com. 3583 IN CNAME chain87.examp1e.com. >> chain87.examp1e.com. 3583 IN CNAME chain86.examp1e.com. >> chain86.examp1e.com. 3583 IN CNAME chain85.examp1e.com. >> chain85.examp1e.com. 3577 IN CNAME chain84.examp1e.com. >> chain84.examp1e.com. 3578 IN CNAME chain83.examp1e.com. >> chain83.examp1e.com. 3578 IN CNAME chain82.examp1e.com. >> chain82.examp1e.com. 3578 IN CNAME chain81.examp1e.com. >> chain81.examp1e.com. 3579 IN CNAME chain80.examp1e.com. >> chain80.examp1e.com. 3570 IN CNAME chain79.examp1e.com. >> chain79.examp1e.com. 3571 IN CNAME chain78.examp1e.com. >> chain78.examp1e.com. 3571 IN CNAME chain77.examp1e.com. >> chain77.examp1e.com. 3571 IN CNAME chain76.examp1e.com. >> chain76.examp1e.com. 3572 IN CNAME chain75.examp1e.com. >> chain75.examp1e.com. 3564 IN CNAME chain74.examp1e.com. >> chain74.examp1e.com. 3564 IN CNAME chain73.examp1e.com. >> chain73.examp1e.com. 3564 IN CNAME chain72.examp1e.com. >> chain72.examp1e.com. 3564 IN CNAME chain71.examp1e.com. >> chain71.examp1e.com. 3564 IN CNAME chain70.examp1e.com. >> chain70.examp1e.com. 3519 IN CNAME chain69.examp1e.com. >> chain69.examp1e.com. 3519 IN CNAME chain68.examp1e.com. >> chain68.examp1e.com. 3519 IN CNAME chain67.examp1e.com. >> chain67.examp1e.com. 3519 IN CNAME chain66.examp1e.com. >> chain66.examp1e.com. 3519 IN CNAME chain65.examp1e.com. >> chain65.examp1e.com. 3519 IN CNAME chain64.examp1e.com. >> chain64.examp1e.com. 3520 IN CNAME chain63.examp1e.com. >> chain63.examp1e.com. 3520 IN CNAME chain62.examp1e.com. >> chain62.examp1e.com. 3520 IN CNAME chain61.examp1e.com. >> chain61.examp1e.com. 3554 IN CNAME chain60.examp1e.com. >> chain60.examp1e.com. 3549 IN CNAME chain59.examp1e.com. >> chain59.examp1e.com. 3549 IN CNAME chain58.examp1e.com. >> chain58.examp1e.com. 3549 IN CNAME chain57.examp1e.com. >> chain57.examp1e.com. 3549 IN CNAME chain56.examp1e.com. >> chain56.examp1e.com. 3549 IN CNAME chain55.examp1e.com. >> chain55.examp1e.com. 3535 IN CNAME chain54.examp1e.com. >> chain54.examp1e.com. 3536 IN CNAME chain53.examp1e.com. >> chain53.examp1e.com. 3536 IN CNAME chain52.examp1e.com. >> chain52.examp1e.com. 3536 IN CNAME chain51.examp1e.com. >> chain51.examp1e.com. 3536 IN CNAME chain50.examp1e.com. >> chain50.examp1e.com. 3536 IN CNAME chain49.examp1e.com. >> chain49.examp1e.com. 3536 IN CNAME chain48.examp1e.com. >> chain48.examp1e.com. 3536 IN CNAME chain47.examp1e.com. >> chain47.examp1e.com. 3536 IN CNAME chain46.examp1e.com. >> chain46.examp1e.com. 3541 IN CNAME chain45.examp1e.com. >> chain45.examp1e.com. 3531 IN CNAME chain44.examp1e.com. >> chain44.examp1e.com. 3531 IN CNAME chain43.examp1e.com. >> chain43.examp1e.com. 3531 IN CNAME chain42.examp1e.com. >> chain42.examp1e.com. 3531 IN CNAME chain41.examp1e.com. >> chain41.examp1e.com. 3531 IN CNAME chain40.examp1e.com. >> chain40.examp1e.com. 3525 IN CNAME chain39.examp1e.com. >> chain39.examp1e.com. 3526 IN CNAME chain38.examp1e.com. >> chain38.examp1e.com. 3526 IN CNAME chain37.examp1e.com. >> chain37.examp1e.com. 3526 IN CNAME chain36.examp1e.com. >> chain36.examp1e.com. 3526 IN CNAME chain35.examp1e.com. >> chain35.examp1e.com. 3513 IN CNAME chain34.examp1e.com. >> chain34.examp1e.com. 3513 IN CNAME chain33.examp1e.com. >> chain33.examp1e.com. 3513 IN CNAME chain32.examp1e.com. >> chain32.examp1e.com. 3513 IN CNAME chain31.examp1e.com. >> chain31.examp1e.com. 3513 IN CNAME chain30.examp1e.com. >> chain30.examp1e.com. 3508 IN CNAME chain29.examp1e.com. >> chain29.examp1e.com. 3508 IN CNAME chain28.examp1e.com. >> chain28.examp1e.com. 3508 IN CNAME chain27.examp1e.com. >> chain27.examp1e.com. 3508 IN CNAME chain26.examp1e.com. >> chain26.examp1e.com. 3508 IN CNAME chain25.examp1e.com. >> chain25.examp1e.com. 3499 IN CNAME chain24.examp1e.com. >> chain24.examp1e.com. 3499 IN CNAME chain23.examp1e.com. >> chain23.examp1e.com. 3500 IN CNAME chain22.examp1e.com. >> chain22.examp1e.com. 3500 IN CNAME chain21.examp1e.com. >> chain21.examp1e.com. 3500 IN CNAME chain20.examp1e.com. >> chain20.examp1e.com. 3447 IN CNAME chain19.examp1e.com. >> chain19.examp1e.com. 3447 IN CNAME chain18.examp1e.com. >> chain18.examp1e.com. 3447 IN CNAME chain17.examp1e.com. >> chain17.examp1e.com. 3448 IN CNAME chain16.examp1e.com. >> chain16.examp1e.com. 3448 IN CNAME chain15.examp1e.com. >> chain15.examp1e.com. 3448 IN CNAME chain14.examp1e.com. >> chain14.examp1e.com. 3448 IN CNAME chain13.examp1e.com. >> chain13.examp1e.com. 3448 IN CNAME chain12.examp1e.com. >> chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. >> chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. >> chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. >> chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. >> chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. >> chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. >> chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. >> chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. >> chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. >> chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. >> chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. >> chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. >> chain0.examp1e.com. 3460 IN A 64.57.183.119 >> >> ;; Query time: 2 msec >> ;; SERVER: 192.168.80.2#53(192.168.80.2) >> ;; WHEN: Wed May 27 13:31:17 EDT 2020 >> ;; MSG SIZE rcvd: 2275 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > --00000000000047968405a6a5e63a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I should also note though that Chrome's built-in = stub won't do any followup queries if the full chain is not in the resp= onse from the recursive.

On Wed, May 27, 2020 at 3:03 PM Eric Orth <ericorth@google.com> wrote:


On Wed, May 27, 2020 at 1:49 PM John R Levine <johnl@taugh.com> wrote= :
While I should= have been doing something else, I made a rather long CNAME
chain.=C2=A0 When I looked up chain.examp1e.com it got SERVFAIL, but aft= er I
warmed up my cache five links at a time by looking for chain5, chain10, chain15, and so forth, it worked.=C2=A0 At least it worked in "dig&quo= t; and "host".
When I try and look up http://chain.examp1e.com, Chrome waits a while and says not found,

If Chrome is using its = built-in stub, there's not expected to be a limit (other than the overa= ll message size limits), but nothing tests chains this long other than secu= rity fuzzers that are only looking for crashes or memory issues.
= =C2=A0
Firefox waits= a while and says "Hmm. We=E2=80=99re having
trouble finding that site." and Safari on my Mac hangs.=C2=A0 (Feel fr= ee to try
it yourself.)

I realize the answer to most questions like this can be summarized as
"don't do that", but is there any consensus as to the maximum= CNAME chain
length that works reliably, and what happens if the chain is too long?
Hanging seems sub-optimal.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

$ dig chain.examp1e.com A
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.6 <<>> chain.examp1e.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;= chain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IN=C2= =A0 =C2=A0 =C2=A0 A

;; ANSWER SECTION:
c= hain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0= =C2=A0 CNAME=C2=A0 =C2=A0chain100.examp1e.com.
chain100.examp1e.com.=C2=A0 =C2=A03371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain99.examp1e.com.
chain99.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain98.examp1e.com.
chain98.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain97.examp1e.com.
chain97.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain96.examp1e.com.
chain96.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain95.examp1e.com.
chain95.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain94.examp1e.com.
chain94.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain93.examp1e.com.
chain93.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain92.examp1e.com.
chain92.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain91.examp1e.com.
chain91.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain90.examp1e.com.
chain90.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain89.examp1e.com.
chain89.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain88.examp1e.com.
chain88.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain87.examp1e.com.
chain87.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain86.examp1e.com.
chain86.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain85.examp1e.com.
chain85.examp1e.com.=C2=A0 =C2=A0 3577=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain84.examp1e.com.
chain84.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain83.examp1e.com.
chain83.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain82.examp1e.com.
chain82.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain81.examp1e.com.
chain81.examp1e.com.=C2=A0 =C2=A0 3579=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain80.examp1e.com.
chain80.examp1e.com.=C2=A0 =C2=A0 3570=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain79.examp1e.com.
chain79.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain78.examp1e.com.
chain78.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain77.examp1e.com.
chain77.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain76.examp1e.com.
chain76.examp1e.com.=C2=A0 =C2=A0 3572=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain75.examp1e.com.
chain75.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain74.examp1e.com.
chain74.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain73.examp1e.com.
chain73.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain72.examp1e.com.
chain72.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain71.examp1e.com.
chain71.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain70.examp1e.com.
chain70.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain69.examp1e.com.
chain69.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain68.examp1e.com.
chain68.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain67.examp1e.com.
chain67.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain66.examp1e.com.
chain66.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain65.examp1e.com.
chain65.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain64.examp1e.com.
chain64.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain63.examp1e.com.
chain63.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain62.examp1e.com.
chain62.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain61.examp1e.com.
chain61.examp1e.com.=C2=A0 =C2=A0 3554=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain60.examp1e.com.
chain60.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain59.examp1e.com.
chain59.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain58.examp1e.com.
chain58.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain57.examp1e.com.
chain57.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain56.examp1e.com.
chain56.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain55.examp1e.com.
chain55.examp1e.com.=C2=A0 =C2=A0 3535=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain54.examp1e.com.
chain54.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain53.examp1e.com.
chain53.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain52.examp1e.com.
chain52.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain51.examp1e.com.
chain51.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain50.examp1e.com.
chain50.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain49.examp1e.com.
chain49.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain48.examp1e.com.
chain48.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain47.examp1e.com.
chain47.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain46.examp1e.com.
chain46.examp1e.com.=C2=A0 =C2=A0 3541=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain45.examp1e.com.
chain45.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain44.examp1e.com.
chain44.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain43.examp1e.com.
chain43.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain42.examp1e.com.
chain42.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain41.examp1e.com.
chain41.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain40.examp1e.com.
chain40.examp1e.com.=C2=A0 =C2=A0 3525=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain39.examp1e.com.
chain39.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain38.examp1e.com.
chain38.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain37.examp1e.com.
chain37.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain36.examp1e.com.
chain36.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain35.examp1e.com.
chain35.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain34.examp1e.com.
chain34.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain33.examp1e.com.
chain33.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain32.examp1e.com.
chain32.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain31.examp1e.com.
chain31.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain30.examp1e.com.
chain30.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain29.examp1e.com.
chain29.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain28.examp1e.com.
chain28.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain27.examp1e.com.
chain27.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain26.examp1e.com.
chain26.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain25.examp1e.com.
chain25.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain24.examp1e.com.
chain24.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain23.examp1e.com.
chain23.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain22.examp1e.com.
chain22.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain21.examp1e.com.
chain21.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain20.examp1e.com.
chain20.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain19.examp1e.com.
chain19.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain18.examp1e.com.
chain18.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain17.examp1e.com.
chain17.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain16.examp1e.com.
chain16.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain15.examp1e.com.
chain15.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain14.examp1e.com.
chain14.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain13.examp1e.com.
chain13.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain12.examp1e.com.
chain12.examp1e.com.=C2=A0 =C2=A0 3449=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain11.examp1e.com.
chain11.examp1e.com.=C2=A0 =C2=A0 3486=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain10.examp1e.com.
chain10.examp1e.com.=C2=A0 =C2=A0 3455=C2=A0 =C2=A0 IN=C2=A0 =C2=A0 = =C2=A0 CNAME=C2=A0 =C2=A0chain9.examp1e.com.
= chain9.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain8.examp1e.com.
= chain8.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain7.examp1e.com.
= chain7.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain6.examp1e.com.
= chain6.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain5.examp1e.com.
= chain5.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain4.examp1e.com.
= chain4.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain3.examp1e.com.
= chain3.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain2.examp1e.com.
= chain2.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain1.examp1e.com.
= chain1.examp1e.com.=C2=A0 =C2=A0 =C2=A03466=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 CNAME=C2=A0 =C2=A0chain0.examp1e.com.
= chain0.examp1e.com.=C2=A0 =C2=A0 =C2=A03460=C2=A0 =C2=A0 IN=C2=A0 =C2= =A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A064.57.183.119

;; Query time: 2 msec
;; SERVER: 192.168.80.2#53(192.168.80.2)
;; WHEN: Wed May 27 13:31:17 EDT 2020
;; MSG SIZE=C2=A0 rcvd: 2275
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000047968405a6a5e63a-- From nobody Wed May 27 12:23:54 2020 Return-Path: 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 1C0AE3A0A03 for ; Wed, 27 May 2020 12:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bER5pJtk; dkim=pass (1536-bit key) header.d=taugh.com header.b=LgK0cVoA 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 h38cKNEPuWWr for ; Wed, 27 May 2020 12:23:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2CC9F3A0A29 for ; Wed, 27 May 2020 12:23:42 -0700 (PDT) Received: (qmail 19419 invoked from network); 27 May 2020 19:23:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4bd9.5ecebe3c.k2005; i=johnl-iecc.com@submit.iecc.com; bh=tKDsj/lJ1jOgG6+p5sASHK8qV3cN628vraVehu/+5vE=; b=bER5pJtk9zx3xWM4FZej9Ssgr828nziVL2kHJ4mXe/UbXEGbXjeUv5kaapQSbZmy93HnFeVbE3AT2nGESQqKFzpRK5IFDZW0ArXP2F/bJcXo51lzbsza7VZOPDTjUruXpTIE9JYuccu+4FdSRhJikiNYw/pQkoMnhrWmvJVlChtu+hJW6DF7/cSyButWNyV6VJVQcm7wsiwUQsO5C6EWpwPljd5erMuVPgwXCFwvmfKd0qu45KQZ4wyqy2WXKlA3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4bd9.5ecebe3c.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=tKDsj/lJ1jOgG6+p5sASHK8qV3cN628vraVehu/+5vE=; b=LgK0cVoAq/V1tRUX4DHpYUyUFnFIZtFqXMu2POmyK2EP+QH3H9pFVCUD8pAER0A0xeg27eB8GPvP1ECEaCfPWUJMu5YHii9//1wfAie/Soy2zqG94TShWb7E7WGO2YInT2ZOoVx9KQ55nfPdgnjAbsDfcM+ZvQeqWYMNeWTpzoAu5SvEZm46JUH43YyAySSjKYPVtCvcAOc0oe+FSKpMudxk9oV4EZ6j0bpkt8b5CeUKgGN1lKYISOkcSKo9aVTX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2020 19:23:39 -0000 Date: 27 May 2020 15:23:39 -0400 Message-ID: From: "John R Levine" To: "Eric Orth" Cc: "dnsop" In-Reply-To: References: User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2014908202-1590607419=:35864" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 19:23:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2014908202-1590607419=:35864 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > I should also note though that Chrome's built-in stub won't do any followup > queries if the full chain is not in the response from the recursive. Interesting point -- if the result is truncated will it requery with TCP? > > On Wed, May 27, 2020 at 3:03 PM Eric Orth wrote: > >> >> >> On Wed, May 27, 2020 at 1:49 PM John R Levine wrote: >> >>> While I should have been doing something else, I made a rather long CNAME >>> chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I >>> warmed up my cache five links at a time by looking for chain5, chain10, >>> chain15, and so forth, it worked. At least it worked in "dig" and >>> "host". >>> When I try and look up http://chain.examp1e.com, Chrome waits a while >>> and says not found, >> >> >> If Chrome is using its built-in stub, there's not expected to be a limit >> (other than the overall message size limits), but nothing tests chains this >> long other than security fuzzers that are only looking for crashes or >> memory issues. >> >> >>> Firefox waits a while and says "Hmm. We’re having >>> trouble finding that site." and Safari on my Mac hangs. (Feel free to >>> try >>> it yourself.) >>> >>> I realize the answer to most questions like this can be summarized as >>> "don't do that", but is there any consensus as to the maximum CNAME chain >>> length that works reliably, and what happens if the chain is too long? >>> Hanging seems sub-optimal. >>> >>> Regards, >>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >>> Please consider the environment before reading this e-mail. https://jl.ly >>> >>> $ dig chain.examp1e.com A >>> ;; Truncated, retrying in TCP mode. >>> >>> ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001 >>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;chain.examp1e.com. IN A >>> >>> ;; ANSWER SECTION: >>> chain.examp1e.com. 3371 IN CNAME chain100.examp1e.com. >>> chain100.examp1e.com. 3371 IN CNAME chain99.examp1e.com. >>> chain99.examp1e.com. 3371 IN CNAME chain98.examp1e.com. >>> chain98.examp1e.com. 3371 IN CNAME chain97.examp1e.com. >>> chain97.examp1e.com. 3371 IN CNAME chain96.examp1e.com. >>> chain96.examp1e.com. 3372 IN CNAME chain95.examp1e.com. >>> chain95.examp1e.com. 3372 IN CNAME chain94.examp1e.com. >>> chain94.examp1e.com. 3372 IN CNAME chain93.examp1e.com. >>> chain93.examp1e.com. 3372 IN CNAME chain92.examp1e.com. >>> chain92.examp1e.com. 3589 IN CNAME chain91.examp1e.com. >>> chain91.examp1e.com. 3589 IN CNAME chain90.examp1e.com. >>> chain90.examp1e.com. 3583 IN CNAME chain89.examp1e.com. >>> chain89.examp1e.com. 3583 IN CNAME chain88.examp1e.com. >>> chain88.examp1e.com. 3583 IN CNAME chain87.examp1e.com. >>> chain87.examp1e.com. 3583 IN CNAME chain86.examp1e.com. >>> chain86.examp1e.com. 3583 IN CNAME chain85.examp1e.com. >>> chain85.examp1e.com. 3577 IN CNAME chain84.examp1e.com. >>> chain84.examp1e.com. 3578 IN CNAME chain83.examp1e.com. >>> chain83.examp1e.com. 3578 IN CNAME chain82.examp1e.com. >>> chain82.examp1e.com. 3578 IN CNAME chain81.examp1e.com. >>> chain81.examp1e.com. 3579 IN CNAME chain80.examp1e.com. >>> chain80.examp1e.com. 3570 IN CNAME chain79.examp1e.com. >>> chain79.examp1e.com. 3571 IN CNAME chain78.examp1e.com. >>> chain78.examp1e.com. 3571 IN CNAME chain77.examp1e.com. >>> chain77.examp1e.com. 3571 IN CNAME chain76.examp1e.com. >>> chain76.examp1e.com. 3572 IN CNAME chain75.examp1e.com. >>> chain75.examp1e.com. 3564 IN CNAME chain74.examp1e.com. >>> chain74.examp1e.com. 3564 IN CNAME chain73.examp1e.com. >>> chain73.examp1e.com. 3564 IN CNAME chain72.examp1e.com. >>> chain72.examp1e.com. 3564 IN CNAME chain71.examp1e.com. >>> chain71.examp1e.com. 3564 IN CNAME chain70.examp1e.com. >>> chain70.examp1e.com. 3519 IN CNAME chain69.examp1e.com. >>> chain69.examp1e.com. 3519 IN CNAME chain68.examp1e.com. >>> chain68.examp1e.com. 3519 IN CNAME chain67.examp1e.com. >>> chain67.examp1e.com. 3519 IN CNAME chain66.examp1e.com. >>> chain66.examp1e.com. 3519 IN CNAME chain65.examp1e.com. >>> chain65.examp1e.com. 3519 IN CNAME chain64.examp1e.com. >>> chain64.examp1e.com. 3520 IN CNAME chain63.examp1e.com. >>> chain63.examp1e.com. 3520 IN CNAME chain62.examp1e.com. >>> chain62.examp1e.com. 3520 IN CNAME chain61.examp1e.com. >>> chain61.examp1e.com. 3554 IN CNAME chain60.examp1e.com. >>> chain60.examp1e.com. 3549 IN CNAME chain59.examp1e.com. >>> chain59.examp1e.com. 3549 IN CNAME chain58.examp1e.com. >>> chain58.examp1e.com. 3549 IN CNAME chain57.examp1e.com. >>> chain57.examp1e.com. 3549 IN CNAME chain56.examp1e.com. >>> chain56.examp1e.com. 3549 IN CNAME chain55.examp1e.com. >>> chain55.examp1e.com. 3535 IN CNAME chain54.examp1e.com. >>> chain54.examp1e.com. 3536 IN CNAME chain53.examp1e.com. >>> chain53.examp1e.com. 3536 IN CNAME chain52.examp1e.com. >>> chain52.examp1e.com. 3536 IN CNAME chain51.examp1e.com. >>> chain51.examp1e.com. 3536 IN CNAME chain50.examp1e.com. >>> chain50.examp1e.com. 3536 IN CNAME chain49.examp1e.com. >>> chain49.examp1e.com. 3536 IN CNAME chain48.examp1e.com. >>> chain48.examp1e.com. 3536 IN CNAME chain47.examp1e.com. >>> chain47.examp1e.com. 3536 IN CNAME chain46.examp1e.com. >>> chain46.examp1e.com. 3541 IN CNAME chain45.examp1e.com. >>> chain45.examp1e.com. 3531 IN CNAME chain44.examp1e.com. >>> chain44.examp1e.com. 3531 IN CNAME chain43.examp1e.com. >>> chain43.examp1e.com. 3531 IN CNAME chain42.examp1e.com. >>> chain42.examp1e.com. 3531 IN CNAME chain41.examp1e.com. >>> chain41.examp1e.com. 3531 IN CNAME chain40.examp1e.com. >>> chain40.examp1e.com. 3525 IN CNAME chain39.examp1e.com. >>> chain39.examp1e.com. 3526 IN CNAME chain38.examp1e.com. >>> chain38.examp1e.com. 3526 IN CNAME chain37.examp1e.com. >>> chain37.examp1e.com. 3526 IN CNAME chain36.examp1e.com. >>> chain36.examp1e.com. 3526 IN CNAME chain35.examp1e.com. >>> chain35.examp1e.com. 3513 IN CNAME chain34.examp1e.com. >>> chain34.examp1e.com. 3513 IN CNAME chain33.examp1e.com. >>> chain33.examp1e.com. 3513 IN CNAME chain32.examp1e.com. >>> chain32.examp1e.com. 3513 IN CNAME chain31.examp1e.com. >>> chain31.examp1e.com. 3513 IN CNAME chain30.examp1e.com. >>> chain30.examp1e.com. 3508 IN CNAME chain29.examp1e.com. >>> chain29.examp1e.com. 3508 IN CNAME chain28.examp1e.com. >>> chain28.examp1e.com. 3508 IN CNAME chain27.examp1e.com. >>> chain27.examp1e.com. 3508 IN CNAME chain26.examp1e.com. >>> chain26.examp1e.com. 3508 IN CNAME chain25.examp1e.com. >>> chain25.examp1e.com. 3499 IN CNAME chain24.examp1e.com. >>> chain24.examp1e.com. 3499 IN CNAME chain23.examp1e.com. >>> chain23.examp1e.com. 3500 IN CNAME chain22.examp1e.com. >>> chain22.examp1e.com. 3500 IN CNAME chain21.examp1e.com. >>> chain21.examp1e.com. 3500 IN CNAME chain20.examp1e.com. >>> chain20.examp1e.com. 3447 IN CNAME chain19.examp1e.com. >>> chain19.examp1e.com. 3447 IN CNAME chain18.examp1e.com. >>> chain18.examp1e.com. 3447 IN CNAME chain17.examp1e.com. >>> chain17.examp1e.com. 3448 IN CNAME chain16.examp1e.com. >>> chain16.examp1e.com. 3448 IN CNAME chain15.examp1e.com. >>> chain15.examp1e.com. 3448 IN CNAME chain14.examp1e.com. >>> chain14.examp1e.com. 3448 IN CNAME chain13.examp1e.com. >>> chain13.examp1e.com. 3448 IN CNAME chain12.examp1e.com. >>> chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. >>> chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. >>> chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. >>> chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. >>> chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. >>> chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. >>> chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. >>> chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. >>> chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. >>> chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. >>> chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. >>> chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. >>> chain0.examp1e.com. 3460 IN A 64.57.183.119 >>> >>> ;; Query time: 2 msec >>> ;; SERVER: 192.168.80.2#53(192.168.80.2) >>> ;; WHEN: Wed May 27 13:31:17 EDT 2020 >>> ;; MSG SIZE rcvd: 2275 >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-2014908202-1590607419=:35864-- From nobody Wed May 27 12:26:29 2020 Return-Path: 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 F0EE23A0A36 for ; Wed, 27 May 2020 12:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HTE3pcsZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=VZcpZ3mX 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 uJUG25f5ohEa for ; Wed, 27 May 2020 12:26:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 C0D1C3A0A34 for ; Wed, 27 May 2020 12:26:24 -0700 (PDT) Received: (qmail 19805 invoked from network); 27 May 2020 19:26:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4d5b.5ecebedf.k2005; i=johnl-iecc.com@submit.iecc.com; bh=+JEfaBeUSugsb5DlF56d2SX5hYzurZqbjJmvn1qODZo=; b=HTE3pcsZNVf8O7SCuKZIx3wVMbNn7hqUzFrLK8CTGEUGo/weJanSJpSzSpRGa4ChWmxFVqpH8uj7Hzn/DTlj5BgNDdHpdADKq7BIgRku20XDKdH28iOYE5iPnd5AxV3Y0N3spOhehBqd4nUTh1gHKUevhhaIGQ5i8W4z1IOwWbO9mjkhKsOxMLXsMBBddvjiSj1Fm1Id3S1OEWpi+P/z3cUcPs2LGtMkvojTt3bBEXDlK/EvksOK8hsEEtSkZIaH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4d5b.5ecebedf.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=+JEfaBeUSugsb5DlF56d2SX5hYzurZqbjJmvn1qODZo=; b=VZcpZ3mXVxSj1IkMdSib9dJbsJmNgFGrU19/rZV0/h58sfhvmh0phxcFo0nbyempGQqpGXOZar+fLEDgpo2CcezmK9v3SXJ0uBe3aYA+WEqNcxq9lgklTW8yk/0IzDISQj2NHOXh+kr08NLP5YL0YDU0c53ooYsKT8/oFStFiYSFQbpLiS2zvCHJO0/0DulHsc4qBJo/oSZX9j7Tq5zxvSulvcqiivztGRHSDy8qpBOORfEetqpsFhr42ueuVqen Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 27 May 2020 19:26:23 -0000 Date: 27 May 2020 15:26:23 -0400 Message-ID: From: "John R Levine" To: "Eric Orth" Cc: "dnsop" In-Reply-To: References: User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 19:26:27 -0000 >> While I should have been doing something else, I made a rather long CNAME >> chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I >> warmed up my cache five links at a time by looking for chain5, chain10, >> chain15, and so forth, it worked. At least it worked in "dig" and "host". >> When I try and look up http://chain.examp1e.com, Chrome waits a while >> and says not found, > > If Chrome is using its built-in stub, there's not expected to be a limit > (other than the overall message size limits), but nothing tests chains this > long other than security fuzzers that are only looking for crashes or > memory issues. On my Mac, I get surprisingly consietent browser results. In Chrome, Firefox, and Safari, chain10.examp1e.com works, chain11.examp1e.com fails slowly. From the TTLs I get from dig, it appears that none of them are using the resolver to follow the CNAME chains. For Firefox I have the canary domain blocked so I dunno what it is doing. >> chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. >> chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. >> chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. >> chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. >> chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. >> chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. >> chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. >> chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. >> chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. >> chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. >> chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. >> chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. >> chain0.examp1e.com. 3460 IN A 64.57.183.119 Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 27 13:06:18 2020 Return-Path: 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 EF0B33A0B15 for ; Wed, 27 May 2020 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 agATvKQBpvz2 for ; Wed, 27 May 2020 13:06:15 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39D3A0B12 for ; Wed, 27 May 2020 13:06:15 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id 841AF26547F; Wed, 27 May 2020 20:06:14 +0000 (UTC) Date: Wed, 27 May 2020 20:06:14 +0000 From: dagon To: Evan Hunt Cc: John R Levine , dnsop@ietf.org Message-ID: <20200527200614.GC3582@sudo.sh> References: <20200527180846.GA51895@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200527180846.GA51895@isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 20:06:17 -0000 On Wed, May 27, 2020 at 06:08:46PM +0000, Evan Hunt wrote: > On Wed, May 27, 2020 at 01:48:32PM -0400, John R Levine wrote: > > is there any consensus as to the maximum CNAME chain length > > that works reliably, and what happens if the chain is too long? Hanging > > seems sub-optimal. > > BIND cuts CNAME chains off at 16. As far as I know that was an arbitrarily- > selected value, but it's been in the code since 1999 and so far as I can > recall, no one's complained. The maximum reliable chain length won't be any > longer than that; it might be shorter. > > When a chain is too long, I think BIND just returns a response with the 16 > CNAMEs it's found so far, and without a final answer. The client can start a > new query from where the response left off, but I would expect most to > treat it as a non-answer. This is an interesting topic. Some recursives cut off at 8 CNAME chains. Some (Level 3, if I recall) fail at less, but retry right after sending SERVFAIL or RCODE!=0 to the stub, perhaps to populate cache farms. Some major "cloud DNS" (e.g., Google if I recall) chase 30 chains before fail. Some appear to have a ~3-sec window for the outbound queries (meaning they have no chain count limit, only time); some appear to have a hard numbered limit like BIND. Poorly crafted DNS crawler scripts seem to follow CNAMEs forever (up to some script mediated timeout period, or until the operator stops the script and complains to the parent zone's registrar, on the theory that unexpected behavior is abuse---despite CNAME chains being useful for path diagnosis in VPN operation, passive DNS monitoring, etc.) The CNAME behavioral matrix can also be extended to include: -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some recursive speakers fail; some complain ("BAD (HORIZONTAL) REFERRAL", but answer), and some follow without complaint. -- All should avoid graph cycles in CNAME chains back to ancestral records. -- Tests for slow responses, where the authority crafting the CNAME delays by some variable millisecond time period, to test whether the chain depth is time or count based. -- One could test for 1034 s.3.6.2 restart to chase discovered CNAMEs, absent additional records being added to cache. Some platforms (Azure, if I recall) return just the CNAME, even if local cache (evidently) holds a terminating record. I've not tested if this (re)introduces circular dependencies, but Azure(?)'s explanation would be that the restart and cycle detection must now occur in the stub. But one should test with/without BIND's minimal-responses (and similar configurations in other recursives), and implications for cycles. -- All of the above, but for DNAME instead of CNAME. PowerDNS will not support this of course, for what I infer are (understandable) architectural and commercial demand reasons. But conceptually an authority creating synthetic CNAME records is a workable substitute for DNAMEs. Some DNAME chase limits follow the CNAME chain limits. One can chain multiple CNAME chains together using DNAME, and this may count against the original chain counter, or start a new one (and sometimes within some timeout period of course). This also stops many script-based crawlers, which don't handle DNAMEs or don't bother to substitute synthesize the query under the new zone tree. (I.e., they appear to cut/grep DNAME answers, and not handle out-zone synthesis, making them blind to the referral subzones.) -- Same, but for so-called ANAME or 'rooted CNAME' records. -- Measure all of these behaviors tests where the NS has essentially zero TTL (e.g., to measure whether retries are with/without NS delegation rediscovery). -- Measure all of the above with/without DNS authorities that are whitelisted for EDNS Client Subnet. (It is hard to think of a reason to allow ECS in a CNAME, PTR, or similarly constrained query type. But some architectures use "turtles all the way down", and the CDN itself needs a CDN via ECS, which then needs a CDN via ECS, etc. I've tested all of these combinations and more. There are also many valid commercial uses for CNAME chains beyond CDN and zone agility (e.g., path discovery, edns-client-subnet testing, etc.) So blocking/limiting CNAME chains seems unwise. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Wed May 27 13:33:58 2020 Return-Path: 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 816153A0C08 for ; Wed, 27 May 2020 13:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.79 X-Spam-Level: X-Spam-Status: No, score=-14.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, FSL_BULK_SIG=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Hz6GQBSXad0f for ; Wed, 27 May 2020 13:33:46 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 213283A0BE9 for ; Wed, 27 May 2020 13:33:44 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id j16so13086246wrb.7 for ; Wed, 27 May 2020 13:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9BD/RXAeE5KeZkfMmz7z/0e3fvNHRZf0S0tvFyaDWL4=; b=QATe8HxgDQs7JyEVt2+l39Ptjp5IRtxuQoQ66O1BTK15edojF29ZCatsqhQK+1V5h+ V4G4ZX5wUlSdP3Yuuxkqigvt5FNAR8HGkT2uezG1wJAqiDMJPyt49aZVVblDonX7oK6p xCN7SeVTGSz8mE5u2NwgqV3PUdwRZrrvljPG/QnmNhLfnLPV0l6ByBStOiQ5uHzKNXHd DA/kebh4rlE20fQu7A94WSQ0j6RG5PA6oFuTo/RbhrHG8FZT9pEjjsyQYkbr+sPm1xuy qspULY2b34dxOJzNEWb9fTcJZwRjDA1URqv+aXTj1W21w0noQjZhii6nnRnEI+r2hq3O OFEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9BD/RXAeE5KeZkfMmz7z/0e3fvNHRZf0S0tvFyaDWL4=; b=j6ivIpQkP0nzFhl1hE1Gv4up63JIN/vUhkFBv0scv91ZSosDXTs19CYYOGIIAVqd+B b9NQ/vQNsI6GolCP4eujj0MHnS93WjhxD29u6y5ti/SlGOWtdnGO8Krmqs0FreZ8UcZ9 PAbUKN3UmoZCzpi0UzEVd+rrjBpwMJlPvarhniDWjYxWwqwx+DF2Mo9dub022mTWy034 iuYA30IvyMueRmMSWYnkwrOSzJ0jE3/u9iZoOlR58Sed+qRkzMypfVF7U4DTUvZHWLp2 VrDa8yOSA9dDiWS1WmJno/hD7tWd+PcY0ifGBLw1rjRZwOQ4kSoEy768GIQHii6QUwZb rq/A== X-Gm-Message-State: AOAM533yAzcrCSiiVtbqQvzUel/Fjty3HVSXt69CVcfyx7cEMqTu8VQD sh57FeE/4wNjZIQcDcDqJnv0E0M2tU7p9/q5ZNPd/w== X-Google-Smtp-Source: ABdhPJxyr58XSJiO1cF11DWHzzv078tfehWXfkNSiNk9HM+CSLPcRCAx0DM2ERRzt1j7SQvoVXpQqm+/0H0ilOAQ6to= X-Received: by 2002:adf:fdcc:: with SMTP id i12mr59614wrs.313.1590611622084; Wed, 27 May 2020 13:33:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Wed, 27 May 2020 16:33:30 -0400 Message-ID: To: John R Levine Cc: dnsop Content-Type: multipart/alternative; boundary="000000000000b6323e05a6a7203a" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 20:33:57 -0000 --000000000000b6323e05a6a7203a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2020 at 3:23 PM John R Levine wrote: > > I should also note though that Chrome's built-in stub won't do any > followup > > queries if the full chain is not in the response from the recursive. > > Interesting point -- if the result is truncated will it requery with TCP? > On TC bit, yes. > > > > > On Wed, May 27, 2020 at 3:03 PM Eric Orth wrote: > > > >> > >> > >> On Wed, May 27, 2020 at 1:49 PM John R Levine wrote: > >> > >>> While I should have been doing something else, I made a rather long > CNAME > >>> chain. When I looked up chain.examp1e.com it got SERVFAIL, but after > I > >>> warmed up my cache five links at a time by looking for chain5, chain1= 0, > >>> chain15, and so forth, it worked. At least it worked in "dig" and > >>> "host". > >>> When I try and look up http://chain.examp1e.com, Chrome waits a while > >>> and says not found, > >> > >> > >> If Chrome is using its built-in stub, there's not expected to be a lim= it > >> (other than the overall message size limits), but nothing tests chains > this > >> long other than security fuzzers that are only looking for crashes or > >> memory issues. > >> > >> > >>> Firefox waits a while and says "Hmm. We=E2=80=99re having > >>> trouble finding that site." and Safari on my Mac hangs. (Feel free t= o > >>> try > >>> it yourself.) > >>> > >>> I realize the answer to most questions like this can be summarized as > >>> "don't do that", but is there any consensus as to the maximum CNAME > chain > >>> length that works reliably, and what happens if the chain is too long= ? > >>> Hanging seems sub-optimal. > >>> > >>> Regards, > >>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > >>> Please consider the environment before reading this e-mail. > https://jl.ly > >>> > >>> $ dig chain.examp1e.com A > >>> ;; Truncated, retrying in TCP mode. > >>> > >>> ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a > >>> ;; global options: +cmd > >>> ;; Got answer: > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001 > >>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, > ADDITIONAL: 1 > >>> > >>> ;; OPT PSEUDOSECTION: > >>> ; EDNS: version: 0, flags:; udp: 4096 > >>> ;; QUESTION SECTION: > >>> ;chain.examp1e.com. IN A > >>> > >>> ;; ANSWER SECTION: > >>> chain.examp1e.com. 3371 IN CNAME chain100.examp1e.com. > >>> chain100.examp1e.com. 3371 IN CNAME chain99.examp1e.com. > >>> chain99.examp1e.com. 3371 IN CNAME chain98.examp1e.com. > >>> chain98.examp1e.com. 3371 IN CNAME chain97.examp1e.com. > >>> chain97.examp1e.com. 3371 IN CNAME chain96.examp1e.com. > >>> chain96.examp1e.com. 3372 IN CNAME chain95.examp1e.com. > >>> chain95.examp1e.com. 3372 IN CNAME chain94.examp1e.com. > >>> chain94.examp1e.com. 3372 IN CNAME chain93.examp1e.com. > >>> chain93.examp1e.com. 3372 IN CNAME chain92.examp1e.com. > >>> chain92.examp1e.com. 3589 IN CNAME chain91.examp1e.com. > >>> chain91.examp1e.com. 3589 IN CNAME chain90.examp1e.com. > >>> chain90.examp1e.com. 3583 IN CNAME chain89.examp1e.com. > >>> chain89.examp1e.com. 3583 IN CNAME chain88.examp1e.com. > >>> chain88.examp1e.com. 3583 IN CNAME chain87.examp1e.com. > >>> chain87.examp1e.com. 3583 IN CNAME chain86.examp1e.com. > >>> chain86.examp1e.com. 3583 IN CNAME chain85.examp1e.com. > >>> chain85.examp1e.com. 3577 IN CNAME chain84.examp1e.com. > >>> chain84.examp1e.com. 3578 IN CNAME chain83.examp1e.com. > >>> chain83.examp1e.com. 3578 IN CNAME chain82.examp1e.com. > >>> chain82.examp1e.com. 3578 IN CNAME chain81.examp1e.com. > >>> chain81.examp1e.com. 3579 IN CNAME chain80.examp1e.com. > >>> chain80.examp1e.com. 3570 IN CNAME chain79.examp1e.com. > >>> chain79.examp1e.com. 3571 IN CNAME chain78.examp1e.com. > >>> chain78.examp1e.com. 3571 IN CNAME chain77.examp1e.com. > >>> chain77.examp1e.com. 3571 IN CNAME chain76.examp1e.com. > >>> chain76.examp1e.com. 3572 IN CNAME chain75.examp1e.com. > >>> chain75.examp1e.com. 3564 IN CNAME chain74.examp1e.com. > >>> chain74.examp1e.com. 3564 IN CNAME chain73.examp1e.com. > >>> chain73.examp1e.com. 3564 IN CNAME chain72.examp1e.com. > >>> chain72.examp1e.com. 3564 IN CNAME chain71.examp1e.com. > >>> chain71.examp1e.com. 3564 IN CNAME chain70.examp1e.com. > >>> chain70.examp1e.com. 3519 IN CNAME chain69.examp1e.com. > >>> chain69.examp1e.com. 3519 IN CNAME chain68.examp1e.com. > >>> chain68.examp1e.com. 3519 IN CNAME chain67.examp1e.com. > >>> chain67.examp1e.com. 3519 IN CNAME chain66.examp1e.com. > >>> chain66.examp1e.com. 3519 IN CNAME chain65.examp1e.com. > >>> chain65.examp1e.com. 3519 IN CNAME chain64.examp1e.com. > >>> chain64.examp1e.com. 3520 IN CNAME chain63.examp1e.com. > >>> chain63.examp1e.com. 3520 IN CNAME chain62.examp1e.com. > >>> chain62.examp1e.com. 3520 IN CNAME chain61.examp1e.com. > >>> chain61.examp1e.com. 3554 IN CNAME chain60.examp1e.com. > >>> chain60.examp1e.com. 3549 IN CNAME chain59.examp1e.com. > >>> chain59.examp1e.com. 3549 IN CNAME chain58.examp1e.com. > >>> chain58.examp1e.com. 3549 IN CNAME chain57.examp1e.com. > >>> chain57.examp1e.com. 3549 IN CNAME chain56.examp1e.com. > >>> chain56.examp1e.com. 3549 IN CNAME chain55.examp1e.com. > >>> chain55.examp1e.com. 3535 IN CNAME chain54.examp1e.com. > >>> chain54.examp1e.com. 3536 IN CNAME chain53.examp1e.com. > >>> chain53.examp1e.com. 3536 IN CNAME chain52.examp1e.com. > >>> chain52.examp1e.com. 3536 IN CNAME chain51.examp1e.com. > >>> chain51.examp1e.com. 3536 IN CNAME chain50.examp1e.com. > >>> chain50.examp1e.com. 3536 IN CNAME chain49.examp1e.com. > >>> chain49.examp1e.com. 3536 IN CNAME chain48.examp1e.com. > >>> chain48.examp1e.com. 3536 IN CNAME chain47.examp1e.com. > >>> chain47.examp1e.com. 3536 IN CNAME chain46.examp1e.com. > >>> chain46.examp1e.com. 3541 IN CNAME chain45.examp1e.com. > >>> chain45.examp1e.com. 3531 IN CNAME chain44.examp1e.com. > >>> chain44.examp1e.com. 3531 IN CNAME chain43.examp1e.com. > >>> chain43.examp1e.com. 3531 IN CNAME chain42.examp1e.com. > >>> chain42.examp1e.com. 3531 IN CNAME chain41.examp1e.com. > >>> chain41.examp1e.com. 3531 IN CNAME chain40.examp1e.com. > >>> chain40.examp1e.com. 3525 IN CNAME chain39.examp1e.com. > >>> chain39.examp1e.com. 3526 IN CNAME chain38.examp1e.com. > >>> chain38.examp1e.com. 3526 IN CNAME chain37.examp1e.com. > >>> chain37.examp1e.com. 3526 IN CNAME chain36.examp1e.com. > >>> chain36.examp1e.com. 3526 IN CNAME chain35.examp1e.com. > >>> chain35.examp1e.com. 3513 IN CNAME chain34.examp1e.com. > >>> chain34.examp1e.com. 3513 IN CNAME chain33.examp1e.com. > >>> chain33.examp1e.com. 3513 IN CNAME chain32.examp1e.com. > >>> chain32.examp1e.com. 3513 IN CNAME chain31.examp1e.com. > >>> chain31.examp1e.com. 3513 IN CNAME chain30.examp1e.com. > >>> chain30.examp1e.com. 3508 IN CNAME chain29.examp1e.com. > >>> chain29.examp1e.com. 3508 IN CNAME chain28.examp1e.com. > >>> chain28.examp1e.com. 3508 IN CNAME chain27.examp1e.com. > >>> chain27.examp1e.com. 3508 IN CNAME chain26.examp1e.com. > >>> chain26.examp1e.com. 3508 IN CNAME chain25.examp1e.com. > >>> chain25.examp1e.com. 3499 IN CNAME chain24.examp1e.com. > >>> chain24.examp1e.com. 3499 IN CNAME chain23.examp1e.com. > >>> chain23.examp1e.com. 3500 IN CNAME chain22.examp1e.com. > >>> chain22.examp1e.com. 3500 IN CNAME chain21.examp1e.com. > >>> chain21.examp1e.com. 3500 IN CNAME chain20.examp1e.com. > >>> chain20.examp1e.com. 3447 IN CNAME chain19.examp1e.com. > >>> chain19.examp1e.com. 3447 IN CNAME chain18.examp1e.com. > >>> chain18.examp1e.com. 3447 IN CNAME chain17.examp1e.com. > >>> chain17.examp1e.com. 3448 IN CNAME chain16.examp1e.com. > >>> chain16.examp1e.com. 3448 IN CNAME chain15.examp1e.com. > >>> chain15.examp1e.com. 3448 IN CNAME chain14.examp1e.com. > >>> chain14.examp1e.com. 3448 IN CNAME chain13.examp1e.com. > >>> chain13.examp1e.com. 3448 IN CNAME chain12.examp1e.com. > >>> chain12.examp1e.com. 3449 IN CNAME chain11.examp1e.com. > >>> chain11.examp1e.com. 3486 IN CNAME chain10.examp1e.com. > >>> chain10.examp1e.com. 3455 IN CNAME chain9.examp1e.com. > >>> chain9.examp1e.com. 3455 IN CNAME chain8.examp1e.com. > >>> chain8.examp1e.com. 3455 IN CNAME chain7.examp1e.com. > >>> chain7.examp1e.com. 3455 IN CNAME chain6.examp1e.com. > >>> chain6.examp1e.com. 3455 IN CNAME chain5.examp1e.com. > >>> chain5.examp1e.com. 3455 IN CNAME chain4.examp1e.com. > >>> chain4.examp1e.com. 3455 IN CNAME chain3.examp1e.com. > >>> chain3.examp1e.com. 3455 IN CNAME chain2.examp1e.com. > >>> chain2.examp1e.com. 3455 IN CNAME chain1.examp1e.com. > >>> chain1.examp1e.com. 3466 IN CNAME chain0.examp1e.com. > >>> chain0.examp1e.com. 3460 IN A 64.57.183.119 > >>> > >>> ;; Query time: 2 msec > >>> ;; SERVER: 192.168.80.2#53(192.168.80.2) > >>> ;; WHEN: Wed May 27 13:31:17 EDT 2020 > >>> ;; MSG SIZE rcvd: 2275 > >>> _______________________________________________ > >>> DNSOP mailing list > >>> DNSOP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnsop > >>> > >> > > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly --000000000000b6323e05a6a7203a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 27, 2020 at 3:23 PM John = R Levine <johnl@taugh.com> wro= te:
> I shoul= d also note though that Chrome's built-in stub won't do any followu= p
> queries if the full chain is not in the response from the recursive.
Interesting point -- if the result is truncated will it requery with TCP?

On TC bit, yes.
=C2=A0

>
> On Wed, May 27, 2020 at 3:03 PM Eric Orth <ericorth@google.com> wrote:
>
>>
>>
>> On Wed, May 27, 2020 at 1:49 PM John R Levine <johnl@taugh.com> wrote:
>>
>>> While I should have been doing something else, I made a rather= long CNAME
>>> chain.=C2=A0 When I looked up chain.examp1e.com it got SERV= FAIL, but after I
>>> warmed up my cache five links at a time by looking for chain5,= chain10,
>>> chain15, and so forth, it worked.=C2=A0 At least it worked in = "dig" and
>>> "host".
>>> When I try and look up http://chain.examp1e.com, Chrome wai= ts a while
>>> and says not found,
>>
>>
>> If Chrome is using its built-in stub, there's not expected to = be a limit
>> (other than the overall message size limits), but nothing tests ch= ains this
>> long other than security fuzzers that are only looking for crashes= or
>> memory issues.
>>
>>
>>> Firefox waits a while and says "Hmm. We=E2=80=99re having=
>>> trouble finding that site." and Safari on my Mac hangs.= =C2=A0 (Feel free to
>>> try
>>> it yourself.)
>>>
>>> I realize the answer to most questions like this can be summar= ized as
>>> "don't do that", but is there any consensus as t= o the maximum CNAME chain
>>> length that works reliably, and what happens if the chain is t= oo long?
>>> Hanging seems sub-optimal.
>>>
>>> Regards,
>>> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
>>> Please consider the environment before reading this e-mail. https://jl.ly<= /a>
>>>
>>> $ dig chain.examp1e.com A
>>> ;; Truncated, retrying in TCP mode.
>>>
>>> ; <<>> DiG 9.10.6 <<>> chain.examp1e.co= m a
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id= : 59001
>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, AD= DITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;chain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0IN=C2=A0 =C2=A0 =C2=A0 A
>>>
>>> ;; ANSWER SECTION:
>>> chain.examp1e.com.=C2=A0 =C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN= =C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain100.examp1e.com.
>>> chain100.examp1e.com.=C2=A0 =C2=A03371=C2=A0 =C2=A0 IN= =C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain99.examp1e.com.
>>> chain99.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain98.examp1e.com.
>>> chain98.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain97.examp1e.com.
>>> chain97.examp1e.com.=C2=A0 =C2=A0 3371=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain96.examp1e.com.
>>> chain96.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain95.examp1e.com.
>>> chain95.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain94.examp1e.com.
>>> chain94.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain93.examp1e.com.
>>> chain93.examp1e.com.=C2=A0 =C2=A0 3372=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain92.examp1e.com.
>>> chain92.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain91.examp1e.com.
>>> chain91.examp1e.com.=C2=A0 =C2=A0 3589=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain90.examp1e.com.
>>> chain90.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain89.examp1e.com.
>>> chain89.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain88.examp1e.com.
>>> chain88.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain87.examp1e.com.
>>> chain87.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain86.examp1e.com.
>>> chain86.examp1e.com.=C2=A0 =C2=A0 3583=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain85.examp1e.com.
>>> chain85.examp1e.com.=C2=A0 =C2=A0 3577=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain84.examp1e.com.
>>> chain84.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain83.examp1e.com.
>>> chain83.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain82.examp1e.com.
>>> chain82.examp1e.com.=C2=A0 =C2=A0 3578=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain81.examp1e.com.
>>> chain81.examp1e.com.=C2=A0 =C2=A0 3579=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain80.examp1e.com.
>>> chain80.examp1e.com.=C2=A0 =C2=A0 3570=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain79.examp1e.com.
>>> chain79.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain78.examp1e.com.
>>> chain78.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain77.examp1e.com.
>>> chain77.examp1e.com.=C2=A0 =C2=A0 3571=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain76.examp1e.com.
>>> chain76.examp1e.com.=C2=A0 =C2=A0 3572=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain75.examp1e.com.
>>> chain75.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain74.examp1e.com.
>>> chain74.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain73.examp1e.com.
>>> chain73.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain72.examp1e.com.
>>> chain72.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain71.examp1e.com.
>>> chain71.examp1e.com.=C2=A0 =C2=A0 3564=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain70.examp1e.com.
>>> chain70.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain69.examp1e.com.
>>> chain69.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain68.examp1e.com.
>>> chain68.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain67.examp1e.com.
>>> chain67.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain66.examp1e.com.
>>> chain66.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain65.examp1e.com.
>>> chain65.examp1e.com.=C2=A0 =C2=A0 3519=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain64.examp1e.com.
>>> chain64.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain63.examp1e.com.
>>> chain63.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain62.examp1e.com.
>>> chain62.examp1e.com.=C2=A0 =C2=A0 3520=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain61.examp1e.com.
>>> chain61.examp1e.com.=C2=A0 =C2=A0 3554=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain60.examp1e.com.
>>> chain60.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain59.examp1e.com.
>>> chain59.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain58.examp1e.com.
>>> chain58.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain57.examp1e.com.
>>> chain57.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain56.examp1e.com.
>>> chain56.examp1e.com.=C2=A0 =C2=A0 3549=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain55.examp1e.com.
>>> chain55.examp1e.com.=C2=A0 =C2=A0 3535=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain54.examp1e.com.
>>> chain54.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain53.examp1e.com.
>>> chain53.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain52.examp1e.com.
>>> chain52.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain51.examp1e.com.
>>> chain51.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain50.examp1e.com.
>>> chain50.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain49.examp1e.com.
>>> chain49.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain48.examp1e.com.
>>> chain48.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain47.examp1e.com.
>>> chain47.examp1e.com.=C2=A0 =C2=A0 3536=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain46.examp1e.com.
>>> chain46.examp1e.com.=C2=A0 =C2=A0 3541=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain45.examp1e.com.
>>> chain45.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain44.examp1e.com.
>>> chain44.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain43.examp1e.com.
>>> chain43.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain42.examp1e.com.
>>> chain42.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain41.examp1e.com.
>>> chain41.examp1e.com.=C2=A0 =C2=A0 3531=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain40.examp1e.com.
>>> chain40.examp1e.com.=C2=A0 =C2=A0 3525=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain39.examp1e.com.
>>> chain39.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain38.examp1e.com.
>>> chain38.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain37.examp1e.com.
>>> chain37.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain36.examp1e.com.
>>> chain36.examp1e.com.=C2=A0 =C2=A0 3526=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain35.examp1e.com.
>>> chain35.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain34.examp1e.com.
>>> chain34.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain33.examp1e.com.
>>> chain33.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain32.examp1e.com.
>>> chain32.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain31.examp1e.com.
>>> chain31.examp1e.com.=C2=A0 =C2=A0 3513=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain30.examp1e.com.
>>> chain30.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain29.examp1e.com.
>>> chain29.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain28.examp1e.com.
>>> chain28.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain27.examp1e.com.
>>> chain27.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain26.examp1e.com.
>>> chain26.examp1e.com.=C2=A0 =C2=A0 3508=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain25.examp1e.com.
>>> chain25.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain24.examp1e.com.
>>> chain24.examp1e.com.=C2=A0 =C2=A0 3499=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain23.examp1e.com.
>>> chain23.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain22.examp1e.com.
>>> chain22.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain21.examp1e.com.
>>> chain21.examp1e.com.=C2=A0 =C2=A0 3500=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain20.examp1e.com.
>>> chain20.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain19.examp1e.com.
>>> chain19.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain18.examp1e.com.
>>> chain18.examp1e.com.=C2=A0 =C2=A0 3447=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain17.examp1e.com.
>>> chain17.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain16.examp1e.com.
>>> chain16.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain15.examp1e.com.
>>> chain15.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain14.examp1e.com.
>>> chain14.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain13.examp1e.com.
>>> chain13.examp1e.com.=C2=A0 =C2=A0 3448=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain12.examp1e.com.
>>> chain12.examp1e.com.=C2=A0 =C2=A0 3449=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain11.examp1e.com.
>>> chain11.examp1e.com.=C2=A0 =C2=A0 3486=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain10.examp1e.com.
>>> chain10.examp1e.com.=C2=A0 =C2=A0 3455=C2=A0 =C2=A0 IN=C2= =A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain9.examp1e.com.
>>> chain9.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain8.examp1e.com.
>>> chain8.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain7.examp1e.com.
>>> chain7.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain6.examp1e.com.
>>> chain6.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain5.examp1e.com.
>>> chain5.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain4.examp1e.com.
>>> chain4.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain3.examp1e.com.
>>> chain3.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain2.examp1e.com.
>>> chain2.examp1e.com.=C2=A0 =C2=A0 =C2=A03455=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain1.examp1e.com.
>>> chain1.examp1e.com.=C2=A0 =C2=A0 =C2=A03466=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0chain0.examp1e.com.
>>> chain0.examp1e.com.=C2=A0 =C2=A0 =C2=A03460=C2=A0 =C2=A0 I= N=C2=A0 =C2=A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A064.57.183.119
>>>
>>> ;; Query time: 2 msec
>>> ;; SERVER: 192.168.80.2#53(192.168.80.2)
>>> ;; WHEN: Wed May 27 13:31:17 EDT 2020
>>> ;; MSG SIZE=C2=A0 rcvd: 2275
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/dnsop<= /a>
>>>
>>
>

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--000000000000b6323e05a6a7203a-- From nobody Wed May 27 13:59:22 2020 Return-Path: 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 239093A0BE4 for ; Wed, 27 May 2020 13:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 5U2YmcfqtUNX for ; Wed, 27 May 2020 13:59:19 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944333A0BE1 for ; Wed, 27 May 2020 13:59:19 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id F3703B074A; Wed, 27 May 2020 20:59:18 +0000 (UTC) From: Paul Vixie To: John R Levine , dnsop@ietf.org Cc: dnsop , Eric Orth Date: Wed, 27 May 2020 20:59:13 +0000 Message-ID: <5643156.t5YRdPtAiO@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 20:59:21 -0000 On Wednesday, 27 May 2020 19:05:35 UTC Eric Orth wrote: > I should also note though that Chrome's built-in stub won't do any followup > queries if the full chain is not in the response from the recursive. that's correct behaviour. full resolvers iterate (and recurse). stubs do not. -- Paul From nobody Wed May 27 14:48:42 2020 Return-Path: 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 0781E3A0CA3 for ; Wed, 27 May 2020 14:48:41 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=portfast.net 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 gzfD3Oturo_E for ; Wed, 27 May 2020 14:48:38 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 AA3433A0CA0 for ; Wed, 27 May 2020 14:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3nTG5Q8+CEFRlog+FWT5/hvrxSWQKradB+RIh5wIOUM=; b=QYl9GcR/NLpiZ+Uyyi/2x2AHOt fKk1stka0TPa812wks1ghu4AbQR+OcXxpjpmDjpqx70DoZchBKm0yXvhUsIMnHNV7+Qoe0WjZFTDA d0a9bL9+kXc9sh/nDewfcyNHZYAaT91EI5ymWCCLSGlsj+ub+rp4esL/r7CWiQPWJ6+k=; Received: from [88.212.170.130] (port=50555 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1je3ue-0004e9-2u (Exim 4.89) for dnsop@ietf.org (return-path ); Wed, 27 May 2020 22:48:36 +0100 To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> From: Ray Bellis Autocrypt: addr=ray@bellis.me.uk; keydata= mQENBFvQpEEBCADBbsjhl44JARZXZoAZXoAxsd/227/ItxFHmo+cogL0qhIvn1F++OozY3mR S6ut5iuI1XMGCz2/ewqfp43k2f+o9DxjIBEqKA+M1hg8ivBMWD8//yo8S80DT2Y6GmLnRz64 sRpw0Z3LcmKULKKDU3lD9Uo05s8c2xUzJTxwxFfpjqA108nEemGnu549qV38Jz1OeuD+7P4R 3du97DyaaW5gyj/ggtiQxQtkbHG9aFRn0ASGON0uu49vRxaeuKwaGExb6FWYXJJSQLScfJ3i 356RdwaO/KezCGAhRiJ06AbPTxq2j9cvnShVb1IsxXQn73JgHVsPKDjdYo98ePWYuHWPABEB AAG0HVJheSBCZWxsaXMgPHJheUBiZWxsaXMubWUudWs+iQFUBBMBCAA+AhsDBQsJCAcCBhUK CQgLAgQWAgMBAh4BAheAFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0P8ACgkQ lD9Tw3qX+kJ+MwgAoW1eeAyyDqykaFO+N9XWMcQeFQamm1hWhjNRCOFuygycbwAe0oJPYn+i VsDoooJ/5zoHPdRV6boG8jEq8JcFwNHd5AXBPpAY9VA44ro83K7BSLMQRSfXB/OXCf5uSpb7 6DZQzem3wFys5g4bYqdSzFRiN42SjhSNxyi8KGrcEpqHgrnOBLUh+aPUgcTeFd3Dwxa21Hb/ qpOZvlKwQ7XjnAA6sMqPOmVJF4bg9D5Jg1jUOexPmwtZ1HN1wbpPZWqy3nGPXaHxHCVBp08M 7ZAIKf4QTVXcHbNxLwZtFO0TU7SK35xhzx4oy3faQIVh8K+CUMPQGU8TA3o78SefoPI8DrkB DQRb0KRXAQgAvveTWC0LkjJ2qTJcYqu0ksRKY44UCHyBNy+SfylH7cGd3FTG5qgPnOAhRAfP p7q+rxAep2adQCY4odd0CWQpmg3KhBf1qARW4HqUKMjff8+Gv7YZTiolsH+P8qQamCNemhSa 8+/vsY0roS25ZWHaHDVSIyyvHU6MsDVX8Z1nc1PwNUEqZST3I5ERVUWY/SQOTJp3fVeaU1Mo X3Bmk+7ugmUfb8Ztr63Fv3OrdEVk4ivHD8KP5c49UD9yTsVksfHqV2LN6/zdTU0CvW4SIEtX f7xQNG/o2/J50yW4e7g59ElYQZJxCjJwKusIV61aAmCe3OLLN05Kp23RrX4AwY26ewARAQAB iQE8BBgBCAAmAhsMFiEEnTo7cotw6xBhK8kRlD9Tw3qX+kIFAl3N5h0FCQPd0OkACgkQlD9T w3qX+kKHIggAncjGFT/LRZncAnX1IBwJfqzOzYWLOG4QHPMoHkaxrb+q3GAHXd6RAWgc8UIR fLJDowI1f2oMXh/PvqZkiVdy0qNPwhNP+i7r8OE8Co3Q1VA9Cw3Ysj2UGF5TQ2cF36XjuH9H uMp8Qy0k3lmHZgf7E/hu8u+O3AoBFG5FQ61fJjKTBazRqZmyxcbVyHHAVoAbOYJU+Mb3vfmy UlDa0FHxLHI6+pYEe7IQxzv22lGzdSgr7oVJnAz2V9sodeB2ALs+Jjh2kR0+SVPg+ED+zXWe p5alounzwhu2brS/vAJwXQXSb1R/65L4HliZk4poaC7UxC+6j0Fu7ICZa2IR9JpNnA== Message-ID: <970122dd-626b-fd99-cfb6-07c44d556664@bellis.me.uk> Date: Wed, 27 May 2020 22:48:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 21:48:41 -0000 On 27/05/2020 17:40, Eric Orth wrote: > Maybe a better solution, but considering that the issue I'm dealing with > is when the stub is unwilling to send additional queries or queries for > new types out of concerns of middlebox ossificiation (especially from > older home routers) on additional queries or unknown query types, does > anybody have any data to show that the multiple qtype EDNS option won't > cause similar issues? > > But in other cases without as much ossifciation concern, especially when > using DoH, I'm supportive of any effort to allow querying multiple types > in the same request.  Would significantly help with some of the security > concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by > identifying and blocking the packets just for the HTTPSSVC records.  If > A/AAAA/HTTPSSVC are all in the same request/response, you can't block > any of it without blocking all of it.  My one concern of that specific > proposal is that if the client doesn't know that the server will respond > for the additional queries, it still has to make separate queries for > all three, leading to lots of redundant responses when the additional > types are handled. In traditional DNS, stub resolvers only talk to a limited set of upstream resolvers, and they could learn (and cache) information about their behaviours, in the same way that recursive servers do for authoritative servers. You only need to launch one "multi QTYPE" query at a server to learn whether subsequent queries to that server can take advantage of that feature. Ray From nobody Wed May 27 16:54:47 2020 Return-Path: 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 9297F3A0BD7; Wed, 27 May 2020 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 GZ6Ozh0HJfHU; Wed, 27 May 2020 16:54:45 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 18E2D3A0BD5; Wed, 27 May 2020 16:54:45 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:58616) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1je5sa-000RsW-LL (Exim 4.92.3) (return-path ); Thu, 28 May 2020 00:54:36 +0100 Date: Thu, 28 May 2020 00:54:36 +0100 From: Tony Finch To: Paul Hoffman cc: Eric Orth , dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] [Ext] unsolicited HTTPSSVC responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 23:54:47 -0000 Paul Hoffman wrote: > > Add where in the response? In the Answer section or in the Additional > section? The semantics and usefulness are wildly different for those > two. We learned from DNAME that a lot of DNS software gets very upset if there are unexpected records in the answer section. If you want to add additional records they have to go in the additional section. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet: Easterly 3 to 5, veering southeasterly 5 or 6 in southwest Fastnet. Slight or moderate. Fair. Good. From nobody Wed May 27 17:02:56 2020 Return-Path: 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 A41573A0DD0 for ; Wed, 27 May 2020 17:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Yzq0JrVPCLp4 for ; Wed, 27 May 2020 17:02:53 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 33AE53A0DCE for ; Wed, 27 May 2020 17:02:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59598) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1je60V-000Vcg-MU (Exim 4.92.3) (return-path ); Thu, 28 May 2020 01:02:47 +0100 Date: Thu, 28 May 2020 01:02:47 +0100 From: Tony Finch To: dagon cc: Evan Hunt , dnsop@ietf.org, John R Levine In-Reply-To: <20200527200614.GC3582@sudo.sh> Message-ID: References: <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 00:02:55 -0000 dagon wrote: > > -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some > recursive speakers fail; some complain ("BAD (HORIZONTAL) > REFERRAL", but answer), and some follow without complaint. Can you explain what these are, please? Tony. -- f.anthony.n.finch http://dotat.at/ Forth, Tyne, Dogger: Variable mainly south 2 to 4. Smooth or slight. Mainly fair. Good, occasionally poor. From nobody Wed May 27 19:44:22 2020 Return-Path: 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 A8EEA3A0B27 for ; Wed, 27 May 2020 19:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 m7EXPJBB9SNy for ; Wed, 27 May 2020 19:44:12 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB03A0B22 for ; Wed, 27 May 2020 19:44:12 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id AABE4260251; Thu, 28 May 2020 02:44:10 +0000 (UTC) Date: Thu, 28 May 2020 02:44:10 +0000 From: dagon To: Tony Finch Cc: Evan Hunt , dnsop@ietf.org, John R Levine Message-ID: <20200528024410.GA7675@sudo.sh> References: <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 02:44:21 -0000 On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote: > dagon wrote: > > > > -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some > > recursive speakers fail; some complain ("BAD (HORIZONTAL) > > REFERRAL", but answer), and some follow without complaint. > > Can you explain what these are, please? If a canonical answer points to the same level as the 'owner name', then the left and right sides share NS. (This is the most common case, and even outlined in 1034.) If this discovery occurs during a CNAME chain chase with yet another empty answer, the NS is in a sense making a referral to itself, or its pool of secondary NS serving the same delegation cut level---the bad horizontal referral. 1034 merely says resolution should be robust, and that "CNAME chains should be followed and CNAME loops signalled as an error", s.3.6.2. But that doesn't mean resolvers have to put up with this behavior quietly. Dig issues warnings in such cases; see followup_lookup() in dighost.c: if (namereln == dns_namereln_equal) { if (!horizontal) printf(";; BAD (HORIZONTAL) REFERRAL\n"); horizontal = true; Tools that warn about this seem to take the larger view that such referrals should be directed maybe to a new sibling tree (e.g., something in example.org CNAME'd to some place in example.com) or further downward (implying there's a zone cut, but that aspect is not enforced or audited by dig.) There's sense in this: during the second empty answer in CNAME to a mere sibling label, the recursive is *already* talking to the right authority, dammit, and frankly it's inability to sort the zone into a non-chained state is an unhelpful referral. (It may also symptomatic of a zone configuration error--- implicit $ORIGINs and inconsistent fqdns, and such---which is probably why dig included this warning.) You can actually experience something like horizontal referrals in some US airport security screenings, which segregate passenger lines based on ticket classes. If you have a higher ranked ticket, but stand in the *longer* lower ranked line to chat with your friend, you might be referred back to the end of the higher ranked ticket line, just to arrive again at the very same screening point---a bad horizontal referral in most people's view. I never encountered this in European airports, and so it is very fitting that ldns tools and kdig don't check horizontal referrals like dig. By this analogy, DNS resolvers have a choice in chained horizontal follows: quietly continue the journey, continue on but argue to anyone logging complaints (dig), or just abruptly cancel the flight (SERVFAIL). It would be useful to have a survey of all such behaviors for various appliances and tools on the Internet, since this sometimes leads to zones being unavailable. You can find a few anecdotes in the BIND support lists. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Wed May 27 20:22:49 2020 Return-Path: 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 B1A6E3A0B66 for ; Wed, 27 May 2020 20:22:48 -0700 (PDT) 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 ZFeoFa-QKGKQ for ; Wed, 27 May 2020 20:22:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 1FE213A0B65 for ; Wed, 27 May 2020 20:22:47 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3DD9C3AB003; Thu, 28 May 2020 03:22:45 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2D6A9160054; Thu, 28 May 2020 03:22:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 18C8816006C; Thu, 28 May 2020 03:22:45 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ob9gM4vyUi2O; Thu, 28 May 2020 03:22:45 +0000 (UTC) Received: from [1.0.0.3] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id E92FE160054; Thu, 28 May 2020 03:22:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Mark Andrews In-Reply-To: <20200528024410.GA7675@sudo.sh> Date: Thu, 28 May 2020 13:22:40 +1000 Cc: Tony Finch , Evan Hunt , dnsop@ietf.org, John R Levine Content-Transfer-Encoding: quoted-printable Message-Id: <14B0EB24-1A76-4976-9111-9F3D520B445C@isc.org> References: <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> <20200528024410.GA7675@sudo.sh> To: dagon X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 03:22:49 -0000 'BAD (HORIZONTAL) REFERRAL' has nothing to do with CNAMES. It=E2=80=99s = reporting a referral to a set of servers that in turn return a referral to another set of servers server at the same depth. It=E2=80=99s reported by = =E2=80=98dig +trace=E2=80=99.=20 > On 28 May 2020, at 12:44, dagon wrote: >=20 > On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote: >> dagon wrote: >>>=20 >>> -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some >>> recursive speakers fail; some complain ("BAD (HORIZONTAL) >>> REFERRAL", but answer), and some follow without complaint. >>=20 >> Can you explain what these are, please? >=20 > If a canonical answer points to the same level as the 'owner name', > then the left and right sides share NS. (This is the most common > case, and even outlined in 1034.) If this discovery occurs during a > CNAME chain chase with yet another empty answer, the NS is in a sense > making a referral to itself, or its pool of secondary NS serving the > same delegation cut level---the bad horizontal referral. >=20 > 1034 merely says resolution should be robust, and that "CNAME chains > should be followed and CNAME loops signalled as an error", s.3.6.2. > But that doesn't mean resolvers have to put up with this behavior > quietly. Dig issues warnings in such cases; see followup_lookup() in > dighost.c: >=20 > if (namereln =3D=3D dns_namereln_equal) { > if (!horizontal) > printf(";; BAD (HORIZONTAL) REFERRAL\n"); > horizontal =3D true; >=20 > Tools that warn about this seem to take the larger view that such > referrals should be directed maybe to a new sibling tree (e.g., > something in example.org CNAME'd to some place in example.com) or > further downward (implying there's a zone cut, but that aspect is not > enforced or audited by dig.) There's sense in this: during the second > empty answer in CNAME to a mere sibling label, the recursive is > *already* talking to the right authority, dammit, and frankly it's > inability to sort the zone into a non-chained state is an unhelpful > referral. (It may also symptomatic of a zone configuration error--- > implicit $ORIGINs and inconsistent fqdns, and such---which is probably > why dig included this warning.) >=20 > You can actually experience something like horizontal referrals in > some US airport security screenings, which segregate passenger lines > based on ticket classes. If you have a higher ranked ticket, but > stand in the *longer* lower ranked line to chat with your friend, you > might be referred back to the end of the higher ranked ticket line, > just to arrive again at the very same screening point---a bad > horizontal referral in most people's view. I never encountered this > in European airports, and so it is very fitting that ldns tools and > kdig don't check horizontal referrals like dig. >=20 > By this analogy, DNS resolvers have a choice in chained horizontal > follows: quietly continue the journey, continue on but argue to anyone > logging complaints (dig), or just abruptly cancel the flight > (SERVFAIL). >=20 > It would be useful to have a survey of all such behaviors for various > appliances and tools on the Internet, since this sometimes leads to > zones being unavailable. You can find a few anecdotes in the BIND > support lists. >=20 > --=20 > David Dagon > dagon@sudo.sh > D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed May 27 20:24:38 2020 Return-Path: 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 618293A0B68 for ; Wed, 27 May 2020 20:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=At/jGa7Q; dkim=pass (1536-bit key) header.d=taugh.com header.b=wUKCf5+M 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 U_uALKAU5uYr for ; Wed, 27 May 2020 20:24:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6D7A53A0B67 for ; Wed, 27 May 2020 20:24:34 -0700 (PDT) Received: (qmail 3356 invoked from network); 28 May 2020 03:24:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d19.5ecf2ef1.k2005; i=johnl-iecc.com@submit.iecc.com; bh=BPh6fmLtzxze5wH2G+daZVv6adR3FYyzK0cEmZdFzG0=; b=At/jGa7QvxI9LnPagwvMy2lJWtCSfCT8YIBS5NZTsvFPgL7J9Vj5boYHa7WZqaZyxgaBFXJHa8YQMlURWTUQ/2O9URRXao2rrocHIPqnKdVf8iYQkQrmLQAOEJROR8VlG25UJwMKfVkdTNCVdaugTXVsQ0Z96aGtpOAKzyVlwOQJ2tvCJLxUhv6XwBlkhgzPoKkprTvVvMv1//LqlT1HcB5wxjocbBYkxoTivt24m2lGCc0D2Msy+CX9V28M+OD0 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d19.5ecf2ef1.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=BPh6fmLtzxze5wH2G+daZVv6adR3FYyzK0cEmZdFzG0=; b=wUKCf5+MaA7kIsKyHlgNhE+LrqS9pA0ciCN3MwpDMsbKogAg0k4urCi9nT94onxQL86SBOKNKBsa2b07FDcXzbCRCZSfBDJ0DlKEWn8Ou2X5xUKuAes+JUYzWQ3ACxWgL16oVdFC+LBrQ9olgdyDxdo19klV1ypNYiREmDsvqC6OIAJKwyZTGxXYcF6i31FuL8FPBKSmp8RQ0vXlFGPW6VaJzu/C/HQky/gv4WZeOqHOvWgvcIyzCI9HP/IpnAGV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 28 May 2020 03:24:32 -0000 Date: 27 May 2020 23:24:32 -0400 Message-ID: From: "John R Levine" To: "dagon" Cc: dnsop@ietf.org In-Reply-To: <20200528024410.GA7675@sudo.sh> References: <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> <20200528024410.GA7675@sudo.sh> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 03:24:37 -0000 On Thu, 28 May 2020, dagon wrote: > On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote: >> dagon wrote: >>> >>> -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some >>> recursive speakers fail; some complain ("BAD (HORIZONTAL) >>> REFERRAL", but answer), and some follow without complaint. >> >> Can you explain what these are, please? > > If a canonical answer points to the same level as the 'owner name', > then the left and right sides share NS. (This is the most common > case, and even outlined in 1034.) If this discovery occurs during a > CNAME chain chase with yet another empty answer, the NS is in a sense > making a referral to itself, or its pool of secondary NS serving the > same delegation cut level---the bad horizontal referral. It sounds like "horizontal" means within the same zone, and "vertical" means a different zone. I don't know what you mean by "level" -- same number of components in the name? All but the last component the same? In the same zone? Something else? In RFC 1034 CNAMEs are intended as short term transition aidss, sort of like yellow forwarding stickers on paper mail. Now they're mostly used to dynamically delegate names across authority boundaries, which works pretty well, but there's a lot of ancient cruft still sticking to them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 27 21:16:08 2020 Return-Path: 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 A59E43A0BC6 for ; Wed, 27 May 2020 21:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wF-Sn6SQ9ERw for ; Wed, 27 May 2020 21:16:05 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEAD3A0BC5 for ; Wed, 27 May 2020 21:16:05 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id 6B1C8260251; Thu, 28 May 2020 04:16:03 +0000 (UTC) Date: Thu, 28 May 2020 04:16:03 +0000 From: dagon To: Mark Andrews Cc: Tony Finch , Evan Hunt , dnsop@ietf.org, John R Levine Message-ID: <20200528041603.GB7675@sudo.sh> References: <20200527180846.GA51895@isc.org> <20200527200614.GC3582@sudo.sh> <20200528024410.GA7675@sudo.sh> <14B0EB24-1A76-4976-9111-9F3D520B445C@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14B0EB24-1A76-4976-9111-9F3D520B445C@isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] CNAME chain length limits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 04:16:07 -0000 On Thu, May 28, 2020 at 01:22:40PM +1000, Mark Andrews wrote: > 'BAD (HORIZONTAL) REFERRAL' has nothing to do with CNAMES. It’s reporting > a referral to a set of servers that in turn return a referral to another > set of servers server at the same depth. It’s reported by ‘dig +trace’. This thread sought ideas about what to measure in chain handling, where one can encounter this error. It's not CNAME-specific of course, nor were the other NS-oriented comments, or resolution timing limits, etc. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Thu May 28 01:00:21 2020 Return-Path: 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 9EAA13A0BB0 for ; Thu, 28 May 2020 01:00:19 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details. Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 bBxtL84ORmS3 for ; Thu, 28 May 2020 01:00:17 -0700 (PDT) Received: from saturn.zonnestelsel.tk (saturn.zonnestelsel.tk [IPv6:2001:470:78c8:2::11]) (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 F3BD13A0B0A for ; Thu, 28 May 2020 01:00:12 -0700 (PDT) Received: from earth.zonnestelsel.tk ([2001:470:78c8:2::9]) by saturn.zonnestelsel.tk with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jeDSP-0001EE-Rq for dnsop@ietf.org; Thu, 28 May 2020 08:00:09 +0000 From: Shane Kerr To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> Message-ID: Date: Thu, 28 May 2020 10:00:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score-Int: -28 X-Spam-Bar: -- Archived-At: Subject: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 08:00:20 -0000 Ray and other DNS operations folks, On 27/05/2020 10.30, Ray Bellis wrote: > > > On 27/05/2020 07:33, Petr Å paÄek wrote: > >> I would much rather spent time on >> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 >> >> That would bring benefit to broader set of clients and has advantage >> that server does not send back data nobody asked for (thus wasting >> resources on unnecessary work). > > I'd be very happy to revive that work if there's interest. As I have mentioned several times on microphone, I think this draft has huge potential, potentially cutting the number of queries handled by recursive resolvers almost in half - since they could ask for A and AAAA records in a single query. I wonder what work is left other than implementation? Possibly it makes sense to describe client how stub or forwarding resolvers may want to probe their full-service resolvers? I expect that normal behavior would be: 1. Send a query with the Multi-QTYPE option and see if the resolver supports it. 2. If it does to send single queries for address lookups instead of parallel AAAA/A queries. 3. Fallback to parallel AAAA/A queries as soon as they get a response that does not support Multiple-QTYPE. Similar description for recursive-to-authoritative might be helpful, since resolvers cache information about authoritative servers. I guess we could expect resolvers to ask for DNSKEY and NS together when it makes sense, for example. Of course, these use cases can be left as an exercise to the implementer. -- Shane From nobody Thu May 28 01:18:12 2020 Return-Path: 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 5CBCB3A0C3C for ; Thu, 28 May 2020 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 vHFS6j5R9RaQ for ; Thu, 28 May 2020 01:18:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 31FB33A0C37 for ; Thu, 28 May 2020 01:18:00 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id 3F79014056E for ; Thu, 28 May 2020 10:17:56 +0200 (CEST) To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: <0ce3b615-5469-8e42-c07f-7e4a2b3c2ad4@nic.cz> Date: Thu, 28 May 2020 10:17:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 08:18:11 -0000 On 28. 05. 20 10:00, Shane Kerr wrote: > Ray and other DNS operations folks, > > On 27/05/2020 10.30, Ray Bellis wrote: >> >> >> On 27/05/2020 07:33, Petr Å paÄek wrote: >> >>> I would much rather spent time on >>> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 >>> >>> That would bring benefit to broader set of clients and has advantage >>> that server does not send back data nobody asked for (thus wasting >>> resources on unnecessary work). >> >> I'd be very happy to revive that work if there's interest. > > As I have mentioned several times on microphone, I think this draft has huge potential, potentially cutting the number of queries handled by recursive resolvers almost in half - since they could ask for A and AAAA records in a single query. > > I wonder what work is left other than implementation? Most importantly we are missing buy-in (or more precisely _any communication_) with stub resolvers which are actually used by applications. If anyone from Android, iOS, Microsoft, glibc would like to comment here it would be ideal. Personally I: a) Very much like idea of this draft b) At the same time I'm against making this RFC until we have end-to-end implementation. If we do not have implementations on all ends this draft will simply end up as yet another item on my "list of dnsop failures" with drafts published but never implemented, and that's huge waste of everybody's time. > > Possibly it makes sense to describe client how stub or forwarding resolvers may want to probe their full-service resolvers? I expect that normal behavior would be: > > 1. Send a query with the Multi-QTYPE option and see if the resolver supports it. > 2. If it does to send single queries for address lookups instead of parallel AAAA/A queries. > 3. Fallback to parallel AAAA/A queries as soon as they get a response that does not support Multiple-QTYPE. > > Similar description for recursive-to-authoritative might be helpful, since resolvers cache information about authoritative servers. I guess we could expect resolvers to ask for DNSKEY and NS together when it makes sense, for example. Yes, certainly... but ideally this should be done in concert with stub resolver developers so they can tell us what they need from the protocol. Most famously glibc resolver might not have sufficient state to cache this information, or ... I don't know. Petr Å paÄek @ CZ.NIC > Of course, these use cases can be left as an exercise to the implementer. From nobody Thu May 28 07:38:18 2020 Return-Path: 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 A856B3A0F04 for ; Thu, 28 May 2020 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 jx69S0zeCLJB for ; Thu, 28 May 2020 07:38:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 E95003A0E3B for ; Thu, 28 May 2020 07:38:14 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:1488:fffe:6:5c39:29ff:fe8a:696c]) by mail.nic.cz (Postfix) with ESMTPSA id 18C0B14056E; Thu, 28 May 2020 16:38:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1590676692; bh=9rP9zByXBqgLcR6XgVz36LmhzbFPttWD4LuUHSTT1yw=; h=To:From:Date; b=F7MEiK8vxudI2I4DfgF+tpsET2JsvYqEhSmtEm87DS/Js7l0WT7ByeZ5Amin2pf68 OAmL76fv0lHML3y5bAfTVRHc5wsSxVORUkBetM0hypRU3b1bktyLCdz1EZZ68TBTDx F2XeS1z8j0PkuuLX3Sts/hWynafvzE+6Iinvk2W4= To: Shumon Huque Cc: "dnsop@ietf.org WG" References: <7dd08da3-72f8-f25a-c6be-4ff7f76a4084@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz> Date: Thu, 28 May 2020 16:38:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 14:38:18 -0000 On 25. 05. 20 5:23, Shumon Huque wrote: > On Thu, May 21, 2020 at 8:24 AM Petr Å paÄek > wrote: > > > > >    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 > > I would appreciate a practical example of changes envisioned in the following paragraph: > > >    A common reason that zone owners want to ensure that resolvers place > >    the authoritative NS RRset preferentially in their cache is that the > >    TTLs may differ between the parent and child side of the zone cut. > >    Some DNS Top Level Domains (TLDs) only support long fixed TTLs in > >    their delegation NS sets, and this inhibits a child zone owner's > >    ability to make more rapid changes to their nameserver configuration > >    using a shorter TTL, if resolvers have no systematic mechanism to > >    observe and cache the child NS RRset. > > Could someone please post an example in steps? Something like: > - time 0, NSSET parent = {P0}, NSSET child = {C0} > - time 1, NSSET parent = {P1}, NSSET child = {C1} > ... along with textual description what operator is hoping to achieve? > > > I'll try to come up with a step by step example later. But in the example > cited, what the operator is trying to achieve is to change their nameserver > configuration (e.g. switch to another set of nameservers for their zone) in > such a way that (1) they can make that change visible to resolvers  > reasonably quickly, and (2) to make sure they are able to backout that > change quickly if things go wrong. They can do this by lowering the TTL > in the child NS set which is under their control -- assuming that resolvers are > preferentially caching the child NS set, in accordance with the data ranking > rules of the DNS protocol (the child NS set is authoritative). > > Ad 4.  Delegation Revalidation: > > I agree with author's note "we would prefer to discard the extensive mechanism" but the simple mechanism has simple description for me to understand consequences. > > > I've heard the same from other implementers too. Paul V has mentioned that there are some subtle corner cases that are dealt with more precisely by the extensive algorithm (I can't recall the details right now, but maybe he will elaborate for us). Even if we end up on the simple path, it would be good to have a better understanding of those cases. > > >    The simple mechanism: > > > >    o  Cap the time to cache the child NS RRset to the lower of child and > >       parent NS RRset TTL.  The normal iterative resolution algorithm > >       will then cause delegation revalidation to naturally occur at the > >       expiration of the capped child NS TTL, along with dispatching of > >       the validation query to upgrade NS RRset credibility. > > So far so good, but it does not specify what should happen with RRsets other than NS. Even if nothing is prescribed please state that explicitly. > > > Thanks, yes I agree we should discuss all of these. Some quick thoughts for now .. > > Most importantly: > - Does the NS affect maximum TTL of _other_ data in the zone? > > > I think there are probably different views on what should happen here. Folks who want very prompt takedown of "bad" domains, will probably prefer a complete pruning of the cache at the delegation point at the revalidation interval, if the NS set has changed or disappeared. When this topic has come up in the past, there has been pushback from some implementers that it's difficult to do this because they use a non-tree data structure for the cache (a hash table most commonly). Most resolvers these days already enforce a max cache TTL parameter, so that typically prevents too much abuse. But at the very least, they should probably use the revalidation interval as a signal to stop "pre-fetching" records below the cut. > > - If it does, doesn't it increase risk of thundering herd behavior? > > > Possibly, depending on how popular the zone is, and what we decide is the answer to the previous question. At any rate, implementers should always employ strategies that bound how much work resolvers can be caused to do. I'm not concerned about any single resolver instance, I'm more concerned about large number of resolver instances doing the same thing at the same time. E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of all other records in the zone, then each resolver instance would clear zone from its cache each 30 seconds. That might cause interesting behavior when NS TTL is shortened e.g. before NS set change etc. I do not know if there really is a problem, I'm just trying to explain why potential for thundering herd needs to be be seriously analyzed. > > It might be reasonable to suggest that resolvers enforce a lower limit on the child NS TTL (5 minutes?). If they see something less than that, it would be set to the limit instead. > > - If it does not, is it even worth the effort if attacker can put week long TTL for A/AAAA and keep using that? > > > Answered above ...  >   > > - How should resolver handle RCODE=NXDOMAIN? Should it have different effect than changing NS set to different set of servers? > > > If resolvers are following RFC 8020 strictly, they are pruning their cache at the delegation - that would be the ideal. Otherwise, they should allow cached records below to live on, subject to max-cache TTL and disabling of pre-fetching. > > Or change in DS record value? > > > Which value? TTL or RDATA? > > DS TTL expiration would automatically trigger a revalidation of the child SEP keys at the parent. RFC 4035 says DS and delegating NS TTL SHOULD match, so NS revalidation should happen on the same time scale. In reality though, they are often different (COM/NET uses 2d for NS, 1d for DS). if NS > DS, a resolver could just decide to explicitly fetch the expiring DS first and wait out the delegating NS TTL if the DS rdata has not changed. But it seems much simpler to just say that  if there is a secure delegation, then the DS TTL should be used as the NS revalidation interval too. > > For me personally mixing two problems (GHOST domains and NS inconsistency) in single proposal does not help me to understand reasoning behind the proposal and its intended effects. > > > Ok, we'll think about how to make this clearer. But the two topics are related. If resolvers prefer the authoritative child NS set, then timely revalidation of the delegation at the parent is also necessary. Yeah, you are right. It is probably good idea to discuss both at once because it will force us to find compromise between the two. E.g. most aggressive approach where resolver prunes cache on mere NS set _change_ might increase fragility when someone makes mistake while doing NS set change etc. Having said that, I still think it would help if arguments/requirements for each use-case (GHOST vs. NS inconsistency / malicious vs. well-behaved operator) were laid out separately and then document reconciled arguments from these two camps and reached single recommendation for resolver implementers. -- Petr Å paÄek @ CZ.NIC From nobody Thu May 28 08:55:24 2020 Return-Path: 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 52AFE3A0E85 for ; Thu, 28 May 2020 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 4vqSUmPaXavv for ; Thu, 28 May 2020 08:55:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B599F3A0E32 for ; Thu, 28 May 2020 08:55:21 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 25D90B074A; Thu, 28 May 2020 15:55:16 +0000 (UTC) From: Paul Vixie To: Shumon Huque , dnsop@ietf.org Cc: "dnsop@ietf.org WG" , Petr =?utf-8?B?xaBwYcSNZWs=?= Date: Thu, 28 May 2020 15:55:15 +0000 Message-ID: <33141878.RIuage5OGR@linux-9daj> Organization: none In-Reply-To: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz> References: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 15:55:23 -0000 On Thursday, 28 May 2020 14:38:11 UTC Petr =C5=A0pa=C4=8Dek wrote: > On 25. 05. 20 5:23, Shumon Huque wrote: > > ... > > Most importantly: > > - Does the NS affect maximum TTL of _other_ data in the zone? > >=20 > > I think there are probably different views on what should happen here. > > Folks who want very prompt takedown of "bad" domains, will probably > > prefer a complete pruning of the cache at the delegation point at the > > revalidation interval, if the NS set has changed or disappeared. ... yes, that was the original motive for revalidation itself, noting that it a= lso=20 facilitates emergency redelegation, for example, after a registrant/registr= ar=20 account compromise. so the domain might not be bad, but the cached content= =20 might be poisonous in other ways. > > When > > this topic has come up in the past, there has been pushback from some > > implementers that it's difficult to do this because they use a non-tree > > data structure for the cache (a hash table most commonly). ... i don't think we should argue the computer science behind implementing this= =2E=20 if the cache doesn't facilitate "rm -r" behaviour directly, then it might=20 choose to bookend the retrievals, such that retrieving data having a bailiw= ick=20 whose timestamp is older than the revalidation event would cause deletion a= nd=20 refetch at the time of the encounter. these details should not enter into a= =20 discussion of whether the system should have a capability or not. > > - If it does, doesn't it increase risk of thundering herd behavior? > >=20 > > Possibly, depending on how popular the zone is, and what we decide is t= he > > answer to the previous question. At any rate, implementers should always > > employ strategies that bound how much work resolvers can be caused to d= o. > I'm not concerned about any single resolver instance, I'm more concerned > about large number of resolver instances doing the same thing at the same > time. >=20 > E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of all > other records in the zone, then each resolver instance would clear zone > from its cache each 30 seconds. That might cause interesting behavior when > NS TTL is shortened e.g. before NS set change etc. >=20 > I do not know if there really is a problem, I'm just trying to explain why > potential for thundering herd needs to be be seriously analyzed. if we can think of a way that the intervals can become synchronized, then w= e=20 would treat this with random subtractive revalidation. to get a thundering= =20 herd every member of the herd would have to start their interval at the sam= e=20 time. such synchronicity is hard to trigger. =2D-=20 Paul From nobody Thu May 28 09:22:31 2020 Return-Path: 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 C92653A0FB5 for ; Thu, 28 May 2020 09:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 udmsJvDz4rn5 for ; Thu, 28 May 2020 09:22:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 BCB283A0F84 for ; Thu, 28 May 2020 09:22:27 -0700 (PDT) Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id 163BD1405A7 for ; Thu, 28 May 2020 18:22:26 +0200 (CEST) To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtCRWbGFkaW3DrXIg xIx1bsOhdCA8dmN1bmF0QGdtYWlsLmNvbT6JAlcEEwEIAEECGyMFCQlmAYAFCwkIBwIGFQgJ CgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w3gIZAQAKCRDnR98f lXWjqs7GEACZlVtvy0Q45DrRQJ2B5SAeb0ZJ5OZQFPFnnl4UjL2Q9A1jglzjftbhjfwf41K9 ouUoa6R8X8nlpGwo8DSZwXNYni8AXUMYh01VgSFop/6Uxeaczyz+X6/YJ5Q+UMEkVz2rrezp ZXG8pj0+yf8fGbImEqGDJInQZoJhUDaaFSiyFIMJWQUE52O117fAUvDDfVdvg3PDjaR+Mqf9 w6bZNm6Sr2LCJrxTLr71PcpZC0nD0menvUkAzwe4BzVmciSZWtyQB0fhlr6cBGb0WpqgYlXO V0TecMtAZGKrzsT48fspeBGPPobW9t6YsnFgQQB1V3ON4VxHxDeD3OV9Aq91zLl1cgBmp/z6 5APzzqHXthX/meBCzKLO06w82Np/gIeksFA05HbbykZElslbB2eFz8W3tV4WLWcKucDPl+Pm zlbt8XprWE7Pyn6mFp8beZQWT0VOcSTH/UOfEImplxFLRDTLk0wjMye/i06XlPu/1nrditHw mlVjFbdc7NSiO8rXdUgTuOEwdZMyIhCB9SWNxZa+7F3kVKdXTBytVaYSfD3qoDBP8bhaeDF8 K6054uo5pmBXD2f8WGqbuikNh64i1oncmj475uxRKkzByrkY9XN9qRKjWav6/ZemxMRgGmV+ HHef8lhyLthDvucIEHELuRK+xWmcD4fn5Mhk4DN4LLezwrkCDQRYA5J2ARAAyHww3huLEtsd yqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zxx85WcuaO1OVq ung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPpDkGodS0De9os A+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOojGMiLoZvELY8 6Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxMt5LB/MSrmECB 5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoRbh7i4fT0lWvM XTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJV7xVLTtS1Eam VqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p02oSecDl5yVX plJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGXM71OpmONQJGF 24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0Q2zochS64Mcg 0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYBgAAKCRDnR98f lXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw9SLUt7OGuUnI pKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrieb6iPjvAARXJC PTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTjxZzmGgvNSi6J Dlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJiba7iFPcGwcCl CSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhwQYXm4/pDmNT8 UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvLwoHib0jEvohP MJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTNr+qHh+7Ltrkb u/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2KgT1AcZ51E+xG+ cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGoUREr0rkMnFVs WeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> Date: Thu, 28 May 2020 18:22:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 16:22:30 -0000 Hello. On 5/28/20 10:00 AM, Shane Kerr wrote: > As I have mentioned several times on microphone, I think this draft > has huge potential, potentially cutting the number of queries handled > by recursive resolvers almost in half - since they could ask for A and > AAAA records in a single query. I'm not sure if it would be a net benefit if we consider the added complexity (like the few unpleasant corner cases), the need to implement on both sides, and other ways that are available.  Is saving the number of IP-layer packets the only significant motivation? For resolver-to-auth case I do suspect some potential.  Plain UDP will probably still stay popular there for some time.  Though I'm afraid this might _sometimes_ push the answer sizes too large to fit into one packet (in signed zones), which in my eyes slightly reduces attractiveness of the technique, now that we know that UDP over 1.5 kB is no good. For non-auth cases, you typically communicate with just one upstream resolver (or very few), so if the number of packets is a concern, I'd go for a long-lived TCP or TLS connection (there's e.g. privacy motivation, too).  That's all standardized already, and it naturally avoids those extra corner cases.  Sure, it's probably possible to improve significantly on session timers and resuming, performance, usage of Nagle's algorithm, etc. but ATM to me that feels a more worthwhile investment than any of the multi-answer proposals.  One advantage is that many of the TCP/TLS improvements can be deployed one-sidedly with some effect but multi-QTYPEs can't. --Vladimir From nobody Thu May 28 10:47:51 2020 Return-Path: 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 84FB33A0AB8 for ; Thu, 28 May 2020 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 O7ygagW2Wfqc for ; Thu, 28 May 2020 10:47:41 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 2B9373A0AB4 for ; Thu, 28 May 2020 10:47:41 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id n11so3907444qkn.8 for ; Thu, 28 May 2020 10:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DUg86WIGHtStMCObqpt8258enGIyNgEG0NckYlkMzYI=; b=pek5EooSrvlcBUUW8zT5gEEYJrKf82csHtqYLM72yMCoYnS8nOSxzl3IhPT346DZOv EShJchH/DKDyzOxNGAHn+gB8A2cksAbhSdc8k0a/x/ApxpGXCrvzF4GFegoedOezwdhM DtTiUq8RSUqdtt22jYZNpai5c5ycP1+uL48WY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DUg86WIGHtStMCObqpt8258enGIyNgEG0NckYlkMzYI=; b=bzWwr0uzF+bmtjQ/PXZ75J1zbEKqlOS6XkouLIY0RUR9KY1oFIz+O4NY8RPTYMQGhr wGB9avndiY0K2JJqoLobc8G8SIlxzODW+rkvRE34B1flk4Z4sPPIPZPvdg0JnMr511BI wg6EUkNgfMgdCc9jH+N1dE4PAPOGEyilbmXS6OBLfNSNS1ejiASpifDEuV4sVmXxEFVL eXS62+R1kaZQEjPKz1v+ZusVEAQAsoUs552v89b7rwj4wY+MSNOzaoScK7NfrZ3xyMEJ 5U28O/yDV9xhAZb0PHLJTcPDFIAQfU92GL7eEptfx0OpAnLO18Ih3RoOxvOq4TiaTUJO hbcQ== X-Gm-Message-State: AOAM532fowet1j+VrFJdfYzwAwJ9ZpMtP1LWxr/X+wf5ADxlfN8Trsdd bK5BKrVrxk12eD1i4dGE938gSq/VKQAcG43r X-Google-Smtp-Source: ABdhPJzsjvmt1PE2TdFGLF/whjuTD8A+LCHc1ywNGYDgYAGxEUV6YN7zwJnFKOo6DprPN1TRvh/iFg== X-Received: by 2002:a37:6cd:: with SMTP id 196mr3889319qkg.393.1590688059860; Thu, 28 May 2020 10:47:39 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:8432:79d0:ce9f:f840? ([2607:f2c0:e784:c7:8432:79d0:ce9f:f840]) by smtp.gmail.com with ESMTPSA id l188sm5260353qke.127.2020.05.28.10.47.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 10:47:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joe Abley In-Reply-To: <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> Date: Thu, 28 May 2020 13:47:36 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <341E5096-E8D7-49C6-93A2-97881C688035@hopcount.ca> References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> To: =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 17:47:49 -0000 On 28 May 2020, at 12:22, Vladim=C3=ADr =C4=8Cun=C3=A1t = wrote: > I'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to = implement > on both sides, and other ways that are available. Is saving the = number > of IP-layer packets the only significant motivation? >=20 > For resolver-to-auth case I do suspect some potential. [...] This is a tangent, and not directly related to the topic of packing = extra records into an answer section. This general separation of stub-to-resolver and resolver-to-auth use = cases seems like it's coming up more often. Another recent example is = the question of discovery of available transports (DoT, DoH, etc) for = stub-to-resolver is being examined as a separate problem from the same = question for resolver-to-auth, which I think is also reasonable. Architecturally, today, we treat those use cases (and others like = forwarder-to-resolver, or forwarder-to-forwarder) as all using the same = protocol in all the senses of that phrase. Perhaps it's time to look at whether it would be useful to draw some = boundaries across what is currently one diagram describing how people = look stuff up. It seems to me that there are useful distinctions we = could make in response behaviour, for example, depending on whether it's = auth-to-resolver or resolver-to-stub. Access control, transport security = and privacy and amplification potential also seem like they might be = considered differently in different parts of the system. We already have some flags that only mean anything for particular = use-cases, like AD that is meaningless in a response from auth to = resolver. Maybe we could consider an evolution of the architecture to = make it more clear that we can imagine different optimisations being = applied to different parts of it. Just a thought. Joe= From nobody Thu May 28 12:21:50 2020 Return-Path: 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 1C39E3A09A2 for ; Thu, 28 May 2020 12:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 27FdNgyUC_l5 for ; Thu, 28 May 2020 12:21:47 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 D17EF3A0946 for ; Thu, 28 May 2020 12:21:46 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id q11so434787wrp.3 for ; Thu, 28 May 2020 12:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WkcArdDiDGfIb+P7v24qbtIgLTQLViojF5WPWYQLiew=; b=PyG6bfwrOCTkRg38JxTxbuQbrH6OW73JqT5Sn8GAXjbxU2PnfG7UYzNfAGJJmzRE/u g4wdx8S//oCzmYaHbfCOksLN89KBcTuiCiuuYWslimgyOOQ2FHiVHK3KRUVgEsaiJNze sYt5htIdTP8NVLacoVxIQu06rJI6zU7jcJrDmRmvcdf5pjJOq5oijv/m0k6Q19dYz9GF v3KCQzPEXi7Y1LbNsWHUUaCzLQJZ5xn1Mrf21smjjHK/j4FRYlxfKwTvjjLo9QT9JhJQ YRrtE5RHC5THuFw4q5PE+UIulj0wMSKJ1ZUUgllTxV51KSr7Z1NsVgG+1CV4VpJmiPtC Us1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WkcArdDiDGfIb+P7v24qbtIgLTQLViojF5WPWYQLiew=; b=l0S8sLAGhU37Mn+mn9IS/ICkjbGCl8DgJSDk8Mgi/E8zyPnLg1yCq1H3T0uiKK6Gyk sB+k9A30rpuo/VHg4hUWb0fS/eo6UvLjcoEO0vSADZtBNJp3qgsP+7K6Ozl22HgvIdL+ mQiTjtC3dJM/vcP4z81pvceDadFzjeFVEHToAg/8E8ljkGXHpXx01wmPfuVK9DIuh59Y m6Rf9KOh7GC70K9kblccHHyd0Zv5jSu1+wbDWWc33OONX2mAKsZDwA27dhA/udWZdugm 6L8rYaEzII+BAzmpRSyIHk///JaFKKqhTpI+T+S4pqHX7liR9kt/V7jIADZCgYzBNFYF sYWA== X-Gm-Message-State: AOAM533gE2kjnDka36aKhQGFvYKBYk6o4RsTzV8tjrnKLXYeSJcyeWBJ gT/0u6qalAHo2M3NoB2s3XAq/4sB1LS/RsdqfdwQsdNc X-Google-Smtp-Source: ABdhPJzdLiMLNigWwYuAvGOwHxE8UhILp86d/eHPc865vnyPTb0pJ5e8rmt8NLX98ZL/m2HuW+KsP9EagOU/OKMnOtY= X-Received: by 2002:adf:de0b:: with SMTP id b11mr4865813wrm.346.1590693704304; Thu, 28 May 2020 12:21:44 -0700 (PDT) MIME-Version: 1.0 References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> In-Reply-To: <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> From: Eric Orth Date: Thu, 28 May 2020 15:21:32 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="0000000000003156ff05a6ba3d2c" Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 19:21:49 -0000 --0000000000003156ff05a6ba3d2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I lead engineering for the stub resolver built into Chrome browser, so while not an OS-level stub, maybe still prominent enough to count for the "any communication" requested above. My biggest concern with an approach like this is ossification from middleboxes (especially some old home routers) that may not be ideally engineered for the modern web. Chrome has seen significant issues in the past with such middleboxes creating pain (super slow responses mostly) for a small number of our users on sending unusual queries or an increased amount of queries. As such, we're generally afraid of sending out anything other than basic and rate-limited requests when it comes to Classic DNS. Attempting new things and falling back to conservative behavior on an issue is not necessarily a reasonable approach because the middlebox pain is not always limited to the individual queries. In some cases, probing or experimenting with resolver capabilities can cause user pain for all subsequent queries for a period of time on the order of minutes. Since this specific multi-query proposal encodes it in EDNS, it might be more reasonable. I don't have any actual data to back this up, but I would guess that unknown EDNS options are less likely to cause issues than completely unknown queries. So it might be safe enough to at least do super cautious experimentation around it. Note that none of these ossification issues are really a concern with DoH (or DoT) where we can be reasonably sure we're talking to a modern non-ossified resolver. The usefulness of combining queries is a little reduced since DoT and DoH often use connection sharing for multiple requests anyway. But there's still some potential value. In ECH (ESNI) discussions, it has come up a few times that an attacker could try to force a downgrade from ECH by identifying and blocking the larger packets containing HTTPSSVC responses that contain ECH keys but not address resolves. Much safer if A/AAAA and HTTPSSVC can be in the same query/response to force an attacker to block everything or nothing. Additional possible issues with this multi-query proposal: *By combining A and AAAA, you might lose nice abilities to try to speed things up using Happy Eyeballs v2 style algorithms to immediately start using addresses as they come in, before all addresses are received. Not currently a huge issue for Chrome DNS because we don't currently support Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that improvement. *The current proposal seems to give the resolver a lot of leeway to only sometimes include the additional results and includes a TODO note that maybe there should be a way for clients to mark qtypes as mandatory. I don't think the client would get as much use out of multiple qtypes unless it had reasonable confidence that it would at least usually get all the responses. Otherwise, the client is often going to have to make multiple requests in parallel anyway to ensure it can get all the responses reasonably quickly in parallel. Then again, if it's something like requesting an extra qtype that we would be afraid to send in Classic DNS anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more value of just adding in the additional qtype and using the response opportunistically when received. On Thu, May 28, 2020 at 12:22 PM Vladim=C3=ADr =C4=8Cun=C3=A1t wrote: > Hello. > > On 5/28/20 10:00 AM, Shane Kerr wrote: > > As I have mentioned several times on microphone, I think this draft > > has huge potential, potentially cutting the number of queries handled > > by recursive resolvers almost in half - since they could ask for A and > > AAAA records in a single query. > > I'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to implement > on both sides, and other ways that are available. Is saving the number > of IP-layer packets the only significant motivation? > > For resolver-to-auth case I do suspect some potential. Plain UDP will > probably still stay popular there for some time. Though I'm afraid this > might _sometimes_ push the answer sizes too large to fit into one packet > (in signed zones), which in my eyes slightly reduces attractiveness of > the technique, now that we know that UDP over 1.5 kB is no good. > > For non-auth cases, you typically communicate with just one upstream > resolver (or very few), so if the number of packets is a concern, I'd go > for a long-lived TCP or TLS connection (there's e.g. privacy motivation, > too). That's all standardized already, and it naturally avoids those > extra corner cases. Sure, it's probably possible to improve > significantly on session timers and resuming, performance, usage of > Nagle's algorithm, etc. but ATM to me that feels a more worthwhile > investment than any of the multi-answer proposals. One advantage is > that many of the TCP/TLS improvements can be deployed one-sidedly with > some effect but multi-QTYPEs can't. > > --Vladimir > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000003156ff05a6ba3d2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I lead engineering for the stub resolver built into Chrome= browser, so while not an OS-level stub, maybe still prominent enough to co= unt for the "any communication" requested above.

My biggest concern with an approach like this is ossification from middl= eboxes (especially some old home routers) that may not be ideally engineere= d for the modern web.=C2=A0 Chrome has seen significant issues in the past = with such middleboxes creating pain (super slow responses mostly) for a sma= ll number of=C2=A0our users on sending unusual queries or an increased amou= nt of queries.=C2=A0 As such, we're generally afraid of sending out any= thing other than basic and rate-limited requests when it comes to Classic D= NS.=C2=A0 Attempting new things and falling back to conservative behavior o= n an issue is not necessarily a reasonable approach because the middlebox p= ain is not always limited to the individual queries.=C2=A0 In some cases, p= robing or experimenting with resolver capabilities can cause user pain for = all subsequent queries for a period of time on the order of minutes.
<= div>
Since this specific multi-query proposal encodes it in E= DNS, it might be more reasonable.=C2=A0 I don't have any actual data to= back this up, but I would guess that unknown EDNS options are less likely = to cause issues than completely unknown queries.=C2=A0 So it might be safe = enough to at least do super cautious experimentation around it.
<= br>
Note that none of these ossification issues are really a conc= ern with DoH (or DoT) where we can be reasonably sure we're talking to = a modern non-ossified resolver.=C2=A0 The usefulness of combining queries i= s a little reduced since DoT and DoH often use connection sharing for multi= ple requests anyway.=C2=A0 But there's still some potential value.=C2= =A0 In ECH (ESNI) discussions, it has come up a few times that an attacker = could try to force a downgrade from ECH by identifying and blocking the lar= ger packets containing HTTPSSVC responses that contain ECH keys but not add= ress resolves.=C2=A0 Much safer if A/AAAA and HTTPSSVC can be in the same q= uery/response to force an attacker to block everything or nothing.

Additional possible issues with this multi-query proposal:=
*By combining A and AAAA, you might lose nice abilities to try t= o speed things up using Happy Eyeballs v2 style algorithms to immediately s= tart using addresses as they come in, before all addresses are received.=C2= =A0 Not currently a huge issue for Chrome DNS because we don't currentl= y support Happy Eyeballs v2, but we'd be hesitant to lose the ability t= o make that improvement.
*The current proposal seems to give the = resolver a lot of leeway to only sometimes include the additional results a= nd includes a TODO note that maybe there should be a way for clients to mar= k qtypes as mandatory.=C2=A0 I don't think the client would get as much= use out of multiple qtypes=C2=A0unless it had reasonable confidence that i= t would at least usually get all the responses.=C2=A0 Otherwise, the client= is often going to have to make multiple requests in parallel anyway to ens= ure it can get all the responses reasonably quickly in parallel.=C2=A0 Then= again, if it's something like requesting an extra qtype that we would = be afraid to send in Classic DNS anyway (due to the ossification issues), e= g HTTPSVC, I suppose there's more value of just adding in the additiona= l qtype and using the response opportunistically=C2=A0when received.
<= /div>
O= n Thu, May 28, 2020 at 12:22 PM Vladim=C3=ADr =C4=8Cun=C3=A1t <vladimir.cunat+i= etf@nic.cz> wrote:
Hello.

On 5/28/20 10:00 AM, Shane Kerr wrote:
> As I have mentioned several times on microphone, I think this draft > has huge potential, potentially cutting the number of queries handled<= br> > by recursive resolvers almost in half - since they could ask for A and=
> AAAA records in a single query.

I'm not sure if it would be a net benefit if we consider the added
complexity (like the few unpleasant corner cases), the need to implement on both sides, and other ways that are available.=C2=A0 Is saving the numbe= r
of IP-layer packets the only significant motivation?

For resolver-to-auth case I do suspect some potential.=C2=A0 Plain UDP will=
probably still stay popular there for some time.=C2=A0 Though I'm afrai= d this
might _sometimes_ push the answer sizes too large to fit into one packet (in signed zones), which in my eyes slightly reduces attractiveness of
the technique, now that we know that UDP over 1.5 kB is no good.

For non-auth cases, you typically communicate with just one upstream
resolver (or very few), so if the number of packets is a concern, I'd g= o
for a long-lived TCP or TLS connection (there's e.g. privacy motivation= ,
too).=C2=A0 That's all standardized already, and it naturally avoids th= ose
extra corner cases.=C2=A0 Sure, it's probably possible to improve
significantly on session timers and resuming, performance, usage of
Nagle's algorithm, etc. but ATM to me that feels a more worthwhile
investment than any of the multi-answer proposals.=C2=A0 One advantage is that many of the TCP/TLS improvements can be deployed one-sidedly with
some effect but multi-QTYPEs can't.

--Vladimir

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000003156ff05a6ba3d2c-- From nobody Thu May 28 23:47:48 2020 Return-Path: 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 A1E563A0915 for ; Thu, 28 May 2020 23:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 STgmWp6i3Dla for ; Thu, 28 May 2020 23:47:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 50F5C3A0914 for ; Thu, 28 May 2020 23:47:42 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id F1F9313FCD0; Fri, 29 May 2020 08:47:39 +0200 (CEST) To: Joe Abley Cc: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> <341E5096-E8D7-49C6-93A2-97881C688035@hopcount.ca> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: <9a7ad888-16fb-a052-9c2c-f8d901b8d6d2@nic.cz> Date: Fri, 29 May 2020 08:47:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <341E5096-E8D7-49C6-93A2-97881C688035@hopcount.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 06:47:47 -0000 On 28. 05. 20 19:47, Joe Abley wrote: > On 28 May 2020, at 12:22, Vladimír ÄŒunát wrote: > >> I'm not sure if it would be a net benefit if we consider the added >> complexity (like the few unpleasant corner cases), the need to implement >> on both sides, and other ways that are available. Is saving the number >> of IP-layer packets the only significant motivation? >> >> For resolver-to-auth case I do suspect some potential. [...] > > This is a tangent, and not directly related to the topic of packing extra records into an answer section. > > This general separation of stub-to-resolver and resolver-to-auth use cases seems like it's coming up more often. Another recent example is the question of discovery of available transports (DoT, DoH, etc) for stub-to-resolver is being examined as a separate problem from the same question for resolver-to-auth, which I think is also reasonable. > > Architecturally, today, we treat those use cases (and others like forwarder-to-resolver, or forwarder-to-forwarder) as all using the same protocol in all the senses of that phrase. >From my resolver implementer view, these variants actually _are_ different protocols which merely share the same wire format and port number. Differences between mentioned protocol manifest itself any time we encounter a network which silently redirects all traffic on port 53 to local resolver. Recursive resolution attempts in such networks fails horribly because the protocols are actually different and fields mean different things. Having said that ... > > Perhaps it's time to look at whether it would be useful to draw some boundaries across what is currently one diagram describing how people look stuff up. It seems to me that there are useful distinctions we could make in response behaviour, for example, depending on whether it's auth-to-resolver or resolver-to-stub. Access control, transport security and privacy and amplification potential also seem like they might be considered differently in different parts of the system. > > We already have some flags that only mean anything for particular use-cases, like AD that is meaningless in a response from auth to resolver. Maybe we could consider an evolution of the architecture to make it more clear that we can imagine different optimisations being applied to different parts of it. I very much agree, we need to clean up this historical mess! Clear split between stub/forwarding/recursive would help a lot. -- Petr Å paÄek @ CZ.NIC From nobody Fri May 29 00:06:17 2020 Return-Path: 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 639E53A095E for ; Fri, 29 May 2020 00:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 cwGWqVaBV9Sm for ; Fri, 29 May 2020 00:06:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 EC1533A095B for ; Fri, 29 May 2020 00:06:11 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:9943:9e83:4a73:f678]) by mail.nic.cz (Postfix) with ESMTPSA id EA87213FE60 for ; Fri, 29 May 2020 09:06:07 +0200 (CEST) To: dnsop@ietf.org References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ== Organization: CZ.NIC Message-ID: <16ef2458-8175-3311-88f4-80028a00549e@nic.cz> Date: Fri, 29 May 2020 09:06:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 07:06:16 -0000 On 28. 05. 20 21:21, Eric Orth wrote: > I lead engineering for the stub resolver built into Chrome browser, so while not an OS-level stub, maybe still prominent enough to count for the "any communication" requested above. > > My biggest concern with an approach like this is ossification from middleboxes (especially some old home routers) that may not be ideally engineered for the modern web.  Chrome has seen significant issues in the past with such middleboxes creating pain (super slow responses mostly) for a small number of our users on sending unusual queries or an increased amount of queries.  As such, we're generally afraid of sending out anything other than basic and rate-limited requests when it comes to Classic DNS.  Attempting new things and falling back to conservative behavior on an issue is not necessarily a reasonable approach because the middlebox pain is not always limited to the individual queries.  In some cases, probing or experimenting with resolver capabilities can cause user pain for all subsequent queries for a period of time on the order of minutes. > > Since this specific multi-query proposal encodes it in EDNS, it might be more reasonable.  I don't have any actual data to back this up, but I would guess that unknown EDNS options are less likely to cause issues than completely unknown queries.  So it might be safe enough to at least do super cautious experimentation around it. I would say it depends on sheer luck: EDNS handling is specified in RFC 2671 from 1999, unknown type handling is in RFC 3597 from 2003. Both should work in 2020. If they don't because resolver vendors does not care. > > Note that none of these ossification issues are really a concern with DoH (or DoT) where we can be reasonably sure we're talking to a modern non-ossified resolver. Sorry but I think you have unrealistic hopes, probably caused by largely nonexistent auto-disovery of DoH/DoT servers. AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ!box router - mainstream in Germany and countries around) are adding support for DoT and possibly also DoH. Personally I do not see any reason why their resolver available over DoT/DoH should work any better than their unencrypted DNS resolver, which is (at least not in case of AVM) not famous for standards-compliance or performance. Of course vendors are going to reuse whatever they had before, so additional TLS+HTTP layers will just add new bugs on top of whatever bugs they had before. In other words, whole anti-ossification argument seems to hold at the moment only because of missing auto-discovery protocol for encrypted transports. Once we have auto-discovery all the problems will bounce back. Sorry for my grim predictions! > The usefulness of combining queries is a little reduced since DoT and DoH often use connection sharing for multiple requests anyway.  But there's still some potential value.  In ECH (ESNI) discussions, it has come up a few times that an attacker could try to force a downgrade from ECH by identifying and blocking the larger packets containing HTTPSSVC responses that contain ECH keys but not address resolves.  Much safer if A/AAAA and HTTPSSVC can be in the same query/response to force an attacker to block everything or nothing. Hmm, shouldn't it be detected at TLS layer? It seems to me that only explotable problem would be if client interpreted connection timeout or TLS errors as missing ESNI RR, which does not sound like a good idea to me. > Additional possible issues with this multi-query proposal: > *By combining A and AAAA, you might lose nice abilities to try to speed things up using Happy Eyeballs v2 style algorithms to immediately start using addresses as they come in, before all addresses are received.  Not currently a huge issue for Chrome DNS because we don't currently support Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that improvement. Interesting... Do you have measurements which suggest that A/AAAA answers have different timing properties? I would expect it mostly depends on whatever is in cache, and if multi-query takes off we can expect both to be present in cache with the same TTL. > *The current proposal seems to give the resolver a lot of leeway to only sometimes include the additional results and includes a TODO note that maybe there should be a way for clients to mark qtypes as mandatory.  I don't think the client would get as much use out of multiple qtypes unless it had reasonable confidence that it would at least usually get all the responses.  Otherwise, the client is often going to have to make multiple requests in parallel anyway to ensure it can get all the responses reasonably quickly in parallel.  Then again, if it's something like requesting an extra qtype that we would be afraid to send in Classic DNS anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more value of just adding in the additional qtype and using the response opportunistically when received. I agree - making it mandatory seems like reasonable approch (within certain limits, e.g. answer size etc.). Petr Å paÄek @ CZ.NIC > > On Thu, May 28, 2020 at 12:22 PM Vladimír ÄŒunát > wrote: > > Hello. > > On 5/28/20 10:00 AM, Shane Kerr wrote: > > As I have mentioned several times on microphone, I think this draft > > has huge potential, potentially cutting the number of queries handled > > by recursive resolvers almost in half - since they could ask for A and > > AAAA records in a single query. > > I'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to implement > on both sides, and other ways that are available.  Is saving the number > of IP-layer packets the only significant motivation? > > For resolver-to-auth case I do suspect some potential.  Plain UDP will > probably still stay popular there for some time.  Though I'm afraid this > might _sometimes_ push the answer sizes too large to fit into one packet > (in signed zones), which in my eyes slightly reduces attractiveness of > the technique, now that we know that UDP over 1.5 kB is no good. > > For non-auth cases, you typically communicate with just one upstream > resolver (or very few), so if the number of packets is a concern, I'd go > for a long-lived TCP or TLS connection (there's e.g. privacy motivation, > too).  That's all standardized already, and it naturally avoids those > extra corner cases.  Sure, it's probably possible to improve > significantly on session timers and resuming, performance, usage of > Nagle's algorithm, etc. but ATM to me that feels a more worthwhile > investment than any of the multi-answer proposals.  One advantage is > that many of the TCP/TLS improvements can be deployed one-sidedly with > some effect but multi-QTYPEs can't. > > --Vladimir From nobody Fri May 29 09:24:38 2020 Return-Path: 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 3DBE13A0D9A for ; Fri, 29 May 2020 09:24:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=kumari-net.20150623.gappssmtp.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 SL8mI-M4zg4Z for ; Fri, 29 May 2020 09:24:32 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 BB0963A0D7D for ; Fri, 29 May 2020 09:24:31 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id s1so3364936ljo.0 for ; Fri, 29 May 2020 09:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i87JIV2LcRC3HDQznTHUcOh6lH5Px/e+R5LAPR56pRM=; b=RKXBqOYL2HxP3YbVhZAl3sombx677X0BfbXlk+YUah4jTSgGwN4uDN0ColJDAeXwVn ZOFhGfBA/ALUv8QmSvTd5a5NzTKWm1mWOkItzeFoJO4WHt5AKBlanyQ36Hnfaj4ZSD4M 0fx0lfOjPy1DuAN/0E+SS+6gfwo9fsJ/eUb3fILIGLYGBzA7u8cwb+n7ioucvZSJToxC FbBEtJjI9R8fa7FycPl84Z3/M8Q9izhHvAQfK4aC6K9Py+zItwZgAMdgGPyT6Ax6Mopz 2ZMFIv/fp0tKzI2WJ/EWBEiH7jhd2IGn38eWKFFwa88bD81AJ+OMRwPbgTZZlXVXwHTE Ra/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i87JIV2LcRC3HDQznTHUcOh6lH5Px/e+R5LAPR56pRM=; b=hZYnbn63dzLxNxHXJRRZ7H0u5PNPQQZinspiKlW7jdHrLzvhVvB/bH7y7MvUWBN0Wn 5PIUkCORDiIiNqCASBT5L2SCW4rYc0CVA2PHUyPXhaCLWirSZ/Fxo60qdm2sIw3hFegr gF6T0fbCdoPpKWQrJwMFTSdOR1IYAV4oEcKtPzDpElfVoK8SUhp60eTNV8iFWim3DQxa NFfimEbR7N2EtpHVMeh0QKXisr851CYPclRFY28B4JdZ1tkup2lDshHQANLez2LGEijd zt+SRWEA6If5TMIlq2eOnp6X0CycsxcIeadV2JN/kKf4VfgAjSn4zpEu77EE2GJl+w2b FwYg== X-Gm-Message-State: AOAM531/psuTIv3XMHEX2VKa7AZr1fXidopHPjlpIRxUvSC496DntLNY DGnmWwLBZJgkCOSD1jr4jx45mCy1CdT0jtHWOoUzeg== X-Google-Smtp-Source: ABdhPJwRQ9F9Lq4WVMqzQTTlCj+yYZlk9xh3RcrcR5lwyRvURT4K+j8sgvnD5PJADOXPdWreIeK0qXZ9VHxxlmwXaQI= X-Received: by 2002:a05:651c:103a:: with SMTP id w26mr4632085ljm.403.1590769468754; Fri, 29 May 2020 09:24:28 -0700 (PDT) MIME-Version: 1.0 References: <80827E5F-F0DF-4A3C-BD2D-9E57991337FD@gmail.com> In-Reply-To: From: Warren Kumari Date: Fri, 29 May 2020 12:23:51 -0400 Message-ID: To: Donald Eastlake Cc: Tim Wicinski , Stephen Morris , dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:24:36 -0000 On Mon, May 11, 2020 at 3:39 PM Donald Eastlake wrote: > > Hi Tim, > > On Mon, May 11, 2020 at 1:51 PM Tim Wicinski wrote: >> >> Donald >> >> So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ? > > > Yes, that would be fine. > Having heard no objections / other comments, let's go with this. Thank you everyone, and special thanks to the authors for being so diligent, and Tim for the writeup / summary... Authors, please submit the updated version, and POKE ME LOUDLY so I don't miss it. W > SHA-224 is just SHA-256 with some different initial vectors and the resul= t truncated to 224 bits. So if you have implemented SHA-256, it takes like = 0.1% more code to add SHA-224. And, while the value of SHA-224 would be dif= ferent for a particular input from the value of SHA-256 truncated to 224 bi= ts, I don't see any reason why it would be less secure. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E.. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > >> On Mon, May 11, 2020 at 12:29 AM Donald Eastlake wrot= e: >>> >>> The incremental effort to implement SHA-224 if you are implementing SHA= -256 is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDE= D to use when SHA-256 is MUST implement and RECOMMENDED to use and you can = use SHA-256 with truncation to 224 or even fewer bits. >>> >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>> Donald E.. Eastlake 3rd +1-508-333-2270 (cell) >>> 2386 Panoramic Circle, Apopka, FL 32703 USA >>> d3e3e3@gmail.com >>> >>> >>> On Sat, May 9, 2020 at 9:52 PM Tim Wicinski wrote: >>>> >>>> To follow up on Stephen's comments, a table was added to 2845bis to >>>> list all the algorithms that are currently in the IANA registry, >>>> along with suggestions for implementation. This was the first version= : >>>> >>>> Requirement Name >>>> ----------- ------------------------ >>>> Optional HMAC-MD5.SIG-ALG.REG.INT >>>> Optional gss-tsig >>>> Mandatory hmac-sha1 >>>> Optional hmac-sha224 >>>> Mandatory hmac-sha256 >>>> Optional hmac-sha384 >>>> Optional hmac-sha512 >>>> >>>> During the IESG review (I think it was the SECDIR review), there was >>>> a meltdown over implementing SHA-1. But SHA-1 is in use currently. >>>> My suggestion was to do a variation describing implementation use. >>>> This is what I came up with(so blame me): >>>> >>>> Name Implementation Use >>>> ------------------------ -------------- --------------- >>>> HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT >>>> gss-tsig MAY MAY >>>> hmac-sha1 MUST NOT RECOMMENDED >>>> hmac-sha224 MAY NOT RECOMMENDED >>>> hmac-sha256 MUST RECOMMENDED >>>> hmac-sha256-128 MAY MAY >>>> hmac-sha384 MAY MAY >>>> hmac-sha384-192 MAY MAY >>>> hmac-sha512 MAY MAY >>>> hmac-sha512-256 MAY MAY >>>> >>>> On the use side, these are mostly guesses. We would love to hear >>>> what the WG has to say about this. >>>> >>>> thanks >>>> tim >>>> >>>> >>>> On Mon, May 4, 2020 at 2:07 PM Stephen Morris w= rote: >>>>> >>>>> >>>>> > On 4 May 2020, at 19:00, internet-drafts@ietf.org wrote: >>>>> > >>>>> > >>>>> > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> > This draft is a work item of the Domain Name System Operations WG o= f the IETF. >>>>> > >>>>> > Title : Secret Key Transaction Authentication for = DNS (TSIG) >>>>> > Authors : Francis Dupont >>>>> > Stephen Morris >>>>> > Paul Vixie >>>>> > Donald E. Eastlake 3rd >>>>> > Olafur Gudmundsson >>>>> > Brian Wellington >>>>> > Filename : draft-ietf-dnsop-rfc2845bis-08.txt >>>>> > Pages : 29 >>>>> > Date : 2020-05-04 >>>>> >>>>> >>>>> The update addresses to the draft comments made during the IESG revie= w. There were a fair number of these which led to a number of changes to t= he document. These are listed below. >>>>> >>>>> One significant change is that the list of acceptable algorithms has = been extended, and WG approval for this is sought. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> >>>>> Comments from Roman Danyliw >>>>> --- >>>>> > ** Section 1.3. Per =E2=80=9CIn 2017, two nameservers strictly fo= llowing that document (and the related [RFC4635]) were discovered to have s= ecurity problems related to this feature=E2=80=9D, consider providing a ref= erence to the published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3= 143) >>>>> >>>>> I=E2=80=99ve added these (and one other related CVE) as informative r= eferences. Using just the CVE number as a reference seemed a bit spartan, = so I=E2=80=99ve added a title to each incident. As the description of the C= VEs in Mitre=E2=80=99s database don=E2=80=99t contain a title (only a descr= iption, which can be rather long), I=E2=80=99ve taken the title from ISC=E2= =80=99s KnowledgeBase (for the BIND CVEs) and from the Knot release notes (= for the Knot CVE). >>>>> >>>>> >>>>> > ** Section 6. Per =E2=80=9CSHA-1 collisions have been demonstrated= so the MD5 security considerations apply to SHA-1 in a similar manner. Al= though support for hmac-sha1 in TSIG is still mandatory for compatibility r= easons, existing uses should be replaced with hmac-sha256 or other SHA-2 di= gest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>>>> > >>>>> > -- It=E2=80=99s worth repeating those MD5 security considerations h= ere >>>>> >>>>> I=E2=80=99m not really keen on doing this, since the security conside= rations in RFC 6151 cover two paragraphs and including them - or even a sum= mary of them - would detract from the flow of the document. However, I hav= e explicitly included a reference to RFC 6151 in the text. >>>>> >>>>> >>>>> > -- (from Magnus Nystrom=E2=80=99s SECDIR review, thanks Magnus!) it= =E2=80=99s worth including references to the recent SHA-1 cryptoanalysis pr= ovided in the SECDIR review >>>>> >>>>> Added references to just one of these papers (=E2=80=9DSHA1 is a Sham= bles=E2=80=9D). We=E2=80=99re not doing a general analysis of the algorith= ms, so a simple reference to a paper than describes a SHA1 collision is all= that is needed. (As an aside, the paper doesn't give the date of publicat= ion, so I had to search the Web looking for references to it. I think I=E2= =80=99ve got the date correct, but I=E2=80=99d be grateful for a double-che= ck.) >>>>> >>>>> >>>>> > -- The SHA-2 family should be a normative SHOULD (or RECOMMENDED). >>>>> >>>>> Done - see Table 2 >>>>> >>>>> >>>>> > ** Section 10. Per =E2=80=9CFor all of the message authentication = code algorithms listed in this document, those producing longer values are = believed to be stronger=E2=80=9D, as noted in Magnus=E2=80=99s SECDIR revie= w, this could be misconstrued as the algorithm choice not the digest length= provides the security. Recommend rephrasing (or making some statement >>>>> >>>>> I=E2=80=99ve reworded this paragraph (in section 10). It now reads: >>>>> >>>>> "Although the strength of an algorithm determines its security, the= re >>>>> have been some arguments that mild truncation can strengthen a MAC = by >>>>> reducing the information available to an attacker. However, excess= ive >>>>> truncation clearly weakens authentication by reducing the number of >>>>> bits an attacker has to try to break the authentication by brute >>>>> force [RFC2104]." >>>>> >>>>> >>>>> > ** Editorial >>>>> > -- Section 4.3.2. Per =E2=80=9CWhen verifying an incoming message,= this is the message after the TSIG RR and been removed and the ARCOUNT fie= ld has been decremented.=E2=80=9D, this sentence doesn=E2=80=99t parse (is = missing a word). >>>>> > >>>>> > -- Section 4.3.2. Per =E2=80=9CA whole and complete DNS message in= wire format.=E2=80=9D, this isn=E2=80=99t a sentence. >>>>> >>>>> Section 4.3.2 has been reworded to address these issues. >>>>> >>>>> >>>>> >>>>> Comments from Benjamin Kaduk >>>>> >>>>> > Thanks for putting together this update; it's good to see the secur= ity >>>>> > issue getting closed off in the udpated spec, and progression to fu= ll >>>>> > Internet Standard! I do have several substantive comments (as well= as >>>>> > some minor/nit-level ones), many of which are listed here at the to= p but >>>>> > a few of which are interspersed in the per-section comments. >>>>> > >>>>> > >>>>> > I considered making this a Discuss point, but it should be pretty >>>>> > uncontroversial and I trust that the right thing will happen even i= f I >>>>> > don't: there's a couple lingering remnants of SHA-1 being the >>>>> > preferred algorithm that need to be cleaned up, in Sections 5.2.2.1= and >>>>> > 10 (further detailed in the per-section comments). >>>>> >>>>> The document now mentions SHA1 collisions and notes that the MD5 secu= rity considerations apply to SHA1. It also mentions that support for SHA1 = is mandatory for compatibility reasons but in existing uses it should be re= placed by a stronger one. >>>>> >>>>> >>>>> > I also initially had made the following point a Discuss-level point= , but >>>>> > decided to not do so since I don't remember any BCP-level guidance >>>>> > relating to cross-protocol attacks. Nevertheless, I strongly encou= rage >>>>> > the authors to consider that cryptographic best practice is to use = any >>>>> > given key with exactly one cryptographic algorithm. The record for= mat >>>>> > listed in Section 4.2 has the key name and algorithm as separately >>>>> > conveyed, which would allow for a given key to be used with all >>>>> > implemented algorithms. We should include some discussion that it'= s >>>>> > best to only use a single algorithm with any given key. >>>>> >>>>> The following text has been added to the Security Considerations sect= ion: >>>>> >>>>> "To prevent cross-algorithm attacks, there SHOULD only be one >>>>> algorithm associated with any given key name." >>>>> >>>>> >>>>> > We also have a 16-bit wide field for "Fudge", which (since it count= s >>>>> > seconds) corresponds to a maximum window of something like +/- 18 h= ours; >>>>> > it's hard to believe that we really want to give people the rope to >>>>> > allow for that much time skew. (Yes, I understand that implementat= ions >>>>> > will set something sane in practice but that doesn't necessarily me= an >>>>> > that the protocol still has to allow it.) >>>>> >>>>> That was set in the original RFC 2845. Although I agree with the com= ments, changing the size of that field would be a significant undertaking. = However, section 10 does state that the RECOMMENDED fudge value in most ci= rcumstances is 300 seconds. >>>>> >>>>> >>>>> > Our authoritative list of algorithm names (Table 1) is rather divor= ced >>>>> > from the references to be consulted for the individual hash algorit= hms >>>>> > to be used with the HMAC procedure. The ones used here are suffici= ently >>>>> > well-known that I'm not terribly concerned about it, though. >>>>> >>>>> The first paragraph of the IANA considerations section lists the algo= rithms and references to where they are described, and I didn=E2=80=99t wan= t to duplicate the information. >>>>> >>>>> >>>>> > Abstract >>>>> > >>>>> > The title says "DNS" but maybe the body of the abstract should as w= ell? >>>>> >>>>> In the abstract, changed: >>>>> >>>>> "It can be used to authenticate dynamic updates as coming from an app= roved client" >>>>> >>>>> to >>>>> >>>>> "It can be used to authenticate dynamic updates to a DNS zone as comi= ng from an approved client" >>>>> >>>>> >>>>> > Section 1.1 >>>>> > >>>>> > Some of this language feels like it might not age terribly well, e.= g., >>>>> > "this can provide" or "[t]here was a need". >>>>> > >>>>> > addresses that need. The proposal is unsuitable for general serv= er >>>>> > to server authentication for servers which speak with many other >>>>> > servers, since key management would become unwieldy with the numb= er >>>>> > of shared keys going up quadratically. But it is suitable for ma= ny >>>>> > resolvers on hosts that only talk to a few recursive servers. >>>>> >>>>> Changed to: >>>>> >>>>> "The authentication mechanism proposed here provides a >>>>> simple and efficient authentication between clients and local= servers >>>>> by using shared secret keys to establish a trust relationship= between >>>>> two entities. Such keys must be protected in a manner simila= r to >>>>> private keys, lest a third party masquerade as one of the int= ended >>>>> parties (by forging the MAC). The proposal is unsuitable for= general >>>>> server to server authentication for servers which speak with = many >>>>> other servers, since key management would become unwieldy wit= h the >>>>> number of shared keys going up quadratically. But it is suita= ble for >>>>> many resolvers on hosts that only talk to a few recursive ser= vers.=E2=80=9D >>>>> >>>>> >>>>> > Should zone transfers be mentioned here as well? >>>>> >>>>> Zone transfers are mentioned in the preceding paragraph. >>>>> >>>>> >>>>> > Section 1.2 >>>>> > >>>>> > I don't understand the motivation for changing terminology from MAC= s to >>>>> > "signatures"; they're still MACs even though they're transaction-ba= sed. >>>>> >>>>> The mention of signatures in section 1.2 is intended as a link betwee= n the name of the RR (TSIG or Transaction Signature) and the term MAC used = in the rest of the document. >>>>> >>>>> >>>>> > MAC of the query as part of the calculation. Where a response >>>>> > comprises multiple packets, the calculation of the MAC associated >>>>> > with the second and subsequent packets includes in its inputs the= MAC >>>>> > for the preceding packet. In this way it is possible to detect a= ny >>>>> > interruption in the packet sequence. >>>>> > >>>>> > I suggest mentioning the lack of mechanism to detect truncation of = the >>>>> > packet sequence. >>>>> >>>>> That is a fair point. I=E2=80=99ve modified the last sentence to rea= d: >>>>> >>>>> "In this way it is possible to detect any interruption in the pack= et sequence, >>>>> although not its premature termination." >>>>> >>>>> >>>>> > Section 4.2 >>>>> > >>>>> > NAME The name of the key used, in domain name syntax... The nam= e >>>>> > should reflect the names of the hosts and uniquely identify= the >>>>> > key among a set of keys these two hosts may share at any gi= ven >>>>> > time. For example, if hosts A.site.example and >>>>> > B.example.net >>>>> > >>>>> > share a key, possibilities for the key name include >>>>> > .A.site.example, ...B.example.net, and >>>>> > .A.site.example.B...example.net. It should be possible= for >>>>> > more than one key to be in simultaneous use among a set of >>>>> > interacting hosts. >>>>> > >>>>> > I'd suggest adding a note along the lines of "This allows for perio= dic >>>>> > key rotation per best operational practices, as well as algorithm >>>>> > agility as indicated by [BCP201].=E2=80=9D >>>>> >>>>> Added. >>>>> >>>>> >>>>> > The name may be used as a local index to the key involved a= nd >>>>> > it is recommended that it be globally unique. Where a key = is >>>>> > >>>>> > (nit?): this feels more like a "but" than an "and", to me. >>>>> >>>>> Well spotted. I also think it is more =E2=80=9Cbut=E2=80=9D than =E2= =80=9Cand=E2=80=9D >>>>> >>>>> >>>>> > * MAC Size - an unsigned 16-bit integer giving the length = of >>>>> > MAC field in octets. Truncation is indicated by a MAC s= ize >>>>> > less than the size of the keyed hash produced by the >>>>> > algorithm specified by the Algorithm Name. >>>>> > >>>>> > nit: I would suggest "output size", as there are potentially a few >>>>> > different sizes involved (key size, block size, and output size, fo= r >>>>> > starters, though I think the possibility of confusion here is low). >>>>> >>>>> I disagree here. =E2=80=9CMAC Size=E2=80=9D is an unambiguous referen= ce to this field, and the other size mentioned - that of the keyed hash is,= I think, also unambiguous. >>>>> >>>>> >>>>> > * Other Len - an unsigned 16-bit integer specifying the le= ngth >>>>> > of the "Other Data" field in octets. >>>>> > >>>>> > * Other Data - this unsigned 48-bit integer field will be >>>>> > empty unless the content of the Error field is BADTIME, = in >>>>> > which case it will contain the server's current time as = the >>>>> > number of seconds since 00:00 on 1970-01-01 UTC, ignorin= g >>>>> > leap seconds (see Section 5.2...3). >>>>> > >>>>> > I'm slightly confused at the interplay between the explicit length = field >>>>> > and the "empty unless" directive. Does this mean that the only all= owed >>>>> > values in the "Other Len" are 0 and 6? Does "empty" mean "length-z= ero=E2=80=9D? >>>>> >>>>> I=E2=80=99ve rewritten this slightly in a bid to make it clearer that= =E2=80=9COther Data=E2=80=9D being empty means that =E2=80=9COther Len=E2= =80=9D is zero. >>>>> >>>>> >>>>> > Section 4.3.1 >>>>> > >>>>> > Only included in the computation of a MAC for a response message = (or >>>>> > the first message in a multi-message response), the validated req= uest >>>>> > MAC MUST be included in the MAC computation. If the request MAC >>>>> > failed to validate, an unsigned error message MUST be returned >>>>> > instead. (Section 5.3.2). >>>>> > >>>>> > side note: while Section 5.3.2 specifies how to create an unsigned = error >>>>> > message, it looks like Section 5.2 (and subsections lists specific >>>>> > RCODEs that are to be used. >>>>> >>>>> That is the case. Section 4 is a description of the TSIG RR and its = fields. Section 5 describes the contents of the fields in various situatio= ns (client transmission, server reception, server transmission, client rece= ption). >>>>> >>>>> >>>>> > Section 4.3.2 >>>>> > >>>>> > When verifying an incoming message, this is the message after the >>>>> > TSIG RR and been removed and the ARCOUNT field has been decrement= ed. >>>>> > If the message ID differs from the original message ID, the origi= nal >>>>> > message ID is substituted for the message ID. (This could happen= , >>>>> > for example, when forwarding a dynamic update request.) >>>>> > >>>>> > I trust (based on this text having survived while going for full IS= ) >>>>> > that there are no interesting record-keeping considerations with re= spect >>>>> > to knowing the message ID(s) to substitute, in the "forwarding a >>>>> > dynamic-update request" case, presumably since this is just the fie= ld >>>>> > from the TSIG RDATA and not some externally retained state. >>>>> >>>>> That is correct - the original ID is stored in the TSIG record=E2=80= =99s RDATA and it is from there that the original ID is retrieved when a su= bstitution is made. >>>>> >>>>> >>>>> > Section 4.3.3 >>>>> > >>>>> > The RR RDLEN and RDATA MAC Length are not included in the input t= o >>>>> > MAC computation since they are not guaranteed to be knowable befo= re >>>>> > the MAC is generated. >>>>> > >>>>> > I appreciate that this is explicitly noted; there are some security >>>>> > considerations regarding the non-inclusion of the (truncated) mac l= ength >>>>> > as input, though. The local truncation policy helps here, but not = 100%. >>>>> >>>>> OK >>>>> >>>>> >>>>> > For each label type, there must be a defined "Canonical wire form= at" >>>>> > >>>>> > Just to check my understanding: label types only come into play for= the >>>>> > two fields that are in domain name syntax, key name and algorithm n= ame? >>>>> >>>>> There was actually an error in the text here: RFC 4034 section 6.1 is= concerned with Canonical Name Order. It is section 6.2 that details the c= anonical wire format - I=E2=80=99ve changed the reference. >>>>> >>>>> Going back to the original point, yes, that is correct. Label type 0= 0 is uncompressed name. (11 is a compressed name, and label types 01 and 10= are discouraged - see RFC 6891 section 5). >>>>> >>>>> >>>>> > Section 5.1 >>>>> > >>>>> > the server. This TSIG record MUST be the only TSIG RR in the mes= sage >>>>> > and MUST be last record in the Additional Data section. The clie= nt >>>>> > >>>>> > (Is there anything else that tries to insist on being the last reco= rd in >>>>> > the additional data section? I guess it doesn't really make sense = to >>>>> > try to Update: 1035 just to note this requirement.) >>>>> >>>>> Not to our knowledge. >>>>> >>>>> >>>>> > MUST store the MAC and the key name from the request while awaiti= ng >>>>> > an answer. >>>>> > >>>>> > [This is going to end up alongside the request-ID that it has to st= ore >>>>> > already, right?] >>>>> >>>>> Yes. The request MAC is included as one of the components used by th= e server to generate the response - which should be encoded using the same = key as used in the request. >>>>> >>>>> >>>>> > Note that some older name servers will not accept requests with a >>>>> > nonempty additional data section. Clients SHOULD only attempt si= gned >>>>> > transactions with servers who are known to support TSIG and share >>>>> > some algorithm and secret key with the client -- so, this is not = a >>>>> > problem in practice. >>>>> > >>>>> > (The context in which this "SHOULD" appears makes it feel like it's >>>>> > repeating an admontion from elsewhere and not the only instance of = the >>>>> > requirement, in which case a reference might be appropriate.) >>>>> >>>>> I=E2=80=99ve removed this paragraph. The reference to older name ser= vers is now completely out of date (it was a carry-over from the original 2= 0-year old text). The rest of the paragraph seems superfluous - rather lik= e stating that TCP clients should only connect to servers that support TCP. >>>>> >>>>> >>>>> > Section 5.2 >>>>> > >>>>> > If the TSIG RR cannot be understood, the server MUST regard the >>>>> > message as corrupt and return a FORMERR to the server. Otherwise= the >>>>> > server is REQUIRED to return a TSIG RR in the response. >>>>> > >>>>> > As written, this could be read as an attempt to make a normative >>>>> > requirement of servers that do not implement this spec. Presumably= it's >>>>> > just restating a requirement of the core protocol, though? >>>>> >>>>> It is the core protocol. >>>>> >>>>> I see your point though. However, by implication we are talking abou= t a server that implements TSIG. >>>>> >>>>> >>>>> > Section 5.2.2 >>>>> > >>>>> > Using the information in the TSIG, the server should verify the M= AC >>>>> > by doing its own calculation and comparing the result with the MA= C >>>>> > received. If the MAC fails to verify, the server MUST generate a= n >>>>> > >>>>> > Is there any other way to verify the MAC? (Should this be a "MUST >>>>> > verify=E2=80=9D?) >>>>> >>>>> Well spotted, it should be a =E2=80=9CMUST=E2=80=9D - changed. >>>>> >>>>> >>>>> > Section 5.2.2.1 >>>>> > >>>>> > When space is at a premium and the strength of the full length of= a >>>>> > MAC is not needed, it is reasonable to truncate the keyed hash an= d >>>>> > use the truncated value for authentication. HMAC SHA-1 truncated= to >>>>> > 96 bits is an option available in several IETF protocols, includi= ng >>>>> > IPsec and TLS. >>>>> > >>>>> > Also Kerberos, where it was the strongest option for a while and we= had >>>>> > to define a new encryption type to provide a better option (RFC 800= 9). >>>>> > >>>>> > This text seems to be implying that HMAC SHA-1 truncated to 96 bits= is a >>>>> > recommendable option, which is ... far from clear. I'd prefer to h= ave a >>>>> > note that this specific truncation was appropriate when initially >>>>> > specified but may not provide a security level appropriate for all = cases >>>>> > in the modern environment, or preferrably to just change the refere= nce >>>>> > to (e.g.) SHA-384-192 or SHA-256-128. >>>>> >>>>> Added the following an the end of the paragraph: >>>>> >>>>> However, while this option is kept for backwards compatibility, >>>>> it may not provide a security level appropriate for all cases >>>>> in the modern environment. In these cases, it is preferable to >>>>> use a hashing algorithm such as SHA-256-128, SHA-384-192 >>>>> or SHA-256-128 [RFC4868]. >>>>> >>>>> I=E2=80=99ve also added the algorithms =E2=80=9Chmac-sha256-128=E2=80= =9D, =E2=80=9Chmac-sha384-192=E2=80=9D and =E2=80=9Chmac-sha512-256=E2=80= =9D as optional algorithms to the algorithm table. >>>>> >>>>> >>>>> > This is sent when the signer has truncated the keyed hash out= put >>>>> > to an allowable length, as described in [RFC2104], taking ini= tial >>>>> > octets and discarding trailing octets. TSIG truncation can o= nly >>>>> > >>>>> > (Or when an on-path attacker has performed truncation.) >>>>> >>>>> True, but an on-path attacker can manipulate the message in any way p= ossible. I=E2=80=99m not sure whether adding this caveat will add anything= to the document. >>>>> >>>>> >>>>> > Section 5.2.3 >>>>> > >>>>> > (BADTIME). The server SHOULD also cache the most recent time sig= ned >>>>> > value in a message generated by a key, and SHOULD return BADTIME = if a >>>>> > message received later has an earlier time signed value. A respo= nse >>>>> > >>>>> > (But there's no fudge factor on this check, other than the inherent >>>>> > limit of seconds granularity, as alluded to by the last paragraph o= f >>>>> > this section?) >>>>> >>>>> The last paragraph in the section states that handling this issue sho= uld be left up to implementations and that the exact method (and by implica= tion, the size of the fudge factor) be determined by the implementation the= mselves. >>>>> >>>>> >>>>> > Section 5.3.1 >>>>> > >>>>> > A zone transfer over a DNS TCP session can include multiple DNS >>>>> > messages. Using TSIG on such a connection can protect the connec= tion >>>>> > from hijacking and provide data integrity. The TSIG MUST be incl= uded >>>>> > >>>>> > (I assume that "hijacking TCP" means a sequence-number-guessing att= ack >>>>> > that would require the attacker to be winning the race against the >>>>> > legitimate sender to cause modified data to be introduced into the = TCP >>>>> > stream? This is maybe not the best word to use for such a case.) >>>>> >>>>> I=E2=80=99ve changed =E2=80=9Chijack=E2=80=9D to =E2=80=9Cattack=E2= =80=9D. >>>>> >>>>> >>>>> > on all DNS messages in the response. For backward compatibility,= a >>>>> > client which receives DNS messages and verifies TSIG MUST accept = up >>>>> > to 99 intermediary messages without a TSIG. The first message is >>>>> > >>>>> > (side note: I'm kind of curious what such compatibility is needed w= ith. >>>>> > Also, this gives an attacker some flexibility into which to incorpo= rate >>>>> > a collision, though given the near-real-time constraints and the >>>>> > strength of the HMAC construction I don't expect any practical impa= ct.) >>>>> >>>>> The original RFC 2845 did not require all packets in a message stream= to contain a TSIG, it just stated that there be no more than 99 intermedia= ry messages without a TSIG (presumably to cut down on the overhead required= in message calculations - remember that RFC 2845 was published 20 years ag= o). Although many DNS implementations now add a TSIG to every message, it = is by no means certain that all do. (In fact, less than three years ago, a = bug was introduced into BIND, causing it to require that all packets in a z= one transfer would contain a TSIG. A fix allowing BIND to accept up to 99 = packets between signed ones was released shortly afterwards after reports w= ere received of zone transfers failing.) >>>>> >>>>> >>>>> > Section 5.3.2 >>>>> > >>>>> > Request MAC (if the request MAC validated) >>>>> > DNS Message (response) >>>>> > TSIG Variables (response) >>>>> > >>>>> > The reason that the request is not included in this MAC in some c= ases >>>>> > is to make it possible for the client to verify the error. If th= e >>>>> > error is not a TSIG error the response MUST be generated as speci= fied >>>>> > in Section 5.3. >>>>> > >>>>> > This makes it sound like the server excludes the request MAC from t= he >>>>> > digest if it failed to validate (something the client cannot predic= t), >>>>> > so that the client must perform trial verification of both versions= in >>>>> > order to validate the response. Is that correct? >>>>> >>>>> No. If the incoming MAC failed to validate, the server should send b= ack an unsigned response (MAC size =3D=3D 0 and empty MAC). >>>>> >>>>> >>>>> > Also, I think that the "in some cases" is not properly placed: as-i= s, it >>>>> > says that the request (not request MAC) is sometimes not included >>>>> > (implying that sometimes it is), which does not match up with the >>>>> > specification for the digest components. I presume that the intent= is >>>>> > to say that in some cases the client could not verify the error, if= the >>>>> > request itself was always included in the digest. >>>>> >>>>> Changed =E2=80=9Crequest=E2=80=9D to =E2=80=9Crequest MAC=E2=80=9D. >>>>> >>>>> If the MAC could not be verified, it is possible that it was corrupte= d, which would prevent the client verifying the response. But a major reaso= n is that an incorrect MAC included in a signed response led to the CVEs th= at prompted this document update. >>>>> >>>>> >>>>> > Section 5.4.1 >>>>> > >>>>> > If an RCODE on a response is 9 (NOTAUTH), but the response TSIG >>>>> > validates and the TSIG key recognised by the client but different >>>>> > from that used on the request, then this is a Key Error. The cli= ent >>>>> > >>>>> > nits: missing words "key is recognized" and "but is different=E2=80= =9D >>>>> >>>>> It now reads =E2=80=9Ckey is recognized but different" >>>>> >>>>> >>>>> > Section 5.5 >>>>> > >>>>> > destination or the next forwarder. If no transaction security is >>>>> > available to the destination and the message is a query then, if = the >>>>> > corresponding response has the AD flag (see [RFC4035]) set, the >>>>> > forwarder MUST clear the AD flag before adding the TSIG to the >>>>> > response and returning the result to the system from which it >>>>> > received the query. >>>>> > >>>>> > Is there anything to say about the CD bit? (It's independent crypt= o, so >>>>> > I don't expect so, but it seems worth checking.) >>>>> >>>>> No. CD is just a mechanism by which a client can request that the se= rver not do DNSSEC signature validation on the data and so allow the client= to receive the data instead of a SERVFAIL response. >>>>> >>>>> >>>>> > Section 6 >>>>> > >>>>> > The only message digest algorithm specified in the first version = of >>>>> > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], >>>>> > [RFC2104]). Although a review of its security [RFC6151] conclude= d >>>>> > that "it may not be urgent to remove HMAC-MD5 from the existing >>>>> > protocols", with the availability of more secure alternatives the >>>>> > opportunity has been taken to make the implementation of this >>>>> > algorithm optional. >>>>> > >>>>> > It seems worth noting that the advice from RFC 6151 is already nine >>>>> > years old. >>>>> >>>>> I=E2=80=99ve use the phrasing "Although a review of its security some= years ago=E2=80=9D. >>>>> >>>>> >>>>> > [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], >>>>> > [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 >>>>> > security considerations apply to SHA-1 in a similar manner... Al= though >>>>> > >>>>> > I'd consider referencing (e.g.) >>>>> > shattered.io >>>>> > for the "collisions have >>>>> > been demonstrated" claim, though it's pretty optional. >>>>> >>>>> A reference has been made to the =E2=80=9CSHA1 is a Shambles=E2=80=9D= paper... >>>>> >>>>> >>>>> > support for hmac-sha1 in TSIG is still mandatory for compatibilit= y >>>>> > reasons, existing uses should be replaced with hmac-sha256 or oth= er >>>>> > SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. >>>>> > >>>>> > Is this "sha1 mandatory for compatibility" going to age well? If w= e >>>>> > have two implementations that can operate with sha2 variants, is it >>>>> > required to keep this as mandatory (vs. optional with a note about >>>>> > deployed reality at time of publication) for progression to Interne= t >>>>> > Standard? >>>>> >>>>> This has been addressed by splitting the =E2=80=9CMandatory/Optional= =E2=80=9D column in RFC4635 (from which Table 2 was derived) into =E2=80=9C= Implementation=E2=80=9D and =E2=80=9CUse=E2=80=9D. SHA1 is required to be = implemented (for backwards compatibility) but its use is not recommended. >>>>> >>>>> >>>>> > Optional hmac-sha224 >>>>> > >>>>> > It's not clear there's much reason to keep this around, or if we do= , it >>>>> > could probably be "not recommended". (I assume that just dropping = it >>>>> > entirely makes things annoying w.r.t. the IANA registry.) >>>>> >>>>> It has been left in for compatibility reasons, but its use is not rec= ommended. >>>>> >>>>> >>>>> > Section 9 >>>>> > >>>>> > Previous specifications [RFC2845] and [RFC4635] defined values fo= r >>>>> > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an >>>>> > >>>>> > I'd suggest "HMAC-MD5 and HMAC-SHA-1", as the implied grouping wher= e >>>>> > HMAC qualifies both hash algorithms is not terribly clear. >>>>> >>>>> Changed to >>>>> >>>>> Previous specifications [RFC2845] and [RFC4635] defined names= for >>>>> the HMAC-MD5 and the various HMAC-SHA algorithms. >>>>> >>>>> >>>>> > Section 10 >>>>> > >>>>> > I suggest some discussion that the way truncation policy works, an >>>>> > attackers ability to forge messages accepted as valid is limited by= the >>>>> > amount of truncation that the recipient is willing to accept, not t= he >>>>> > amount of truncation used to generate messages by the legitimate se= nder. >>>>> >>>>> I think this is already taken care of by the reference to a local pol= icy in the =E2=80=9CTruncation Check and Error Handling=E2=80=9D section (5= .2.4). >>>>> >>>>> >>>>> > There's also some fairly standard content to put in here about allo= wing >>>>> > for an unsigned error response to a signed request, so an attacker = (even >>>>> > off-path) can spoof such resposnes. (Section 5.4 indicates that th= e >>>>> > client should continue to wait if it gets such a thing, which helps= a >>>>> > lot.) >>>>> >>>>> I=E2=80=99ve just added text that an unsigned response is not conside= red acceptable because can be subject to spoofing and manipulation. >>>>> >>>>> >>>>> > TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two >>>>> > entities. >>>>> > >>>>> > I suggest adding "; any such additional sharing would allow any par= ty >>>>> > knowing the key to impersonate any other such party to members of t= he >>>>> > group=E2=80=9D. >>>>> >>>>> Added. >>>>> >>>>> >>>>> > A fudge value that is too large may leave the server open to repl= ay >>>>> > attacks. A fudge value that is too small may cause failures if >>>>> > machines are not time synchronized or there are unexpected networ= k >>>>> > delays. The RECOMMENDED value in most situations is 300 seconds. >>>>> > >>>>> > Our experience with kerberos in modern network environments has sho= wn >>>>> > that 5 minutes is much larger than needed, though it's not clear th= ere's >>>>> > a strong need to change this recommendation right now. >>>>> >>>>> The value is recommended (and even then, only in =E2=80=9Cmost situat= ions=E2=80=9D), so implementations are free to set their own value. Howeve= r, any guidance as to typical time skews measured across a network would be= useful in a number of protocols. >>>>> >>>>> >>>>> > Significant progress has been made recently in cryptanalysis of h= ash >>>>> > functions of the types used here. While the results so far shoul= d >>>>> > not affect HMAC, the stronger SHA-1 and SHA-256 algorithms are be= ing >>>>> > made mandatory as a precaution. >>>>> > >>>>> > Please revise this note to not imply that SHA-1 is considered "stro= ng=E2=80=9D. >>>>> >>>>> Text revised to >>>>> >>>>> Significant progress has been made recently in cryptanalysis = of hash >>>>> functions of the types used here. While the results so far s= hould not >>>>> affect HMAC, the stronger SHA-256 algorithm is being made man= datory >>>>> as a precaution. >>>>> >>>>> >>>>> > Section 11.2 >>>>> > >>>>> > I'm not sure why RFC 2104 is listed as informative. >>>>> >>>>> RFC2104 is an Informational RFC and =E2=80=9CIdnits=E2=80=9D warns of= a possible downref if the reference is placed in the =E2=80=9CNormative=E2= =80=9D section. >>>>> >>>>> >>>>> >>>>> Comments from Mirja K=C3=BChlewind >>>>> >>>>> > I only had limited time for a quick review of this document, so I m= ight not be aware of all the needed background and details. Still I have tw= o quick questions on retries: >>>>> > >>>>> > 1) Sec 5.2.3: >>>>> > "Implementations should be aware >>>>> > of this possibility and be prepared to deal with it, e.g. by >>>>> > retransmitting the rejected request with a new TSIG once outstand= ing >>>>> > requests have completed or the time given by their time signed pl= us >>>>> > fudge value has passed." >>>>> > I might not be aware of all protocol details and maybe this is alre= ady specified somewhere: While unlikely, it is possible that a request migh= t be retransmitted multiple times, as that could cause president congestion= over time, it's always good practice to define a maximum number of retrans= missions. If that is already defined somewhere, maybe adding a note/pointer= would be good as well. >>>>> >>>>> If someone can suggest a suitable number (and a reason for it), we ca= n consider doing this. In the meantime, I=E2=80=99ve merely stated that im= plementation should limit the number of retransmissions and so leave the ch= oice up to the implementation. >>>>> >>>>> >>>>> > 2) Sec 5.3.1: >>>>> > " This allows the client to rapidly detect when the session has b= een >>>>> > altered; at which point it can close the connection and retry." >>>>> > When (immediately or after some waiting time) should the client ret= ry and how often? >>>>> >>>>> I think that should be down to the implementation to decide. >>>>> >>>>> >>>>> > You further say >>>>> > "The client SHOULD treat this the >>>>> > same way as they would any other interrupted transfer (although t= he >>>>> > exact behavior is not specified here)." >>>>> > Where is that specified? Can you provide a pointer in the text? >>>>> >>>>> That was a mistake in transcribing the original RFC2845 text. The fi= nal word =E2=80=9Chere=E2=80=9D has been removed paragraph now reads: >>>>> >>>>> The client SHOULD treat this the same way as they would any o= ther >>>>> interrupted transfer (although the exact behavior is not spec= ified). >>>>> >>>>> >>>>> > 3) Sec 8. Shared Secrets: Would it be appropriate to use more norm= ative language here? There are a bunch of lower case shoulds in this sectio= n; is that on purpose? >>>>> >>>>> The context in which the lower-case =E2=80=9Cshould=E2=80=9Ds appear = is very general security advice. Although this is something users ought to= do, it is not really a specific recommendation. >>>>> >>>>> >>>>> >>>>> Comments from Barry Leiba >>>>> >>>>> > =E2=80=94 Section 4.2 =E2=80=94 >>>>> > >>>>> > * Other Len - an unsigned 16-bit integer specifying the le= ngth >>>>> > of the "Other Data" field in octets. >>>>> > * Other Data - this unsigned 48-bit integer field will be >>>>> > >>>>> > Does this mean that =E2=80=9Cother data=E2=80=9D is always 48 bits?= If so, does that mean tgat the value of =E2=80=9Cother len=E2=80=9D is al= ways 6? If so, then shouldn=E2=80=99t it say that? If not, then what don= =E2=80=99t I understand? >>>>> >>>>> Benjamin Kaduk also made the same comment, it has been addressed abov= e. >>>>> >>>>> >>>>> > =E2=80=94 Section 5.1 =E2=80=94 >>>>> > >>>>> > Clients SHOULD only attempt signed >>>>> > transactions with servers who are known to support TSIG and share >>>>> > some algorithm and secret key with the client -- so, this is not = a >>>>> > problem in practice. >>>>> > >>>>> > Why SHOULD and not MUST? >>>>> >>>>> Benjamin Kaduk also noted an issue here. The paragraph has been remo= ved. >>>>> >>>>> >>>>> > =E2=80=94 Section 5.3.2 =E2=80=94 >>>>> > >>>>> > The server SHOULD also cache the most recent time signed >>>>> > value in a message generated by a key >>>>> > >>>>> > I tripped over this until I realized you mean =E2=80=9CTime Signed = value=E2=80=9D. You capitalize it elsewhere, and it helps the parsing if i= t=E2=80=99s consistent. There are four uncapitalized instances in this sect= ion. >>>>> >>>>> =E2=80=9Ctime signed=E2=80=9D has been capitalised. In addition, in = the description of the field, =E2=80=9Ctims signed=E2=80=9D has been replac= ed with =E2=80=9Ctime the message was signed=E2=80=9D. >>>>> >>>>> Elsewhere, a =E2=80=9Cfudge field=E2=80=9D has been replaced by =E2= =80=9CFudge field=E2=80=9D (although occurrences of =E2=80=9Cfudge value=E2= =80=9D have not been capitalised, as the context of that is that it is refe= rring to the contents of the Fudge field). Also, =E2=80=9Cother data=E2=80= =9D and =E2=80=9Cother data length=E2=80=9D have been replaced with the (ca= pitalised) field names, =E2=80=9COther Data=E2=80=9D and =E2=80=9COther Len= =E2=80=9D. >>>>> >>>>> >>>>> > =E2=80=94 Section 9 =E2=80=94 >>>>> > >>>>> > There is no structure >>>>> > required other than names for different algorithms must be unique >>>>> > when compared as DNS names, i.e., comparison is case insensitive. >>>>> > >>>>> > I found this sentence to be really awkward and hard to parse. May = I suggest this?: >>>>> > >>>>> > NEW >>>>> > There is no structure to the names, and algorithm names are compare= d as if they were DNS names (the comparison is case-insensitive). >>>>> > END >>>>> > >>>>> > I don=E2=80=99t think you really need to say that each name is diff= erent/unique, right? >>>>> >>>>> Agreed. The text has been changed to that suggested. >>>>> >>>>> >>>>> > other algorithm >>>>> > names are simple (i.e., single-component) names. >>>>> > >>>>> > Nitty thing that you can completely ignore, but I would avoid the L= atin abbreviation thus: =E2=80=9Cother algorithm names are simple, single-c= omponent names.=E2=80=9D >>>>> >>>>> Changed. >>>>> >>>>> >>>>> >>>>> Comments from =C3=89ric Vyncke >>>>> >>>>> > Thank you for the work put into this document. It is clear and easy= to read. >>>>> > >>>>> > Please find below some non-blocking COMMENTs and NITs. An answer wi= ll be appreciated. >>>>> > >>>>> > I hope that this helps to improve the document, >>>>> > >>>>> > Regards, >>>>> > >>>>> > -=C3=A9ric >>>>> > >>>>> > =3D=3D COMMENTS =3D=3D >>>>> > >>>>> > There are 6 authors while the usual procedure is to limit to 5 auth= ors... Personally, I do not care. >>>>> > >>>>> > -- Section 1.3 -- >>>>> > It is a little unclear to me whether the "two nameservers" were two= implementations or two actual DNS servers. >>>>> >>>>> Agreed, it was unclear. Changed to =E2=80=9Ctwo name server implemen= tations=E2=80=9D. >>>>> >>>>> >>>>> > -- Section 5.2 -- >>>>> > Suggest to provide some justifications about "copied to a safe loca= tion": the DNS message was sent in the clear, why does the TSIG part be cop= ied in a safe location? Please define what is meant by "safe location" (Mai= nly for my own curiosity) >>>>> >>>>> It is a bit over-specified and has been changed. The text now reads: >>>>> >>>>> Upon receipt of >>>>> a message with exactly one correctly placed TSIG RR, a copy of= the >>>>> TSIG RR is stored, and the TSIG RR is removed from the DNS Mes= sage, >>>>> and decremented out of the DNS message header's ARCOUNT. >>>>> >>>>> >>>>> > "cannot be understood" is also quite vague. >>>>> >>>>> Changed to =E2=80=9Ccannot be interpreted=E2=80=9D. >>>>> >>>>> >>>>> > -- Section 5.3 -- >>>>> > About rejecting request with a time signed value being earlier than= the last received value. I wonder what is the value of this behavior if th= ere is no 'fudge' as well... The last paragraph of this section describes t= his case and push the error handling to the request initiator. Any reason w= hy being flexible on the receiving site was not selected ? >>>>> >>>>> The fudge value is to cope with clock skew between the sender and rec= eiver. This won't impact on the order in which the packets are received by= the receiver, for which the =E2=80=9Ctime signed=E2=80=9D is a first-level= check. (It is not fool-proof - a number of packets signed by the sender wi= thin a second of one another may have the same =E2=80=9CTime Signed=E2=80= =9D field.) >>>>> >>>>> Pushing the error handling to the initiation goes back to the origina= l RFC 2845. >>>>> >>>>> >>>>> > =3D=3D NITS =3D=3D >>>>> > >>>>> > -- Section 4.3.2 -- >>>>> > Is " A whole and complete DNS message in wire format." a complete a= nd valid sentence? >>>>> >>>>> This was also pointed out by Roman Danyliw and has been addressed. >>>>> >>>>> >>>>> Other changes made during editing >>>>> >>>>> * There was no description of the contents of the =E2=80=9CError=E2= =80=9D and =E2=80=9COther Data=E2=80=9D fields were in a request. This has= now been corrected (Error is set to 0. The contents of =E2=80=9COther Data= =E2=80=9D are stated to be undefined to allow for extensions such as draft-= andrews-dnsop-defeat-frag-attack.) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DNSOP mailing list >>>>> DNSOP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 29 11:02:50 2020 Return-Path: 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 1395C3A0EED for ; Fri, 29 May 2020 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 l3ebvnmR5UbX for ; Fri, 29 May 2020 11:02:40 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 889153A0EB9 for ; Fri, 29 May 2020 11:02:39 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t18so4780452wru.6 for ; Fri, 29 May 2020 11:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cqGaCz5+72naTHNiyi+Kucr6z+NQ2eDgVohUkHO4wHc=; b=Yvm/45WnewZwLN8pBjBQ/NJ1/Xtw60bPzNBTg6lkZ+hFMHGId6YZVurdkrNMji6iTG Yf6WZba9CaXPZfafJBm1//FXsMO/gEW0Q774nq+XZj+/9xcr6W9XHJ78Iqlq82FswkRJ 9LMSv5b0jF6a+98Fi4BQGb+jNniRXn2bw94wyunyWsQOqhdEMvunLDb8vhQv/ipd1Ukf FKckFBpGHGQnCV/oGNcHrpJrOIA1uqPdHPmWcY7GOPuS2OCF86+a4rB9TikGKIqVrGM9 kk00k+4V8hb7BrPYoGvS94QmiLIZDQWlfHZFPFRq36qnu9chZ3FFZaOUFnvks39NHNhh N+sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cqGaCz5+72naTHNiyi+Kucr6z+NQ2eDgVohUkHO4wHc=; b=Sqb4emNHTl/6L99XGGy1vbXNS47tWOtHIsnUr8IzEa6zU8VY6DkThazGgo2sw6hp/J spaogjqZO6u3djkZQPOR9a7a3dcVsrEvGHcTq7S2KcsHCHPKtMJlMTWPYv4MbYem6cD2 4ygeLh7BzJ5buNQZ95PbWqtbVXKZUtSXubvGFDGKOfHdQborWS1VZ4274HHswJdg3o/D UPZIh2ZXWI+T6XwwVN6YoeUZCVVodddbCEUuvXezBFosKxGN6HpKy2Mh6BYVKw81zS6G EWcOXXMdyLlfAK67SmRg1MYSycCJqYMGthFyHDMFXh2NAgiEfg3c2lL+dfR00JbymVqS M2mg== X-Gm-Message-State: AOAM532XbxgiTopKo6kyUTPuBOfYuOkbwBGecFUUZVaCJga9w1beegnd MH+hVhUcuJFf+JorZAKPy0S0E6z1mHO1uLEFE7NaPg== X-Google-Smtp-Source: ABdhPJzfn3MxuNoofJisC0KlWnGaz7d2mOxbW77ytaNriIHBdAlLN519CgwNOYw1AxGt3Zf/+QxTS9SNTQk3zfetm2Q= X-Received: by 2002:adf:fdcc:: with SMTP id i12mr10371794wrs.313.1590775357570; Fri, 29 May 2020 11:02:37 -0700 (PDT) MIME-Version: 1.0 References: <1852098.ajqZCkXiOD@linux-9daj> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk> <3e349f68-3f59-82af-d81c-bfb24f54e65e@nic.cz> <16ef2458-8175-3311-88f4-80028a00549e@nic.cz> In-Reply-To: <16ef2458-8175-3311-88f4-80028a00549e@nic.cz> From: Eric Orth Date: Fri, 29 May 2020 14:02:25 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop Content-Type: multipart/alternative; boundary="0000000000001b67b905a6cd403a" Archived-At: Subject: Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 18:02:50 -0000 --0000000000001b67b905a6cd403a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 29, 2020 at 3:06 AM Petr =C5=A0pa=C4=8Dek = wrote: > > > On 28. 05. 20 21:21, Eric Orth wrote: > > I lead engineering for the stub resolver built into Chrome browser, so > while not an OS-level stub, maybe still prominent enough to count for the > "any communication" requested above. > > > > My biggest concern with an approach like this is ossification from > middleboxes (especially some old home routers) that may not be ideally > engineered for the modern web. Chrome has seen significant issues in the > past with such middleboxes creating pain (super slow responses mostly) fo= r > a small number of our users on sending unusual queries or an increased > amount of queries. As such, we're generally afraid of sending out anythi= ng > other than basic and rate-limited requests when it comes to Classic DNS. > Attempting new things and falling back to conservative behavior on an iss= ue > is not necessarily a reasonable approach because the middlebox pain is no= t > always limited to the individual queries. In some cases, probing or > experimenting with resolver capabilities can cause user pain for all > subsequent queries for a period of time on the order of minutes. > > > > Since this specific multi-query proposal encodes it in EDNS, it might b= e > more reasonable. I don't have any actual data to back this up, but I wou= ld > guess that unknown EDNS options are less likely to cause issues than > completely unknown queries. So it might be safe enough to at least do > super cautious experimentation around it. > > I would say it depends on sheer luck: > EDNS handling is specified in RFC 2671 from 1999, unknown type handling i= s > in RFC 3597 from 2003. Both should work in 2020. If they don't because > resolver vendors does not care. > Right. I'm sure we'll still hit plenty of cases where the resolver doesn't support those RFCs, and thus we may get behavior such as stripping the unrecognized EDNS records or maybe even returning an error for the entire request. But my prediction is that unknown EDNS records will be much less likely, compared to unknown question qtype or too many queries, to cause the really bad behavior where the resolver crashes and behaves poorly for subsequent "normal" requests. > > > > > Note that none of these ossification issues are really a concern with > DoH (or DoT) where we can be reasonably sure we're talking to a modern > non-ossified resolver. > > Sorry but I think you have unrealistic hopes, probably caused by largely > nonexistent auto-disovery of DoH/DoT servers. > > AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ!box > router - mainstream in Germany and countries around) are adding support f= or > DoT and possibly also DoH. Personally I do not see any reason why their > resolver available over DoT/DoH should work any better than their > unencrypted DNS resolver, which is (at least not in case of AVM) not famo= us > for standards-compliance or performance. Of course vendors are going to > reuse whatever they had before, so additional TLS+HTTP layers will just a= dd > new bugs on top of whatever bugs they had before. > > In other words, whole anti-ossification argument seems to hold at the > moment only because of missing auto-discovery protocol for encrypted > transports. Once we have auto-discovery all the problems will bounce back= . > Sorry for my grim predictions! Yeah, maybe more accurate to say ossification is not an issue for Chrome's current approach. Chrome currently only does by-default upgrade for providers in a hardcoded mapping, and RFC3597 support is an explicit requirement for the mapping. For DoT/DoH in general, I would still argue that ossification is reduced (resolvers need at least one update since the invention of DoT/DoH and less involved parties when the secure connection kicks most interceptors out of the mix), but you are correct that it is not eliminated. > > > > The usefulness of combining queries is a little reduced since DoT and > DoH often use connection sharing for multiple requests anyway. But there= 's > still some potential value. In ECH (ESNI) discussions, it has come up a > few times that an attacker could try to force a downgrade from ECH by > identifying and blocking the larger packets containing HTTPSSVC responses > that contain ECH keys but not address resolves. Much safer if A/AAAA and > HTTPSSVC can be in the same query/response to force an attacker to block > everything or nothing. > > Hmm, shouldn't it be detected at TLS layer? It seems to me that only > explotable problem would be if client interpreted connection timeout or T= LS > errors as missing ESNI RR, which does not sound like a good idea to me. > Detection might be nothing more than timeout of the HTTPSSVC response. Specifically because of this attack, the HTTPSSVC draft requires that when using DoT/DoH, if the HTTPSSVC record results in timeout, transport error, or SERVFAIL, that the client not fallback to normal behavior using A/AAAA. Without the attack and RFC guidance, I imagine most clients would respond to any issues with the HTTPSSVC by reverting to their pre-HTTPSSVC-support behavior and just using A/AAAA normally because it's not ideal to create situations where otherwise-working requests could be broken only for the clients that support the new feature, especially when, at least to begin with, the vast majority of domains will legitimately not have HTTPSSVC records. > > > > Additional possible issues with this multi-query proposal: > > *By combining A and AAAA, you might lose nice abilities to try to speed > things up using Happy Eyeballs v2 style algorithms to immediately start > using addresses as they come in, before all addresses are received. Not > currently a huge issue for Chrome DNS because we don't currently support > Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that > improvement. > > Interesting... Do you have measurements which suggest that A/AAAA answers > have different timing properties? I would expect it mostly depends on > whatever is in cache, and if multi-query takes off we can expect both to = be > present in cache with the same TTL. > I don't have any data on-hand, but the relevant RFC8305 does mention networks handling some address families sub-optimally as a motivation for the algorithm. > > > > *The current proposal seems to give the resolver a lot of leeway to onl= y > sometimes include the additional results and includes a TODO note that > maybe there should be a way for clients to mark qtypes as mandatory. I > don't think the client would get as much use out of multiple qtypes unles= s > it had reasonable confidence that it would at least usually get all the > responses. Otherwise, the client is often going to have to make multiple > requests in parallel anyway to ensure it can get all the responses > reasonably quickly in parallel. Then again, if it's something like > requesting an extra qtype that we would be afraid to send in Classic DNS > anyway (due to the ossification issues), eg HTTPSVC, I suppose there's mo= re > value of just adding in the additional qtype and using the response > opportunistically when received. > > I agree - making it mandatory seems like reasonable approch (within > certain limits, e.g. answer size etc.). > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > > > > On Thu, May 28, 2020 at 12:22 PM Vladim=C3=ADr =C4=8Cun=C3=A1t < > vladimir.cunat+ietf@nic.cz > wrote: > > > > Hello. > > > > On 5/28/20 10:00 AM, Shane Kerr wrote: > > > As I have mentioned several times on microphone, I think this dra= ft > > > has huge potential, potentially cutting the number of queries > handled > > > by recursive resolvers almost in half - since they could ask for = A > and > > > AAAA records in a single query. > > > > I'm not sure if it would be a net benefit if we consider the added > > complexity (like the few unpleasant corner cases), the need to > implement > > on both sides, and other ways that are available. Is saving the > number > > of IP-layer packets the only significant motivation? > > > > For resolver-to-auth case I do suspect some potential. Plain UDP > will > > probably still stay popular there for some time. Though I'm afraid > this > > might _sometimes_ push the answer sizes too large to fit into one > packet > > (in signed zones), which in my eyes slightly reduces attractiveness > of > > the technique, now that we know that UDP over 1.5 kB is no good. > > > > For non-auth cases, you typically communicate with just one upstrea= m > > resolver (or very few), so if the number of packets is a concern, > I'd go > > for a long-lived TCP or TLS connection (there's e.g. privacy > motivation, > > too). That's all standardized already, and it naturally avoids tho= se > > extra corner cases. Sure, it's probably possible to improve > > significantly on session timers and resuming, performance, usage of > > Nagle's algorithm, etc. but ATM to me that feels a more worthwhile > > investment than any of the multi-answer proposals. One advantage i= s > > that many of the TCP/TLS improvements can be deployed one-sidedly > with > > some effect but multi-QTYPEs can't. > > > > --Vladimir > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --0000000000001b67b905a6cd403a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 29, 2020 at 3:06 AM Petr = =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:


On 28. 05. 20 21:21, Eric Orth wrote:
> I lead engineering for the stub resolver built into Chrome browser, so= while not an OS-level stub, maybe still prominent enough to count for the = "any communication" requested above.
>
> My biggest concern with an approach like this is ossification from mid= dleboxes (especially some old home routers) that may not be ideally enginee= red for the modern web.=C2=A0 Chrome has seen significant issues in the pas= t with such middleboxes creating pain (super slow responses mostly) for a s= mall number of=C2=A0our users on sending unusual queries or an increased am= ount of queries.=C2=A0 As such, we're generally afraid of sending out a= nything other than basic and rate-limited requests when it comes to Classic= DNS.=C2=A0 Attempting new things and falling back to conservative behavior= on an issue is not necessarily a reasonable approach because the middlebox= pain is not always limited to the individual queries.=C2=A0 In some cases,= probing or experimenting with resolver capabilities can cause user pain fo= r all subsequent queries for a period of time on the order of minutes.
>
> Since this specific multi-query proposal encodes it in EDNS, it might = be more reasonable.=C2=A0 I don't have any actual data to back this up,= but I would guess that unknown EDNS options are less likely to cause issue= s than completely unknown queries.=C2=A0 So it might be safe enough to at l= east do super cautious experimentation around it.

I would say it depends on sheer luck:
EDNS handling is specified in RFC 2671 from 1999, unknown type handling is = in RFC 3597 from 2003. Both should work in 2020. If they don't because = resolver vendors does not care.

Right.= =C2=A0 I'm sure we'll still hit plenty of cases where the resolver = doesn't support those RFCs, and thus we may get behavior such as stripp= ing the unrecognized EDNS records or maybe even returning an error for the = entire request.=C2=A0 But my prediction is that unknown EDNS records will b= e much less likely, compared to unknown question=C2=A0qtype or too many que= ries, to cause the really bad behavior where the resolver crashes and behav= es poorly for subsequent "normal" requests.
=C2=A0

>
> Note that none of these ossification issues are really a concern with = DoH (or DoT) where we can be reasonably sure we're talking to a modern = non-ossified resolver.

Sorry but I think you have unrealistic hopes, probably caused by largely no= nexistent auto-disovery of DoH/DoT servers.

AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ= !box router - mainstream in Germany and countries around) are adding suppor= t for DoT and possibly also DoH. Personally I do not see any reason why the= ir resolver available over DoT/DoH should work any better than their unencr= ypted DNS resolver, which is (at least not in case of AVM) not famous for s= tandards-compliance or performance. Of course vendors are going to reuse wh= atever they had before, so additional TLS+HTTP layers will just add new bug= s on top of whatever bugs they had before.

In other words, whole anti-ossification argument seems to hold at the momen= t only because of missing auto-discovery protocol for encrypted transports.= Once we have auto-discovery all the problems will bounce back. Sorry for m= y grim predictions!=C2=A0

Yeah, maybe more = accurate to say ossification is not an issue for Chrome's current appro= ach.=C2=A0 Chrome currently only does by-default upgrade for providers in a= hardcoded mapping, and RFC3597 support is an explicit requirement for the = mapping.=C2=A0 For DoT/DoH in general, I would still argue that ossificatio= n is reduced (resolvers need at least one update since the invention of DoT= /DoH and less involved parties when the secure connection kicks most interc= eptors out of the mix), but you are correct that it is not eliminated.
=C2=A0


> The usefulness of combining queries is a little reduced since DoT and = DoH often use connection sharing for multiple requests anyway.=C2=A0 But th= ere's still some potential value.=C2=A0 In ECH (ESNI) discussions, it h= as come up a few times that an attacker could try to force a downgrade from= ECH by identifying and blocking the larger packets containing HTTPSSVC res= ponses that contain ECH keys but not address resolves.=C2=A0 Much safer if = A/AAAA and HTTPSSVC can be in the same query/response to force an attacker = to block everything or nothing.

Hmm, shouldn't it be detected at TLS layer? It seems to me that only ex= plotable problem would be if client interpreted connection timeout or TLS e= rrors as missing ESNI RR, which does not sound like a good idea to me.
<= /blockquote>

Detection might be nothing more than timeou= t of the HTTPSSVC response.=C2=A0 Specifically because of this attack, the = HTTPSSVC draft requires that when using DoT/DoH, if the HTTPSSVC record res= ults in timeout, transport error, or SERVFAIL, that the client not fallback= to normal behavior using A/AAAA.=C2=A0 Without the attack and RFC guidance= , I imagine most clients would respond to any issues with the HTTPSSVC by r= everting to their pre-HTTPSSVC-support behavior and just using A/AAAA norma= lly because it's not ideal to create situations where otherwise-working= requests could be broken only for the clients that support the new feature= , especially when, at least to begin with, the vast majority of domains wil= l legitimately not have HTTPSSVC records.
=C2=A0


> Additional possible issues with this multi-query proposal:
> *By combining A and AAAA, you might lose nice abilities to try to spee= d things up using Happy Eyeballs v2 style algorithms to immediately start u= sing addresses as they come in, before all addresses are received.=C2=A0 No= t currently a huge issue for Chrome DNS because we don't currently supp= ort Happy Eyeballs v2, but we'd be hesitant to lose the ability to make= that improvement.

Interesting... Do you have measurements which suggest that A/AAAA answers h= ave different timing properties? I would expect it mostly depends on whatev= er is in cache, and if multi-query takes off we can expect both to be prese= nt in cache with the same TTL.

I don= 9;t have any data on-hand, but the relevant RFC8305 does mention networks h= andling some address families sub-optimally as a motivation for the algorit= hm.
=C2=A0


> *The current proposal seems to give the resolver a lot of leeway to on= ly sometimes include the additional results and includes a TODO note that m= aybe there should be a way for clients to mark qtypes as mandatory.=C2=A0 I= don't think the client would get as much use out of multiple qtypes=C2= =A0unless it had reasonable confidence that it would at least usually get a= ll the responses.=C2=A0 Otherwise, the client is often going to have to mak= e multiple requests in parallel anyway to ensure it can get all the respons= es reasonably quickly in parallel.=C2=A0 Then again, if it's something = like requesting an extra qtype that we would be afraid to send in Classic D= NS anyway (due to the ossification issues), eg HTTPSVC, I suppose there'= ;s more value of just adding in the additional qtype and using the response= opportunistically=C2=A0when received.

I agree - making it mandatory seems like reasonable approch (within certain= limits, e.g. answer size etc.).

Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC


>
> On Thu, May 28, 2020 at 12:22 PM Vladim=C3=ADr =C4=8Cun=C3=A1t <vladimir.cun= at+ietf@nic.cz <mailto:vladimir.cunat%2Bietf@nic.cz>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hello.
>
>=C2=A0 =C2=A0 =C2=A0On 5/28/20 10:00 AM, Shane Kerr wrote:
>=C2=A0 =C2=A0 =C2=A0> As I have mentioned several times on microphon= e, I think this draft
>=C2=A0 =C2=A0 =C2=A0> has huge potential, potentially cutting the nu= mber of queries handled
>=C2=A0 =C2=A0 =C2=A0> by recursive resolvers almost in half - since = they could ask for A and
>=C2=A0 =C2=A0 =C2=A0> AAAA records in a single query.
>
>=C2=A0 =C2=A0 =C2=A0I'm not sure if it would be a net benefit if we= consider the added
>=C2=A0 =C2=A0 =C2=A0complexity (like the few unpleasant corner cases), = the need to implement
>=C2=A0 =C2=A0 =C2=A0on both sides, and other ways that are available.= =C2=A0 Is saving the number
>=C2=A0 =C2=A0 =C2=A0of IP-layer packets the only significant motivation= ?
>
>=C2=A0 =C2=A0 =C2=A0For resolver-to-auth case I do suspect some potenti= al.=C2=A0 Plain UDP will
>=C2=A0 =C2=A0 =C2=A0probably still stay popular there for some time.=C2= =A0 Though I'm afraid this
>=C2=A0 =C2=A0 =C2=A0might _sometimes_ push the answer sizes too large t= o fit into one packet
>=C2=A0 =C2=A0 =C2=A0(in signed zones), which in my eyes slightly reduce= s attractiveness of
>=C2=A0 =C2=A0 =C2=A0the technique, now that we know that UDP over 1.5 k= B is no good.
>
>=C2=A0 =C2=A0 =C2=A0For non-auth cases, you typically communicate with = just one upstream
>=C2=A0 =C2=A0 =C2=A0resolver (or very few), so if the number of packets= is a concern, I'd go
>=C2=A0 =C2=A0 =C2=A0for a long-lived TCP or TLS connection (there's= e.g. privacy motivation,
>=C2=A0 =C2=A0 =C2=A0too).=C2=A0 That's all standardized already, an= d it naturally avoids those
>=C2=A0 =C2=A0 =C2=A0extra corner cases.=C2=A0 Sure, it's probably p= ossible to improve
>=C2=A0 =C2=A0 =C2=A0significantly on session timers and resuming, perfo= rmance, usage of
>=C2=A0 =C2=A0 =C2=A0Nagle's algorithm, etc. but ATM to me that feel= s a more worthwhile
>=C2=A0 =C2=A0 =C2=A0investment than any of the multi-answer proposals.= =C2=A0 One advantage is
>=C2=A0 =C2=A0 =C2=A0that many of the TCP/TLS improvements can be deploy= ed one-sidedly with
>=C2=A0 =C2=A0 =C2=A0some effect but multi-QTYPEs can't.
>
>=C2=A0 =C2=A0 =C2=A0--Vladimir

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--0000000000001b67b905a6cd403a-- From nobody Sat May 30 10:13:25 2020 Return-Path: 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 AC8043A0893 for ; Sat, 30 May 2020 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 qnnmM_ZxpddB for ; Sat, 30 May 2020 10:13:22 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 03B5B3A0891 for ; Sat, 30 May 2020 10:13:22 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id h10so2675885iob.10 for ; Sat, 30 May 2020 10:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKF5tsQOUhYaJh5rELD6s5G++b94qicwlvXaJezyCnI=; b=hBL3HddpGELfXWC12lE4KLyjUwW0LP4rGs8W+yhztxQ1FY+iyNoHGCMT6DFs+Y5Q2b e4yqpUyAWkv4LczDK+doCkuL2/8FTrVXpjQ/Okodi4ARKJwiYluRfK6X8+GNlwgH3CTq Um0EWknGetbFMEQGOhIbfMqno4uHH9VgaV8WGITTbZIejyySFYwxN0tqOsBLQTQ0heEc Umr5J6RONEFuiAHbp9/+bugybWAkvjyvHG8reKJsMKJ7wtvu4EE+EPZJAYYPXDs6TqrX PcmpiafUvKsrpqPpjls2Nj28M/2l7wacMdZ27f3Qgg7M2RVAH8v4wXHl5rFrxV943JvL Ibzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKF5tsQOUhYaJh5rELD6s5G++b94qicwlvXaJezyCnI=; b=qGM0ceFO9NXKFe6mvBFMdpS+ysUnbuk7a/3G9rok//mYOri03PB2Pk6jLIJdZ8FlGL 1/UrsHMU9WtFCPoRwlDHgfJhgKtOEvd46WaVr0wGK3hS49R+HH0MCu9rV7jGXilPNI5C YVIMQL0F1q2QW9552CttNYKS2CIt/l0064XqsPbau9qUFgttEOkMOQnNh9RI3Jj24q0C 1mNMAFSxLZKDFVvlarb+YJY4g5xcafRPB6ZaSqWOguWIr1ZUfVzpmWvTqPOzStoquhiP wG9zeqqXvdQvVCZISmJaXJlTBySdydRb0t3vnLoIwYjdNszn7HEEdEUGnclYABCZU6PK wVbA== X-Gm-Message-State: AOAM530bwmIEPO0DP3wqqgGViODanZlfpFpSv5gyyARck4EDdoUS9Dtm Y25wlK/dnY7/8Bk1BB6yREMBHc+j1Rs6Q3p7UnM= X-Google-Smtp-Source: ABdhPJzyCcQgOvqxt2kxKXHVnW2T649h3EWXls566tqXRyqC5TSyNJwFGYszD9CAjfFhDDEilYo5y8Ms0jgSEk5wO3E= X-Received: by 2002:a02:2c6:: with SMTP id 189mr13478342jau.115.1590858801277; Sat, 30 May 2020 10:13:21 -0700 (PDT) MIME-Version: 1.0 References: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz> <33141878.RIuage5OGR@linux-9daj> In-Reply-To: <33141878.RIuage5OGR@linux-9daj> From: Gavin McCullagh Date: Sat, 30 May 2020 10:13:10 -0700 Message-ID: To: Paul Vixie Cc: Shumon Huque , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000bcf0e205a6e0ad1a" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 17:13:25 -0000 --000000000000bcf0e205a6e0ad1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Thu, May 28, 2020 at 8:56 AM Paul Vixie wrote: > On Thursday, 28 May 2020 14:38:11 UTC Petr =C5=A0pa=C4=8Dek wrote: > > On 25. 05. 20 5:23, Shumon Huque wrote: > > > ... > > > Most importantly: > > > - Does the NS affect maximum TTL of _other_ data in the zone? > > > > > > I think there are probably different views on what should happen here= . > > > Folks who want very prompt takedown of "bad" domains, will probably > > > prefer a complete pruning of the cache at the delegation point at the > > > revalidation interval, if the NS set has changed or disappeared. ... > Those last few words seem very critical. "If the NS set has changed or disappeared". > > E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of al= l > > other records in the zone, then each resolver instance would clear zone > > from its cache each 30 seconds. That might cause interesting behavior > when > > NS TTL is shortened e.g. before NS set change etc. > > > > I do not know if there really is a problem, I'm just trying to explain > why > > potential for thundering herd needs to be be seriously analyzed. > I think Petr's point might be that someone could interpret the draft (perhaps especially the simple mechanism) to mean that the NS TTL becomes an effective cap on the TTL of all records below the zone cut even where the NS set has not changed. If lowering a delegating NS TTL to 300 for a very large zone (or one high up the tree) meant a lot of resolvers might expire every record below the zone cut every 300 seconds (even unsynchronized), then it seems like lowering that TTL could produce a thundering herd. I think the intent of the draft and Shumon's quote above are that a resolver should only expire cached subdomain records when the delegating NS changes. Would it be useful to be explicit about that? I imagine even the NS revalidation means that if an operator lowers a delegating NS TTL to e.g. 300 in advance of a change in order to "make that change visible to resolvers reasonably quickly", they might well see a 300 second long period of thunder immediately after the change while every resolver's cache expires that part of the tree and then fills it back up. One minor other question: To revalidate a delegation, the iterative caching DNS resolver will forward the query that triggered revalidation to the nameservers at the closest enclosing zone cut above the revalidation point. Does "the query that triggered revalidation" refer to the original client query which had RD=3D1? If so, does this fit with qname minimization? Gavin --000000000000bcf0e205a6e0ad1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, May 28, 2020 at 8:56 AM Paul Vixie &l= t;paul@redbarn.org> wrote:
On Thursday, 28 May 2= 020 14:38:11 UTC Petr =C5=A0pa=C4=8Dek wrote:
> On 25. 05. 20 5:23, Shumon Huque wrote:
> > ...
> >=C2=A0 =C2=A0 =C2=A0Most importantly:
> >=C2=A0 =C2=A0 =C2=A0- Does the NS affect maximum TTL of _other_ da= ta in the zone?
> >
> > I think there are probably different views on what should happen = here.
> > Folks who want very prompt takedown of "bad" domains, w= ill probably
> > prefer a complete pruning of the cache at the delegation point at= the
> > revalidation interval, if the NS set has changed or disappeared. = ...

Those last few words seem very crit= ical.=C2=A0 "If the NS set has changed or disappeared".=C2=A0
=C2=A0
&= gt; E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of al= l
> other records in the zone, then each resolver instance would clear zon= e
> from its cache each 30 seconds. That might cause interesting behavior = when
> NS TTL is shortened e.g. before NS set change etc.
>
> I do not know if there really is a problem, I'm just trying to exp= lain why
> potential for thundering herd needs to be be seriously analyzed.

I think Petr's point might be that someo= ne could interpret the draft (perhaps especially the simple mechanism) to m= ean that the NS TTL becomes an effective cap on the TTL of all records belo= w the zone cut even where the NS set has not changed.=C2=A0
=
If lowering a delegating NS TTL to 300 for a very large zone= (or one high up the tree) meant a lot of resolvers might expire every reco= rd below the zone cut every 300 seconds (even unsynchronized), then it seem= s like lowering that TTL could produce a thundering herd.=C2=A0=C2=A0 I thi= nk the intent of the draft and Shumon's quote above are that a resolver= should only expire cached subdomain records when the delegating NS changes= . =C2=A0 Would it be useful to be explicit about that?=C2=A0=C2=A0

I imagine even the NS revalidation means that if an opera= tor lowers a delegating NS TTL to e.g. 300 in advance of a change in order = to "make that change visible to resolvers reasonably quickly", th= ey might well see a 300 second long period of thunder immediately after the= change while every resolver's cache expires that part of the tree and = then fills it back up.=C2=A0=C2=A0

One minor = other question:
      To revalid=
ate a delegation, the iterative caching DNS resolver
      will forward the query that triggered revalidation to the
      nameservers at the closest enclosing zone cut above the
      revalidation point.
Does "the query that trigg= ered revalidation" refer to the original client query which had RD=3D1= ?=C2=A0 If so, does this fit with qname minimization?

Gavin

--000000000000bcf0e205a6e0ad1a-- From nobody Sat May 30 10:45:56 2020 Return-Path: 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 B45CA3A0903 for ; Sat, 30 May 2020 10:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 5VENQ-CQvenj for ; Sat, 30 May 2020 10:45:53 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 A5B803A08FF for ; Sat, 30 May 2020 10:45:52 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id mb16so5253865ejb.4 for ; Sat, 30 May 2020 10:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l4u+KVwf/r6xbe/PXSNgHpIJ697TTCBh0CQUzUdKx4Q=; b=qf8tSI/l/QIGYehOgMoiC8GjxTo/2EWM/GBaQ1PE2EivzlYWWhMzgiiT84oUT1XKtL +8uK7ufvkGmxCn4XIvVITdC1HnUt/xe20tEcd302qEANKzawcmZMXgMUmgxdDk653MFU c+490z15Y4VFG74npnEdGj7bRFplnM6qHQkVSTPlUtqSgOWJpVmwaXrYDfeIJtLrSIr6 U3x35UqrXaSHXkj8FmY4NcOCwepg5vKz9ZIejmjC2QZQEXrAfEMFwuSRmMXoMm/gQ2gW i7y12utx58+TZH8N3Ay9non2OWuM8M0gnR9/Foe/6HGc/cARpAwbzYpI4VqlosIkVx5X 99vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l4u+KVwf/r6xbe/PXSNgHpIJ697TTCBh0CQUzUdKx4Q=; b=kb7d6SWSsaTbvbK1jSGWGapA43/gkQMCAbK3d5QJx1t/No40iG0kZh845aHbUgQg+q LdskhsGRoLqsNXSj0I0jsGUswOK7/W9PNEnO07LoNqUH8XIarqDXRtmkk9wSMpxqIJzE JXAYj9oyFiKDK5PGmBKucanzNlp9sMI9kcnsFerN5/QkHklqgyQrAa1fZxNDsQaYr/HV V6BHCiLJiR4l/sAaLODooLJSXicvdKSA18Ak++TgYOeOdpnOrBnw4oYv0sd+fG0Oc2QL 6gH/Q80bXcyHaP6Rjcse0H6Q05sPVz6ohWnVLG2/qIJaVPK9mX3BaYXbNwaiAMDg9Bsw iWeA== X-Gm-Message-State: AOAM5333WqSfBp27+xzHeI4ZlZ5g0lvXXG4EQGEtO5DL0rB7tuoLlYQb cbts7/rR73j2MoCv/mz2FQPXVineJ2h4qZDsAoI= X-Google-Smtp-Source: ABdhPJwCbRfZsQ8TY4adF4ttXzencS+Gx74qFqXTEOUq3gFpTdVchZXsDU9dVD+amepq/xWQYSw9QJuZbs8tZ+JmUvg= X-Received: by 2002:a17:906:4554:: with SMTP id s20mr7085106ejq.241.1590860750036; Sat, 30 May 2020 10:45:50 -0700 (PDT) MIME-Version: 1.0 References: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz> <33141878.RIuage5OGR@linux-9daj> In-Reply-To: From: Shumon Huque Date: Sat, 30 May 2020 13:45:38 -0400 Message-ID: To: Gavin McCullagh Cc: Paul Vixie , "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000e4a3a305a6e121d3" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 17:45:56 -0000 --000000000000e4a3a305a6e121d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 30, 2020 at 1:13 PM Gavin McCullagh wrote: > Hi, > > On Thu, May 28, 2020 at 8:56 AM Paul Vixie wrote: > >> On Thursday, 28 May 2020 14:38:11 UTC Petr =C5=A0pa=C4=8Dek wrote: >> > On 25. 05. 20 5:23, Shumon Huque wrote: >> > > ... >> > > Most importantly: >> > > - Does the NS affect maximum TTL of _other_ data in the zone? >> > > >> > > I think there are probably different views on what should happen her= e. >> > > Folks who want very prompt takedown of "bad" domains, will probably >> > > prefer a complete pruning of the cache at the delegation point at th= e >> > > revalidation interval, if the NS set has changed or disappeared. ... >> > > Those last few words seem very critical. "If the NS set has changed or > disappeared". > > >> > E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of a= ll >> > other records in the zone, then each resolver instance would clear zon= e >> > from its cache each 30 seconds. That might cause interesting behavior >> when >> > NS TTL is shortened e.g. before NS set change etc. >> > >> > I do not know if there really is a problem, I'm just trying to explain >> why >> > potential for thundering herd needs to be be seriously analyzed. >> > > I think Petr's point might be that someone could interpret the draft > (perhaps especially the simple mechanism) to mean that the NS TTL becomes > an effective cap on the TTL of all records below the zone cut even where > the NS set has not changed. > > If lowering a delegating NS TTL to 300 for a very large zone (or one high > up the tree) meant a lot of resolvers might expire every record below the > zone cut every 300 seconds (even unsynchronized), then it seems like > lowering that TTL could produce a thundering herd. I think the intent o= f > the draft and Shumon's quote above are that a resolver should only expire > cached subdomain records when the delegating NS changes. Would it be > useful to be explicit about that? > Gavin - yes, I agree. I was indeed deliberate in my wording about "If the NS set has changed or disappeared" to avoid creating unnecessary work for resolvers. This topic is not yet discussed in the draft, but assuming the draft is adopted and we cover it, we can make it explicit. One minor other question: > > To revalidate a delegation, the iterative caching DNS resolver > will forward the query that triggered revalidation to the > nameservers at the closest enclosing zone cut above the > revalidation point. > > Does "the query that triggered revalidation" refer to the original client > query which had RD=3D1? If so, does this fit with qname minimization? > Yeah, good catch. We need to adjust that text slightly to be compatible with qname minimization, which should be pretty straightforward - it's just pruning the requisite number of left most labels for the enclosing zone. Shumon. --000000000000e4a3a305a6e121d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, May 30, 2020 at 1:13 PM Gavin McC= ullagh <gmccullagh@gmail.com= > wrote:
Hi,

On Thu, May 28, 2020 at= 8:56 AM Paul Vixie <paul@redbarn.org> wrote:
On Thursday, 28 May 2020 14:38:11 UTC Petr =C5=A0pa=C4= =8Dek wrote:
> On 25. 05. 20 5:23, Shumon Huque wrote:
> > ...
> >=C2=A0 =C2=A0 =C2=A0Most importantly:
> >=C2=A0 =C2=A0 =C2=A0- Does the NS affect maximum TTL of _other_ da= ta in the zone?
> >
> > I think there are probably different views on what should happen = here.
> > Folks who want very prompt takedown of "bad" domains, w= ill probably
> > prefer a complete pruning of the cache at the delegation point at= the
> > revalidation interval, if the NS set has changed or disappeared. = ...

Those last few words seem very crit= ical.=C2=A0 "If the NS set has changed or disappeared".=C2=A0
=C2=A0
&= gt; E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of al= l
> other records in the zone, then each resolver instance would clear zon= e
> from its cache each 30 seconds. That might cause interesting behavior = when
> NS TTL is shortened e.g. before NS set change etc.
>
> I do not know if there really is a problem, I'm just trying to exp= lain why
> potential for thundering herd needs to be be seriously analyzed.

I think Petr's point might be that someo= ne could interpret the draft (perhaps especially the simple mechanism) to m= ean that the NS TTL becomes an effective cap on the TTL of all records belo= w the zone cut even where the NS set has not changed.=C2=A0
=
If lowering a delegating NS TTL to 300 for a very large zone= (or one high up the tree) meant a lot of resolvers might expire every reco= rd below the zone cut every 300 seconds (even unsynchronized), then it seem= s like lowering that TTL could produce a thundering herd.=C2=A0=C2=A0 I thi= nk the intent of the draft and Shumon's quote above are that a resolver= should only expire cached subdomain records when the delegating NS changes= . =C2=A0 Would it be useful to be explicit about that?=C2=A0

Gavin - yes, I agree. I was indeed deli= berate in my wording about "If the NS set has changed or disappeared&q= uot; to avoid creating unnecessary work for resolvers. This topic is not ye= t discussed in the draft, but assuming the draft is adopted and we cover it= , we can make it explicit.

One = minor other question:
      To revalidate a delegation, =
the iterative caching DNS resolver
      will forward the query that triggered revalidation to the
      nameservers at the closest enclosing zone cut above the
      revalidation point.
Does "the query that trigg= ered revalidation" refer to the original client query which had RD=3D1= ?=C2=A0 If so, does this fit with qname minimization?

Yeah, good catch. We need to adjust that text = slightly to be compatible with qname minimization, which should be pretty s= traightforward - it's just pruning the requisite number of left most la= bels for the enclosing zone.

Shumon.
--000000000000e4a3a305a6e121d3-- From nobody Sat May 30 14:52:15 2020 Return-Path: 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 490703A0AB1 for ; Sat, 30 May 2020 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 EQSv5-04AeHv for ; Sat, 30 May 2020 14:52:10 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0623A0AB0 for ; Sat, 30 May 2020 14:52:10 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CADF5B074A; Sat, 30 May 2020 21:52:06 +0000 (UTC) From: Paul Vixie To: Gavin McCullagh Cc: Shumon Huque , "dnsop@ietf.org WG" Date: Sat, 30 May 2020 21:52:05 +0000 Message-ID: <1784179.3RNBUOQf3q@linux-9daj> Organization: none In-Reply-To: References: <33141878.RIuage5OGR@linux-9daj> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] New draft on delegation revalidation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 21:52:14 -0000 On Saturday, 30 May 2020 17:13:10 UTC Gavin McCullagh wrote: > ... > > I think Petr's point might be that someone could interpret the draft > (perhaps especially the simple mechanism) to mean that the NS TTL becomes > an effective cap on the TTL of all records below the zone cut even where > the NS set has not changed. i hadn't seen that possible interpretation, and never intended that potential outcome, so thank you for explaining that the draft language is unclear in that way. > > If lowering a delegating NS TTL to 300 for a very large zone (or one high > up the tree) meant a lot of resolvers might expire every record below the > zone cut every 300 seconds (even unsynchronized), then it seems like > lowering that TTL could produce a thundering herd. i think there are two discussable matters there. first, the thundering herd would still have to be externally synchronized somehow, or else each member of the herd would begin their 300-second cycle independently, and never thunder. second, the only condition under which "rm -r $apex" would occur in the cache is if the delegation point disappears or if it rolls over 100% (no NS RRs in common between two successive NS RRsets seen during delegation.) so, very rare. we can clarify the language to remove the possible misinterpretation you're describing. > I think the intent of > the draft and Shumon's quote above are that a resolver should only expire > cached subdomain records when the delegating NS changes. Would it be > useful to be explicit about that? yes, apparently so :-). > I imagine even the NS revalidation means that if an operator lowers a > delegating NS TTL to e.g. 300 in advance of a change in order to "make that > change visible to resolvers reasonably quickly", they might well see a 300 > second long period of thunder immediately after the change while every > resolver's cache expires that part of the tree and then fills it back up. until and unless we have a way for authorities to notify existing caches that a delegation has changed (either in content of NS or DS RRset, or A/AAAA glue under the delegation point, or TTL of any of that), then the change in your example would not be seen by all caches at the same time, which means they could not synchronize their revalidation cycles into a thundering herd. as an interesting corner case, an RFC2308 negative proof that included a delegation section could cause an updated delegation to be seen immediately by a large number of caches, for example during a randomized subdomain attack. it seems possible that this latent attack vector deserves mention in the revalidation draft, but i'm not sure how to describe "synchrony should be avoided" other than to say that caches practicing delegation revalidation ought to begin this process at a random time during the last 20% of the delegating TTL, to avoid becoming part of a thundering herd if their original delegation reception time was somehow broadly synchronized. > > One minor other question: > > To revalidate a delegation, the iterative caching DNS resolver > will forward the query that triggered revalidation to the > nameservers at the closest enclosing zone cut above the > revalidation point. > > Does "the query that triggered revalidation" refer to the original client > query which had RD=1? If so, does this fit with qname minimization? that language predates Q-M, so thanks for noticing the mismatch. we'll have to say "whatever query would normally be forwarded to the authority". what we're trying to avoid is making an NS query for the delegation, since that's considered by many authority operators as a diagnostic query that they can't or won't answer. but i agree, this has to be updated to cover the Q-M method. -- Paul