From nobody Tue Sep 12 12:45:28 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43697132ECF for ; Tue, 12 Sep 2017 12:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XXxpShEglV1a for ; Tue, 12 Sep 2017 12:45:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E03E132697 for ; Tue, 12 Sep 2017 12:45:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 752D0B8114C; Tue, 12 Sep 2017 12:45:13 -0700 (PDT) To: Donald.Eastlake@motorola.com, suresh.krishnan@gmail.com, terry.manderson@icann.org, ogud@ogud.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rich.tom@alticeusa.com, dnsext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170912194513.752D0B8114C@rfc-editor.org> Date: Tue, 12 Sep 2017 12:45:13 -0700 (PDT) Archived-At: Subject: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 19:45:27 -0000 The following errata report has been submitted for RFC4343, "Domain Name System (DNS) Case Insensitivity Clarification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5112 -------------------------------------- Type: Editorial Reported by: Change "should" to must in section 3.(no subsection) Section: 3 Original Text ------------- comparisons on name lookup for DNS queries should be case insensitive Corrected Text -------------- comparisons on name lookup for DNS queries must be case insensitive Notes ----- Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the following two sentences after that particular sentence use the term MUST. I suspect some readers of the RFC are reading the word "should" and aren't reading the rest of the paragraph. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4343 (draft-ietf-dnsext-insensitive-06) -------------------------------------- Title : Domain Name System (DNS) Case Insensitivity Clarification Publication Date : January 2006 Author(s) : D. Eastlake 3rd Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Sep 12 15:18:32 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95727132F64 for ; Tue, 12 Sep 2017 15:18:30 -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, 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 96Flj8mkAQQG for ; Tue, 12 Sep 2017 15:18:28 -0700 (PDT) Received: from gal.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::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 80FC312421A for ; Tue, 12 Sep 2017 15:18:28 -0700 (PDT) Received: (qmail 48205 invoked by uid 125); 12 Sep 2017 22:18:27 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 12 Sep 2017 22:18:27 -0000 Date: 12 Sep 2017 22:15:00 -0000 Message-ID: <20170912221500.1622.qmail@ary.lan> From: "John Levine" To: dnsext@ietf.org Cc: rfc-editor@rfc-editor.org In-Reply-To: <20170912194513.752D0B8114C@rfc-editor.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 22:18:30 -0000 I would reject this or at most mark it as hold for update. The word "should" in lower case appears in two other places where it's not used in the 2119 sense, and I think this one is not intended to be the 2119 sense either. The sentence in question is describing the historical situation, and the following capital MUSTs tell you what to do. Having said that, if we ever revisit this document, it would benefit from rewording to make it clearer when it is telling you what to do and when it's just giving background. R's, John In article <20170912194513.752D0B8114C@rfc-editor.org> you write: >The following errata report has been submitted for RFC4343, >"Domain Name System (DNS) Case Insensitivity Clarification". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata/eid5112 > >-------------------------------------- >Type: Editorial >Reported by: Change "should" to must in section 3.(no subsection) > >Section: 3 > >Original Text >------------- >comparisons on name lookup for DNS queries should be case insensitive > >Corrected Text >-------------- >comparisons on name lookup for DNS queries must be case insensitive > >Notes >----- >Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have >uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the >following two sentences after that particular sentence use the term MUST. I suspect some readers of the >RFC are reading the word "should" and aren't reading the rest of the paragraph. > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC4343 (draft-ietf-dnsext-insensitive-06) >-------------------------------------- >Title : Domain Name System (DNS) Case Insensitivity Clarification >Publication Date : January 2006 >Author(s) : D. Eastlake 3rd >Category : PROPOSED STANDARD >Source : DNS Extensions >Area : Internet >Stream : IETF >Verifying Party : IESG > >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext > From nobody Wed Sep 13 07:42:30 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0D133017; Wed, 13 Sep 2017 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TNd_A--zeREk; Wed, 13 Sep 2017 07:42:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8D6132949; Wed, 13 Sep 2017 07:42:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3D81CB82150; Wed, 13 Sep 2017 07:42:15 -0700 (PDT) To: rich.tom@alticeusa.com, Donald.Eastlake@motorola.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: warren@kumari.net, iesg@ietf.org, dnsext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170913144215.3D81CB82150@rfc-editor.org> Date: Wed, 13 Sep 2017 07:42:15 -0700 (PDT) Archived-At: Subject: [dnsext] [Errata Held for Document Update] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:42:29 -0000 The following errata report has been held for document update for RFC4343, "Domain Name System (DNS) Case Insensitivity Clarification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5112 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Change "should" to must in section 3.(no subsection) Date Reported: 2017-09-12 Held by: Warren Kumari (IESG) Section: 3 Original Text ------------- comparisons on name lookup for DNS queries should be case insensitive Corrected Text -------------- comparisons on name lookup for DNS queries must be case insensitive Notes ----- --- Original report --- Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the following two sentences after that particular sentence use the term MUST. I suspect some readers of the RFC are reading the word "should" and aren't reading the rest of the paragraph. ---- WK Update ---- The full quote is: "According to the original DNS design decision, comparisons on name lookup for DNS queries should be case insensitive [STD13]. ", and the title of this (RFC4343) is "Domain Name System (DNS) Case Insensitivity Clarification" -- seeing as the whole point of this document is to clarify the original spec, I think that readers will read the RFC2119 bits. However, I do agree that this could be better worded, and future updates of this document should probably reword this to make it clearer. -------------------------------------- RFC4343 (draft-ietf-dnsext-insensitive-06) -------------------------------------- Title : Domain Name System (DNS) Case Insensitivity Clarification Publication Date : January 2006 Author(s) : D. Eastlake 3rd Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Sep 20 10:03:53 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921B3134220 for ; Wed, 20 Sep 2017 10:03:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qizwSIz1hfBG for ; Wed, 20 Sep 2017 10:03:49 -0700 (PDT) Received: from smtp123.ord1d.emailsrvr.com (smtp123.ord1d.emailsrvr.com [184.106.54.123]) (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 CF87713420B for ; Wed, 20 Sep 2017 10:03:49 -0700 (PDT) Received: from smtp8.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id EBB43C0060; Wed, 20 Sep 2017 13:03:48 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp8.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id BBC4AC0059; Wed, 20 Sep 2017 13:03:48 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-96-255-4-80.washdc.fios.verizon.net [96.255.4.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 20 Sep 2017 13:03:48 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Olafur Gudmundsson In-Reply-To: <20170912221500.1622.qmail@ary.lan> Date: Wed, 20 Sep 2017 13:03:48 -0400 Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D4627CA-550A-450C-BFBD-2E7BE51DC378@ogud.com> References: <20170912221500.1622.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 17:03:51 -0000 John and I agree=20 please reject this errata=20 Olafur > On Sep 12, 2017, at 6:15 PM, John Levine wrote: >=20 > I would reject this or at most mark it as hold for update. The word > "should" in lower case appears in two other places where it's not used > in the 2119 sense, and I think this one is not intended to be the 2119 > sense either. The sentence in question is describing the historical > situation, and the following capital MUSTs tell you what to do. =20 >=20 > Having said that, if we ever revisit this document, it would benefit > from rewording to make it clearer when it is telling you what to do > and when it's just giving background. >=20 > R's, > John >=20 >=20 >=20 > In article <20170912194513.752D0B8114C@rfc-editor.org> you write: >> The following errata report has been submitted for RFC4343, >> "Domain Name System (DNS) Case Insensitivity Clarification". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5112 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Change "should" to must in section 3.(no subsection) = >>=20 >> Section: 3 >>=20 >> Original Text >> ------------- >> comparisons on name lookup for DNS queries should be case insensitive >>=20 >> Corrected Text >> -------------- >> comparisons on name lookup for DNS queries must be case insensitive >>=20 >> Notes >> ----- >> Some authoritative DNS servers and/or mitigation devices/software = silently drop queries that have >> uppercase letters in them. Furthermore, the clarification of the = case insensitive comparison in the >> following two sentences after that particular sentence use the term = MUST. I suspect some readers of the >> RFC are reading the word "should" and aren't reading the rest of the = paragraph. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC4343 (draft-ietf-dnsext-insensitive-06) >> -------------------------------------- >> Title : Domain Name System (DNS) Case Insensitivity = Clarification >> Publication Date : January 2006 >> Author(s) : D. Eastlake 3rd >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >>=20 >=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Wed Sep 20 11:32:43 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1A13429D for ; Wed, 20 Sep 2017 11:32:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 und_AKwymiUR for ; Wed, 20 Sep 2017 11:32:40 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 AD937134295 for ; Wed, 20 Sep 2017 11:32:39 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id z39so2859860wrb.8 for ; Wed, 20 Sep 2017 11:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SkIDcvCMLXYhhr0chlZeN5862ohECwH5I33pKHNBuU4=; b=NXD7h0iCSJh+pFJZYiy23UHg8DIQ237ia4fVbnv5rDC6ixO5savCw60friS0Z1q5Pb dvLIgOk/+ptu296olK+5b4W5l1Wz9Rn9bEkZ2Q/kqnoQd6t4eefmqiKo7x15/zDQx2T5 YwQdE9I04HC0yUeXIjn0Bu0Za85yipuOv3QJJ9PhdUlvA0DI3rJVf1t8Vv7Q2Hek8ePV wiJ3SybqE06ZqdrrfolEwG2GIy7rM1YtmMtBt5aArDpH9OOV3ubAsynK0/++WH8Y93uo dKZTnkPmP8o5EXdrELtnL2sa522ugy0utOcfvsc/ZcWjnJBeqcA8LBdhjGqjT0YSZa00 sRwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SkIDcvCMLXYhhr0chlZeN5862ohECwH5I33pKHNBuU4=; b=fH6KA2f9n5QQ66CYWbZSlkg43kmmRKyZQZxUW5LJPFocEj+LUvs1v+p68pAcnjSsbJ CEqfzgMQuEyCFyDYa79ceH19QRL6k0ajCOuUXNbZLq4UyJnAdWpfJXoF8CMnCDuJbsud mN6leWfG8VToz0CAps8pY7GThLxS3HN39cxzTdb1kMliOX7KdKwtPVvUjO7uAzFx88rr 8h5orBF9yvI974y6+CMxSHqYWMClAH13nqv8kQEhwNyfWCN7hKtpWzfVFMJrUez1KBEX vOsRa+dTLATrS6WonTduNvCJn5xhjgRM29EKY0j7ltIpGjh0xjU0bEVutd6iOyhpT144 aRNA== X-Gm-Message-State: AHPjjUg9hpmAzh/YyN1y9E6dF2aUJ3msvkpWGvMIP/ssOuklXKBE431c eSejIDHJ/p+sE3oDJvMZA9NKMjCELCHbzevPKWXSVzG4 X-Google-Smtp-Source: AOwi7QBMkudeYvN383vggOF/lxS5RWzHIxDxHLukfqJmAjvDNptlTTkNj4hfYfxBXiLhmC3qN2TlbJj6oVdF9xkWUGs= X-Received: by 10.223.178.193 with SMTP id g59mr5784978wrd.0.1505932357938; Wed, 20 Sep 2017 11:32:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Wed, 20 Sep 2017 11:31:57 -0700 (PDT) In-Reply-To: <1D4627CA-550A-450C-BFBD-2E7BE51DC378@ogud.com> References: <20170912221500.1622.qmail@ary.lan> <1D4627CA-550A-450C-BFBD-2E7BE51DC378@ogud.com> From: Warren Kumari Date: Wed, 20 Sep 2017 14:31:57 -0400 Message-ID: To: Olafur Gudmundsson Cc: John Levine , dnsext@ietf.org, "rfc-editor@rfc-editor.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 18:32:42 -0000 I marked it as "Hold for update" -- next time someone edits this RFC it might make sense to make it clearer. Sorry, I thought the errata tool would have sent the mail update. W On Wed, Sep 20, 2017 at 1:03 PM, Olafur Gudmundsson wrote: > John and I agree > please reject this errata > > Olafur > >> On Sep 12, 2017, at 6:15 PM, John Levine wrote: >> >> I would reject this or at most mark it as hold for update. The word >> "should" in lower case appears in two other places where it's not used >> in the 2119 sense, and I think this one is not intended to be the 2119 >> sense either. The sentence in question is describing the historical >> situation, and the following capital MUSTs tell you what to do. >> >> Having said that, if we ever revisit this document, it would benefit >> from rewording to make it clearer when it is telling you what to do >> and when it's just giving background. >> >> R's, >> John >> >> >> >> In article <20170912194513.752D0B8114C@rfc-editor.org> you write: >>> The following errata report has been submitted for RFC4343, >>> "Domain Name System (DNS) Case Insensitivity Clarification". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5112 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Change "should" to must in section 3.(no subsection) >>> >>> Section: 3 >>> >>> Original Text >>> ------------- >>> comparisons on name lookup for DNS queries should be case insensitive >>> >>> Corrected Text >>> -------------- >>> comparisons on name lookup for DNS queries must be case insensitive >>> >>> Notes >>> ----- >>> Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have >>> uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the >>> following two sentences after that particular sentence use the term MUST. I suspect some readers of the >>> RFC are reading the word "should" and aren't reading the rest of the paragraph. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4343 (draft-ietf-dnsext-insensitive-06) >>> -------------------------------------- >>> Title : Domain Name System (DNS) Case Insensitivity Clarification >>> Publication Date : January 2006 >>> Author(s) : D. Eastlake 3rd >>> Category : PROPOSED STANDARD >>> Source : DNS Extensions >>> Area : Internet >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >>> >> >> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- 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 Sep 21 03:54:31 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7013421A for ; Thu, 21 Sep 2017 03:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HLVv1alH26V7 for ; Thu, 21 Sep 2017 03:54:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5B5132D45 for ; Thu, 21 Sep 2017 03:54:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C6A89B81F0B; Thu, 21 Sep 2017 03:54:06 -0700 (PDT) To: ed.lewis@neustar.biz, suresh.krishnan@gmail.com, terry.manderson@icann.org, ogud@ogud.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: K.Koymans@uva.nl, dnsext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170921105406.C6A89B81F0B@rfc-editor.org> Date: Thu, 21 Sep 2017 03:54:06 -0700 (PDT) Archived-At: Subject: [dnsext] [Technical Errata Reported] RFC4592 (5119) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:54:29 -0000 The following errata report has been submitted for RFC4592, "The Role of Wildcards in the Domain Name System". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5119 -------------------------------------- Type: Technical Reported by: Karst Koymans Section: 4.7 Original Text ------------- 4.7. NSEC RRSet at a Wildcard Domain Name Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. Synthesis of these records will only occur when the query exactly matches the record. Synthesized NSEC RRs will not be harmful as they will never be used in negative caching or to generate a negative response [RFC2308]. Corrected Text -------------- 4.7. NSEC RRSet at a Wildcard Domain Name Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. NSEC RRSets must not be synthesized from this wildcard NSEC. Notes ----- Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4592 (draft-ietf-dnsext-wcard-clarify-11) -------------------------------------- Title : The Role of Wildcards in the Domain Name System Publication Date : July 2006 Author(s) : E. Lewis Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Thu Sep 21 05:00:48 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA11342C5 for ; Thu, 21 Sep 2017 05:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 A2zA0JfdKv0g for ; Thu, 21 Sep 2017 05:00:45 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A251320C9 for ; Thu, 21 Sep 2017 05:00:45 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 21 Sep 2017 05:00:42 -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.1178.000; Thu, 21 Sep 2017 05:00:42 -0700 From: Edward Lewis To: RFC Errata System , "suresh.krishnan@gmail.com" , Terry Manderson , "ogud@ogud.com" , "ajs@anvilwalrusden.com" CC: "K.Koymans@uva.nl" , "dnsext@ietf.org" Thread-Topic: [Ext] [dnsext] [Technical Errata Reported] RFC4592 (5119) Thread-Index: AQHTMsgETTnbasncMkKOPIRs+ZkkYaK/skcA Date: Thu, 21 Sep 2017 12:00:42 +0000 Message-ID: References: <20170921105406.C6A89B81F0B@rfc-editor.org> In-Reply-To: <20170921105406.C6A89B81F0B@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3588825642_1033411387" MIME-Version: 1.0 Archived-At: Subject: Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 12:00:47 -0000 --B_3588825642_1033411387 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 9/21/17, 06:54, "dnsext on behalf of RFC Errata System" wrote: >Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198). When "The Role of Wildcards in the DNS" was written, "Aggressive Use of DNSSEC-Validated Cache" hadn't been. Until now I wasn't completely aware of that latter document (as I've not followed DNSOP for some time now), although I heard rumors about the idea. (Meaning: I'd have to read the newer document before understanding the errata.) Take this reply as the beginning of a discussion, not a final response, I certainly don't have all the data. Nevertheless, some explanation of the history of the subject passage is in order. The DNS of 10-15 years ago had the concept of a positive cache and a negative cache, the latter from "Negative Caching of DNS Queries (DNS NCACHE)". Entries in the latter cache only happened with a negative answer (i.e., NSEC or NSEC3 in the authority section of a DNS response if DNSSEC was "running"). Data from the answer section in a DNS response would not go there, hence the comment that synthesized answers would do no harm. The distinction of the section in which the NSEC record is received matters. There are two ways an NSEC record can appear in an answer section and one way an NSEC3 record can appear in an Answer section. The protocol will answer for queries with a QTYPE of NSEC (one way for NSEC) but not for NSEC3 (which the count of "ways" is different). The one way each can appear in an answer section is in a zone transfer (AXFR) [and I suppose incremental transfer (IXFR). AXFR and IXFR handling are a whole'nuther topic (see "DNS Zone Transfer Protocol (AXFR)"). I haven't read the "Aggressive Use of DNSSEC-Validated Cache" to know if it overlooked this important distinction, that is, NSEC records in the answer section (of a query-response) are not necessarily qualified to be used for "aggressive use" if because they may be synthesized. The assumption behind the statement in "The Role of Wildcards in the Domain Name System" is that we wanted minimal disruption to existing code bases, hence there was no new restriction added for a query whose type was NSEC. Another element of the historical context, while "The Role of Wildcards in the Domain Name System" was developed, there was uncertainty about whether a cache should be allowed to "usurp" the role of an authority (server) when it came to RCODE Name Error responses. I don't recall my opinion on this at the time, so I'm not arguing one way or the other, but there was reluctance to permit the caches to take this on. There was no consensus then, as there is now, that caches out to be "aggressive." This is why the document assumed that the only use of negative answer records would be to answer specific queries (QNAME, QTYPE, QCLASS), modulo other factors such as "Client Subnet in DNS Queries". This shift in consensus is what makes the subject passive "historically confusing." My take. I'm naturally against adopting errata unless it is clear a change is needed. I do see that the statement is historically confusing, but am not yet certain it is incorrect. I would suggest examining the "Aggressive Use of DNSSEC Validated Cache" to see if it takes into consideration the response message section of the NSEC records. Altering the older document would mean needing to address older code paths, this is why I suggest examining the newer document to see if it has the same assumptions as the older document - specifically the message section. --B_3588825642_1033411387 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQMCdyMKftVYcj0WkIw6dQdjqODqzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA5MjExMjAwNDJaMA0GCSqGSIb3 DQEBAQUABIIBAFBQZ4ysq8wwYXwnm9l3ltmze5VVdZCBUCEGgvwZkrYJz1f140GqxppGC8Nr k9Dbusztnf52j+lgBH5nn+9cnAm4ozfOwqUkEf8mbuoE5ti0AreNoTQE5RbPfrWlfD7NLSB3 ZejOaI9+6zzxHWT2ZTZ9wD0BmnUwqgrAsA3KB/NIqAS6wOB72Gnvnnjv3CRz3DF7Ir6WeB1b o83RalvoljVXq41doDnpHcX5X73AOsp7EPRyMjSY6JXYhOg+xsWvd1Y9LasH0nrl0SefIwwI ahHh1uXRs8I6sNDfqkvHqJHi2qLmWkjfwXWE+5fSgz6b3B9Il6emBzqde9IVqLxN9QY= --B_3588825642_1033411387-- From nobody Thu Sep 21 08:57:13 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF813214D for ; Thu, 21 Sep 2017 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CY69ytvyNpQ1 for ; Thu, 21 Sep 2017 08:57:09 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58619124F57 for ; Thu, 21 Sep 2017 08:57:09 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 21 Sep 2017 08:57:06 -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.1178.000; Thu, 21 Sep 2017 08:57:06 -0700 From: Edward Lewis To: RFC Errata System , "suresh.krishnan@gmail.com" , Terry Manderson , "ogud@ogud.com" , "ajs@anvilwalrusden.com" CC: "K.Koymans@uva.nl" , "dnsext@ietf.org" Thread-Topic: [Ext] [dnsext] [Technical Errata Reported] RFC4592 (5119) Thread-Index: AQHTMsgETTnbasncMkKOPIRs+ZkkYaK/skcAgABCDIA= Date: Thu, 21 Sep 2017 15:57:06 +0000 Message-ID: <2F6AAC7E-CB6D-45AF-9682-32CA420E8E30@icann.org> References: <20170921105406.C6A89B81F0B@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3588839825_1886476913" MIME-Version: 1.0 Archived-At: Subject: Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:57:12 -0000 --B_3588839825_1886476913 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit A top-posted reply... I was urged to read "Aggressive Use of DNSSEC-Validated Cache" and comment on it. Looking at that document, it is consistent with the idea that records in the negative cache are used (for "aggressive use"). In section 5: "If the negative cache of the validating resolver has" ... To drive home how confusing this is, I have this live example of a zone with a wildcard owning an NSEC set (I sed'd the real name to example): ; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> example.example nsec +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14104 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;example.example. IN NSEC ;; ANSWER SECTION: example.example. 241 IN NSEC nic.example. A MX TXT SRV RRSIG NSEC example.example. 241 IN RRSIG NSEC 8 1 300 20171021044514 20170921044514 64884 example. geZpt40NNNE6kTTiMZ8+ubdGWc0k9/MU4VgryRltfn5nTziVbhrNMIkQ 65poyfWL+jtXNZoCOm8GpOzB1c+x+qusA2y3O9AODru/P6LM17e9xTkW t5WvEyvjt2/GiVG2ugjdGZmUZGjX4AKlG0qYz3CBk+a3X215SwsYioN/ sqQ= ;; AUTHORITY SECTION: *.example. 241 IN NSEC nic.example. A MX TXT SRV RRSIG NSEC *.example. 241 IN RRSIG NSEC 8 1 300 20171021044514 20170921044514 64884 example. geZpt40NNNE6kTTiMZ8+ubdGWc0k9/MU4VgryRltfn5nTziVbhrNMIkQ 65poyfWL+jtXNZoCOm8GpOzB1c+x+qusA2y3O9AODru/P6LM17e9xTkW t5WvEyvjt2/GiVG2ugjdGZmUZGjX4AKlG0qYz3CBk+a3X215SwsYioN/ sqQ= ;; Query time: 0 msec ;; SERVER: 10.32.11.34#53(10.32.11.34) ;; WHEN: Thu Sep 21 15:51:16 UTC 2017 ;; MSG SIZE rcvd: 441 In the answer section, the result of the synthesis appears and this would be in the positive cache. In the authority section, the original record appears and this would go in the negative cache. "Aggressive use" mentions the use of the negative cache, so I'd say this is consistent. The begging question: can the cache use the *.example. NSEC to synthesize where the negative cache indicates it would be appropriate to do so? Sure. Same as the authority, synthesized in the answer, proving the non-existence of the QNAME in the authority. On 9/21/17, 08:00, "Edward Lewis" wrote: On 9/21/17, 06:54, "dnsext on behalf of RFC Errata System" wrote: >Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198). When "The Role of Wildcards in the DNS" was written, "Aggressive Use of DNSSEC-Validated Cache" hadn't been. Until now I wasn't completely aware of that latter document (as I've not followed DNSOP for some time now), although I heard rumors about the idea. (Meaning: I'd have to read the newer document before understanding the errata.) Take this reply as the beginning of a discussion, not a final response, I certainly don't have all the data. Nevertheless, some explanation of the history of the subject passage is in order. The DNS of 10-15 years ago had the concept of a positive cache and a negative cache, the latter from "Negative Caching of DNS Queries (DNS NCACHE)". Entries in the latter cache only happened with a negative answer (i.e., NSEC or NSEC3 in the authority section of a DNS response if DNSSEC was "running"). Data from the answer section in a DNS response would not go there, hence the comment that synthesized answers would do no harm. The distinction of the section in which the NSEC record is received matters. There are two ways an NSEC record can appear in an answer section and one way an NSEC3 record can appear in an Answer section. The protocol will answer for queries with a QTYPE of NSEC (one way for NSEC) but not for NSEC3 (which the count of "ways" is different). The one way each can appear in an answer section is in a zone transfer (AXFR) [and I suppose incremental transfer (IXFR). AXFR and IXFR handling are a whole'nuther topic (see "DNS Zone Transfer Protocol (AXFR)"). I haven't read the "Aggressive Use of DNSSEC-Validated Cache" to know if it overlooked this important distinction, that is, NSEC records in the answer section (of a query-response) are not necessarily qualified to be used for "aggressive use" if because they may be synthesized. The assumption behind the statement in "The Role of Wildcards in the Domain Name System" is that we wanted minimal disruption to existing code bases, hence there was no new restriction added for a query whose type was NSEC. Another element of the historical context, while "The Role of Wildcards in the Domain Name System" was developed, there was uncertainty about whether a cache should be allowed to "usurp" the role of an authority (server) when it came to RCODE Name Error responses. I don't recall my opinion on this at the time, so I'm not arguing one way or the other, but there was reluctance to permit the caches to take this on. There was no consensus then, as there is now, that caches out to be "aggressive." This is why the document assumed that the only use of negative answer records would be to answer specific queries (QNAME, QTYPE, QCLASS), modulo other factors such as "Client Subnet in DNS Queries". This shift in consensus is what makes the subject passive "historically confusing." My take. I'm naturally against adopting errata unless it is clear a change is needed. I do see that the statement is historically confusing, but am not yet certain it is incorrect. I would suggest examining the "Aggressive Use of DNSSEC Validated Cache" to see if it takes into consideration the response message section of the NSEC records. Altering the older document would mean needing to address older code paths, this is why I suggest examining the newer document to see if it has the same assumptions as the older document - specifically the message section. --B_3588839825_1886476913 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTQKHohCDleeLFFRamIXfeVejJgPzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA5MjExNTU3MDVaMA0GCSqGSIb3 DQEBAQUABIIBAEBpM3hzziWpc4ElfSfSm0fFDKFsmN86Zi+QsuFn7H6gdTi1PIEZV/aGdRkT kaOQiCxp/8iHF9vZoWXfpAbIRfd4EvGGw7QgNWyetE0YCVQ9bOvfltW+RmGmX1nNrxwWGWWf 35klC+YFq4aZs2+db77nBa9pcXgrCDz3B0kN+HckaON+emPaBdN0yKXSq7LZ9lXFNhqIO3fM cSgrSz5R+dYBEe1qz4ZPIP0ebJf3l0UuyD6IElp41Q0/oz4tNmnNjZN8fuOoDHlN4LyrCujd vdFYtvyMFmpS/MIBmjuqPz2Dz7+5I09i+ZJbTrKXokwrf8haQkovZA6QNLiiOjWoPVI= --B_3588839825_1886476913-- From nobody Thu Sep 21 20:56:39 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED7B1320DC for ; Thu, 21 Sep 2017 20:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 LFXRwTVScjWW for ; Thu, 21 Sep 2017 20:56:35 -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 2F711126DD9 for ; Thu, 21 Sep 2017 20:56:35 -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 E71CE349666; Fri, 22 Sep 2017 03:56:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C2BE4160076; Fri, 22 Sep 2017 03:56:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9798816007C; Fri, 22 Sep 2017 03:56:03 +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 QfTVj5d4Tmbw; Fri, 22 Sep 2017 03:56:03 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F2D3E160076; Fri, 22 Sep 2017 03:56:02 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5C31987A1BBB; Fri, 22 Sep 2017 13:56:00 +1000 (AEST) To: RFC Errata System Cc: ed.lewis@neustar.biz, suresh.krishnan@gmail.com, terry.manderson@icann.org, ogud@ogud.com, ajs@anvilwalrusden.com, K.Koymans@uva.nl, dnsext@ietf.org From: Mark Andrews References: <20170921105406.C6A89B81F0B@rfc-editor.org> In-reply-to: Your message of "Thu, 21 Sep 2017 03:54:06 -0700." <20170921105406.C6A89B81F0B@rfc-editor.org> Date: Fri, 22 Sep 2017 13:56:00 +1000 Message-Id: <20170922035600.5C31987A1BBB@rock.dv.isc.org> Archived-At: Subject: Re: [dnsext] [Technical Errata Reported] RFC4592 (5119) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 03:56:37 -0000 Such NSEC records are identifiable as part of the validation processs and can be flagged to be ignored as part of the synthesis process and/or be stored with the original wildcard name. As a aside named saves validated wild card answers with their original wildcard name so they can be found for data synthesis purposes. I agree with Ed Lewis that this is not a problem with this RFC4592. Mark In message <20170921105406.C6A89B81F0B@rfc-editor.org>, RFC Errata System writes : > The following errata report has been submitted for RFC4592, > "The Role of Wildcards in the Domain Name System". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5119 > > -------------------------------------- > Type: Technical > Reported by: Karst Koymans > > Section: 4.7 > > Original Text > ------------- > 4.7. NSEC RRSet at a Wildcard Domain Name > > Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. > Synthesis of these records will only occur when the query exactly > matches the record. Synthesized NSEC RRs will not be harmful as they > will never be used in negative caching or to generate a negative > response [RFC2308]. > > > Corrected Text > -------------- > 4.7. NSEC RRSet at a Wildcard Domain Name > > Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. > NSEC RRSets must not be synthesized from this wildcard NSEC. > > Notes > ----- > Synthesizing these records would destroy the semantics of the NSEC chain and c > ould be very harmful if implementations would cache them and use them for "Agg > ressive Use of DNSSEC-Validated Cache" (RFC 8198). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4592 (draft-ietf-dnsext-wcard-clarify-11) > -------------------------------------- > Title : The Role of Wildcards in the Domain Name System > Publication Date : July 2006 > Author(s) : E. Lewis > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 22 20:09:28 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67491332DF for ; Fri, 22 Sep 2017 20:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, HTML_MESSAGE=0.001, SPF_PASS=-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 MHBVtJDU9FXg for ; Fri, 22 Sep 2017 20:09:26 -0700 (PDT) Received: from franklin.baylink.com (li1308-44.members.linode.com [45.79.209.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3CA1332D7 for ; Fri, 22 Sep 2017 20:09:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by franklin.baylink.com (Postfix) with ESMTP id 7886C4A2002; Sat, 23 Sep 2017 03:09:25 +0000 (UTC) Received: from franklin.baylink.com ([127.0.0.1]) by localhost (franklin.baylink.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Tciv9A57ae1E; Sat, 23 Sep 2017 03:09:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by franklin.baylink.com (Postfix) with ESMTP id 8E9074A2003; Sat, 23 Sep 2017 03:09:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at franklin.baylink.com Received: from franklin.baylink.com ([127.0.0.1]) by localhost (franklin.baylink.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7x-RWOMlgJUr; Sat, 23 Sep 2017 03:09:24 +0000 (UTC) Received: from [IPv6:2607:fb90:5246:ffd8:aa:6bf:d08a:cb94] (unknown [172.58.155.73]) by franklin.baylink.com (Postfix) with ESMTPSA id 01CCB4A2002; Sat, 23 Sep 2017 03:09:23 +0000 (UTC) Date: Tue, 12 Sep 2017 22:38:22 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <20170912221500.1622.qmail@ary.lan> References: <20170912221500.1622.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----4A11JDH0DN06B9QTQ19VWRB36MIYZI" Content-Transfer-Encoding: 7bit To: dnsext@ietf.org,John Levine CC: rfc-editor@rfc-editor.org From: Jay Ashworth Message-ID: Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 03:09:28 -0000 ------4A11JDH0DN06B9QTQ19VWRB36MIYZI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Long time listener, first-time caller, but the problem I have with this is = that it suggests that queries containing capital letters are dropped=2E=20 I recommend to people with overly complicated and long domain names that, = as best practice, they spell them in camel case in advertising=2E=20 www=2EMyBadDomain=2Ecom Partially, of course, this is to attempt to avoid the Pen Island/Who Repre= sents problem=2E But I do it knowing that the DNS system will case fold th= ose queries and they will thus work properly=2E If there are devices dropping those=2E=2E=2E I gotta say I'm a little unh= appy=2E Is there documentation of that? Cheers, -- jra On September 12, 2017 6:15:00 PM EDT, John Levine wrot= e: >I would reject this or at most mark it as hold for update=2E The word >"should" in lower case appears in two other places where it's not used >in the 2119 sense, and I think this one is not intended to be the 2119 >sense either=2E The sentence in question is describing the historical >situation, and the following capital MUSTs tell you what to do=2E =20 > >Having said that, if we ever revisit this document, it would benefit >from rewording to make it clearer when it is telling you what to do >and when it's just giving background=2E > >R's, >John > > > >In article <20170912194513=2E752D0B8114C@rfc-editor=2Eorg> you write: >>The following errata report has been submitted for RFC4343, >>"Domain Name System (DNS) Case Insensitivity Clarification"=2E >> >>-------------------------------------- >>You may review the report below and at: >>http://www=2Erfc-editor=2Eorg/errata/eid5112 >> >>-------------------------------------- >>Type: Editorial >>Reported by: Change "should" to must in section 3=2E(no subsection) > >> >>Section: 3 >> >>Original Text >>------------- >>comparisons on name lookup for DNS queries should be case insensitive >> >>Corrected Text >>-------------- >>comparisons on name lookup for DNS queries must be case insensitive >> >>Notes >>----- >>Some authoritative DNS servers and/or mitigation devices/software >silently drop queries that have >>uppercase letters in them=2E Furthermore, the clarification of the case >insensitive comparison in the >>following two sentences after that particular sentence use the term >MUST=2E I suspect some readers of the >>RFC are reading the word "should" and aren't reading the rest of the >paragraph=2E >> >>Instructions: >>------------- >>This erratum is currently posted as "Reported"=2E If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected=2E When a decision is reached, the verifying party =20 >>can log in to change the status and edit the report, if necessary=2E=20 >> >>-------------------------------------- >>RFC4343 (draft-ietf-dnsext-insensitive-06) >>-------------------------------------- >>Title : Domain Name System (DNS) Case Insensitivity >Clarification >>Publication Date : January 2006 >>Author(s) : D=2E Eastlake 3rd >>Category : PROPOSED STANDARD >>Source : DNS Extensions >>Area : Internet >>Stream : IETF >>Verifying Party : IESG >> >>_______________________________________________ >>dnsext mailing list >>dnsext@ietf=2Eorg >>https://www=2Eietf=2Eorg/mailman/listinfo/dnsext >> > > >_______________________________________________ >dnsext mailing list >dnsext@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsext --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------4A11JDH0DN06B9QTQ19VWRB36MIYZI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Long time listener, first-time caller, but the pro= blem I have with this is that it suggests that queries containing capital l= etters are dropped=2E

I recommend to people with overly complicated and long domain names that, = as best practice, they spell them in camel case in advertising=2E

www=2EMyBadDomain=2Ecom

Partially, of course, this is to attempt to avoid the Pen Island/Who Repre= sents problem=2E But I do it knowing that the DNS system will case fold th= ose queries and they will thus work properly=2E

If there are devices dropping those=2E=2E=2E I gotta say I'm a little= unhappy=2E Is there documentation of that?

Cheers,
-- jra

On September 12, 2017 6:15:00 PM = EDT, John Levine <johnl@taugh=2Ecom> wrote:
I would reject this or at most mark it as hold for u=
pdate=2E  The word
"should" in lower case appears in two oth=
er places where it's not used
in the 2119 sense, and I think this one =
is not intended to be the 2119
sense either=2E  The sentence in questi=
on is describing the historical
situation, and the following capital M=
USTs tell you what to do=2E  

Having said that, if we ever revis=
it this document, it would benefit
from rewording to make it clearer w=
hen it is telling you what to do
and when it's just giving background=
=2E

R's,
John



In article <2017091=
2194513=2E752D0B8114C@rfc-editor=2Eorg> you write:
The following errata report has been submi=
tted for RFC4343,
"Domain Name System (DNS) Case Insensitivity Cl=
arification"=2E


You may review the report below=
 and at:
http=
://www=2Erfc-editor=2Eorg/errata/eid5112


Type: E=
ditorial
Reported by: Change "should" to must in section 3=
=2E(no subsection) <rich=2Etom@alticeusa=2Ecom>

Section: 3=


Original Text
-------------
comparisons on name looku=
p for DNS queries should be case insensitive

Corrected Text
--------------
comparisons on name lookup for DNS queries must be cas=
e insensitive

Notes
-----
Some authoritative DNS serve=
rs and/or mitigation devices/software silently drop queries that have
=
uppercase letters in them=2E  Furthermore, the clarification of the case in=
sensitive comparison in the
following two sentences after that particu=
lar sentence use the term MUST=2E  I suspect some readers of the
RFC a=
re reading the word "should" and aren't reading the rest of the p=
aragraph=2E

Instructions:
-------------
This erratum i=
s currently posted as "Reported"=2E If necessary, please
use=
 "Reply All" to discuss whether it should be verified or
rej=
ected=2E When a decision is reached, the verifying party  
can log in =
to change the status and edit the report, if necessary=2E 


RFC4343 (draft-ietf-dnsext-insensitive-06)

Title   =
            : Domain Name System (DNS) Case Insensitivity Clarification
Publication Date    : January 2006
Author(s)           : D=2E Eastla=
ke 3rd
Category            : PROPOSED STANDARD
Source            =
  : DNS Extensions
Area                : Internet
Stream         =
     : IETF
Verifying Party     : IESG


dnsext m=
ailing list
dnsext@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/dnsext<=
/a>




dnsext mailing list
dnse=
xt@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/dnsext

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------4A11JDH0DN06B9QTQ19VWRB36MIYZI-- From nobody Sun Sep 24 17:47:07 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5F813295C for ; Sun, 24 Sep 2017 17:47:05 -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, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dM5kjjE9XALz for ; Sun, 24 Sep 2017 17:47:04 -0700 (PDT) Received: from smtp123.ord1d.emailsrvr.com (smtp123.ord1d.emailsrvr.com [184.106.54.123]) (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 AB58D13213D for ; Sun, 24 Sep 2017 17:47:04 -0700 (PDT) Received: from smtp16.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id CCA4F4006D; Sun, 24 Sep 2017 20:47:03 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp16.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7949F40072; Sun, 24 Sep 2017 20:47:03 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-96-255-4-80.washdc.fios.verizon.net [96.255.4.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Sun, 24 Sep 2017 20:47:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Olafur Gudmundsson In-Reply-To: <20170921105406.C6A89B81F0B@rfc-editor.org> Date: Sun, 24 Sep 2017 20:47:02 -0400 Cc: ed.lewis@neustar.biz, suresh.krishnan@gmail.com, terry.manderson@icann.org, ajs@anvilwalrusden.com, K.Koymans@uva.nl, dnsext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <344ECBBE-7DFB-4E53-8DA0-240ABA4D81F0@ogud.com> References: <20170921105406.C6A89B81F0B@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dnsext] [Technical Errata Reported] RFC4592 (5119) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 00:47:06 -0000 This errata report is based on a misunderstanding and should be rejected=20= There is no harm in synthesizing NSEC records as long as the owner name = of the NSEC record sorts before the target name.=20 Olafur > On Sep 21, 2017, at 6:54 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4592, > "The Role of Wildcards in the Domain Name System". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5119 >=20 > -------------------------------------- > Type: Technical > Reported by: Karst Koymans >=20 > Section: 4.7 >=20 > Original Text > ------------- > 4.7. NSEC RRSet at a Wildcard Domain Name >=20 > Wildcard domain names in DNSSEC signed zones will have an NSEC = RRSet. > Synthesis of these records will only occur when the query exactly > matches the record. Synthesized NSEC RRs will not be harmful as = they > will never be used in negative caching or to generate a negative > response [RFC2308]. >=20 >=20 > Corrected Text > -------------- > 4.7. NSEC RRSet at a Wildcard Domain Name >=20 > Wildcard domain names in DNSSEC signed zones will have an NSEC = RRSet. > NSEC RRSets must not be synthesized from this wildcard NSEC. >=20 > Notes > ----- > Synthesizing these records would destroy the semantics of the NSEC = chain and could be very harmful if implementations would cache them and = use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198). >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4592 (draft-ietf-dnsext-wcard-clarify-11) > -------------------------------------- > Title : The Role of Wildcards in the Domain Name System > Publication Date : July 2006 > Author(s) : E. Lewis > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG From nobody Tue Sep 26 13:20:28 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CA6134457 for ; Tue, 26 Sep 2017 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ezOjMCtyqnk9 for ; Tue, 26 Sep 2017 13:20:24 -0700 (PDT) Received: from mx2.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB225134456 for ; Tue, 26 Sep 2017 13:20:21 -0700 (PDT) Received: by mx2.open-xchange.com (Postfix, from userid 1001) id 02FF16A433; Tue, 26 Sep 2017 22:20:20 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.open-xchange.com (Postfix) with ESMTP id EE7C46A3EA; Tue, 26 Sep 2017 22:20:15 +0200 (CEST) Received: from [127.0.0.1] (helo=mx2.open-xchange.com) by localhost with ESMTP (eXpurgate 4.1.8) (envelope-from ) id 59cab67f-034f-7f000001272a-7f000001bb59-1 for ; Tue, 26 Sep 2017 22:20:15 +0200 Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.open-xchange.com (Postfix) with ESMTPS id 7DD586A263; Tue, 26 Sep 2017 22:20:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by open-xchange.com (Postfix) with ESMTP id 71B6C3C10DB; Tue, 26 Sep 2017 22:20:15 +0200 (CEST) Received: from open-xchange.com ([127.0.0.1]) by localhost (imap.open-xchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC-DJOruTjH6; Tue, 26 Sep 2017 22:20:15 +0200 (CEST) Received: from [192.168.0.20] (095-096-086-198.static.chello.nl [95.96.86.198]) (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 4915E3C1A2B; Tue, 26 Sep 2017 22:20:15 +0200 (CEST) From: "Peter van Dijk" To: dnsext@ietf.org, rfc-editor@rfc-editor.org Date: Tue, 26 Sep 2017 22:20:14 +0200 Message-ID: <247EEDCE-8F96-4E96-9DE3-2481FD95D339@powerdns.com> In-Reply-To: References: <20170912221500.1622.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_EE042EF7-4F2F-40D1-8F85-71F290435231_=" Embedded-HTML: [{"HTML":[1110, 4247], "plain":[623, 3650], "uuid":"EB42E533-53D4-4CC3-BEC5-495FC84688F8"}] X-Mailer: MailMate (1.9.7r5419) Content-Transfer-Encoding: 7bit X-purgate-ID: 151428::1506457215-0000034F-8DE5D945/0/0 X-purgate-type: clean X-purgate-size: 11186 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 20:20:26 -0000 --=_MailMate_EE042EF7-4F2F-40D1-8F85-71F290435231_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Jay, neither the original text or the erratum suggest dropping queries with=20 capital letters. The original text already says that queries MUST (2119=20 capital) match uppercase letters to lowercase letters. The suggested=20 erratum (in my eyes unnecessarily) suggests uppercasing a lowercase=20 should to make this even more explicit. As for devices dropping this, I don=E2=80=99t have any documentation hand= y but=20 mixed case is certainly known to trigger bugs in various pieces of=20 software now and then. Kind regards, --=20 Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ On 13 Sep 2017, at 4:38, Jay Ashworth wrote: > Long time listener, first-time caller, but the problem I have with=20 > this is that it suggests that queries containing capital letters are=20 > dropped. > > I recommend to people with overly complicated and long domain names=20 > that, as best practice, they spell them in camel case in advertising. > > www.MyBadDomain.com > > Partially, of course, this is to attempt to avoid the Pen Island/Who=20 > Represents problem. But I do it knowing that the DNS system will case=20 > fold those queries and they will thus work properly. > > If there are devices dropping those... I gotta say I'm a little=20 > unhappy. Is there documentation of that? > > Cheers, > -- jra > > On September 12, 2017 6:15:00 PM EDT, John Levine =20 > wrote: >> I would reject this or at most mark it as hold for update. The word >> "should" in lower case appears in two other places where it's not=20 >> used >> in the 2119 sense, and I think this one is not intended to be the=20 >> 2119 >> sense either. The sentence in question is describing the historical >> situation, and the following capital MUSTs tell you what to do. >> >> Having said that, if we ever revisit this document, it would benefit >> from rewording to make it clearer when it is telling you what to do >> and when it's just giving background. >> >> R's, >> John >> >> >> >> In article <20170912194513.752D0B8114C@rfc-editor.org> you write: >>> The following errata report has been submitted for RFC4343, >>> "Domain Name System (DNS) Case Insensitivity Clarification". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5112 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Change "should" to must in section 3.(no subsection) >> >>> >>> Section: 3 >>> >>> Original Text >>> ------------- >>> comparisons on name lookup for DNS queries should be case=20 >>> insensitive >>> >>> Corrected Text >>> -------------- >>> comparisons on name lookup for DNS queries must be case insensitive >>> >>> Notes >>> ----- >>> Some authoritative DNS servers and/or mitigation devices/software >> silently drop queries that have >>> uppercase letters in them. Furthermore, the clarification of the=20 >>> case >> insensitive comparison in the >>> following two sentences after that particular sentence use the term >> MUST. I suspect some readers of the >>> RFC are reading the word "should" and aren't reading the rest of the >> paragraph. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4343 (draft-ietf-dnsext-insensitive-06) >>> -------------------------------------- >>> Title : Domain Name System (DNS) Case Insensitivity >> Clarification >>> Publication Date : January 2006 >>> Author(s) : D. Eastlake 3rd >>> Category : PROPOSED STANDARD >>> Source : DNS Extensions >>> Area : Internet >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >>> >> >> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=_MailMate_EE042EF7-4F2F-40D1-8F85-71F290435231_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hello Jay,

neither the original text or the erratum suggest dropping= queries with capital letters. The original text already says that querie= s MUST (2119 capital) match uppercase letters to lowercase letters. The s= uggested erratum (in my eyes unnecessarily) suggests uppercasing a lowerc= ase should to make this even more explicit.

As for devices dropping this, I don=E2=80=99t have any do= cumentation handy but mixed case is certainly known to trigger bugs in va= rious pieces of software now and then.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

On 13 Sep 2017, at 4:38, Jay Ashworth wrote:

Lo= ng time listener, first-time caller, but the problem I have with this is = that it suggests that queries containing capital letters are dropped.
I recommend to people with overly complicated and long domain names that,= as best practice, they spell them in camel case in advertising.

www.MyBadDomain.com

Partially, of course, this is to attempt to avoid the Pen Island/Who Repr= esents problem. But I do it knowing that the DNS system will case fold t= hose queries and they will thus work properly.

If there are devices dropping those... I gotta say I'm a little unha= ppy. Is there documentation of that?

Cheers,
-- jra

On September 12, 2017 6:15:00 PM= EDT, John Levine <johnl@taugh.com> wrote:
I would reject this or at most mark it as hold for =
update.  The word
"should" in lower case appears in two ot=
her places where it's not used
in the 2119 sense, and I think this o=
ne is not intended to be the 2119
sense either.  The sentence in que=
stion is describing the historical
situation, and the following capi=
tal MUSTs tell you what to do.  

Having said that, if we ever =
revisit this document, it would benefit
from rewording to make it cl=
earer when it is telling you what to do
and when it's just giving ba=
ckground.

R's,
John



In article <=
;20170912194513.752D0B8114C@rfc-editor.org> you write:
The following errata report has be=
en submitted for RFC4343,
"Domain Name System (DNS) Case Insens=
itivity Clarification".


You may review the re=
port below and at:
http://www.rfc-editor.org/errata/eid5112


T=
ype: Editorial
Reported by: Change "should" to must in sec=
tion 3.(no subsection) <rich.tom@alticeusa.com>

Section:=
 3

Original Text
-------------
comparisons on name l=
ookup for DNS queries should be case insensitive

Corrected Tex=
t
--------------
comparisons on name lookup for DNS queries mus=
t be case insensitive

Notes
-----
Some authoritative=
 DNS servers and/or mitigation devices/software silently drop queries tha=
t have
uppercase letters in them.  Furthermore, the clarification of=
 the case insensitive comparison in the
following two sentences afte=
r that particular sentence use the term MUST.  I suspect some readers of =
the
RFC are reading the word "should" and aren't reading t=
he rest of the paragraph.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary,=
 please
use "Reply All" to discuss whether it should be ve=
rified or
rejected. When a decision is reached, the verifying party =
 
can log in to change the status and edit the report, if necessary.=
 


RFC4343 (draft-ietf-dnsext-insensitive-06)
=


Title               : Domain Name System (DNS) Case Insensiti=
vity Clarification
Publication Date    : January 2006
Author(s)=
           : D. Eastlake 3rd
Category            : PROPOSED STANDARD=

Source              : DNS Extensions
Area                : Int=
ernet
Stream              : IETF
Verifying Party     : IESG


dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/dnsext




dnsex= t mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext=

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

______________________= _________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

--=_MailMate_EE042EF7-4F2F-40D1-8F85-71F290435231_=-- From nobody Tue Sep 26 13:56:03 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45BE134463 for ; Tue, 26 Sep 2017 13:56:01 -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 7NZaiW08DzPO for ; Tue, 26 Sep 2017 13:56:00 -0700 (PDT) Received: from franklin.baylink.com (li1308-44.members.linode.com [45.79.209.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B12132153 for ; Tue, 26 Sep 2017 13:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by franklin.baylink.com (Postfix) with ESMTP id DC5BE4A2002; Tue, 26 Sep 2017 20:55:59 +0000 (UTC) Received: from franklin.baylink.com ([127.0.0.1]) by localhost (franklin.baylink.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KVH7dA5OzBpe; Tue, 26 Sep 2017 20:55:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by franklin.baylink.com (Postfix) with ESMTP id 595F94A2003; Tue, 26 Sep 2017 20:55:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at franklin.baylink.com Received: from franklin.baylink.com ([127.0.0.1]) by localhost (franklin.baylink.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xaDO1rKr7sXW; Tue, 26 Sep 2017 20:55:59 +0000 (UTC) Received: from franklin.baylink.com (franklin.baylink.com [45.79.209.44]) by franklin.baylink.com (Postfix) with ESMTP id 42E9C4A2002; Tue, 26 Sep 2017 20:55:59 +0000 (UTC) Date: Tue, 26 Sep 2017 20:55:59 +0000 (UTC) From: "Jay R. Ashworth" To: Peter van Dijk Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Message-ID: <352496552.13231.1506459359166.JavaMail.zimbra@baylink.com> In-Reply-To: <247EEDCE-8F96-4E96-9DE3-2481FD95D339@powerdns.com> References: <20170912221500.1622.qmail@ary.lan> <247EEDCE-8F96-4E96-9DE3-2481FD95D339@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [45.79.209.44] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF55 (Win)/8.6.0_GA_1153) Thread-Topic: RFC4343 (5112) Thread-Index: 3ItjHQ5VmTJIsgdtzYnorZZ/ZzWMsA== Archived-At: Subject: Re: [dnsext] [Editorial Errata Reported] RFC4343 (5112) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 20:56:01 -0000 > From: "Peter van Dijk" > neither the original text or the erratum suggest dropping queries with > capital letters. The original text already says that queries MUST (2119 > capital) match uppercase letters to lowercase letters. The suggested > erratum (in my eyes unnecessarily) suggests uppercasing a lowercase > should to make this even more explicit. >=20 > As for devices dropping this, I don=E2=80=99t have any documentation hand= y but > mixed case is certainly known to trigger bugs in various pieces of > software now and then. I was, in fact, being aghast at this: >>> Some authoritative DNS servers and/or mitigation devices/software >>> silently drop queries that have uppercase letters in them. If there are authoritative zone servers that drop incoming queries with cap= ital letters in them, I wish someone would let me know where so that I can go se= t=20 them on fire. That's *terribly* antisocial, aside from violating the RFCs = to a fare-thee-well. My apologies for being insufficiently clear about what I was responding to. Cheers, -- jra --=20 Jay R. Ashworth Baylink jra@baylink.= com Designer The Things I Think RFC 2= 100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover = DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1= 274