Re: [dnsext] [Technical Errata Reported] RFC4343 (6361)

Kaspar Etter <me@kasparetter.com> Wed, 23 December 2020 08:51 UTC

Return-Path: <me@kasparetter.com>
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 84AF13A0C7C for <dnsext@ietfa.amsl.com>; Wed, 23 Dec 2020 00:51:35 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 iVTNFvgJjit2 for <dnsext@ietfa.amsl.com>; Wed, 23 Dec 2020 00:51:32 -0800 (PST)
Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6919F3A0C8B for <dnsext@ietf.org>; Wed, 23 Dec 2020 00:51:31 -0800 (PST)
Received: from [192.168.1.4] (unknown [51.154.104.215]) (Authenticated sender: me@kasparetter.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 75769200004; Wed, 23 Dec 2020 08:51:26 +0000 (UTC)
From: Kaspar Etter <me@kasparetter.com>
Message-Id: <611DB60D-9BA1-404C-801B-37374B653255@kasparetter.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_12E0C160-E820-4D00-958C-4432B9EC505B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 23 Dec 2020 09:51:25 +0100
In-Reply-To: <CAF4+nEHUBiUxF_stf8_VPOipy=vOmwtDMrLaCmEQTz9nF3ibGQ@mail.gmail.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, Erik Kline <ek.ietf@gmail.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Olafur Gudmundsson <ogud@ogud.com>, Andrew Sullivan <ajs@anvilwalrusden.com>, IETF DNSEXT WG <dnsext@ietf.org>
To: Donald Eastlake <d3e3e3@gmail.com>
References: <20201222112911.18004F40769@rfc-editor.org> <CAF4+nEHUBiUxF_stf8_VPOipy=vOmwtDMrLaCmEQTz9nF3ibGQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/WlO0EuC_FxdJZd9EkkgYcpJvUeQ>
X-Mailman-Approved-At: Mon, 28 Dec 2020 08:01:44 -0800
Subject: Re: [dnsext] [Technical Errata Reported] RFC4343 (6361)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2020 08:54:30 -0000

Dear Mr. Eastlake,

Thanks a lot for the quick reply. Just to make sure that there’s no misunderstanding: If I figured it out (i.e. I should receive the capitalization of the label as it is in the server’s database in DNS responses), then the deployed DNS DOESN’T conform to this RFC.

Examples:
dig IETF.org <http://ietf.org/> => IETF.org <http://ietf.org/> in the answer section of the DNS response
dig ietf.org <http://ietf.org/> => ietf.org <http://ietf.org/> in the answer section of the DNS response

Since this could be due to one of the DNS servers rather than dig, here’s an API that is independent of my local configuration:
https://dns.google/resolve?name=IETF.org&type=A <https://dns.google/resolve?name=IETF.org&type=A> => IETF.org <http://ietf.org/> in response
https://dns.google/resolve?name=ietf.org&type=A <https://dns.google/resolve?name=ietf.org&type=A> => ietf.org <http://ietf.org/> in response

And here is another public DNS API:
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=IETF.org&type=A <https://cloudflare-dns.com/dns-query?name=IETF.org&type=A%E2%80%99>' => IETF.org <http://ietf.org/> in response
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=ietf.org&type=A <https://cloudflare-dns.com/dns-query?name=ietf.org&type=A>' => ietf.org <http://ietf.org/> in response

The problem with the earlier text in Section 4.1 of RFC 4343 is that, given "taking the label on the node whose name is to be output”, one could argue that my DNS query also specifies a node whose name you might want to output.

In a way, it has to be the capitalization of the label in the database. Otherwise, what’s the point of case preservation on input if there’s no way for anyone other than the DNS administrator, who can look at the zone file, to get the preserved case on output? But why is everyone getting it wrong then?

Can you confirm one more time that the above assessment is correct? Thank you.

And in any case, the status "Held for Document Update” is fine for me.

Best regards,
Kaspar


> On 23 Dec 2020, at 05:14, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
> Hi,
> 
> I am the author of RFC 4343. See below.
> 
> On Tue, Dec 22, 2020 at 6:29 AM RFC Errata System
> <rfc-editor@rfc-editor.org> wrote:
>> The following errata report has been submitted for RFC4343,
>> "Domain Name System (DNS) Case Insensitivity Clarification".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6361
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Kaspar Etter <me@kasparetter.com>
>> 
>> Section: 4.1
>> 
>> Original Text
>> -------------
>> No "case conversion" or "case folding" is done during such output
>> operations, thus "preserving" case.
>> 
>> Corrected Text
>> --------------
>> ?
>> 
>> Notes
>> -----
> 
>> Whose case is preserved? The case of the label in the DNS query or
>> the case of the label in the DNS database?
> 
> The earlier text in Section 4.1 is intended to indicate it is the
> "database".
> 
>> In other words, if there is a DNS record for ietf.org and I query
>> IETF.org, should the DNS response say ietf.org or IETF.org? I would
>> expect it's the former so that the DNS administrator can inform the
>> DNS requester about the preferred capitalization but I can't figure
>> this out on the basis of the RFC.
> 
> Well, you seem to have figured out how it works, although I have no
> idea what why the reference to "DNS administrator" rather than DNS
> resolver or DNS server.
> 
>> Does output case preservation refer to something else? All I observe
>> is that tools like dig return the latter when I run 'dig IETF.org'.
> 
> Right. The deployed DNS generally conforms to this RFC.
> 
>> Maybe an errata is not the right place to ask for clarification but
>> given the name of the RFC, I would expect to find a clear answer to
>> this question in the RFC.
> 
> Well, I have no problem with the theory that any successor document to
> this RFC should be clearer on this point.
> 
>> 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.
> 
> I'm not sure about the details of "errata" status but I think this
> should end up in the "hold for future documentation" or whatever the
> usual formula is. The RFC isn't wrong but is arguably unclear for some
> readers.
> 
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 33896 USA
> d3e3e3@gmail.com
> 
>> --------------------------------------
>> 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