From nobody Tue Dec 22 03:29:30 2020 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 203773A0FEC for ; Tue, 22 Dec 2020 03:29:29 -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, RCVD_IN_DNSWL_BLOCKED=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 QEv1NuCdGflv for ; Tue, 22 Dec 2020 03:29:27 -0800 (PST) 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 DB0CC3A0FEB for ; Tue, 22 Dec 2020 03:29:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 18004F40769; Tue, 22 Dec 2020 03:29:11 -0800 (PST) To: Donald.Eastlake@motorola.com, ek.ietf@gmail.com, evyncke@cisco.com, ogud@ogud.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: me@kasparetter.com, dnsext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201222112911.18004F40769@rfc-editor.org> Date: Tue, 22 Dec 2020 03:29:11 -0800 (PST) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 11:29:29 -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: https://www.rfc-editor.org/errata/eid6361 -------------------------------------- Type: Technical Reported by: Kaspar Etter 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? 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. 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'. 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. 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 Dec 22 20:15:04 2020 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 6F5443A0062 for ; Tue, 22 Dec 2020 20:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCooagpiyKgC for ; Tue, 22 Dec 2020 20:15:00 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92233A005D for ; Tue, 22 Dec 2020 20:15:00 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id k8so13923364ilr.4 for ; Tue, 22 Dec 2020 20:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BE9aMgA59t92gtdA0TOVCIc3j2BnDsI64o5oYhL6cCE=; b=cNldGuAm57Wb3vLAbFrF064JHt6e/pZZpKxQnY2p0HHU1J2Wm/cpt+hzbQ2on7gOzq 1x/yE1HcSFql2RxyX1c9tgKDRzzA52GeYSJxHOnG8ZJHzxOnYwq3ciYkZfCxwom0os82 SQ96BnmzQ683PnQngS42VpvVJVnjnNs2xe1W/FywqFIaGTb5TfwVZVDGz16Yerhz9ker t8+87IrY/QL79deqC44ZX8f2G4C6aWCYjMKWQy0j2aerhyFUNNQUc0LLks9Bt50urLDL LCixg1oGbPSsQJe+oooGnGb4rwyLNj0Gu2Cy7zN/DegAi0NQ4UHuN/hg07TEXrfIRZMF YA4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BE9aMgA59t92gtdA0TOVCIc3j2BnDsI64o5oYhL6cCE=; b=EjPO3a6YshsIKA9bZENHOB4UL0E3CRi3hsV2p8CnF2yxGL0Gy30I2bByRBOXgk0c+u y0AxwLyyYDEt92HPfWnCRg/br4+IFKLQ3opDOeViQCBdZln3VfALYzveBY1qDrNWPKjF q6cg+kdtp/2d6Mg68T7MGlR8nJ2TKgzRu0dA39U1UjU5kvISql78Dva50qgz6qo1CvcD bBPt4pfTgg7M5CCQxprk7Bpg5d0KTRdkJw9BWIHRVCrKOoS874QNrX73Ixga1x7ZBUn/ TB8j3FMvWVB6MkNQPEdZ6UvbhWKfFg/nKOwmDcqUehJTJJRByHWyR1Zr7td5BM0C5ECK IH8Q== X-Gm-Message-State: AOAM5328Z0prswtjzovjXO+x2o8fcz56Q55Enzr10NQBQ1E6U2/gWtjm 9/q6W+iNVo9DeOtjlhE8HkceMAD7WQODFgx1BOM= X-Google-Smtp-Source: ABdhPJywpeHLX8knuE2WLAHN9HBV0hocr2JfcgQ2zG1cA85lsukaNxRN9EWboMgnC5Dzxcly8O2xIzE6w+YrZtAkSZk= X-Received: by 2002:a92:4089:: with SMTP id d9mr20524611ill.199.1608696899584; Tue, 22 Dec 2020 20:14:59 -0800 (PST) MIME-Version: 1.0 References: <20201222112911.18004F40769@rfc-editor.org> In-Reply-To: <20201222112911.18004F40769@rfc-editor.org> From: Donald Eastlake Date: Tue, 22 Dec 2020 23:14:48 -0500 Message-ID: To: RFC Errata System Cc: Eastlake III Donald-LDE008 , Erik Kline , "Eric Vyncke (evyncke)" , Olafur Gudmundsson , Andrew Sullivan , me@kasparetter.com, IETF DNSEXT WG Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 04:15:03 -0000 Hi, I am the author of RFC 4343. See below. On Tue, Dec 22, 2020 at 6:29 AM RFC Errata System 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 > > 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 From me@kasparetter.com Wed Dec 23 00:51:35 2020 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 84AF13A0C7C for ; 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 ; 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 ; 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 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: Cc: RFC Errata System , Eastlake III Donald-LDE008 , Erik Kline , "Eric Vyncke (evyncke)" , Olafur Gudmundsson , Andrew Sullivan , IETF DNSEXT WG To: Donald Eastlake References: <20201222112911.18004F40769@rfc-editor.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 08:54:30 -0000 --Apple-Mail=_12E0C160-E820-4D00-958C-4432B9EC505B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mr. Eastlake, Thanks a lot for the quick reply. Just to make sure that there=E2=80=99s = no misunderstanding: If I figured it out (i.e. I should receive the = capitalization of the label as it is in the server=E2=80=99s database in = DNS responses), then the deployed DNS DOESN=E2=80=99T conform to this = RFC. Examples: dig IETF.org =3D> IETF.org in the = answer section of the DNS response dig ietf.org =3D> 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=E2=80=99s an API that is independent of my local configuration: https://dns.google/resolve?name=3DIETF.org&type=3DA = =3D> IETF.org = in response https://dns.google/resolve?name=3Dietf.org&type=3DA = =3D> ietf.org = in response And here is another public DNS API: curl -H 'accept: application/dns-json' = 'https://cloudflare-dns.com/dns-query?name=3DIETF.org&type=3DA = ' = =3D> IETF.org in response curl -H 'accept: application/dns-json' = 'https://cloudflare-dns.com/dns-query?name=3Dietf.org&type=3DA = ' =3D> = 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=E2=80=9D, = 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=E2=80=99s the point of case preservation on input if = there=E2=80=99s 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=E2=80=9D is fine = for me. Best regards, Kaspar > On 23 Dec 2020, at 05:14, Donald Eastlake wrote: >=20 > Hi, >=20 > I am the author of RFC 4343. See below. >=20 > On Tue, Dec 22, 2020 at 6:29 AM RFC Errata System > wrote: >> 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: >> https://www.rfc-editor.org/errata/eid6361 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Kaspar Etter >>=20 >> Section: 4.1 >>=20 >> Original Text >> ------------- >> No "case conversion" or "case folding" is done during such output >> operations, thus "preserving" case. >>=20 >> Corrected Text >> -------------- >> ? >>=20 >> Notes >> ----- >=20 >> Whose case is preserved? The case of the label in the DNS query or >> the case of the label in the DNS database? >=20 > The earlier text in Section 4.1 is intended to indicate it is the > "database". >=20 >> 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. >=20 > 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. >=20 >> 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'. >=20 > Right. The deployed DNS generally conforms to this RFC. >=20 >> 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. >=20 > Well, I have no problem with the theory that any successor document to > this RFC should be clearer on this point. >=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 >> can log in to change the status and edit the report, if necessary. >=20 > 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. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 33896 USA > d3e3e3@gmail.com >=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 --Apple-Mail=_12E0C160-E820-4D00-958C-4432B9EC505B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Mr. Eastlake,

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

