IETF Logo Mail Archive

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

Paul Hoffman <paul.hoffman@icann.org> Mon, 29 November 2021 19:56 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4FA3A0878 for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9WunRKVlpFf for <dnsop@ietfa.amsl.com>; Mon, 29 Nov 2021 11:56:09 -0800 (PST)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F19B3A0864 for <dnsop@ietf.org>; Mon, 29 Nov 2021 11:56:08 -0800 (PST)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa4.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 1ATJu5qv031465 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Nov 2021 19:56:05 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Mon, 29 Nov 2021 11:56:04 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0922.019; Mon, 29 Nov 2021 11:56:04 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: dnsop <dnsop@ietf.org>
CC: RFC Editor <rfc-editor@rfc-editor.org>
Thread-Topic: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Thread-Index: AQHX5VbnLgdyMlo+c0ikdEAItuzn8qwbb4YAgAACL4A=
Date: Mon, 29 Nov 2021 19:56:04 +0000
Message-ID: <F2B9DBB7-9BBA-4C86-953C-1488A05E079D@icann.org>
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca> <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com> <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca>
In-Reply-To: <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_76063AFD-053E-493A-B8F3-08CD66651229"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-29_09:2021-11-28, 2021-11-29 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Lpa70aRqyE8_6jrqYO2vr4J-CLY>
Subject: Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 19:56:14 -0000

On Nov 29, 2021, at 11:48 AM, Joe Abley <jabley@hopcount.ca> wrote:
> The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and other namespaces can fight their own battles?

This bit of wrong text originates with RFC 6761:
   5.  Authoritative DNS Servers:

       Are developers of authoritative domain name servers expected to
       make their implementations recognize these names as special and
       treat them differently?  If so, how?

   6.  DNS Server Operators:

       Does this reserved Special-Use Domain Name have any potential
       impact on DNS server operators?  If they try to configure their
       authoritative DNS server as authoritative for this reserved name,
       will compliant name server software reject it as invalid?  Do DNS
       server operators need to know about that and understand why?
       Even if the name server software doesn't prevent them from using
       this reserved name, are there other ways that it may not work as
       expected, of which the DNS server operator should be aware?

#5 explicitly talks about expectations on developers of authoritative *DNS* servers dealing with names that are not in the DNS. In retrospect, this was probably a mistake. (In retrospect, that mistake was probably caused by exhaustion from the discussion.)

Despite the nausea-inducing of Peter's suggestion, I think folks here need to deal with it, if for no other reason than RFC 6761 still being a standard.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email