Examples:
dig IETF.org =3D> IETF.org in the answer section of the DNS = response
dig ietf.org =3D> 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=E2=80=99s an API that is independent of my = local configuration:
https://dns.google/resolve?name=3DIETF.org&type=3DA&nbs= p;=3D> IETF.org in = response
https://dns.google/resolve?name=3Dietf.org&type=3DA&nbs= p;=3D> ietf.org in = response

And here is another public DNS = API:
curl = -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=3DIETF.org&type=3D= A' =3D> = IETF.org in = response
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=3Dietf.org&type=3D= A' =3D> 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=E2=80=9D, 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=E2=80=99s = the point of case preservation on input if there=E2=80=99s 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=E2=80=9D 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =   +1-508-333-2270 (cell)
2386 Panoramic Circle, = Apopka, FL 33896 USA
d3e3e3@gmail.com

--------------------------------------
RFC4343 (draft-ietf-dnsext-insensitive-06)
--------------------------------------
Title =             &n= bsp; : Domain Name System (DNS) Case Insensitivity Clarification
Publication Date    : January 2006
Author(s) =           : D. = Eastlake 3rd
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: DNS Extensions
Area =             &n= bsp;  : Internet
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_12E0C160-E820-4D00-958C-4432B9EC505B-- From nobody Mon Dec 28 10:42:33 2020 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 7CF853A0CEE for ; Mon, 28 Dec 2020 10:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Xm0QhAJNt2ns for ; Mon, 28 Dec 2020 10:42:29 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422353A0CEA for ; Mon, 28 Dec 2020 10:42:29 -0800 (PST) Received: from bikeshed.isc.org (unknown [IPv6:2001:4f8:1:f::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F0E633BD531; Mon, 28 Dec 2020 18:42:05 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 908422BFF3; Mon, 28 Dec 2020 18:42:05 +0000 (UTC) Date: Mon, 28 Dec 2020 18:42:05 +0000 From: Evan Hunt To: Kaspar Etter Cc: Donald Eastlake , Eastlake III Donald-LDE008 , IETF DNSEXT WG , Erik Kline , "Eric Vyncke (evyncke)" , Olafur Gudmundsson , RFC Errata System Message-ID: <20201228184205.GA6718@isc.org> References: <20201222112911.18004F40769@rfc-editor.org> <611DB60D-9BA1-404C-801B-37374B653255@kasparetter.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <611DB60D-9BA1-404C-801B-37374B653255@kasparetter.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 18:42:32 -0000 On Wed, Dec 23, 2020 at 09:51:25AM +0100, Kaspar Etter wrote: > 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 => IETF.org in the answer section of the DNS response > dig ietf.org => ietf.org in the answer section of the DNS response This has been ambiguous for a long time. If you check the authoritative servers for ietf.org, the answer section is capitalized as specified in the zone database, not matching the question: $ dig +noall +answer @ns1.ams1.afilias-nst.info. IETF.org ietf.org. 1800 IN A 4.31.198.44 However, some servers use case-insensitive name compression in their responses. Differently-capitalized versions of the same name are treated as duplicates, so if IETF.org appears in the question section, the answer section will refer back to that. In my view, this behavior is incorrect, but it's commonplace. I'm not sure whether this helps with the issue at hand, I just thought the additional context might be useful. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Dec 28 13:17:37 2020 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 75CCE3A0DE6 for ; Mon, 28 Dec 2020 13:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bQZFPF3UM-H for ; Mon, 28 Dec 2020 13:17:34 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 A75873A0DDE for ; Mon, 28 Dec 2020 13:17:34 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id 75so10497432ilv.13 for ; Mon, 28 Dec 2020 13:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+A7rW9SCNcJxDS/gEQVIH7CYkvucxUg5V4CGHEKkZ8o=; b=T0wKcV0+8p3GfB0Bzw/a5zRXGRv8lvyqQYLVvsjchhCFzIhmO2LI/b9qm0T7SC1I3E +GLbOxSZOtUgSgZ/8KfpIo84OO8RQQcmx8WasXqSCYCIkweA2d0TCOOLVuIG9Z5VAuj1 QjcBc3avT5nVPLl00hj8KUYMS/qzRMfWmOkC3ll3eu7oU3MCiaSM1shw8c5Nt0frxaW7 mdrlESemUJqcXmUorFCZBkHcOkpR7Z88PXweQiAUYzm/JMggNEiruehaiZGmgBrIgzdO R6WXFZfuKc8MuQjlh9g+ifuMJ660MIk5HPekHjac7lqjBMs5K5sXJK/EJjqVkK7vk8sh bYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+A7rW9SCNcJxDS/gEQVIH7CYkvucxUg5V4CGHEKkZ8o=; b=giBKkix8tsIyeZQN5NKJ5bp0V34Squx7dI/VH5LIw/l6LO3RDXKgUfLHbXSq7TzLNe +5pBo8fC5z/se3/8yzaNDOkqPdfazMMsEyWBjCPf8DMFfPVttzjLxnHkjys57Q8rth4G CC+tpwvbQYaytOZfgT7Kvg2EKvzHrQ7dUdP2DGfxPS/MPdBRonYXH8LwbXBXLPyg6/d5 cpuv2II1dEUDOY993Pt01GpMO26O0+Ha5d0MbcFGWmUlxOOjTp00iU4lNzmDeyLqc3m8 fbvOHp/oW+QY4yBQL6GRXzxpsxCfjOUInyoiBIRwyQh8pOEgeuCVEUlb2ie9CyfhJDZl rooA== X-Gm-Message-State: AOAM532D55Wkd0pL6K0TZd6d7C6gOeFlVUbqQ5tMmbjCK25YmVgpWCOw MVhCNJwKHjphP79OkfyCDcNweZSU6sfqxtuwcXKORz69u1Q= X-Google-Smtp-Source: ABdhPJxr8fK+buZJiPv9hp1M1jSrh07JKFWnM9kBpaBUDch66S7fyxXUwLyfLSXOMRt8r12LTK8hYi03WZ68PwlujTQ= X-Received: by 2002:a92:4089:: with SMTP id d9mr40639019ill.199.1609190253901; Mon, 28 Dec 2020 13:17:33 -0800 (PST) MIME-Version: 1.0 References: <20201222112911.18004F40769@rfc-editor.org> <611DB60D-9BA1-404C-801B-37374B653255@kasparetter.com> <20201228184205.GA6718@isc.org> In-Reply-To: <20201228184205.GA6718@isc.org> From: Donald Eastlake Date: Mon, 28 Dec 2020 16:17:22 -0500 Message-ID: To: Evan Hunt Cc: Kaspar Etter , Eastlake III Donald-LDE008 , IETF DNSEXT WG , Erik Kline , "Eric Vyncke (evyncke)" , Olafur Gudmundsson , RFC Errata System Content-Type: multipart/alternative; boundary="00000000000075bd9105b78ccd84" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 21:17:37 -0000 --00000000000075bd9105b78ccd84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the recent replies. See below. On Mon, Dec 28, 2020 at 1:42 PM Evan Hunt wrote: > > On Wed, Dec 23, 2020 at 09:51:25AM +0100, Kaspar Etter wrote: > > Thanks a lot for the quick reply. Just to make sure that there=E2=80=99= s no > > misunderstanding: If I figured it out (i.e. I should receive the > > capitalization of the label as it is in the server=E2=80=99s database i= n DNS > > responses), then the deployed DNS DOESN=E2=80=99T conform to this RFC. > > Examples: > > dig IETF.org =3D> IETF.org in the answer section of the DNS response > > dig ietf.org =3D> ietf.org in the answer section of the DNS response > > This has been ambiguous for a long time. If you check the authoritative > servers for ietf.org, the answer section is capitalized as specified in > the zone database, not matching the question: > > $ dig +noall +answer @ns1.ams1.afilias-nst.info. IETF.org > ietf.org. 1800 IN A 4.31.198.44 > > However, some servers use case-insensitive name compression in their > responses. Differently-capitalized versions of the same name are treated as > duplicates, so if IETF.org appears in the question section, the answer > section will refer back to that. In my view, this behavior is incorrect, > but it's commonplace. Right. "correctness" is in the eye of the beholder but all this pointed out in RFC 4343 in the Section 4.1 which is the target of this errata: ... No "case conversion" or "case folding" is done during such output operations, thus "preserving" case. However, to optimize output, indirect labels may be used to point to names elsewhere in the DNS answer. In determining whether the name to be pointed to (for example, the QNAME) is the "same" as the remainder of the name being optimized, the case insensitive comparison specified above is done. Thus, *such optimization may easily destroy the output preservation of case*. This type of optimization is commonly called "name compression". (bold face added) > I'm not sure whether this helps with the issue at hand, I just thought > the additional context might be useful. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. --00000000000075bd9105b78ccd84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the recent replies. See below.
On Mon, Dec 28, 2020 at 1:42 PM Evan Hunt <each@isc.org> wrote:
>
> On Wed, Dec 23, 2020 at 09= :51:25AM +0100, Kaspar Etter wrote:
> > Thanks a lot for the quick= reply. Just to make sure that there=E2=80=99s no
> > misunderstan= ding: If I figured it out (i.e. I should receive the
> > capitaliz= ation of the label as it is in the server=E2=80=99s database in DNS
>= > responses), then the deployed DNS DOESN=E2=80=99T conform to this RFC= .
> > Examples:
> > dig IETF.org <http://ietf.org/> =3D> IETF.org <http://ietf.org/> in the answer section of the DNS response=
> > dig ietf.org <http://ietf.org/> =3D> ietf.org <http://ietf.org/> i= n the answer section of the DNS response
>
> This has been ambi= guous for a long time.=C2=A0 If you check the authoritative
> servers= for ietf.org, the answer section is capita= lized as specified in
> the zone database, not matching the question:=
>
> =C2=A0 =C2=A0$ dig +noall +answer @ns1.ams1.afilias-nst.info. IETF.org
> =C2= =A0 =C2=A0ietf.org. =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A01800 =C2=A0 =C2=A0IN =C2=A0 =C2=A0 =C2=A0A =C2=A0 =C2= =A0 =C2=A0 4.31.198.44
>
> However, some servers use case-insen= sitive name compression in their
> responses. Differently-capitalized= versions of the same name are treated as
> duplicates, so if IETF.or= g appears in the question section, the answer
> section will refer ba= ck to that.=C2=A0 In my view, this behavior is incorrect,
> but it= 9;s commonplace.

Right. "correctness" is in the eye of the= beholder but all this pointed out in RFC 4343 in the Section 4.1 which is = the target of this errata:

=C2=A0 =C2=A0...=C2=A0 =C2=A0No "cas= e conversion" or "case folding" is done
=C2=A0 =C2=A0duri= ng such output operations, thus "preserving" case.=C2=A0 However,= to
=C2=A0 =C2=A0optimize output, indirect labels may be used to point t= o names
=C2=A0 =C2=A0elsewhere in the DNS answer.=C2=A0 In determining w= hether the name to be
=C2=A0 =C2=A0pointed to (for example, the QNAME) i= s the "same" as the remainder of
=C2=A0 =C2=A0the name being o= ptimized, the case insensitive comparison specified
=C2=A0 =C2=A0above i= s done.=C2=A0 Thus, such optimization may easily destroy the output
= =C2=A0 =C2=A0preservation of case.=C2=A0 This type of optimization is c= ommonly called
=C2=A0 =C2=A0"name compression".
(bold face = added)

> I'm not sure whether this helps with the issue at h= and, I just thought
> the additional context might be useful.

= Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2= =A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703= USA
=C2=A0d3e3e3@gmail.com
<= br>> --
> Evan Hunt -- each@isc.or= g
> Internet Systems Consortium, Inc.
--00000000000075bd9105b78ccd84--