Re: [dnsext] [Errata Held for Document Update] RFC4343 (6361)

Mark Andrews <marka@isc.org> Thu, 07 January 2021 05:34 UTC

Return-Path: <marka@isc.org>
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 0758A3A083E; Wed, 6 Jan 2021 21:34:08 -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 cLnKb_W4-Qjr; Wed, 6 Jan 2021 21:34:05 -0800 (PST)
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 8AD5C3A07F7; Wed, 6 Jan 2021 21:34:05 -0800 (PST)
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 330593BD553; Thu, 7 Jan 2021 05:34:05 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1E076160081; Thu, 7 Jan 2021 05:34:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D804160080; Thu, 7 Jan 2021 05:34:05 +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 fcnOeCx2C1Jt; Thu, 7 Jan 2021 05:34:04 +0000 (UTC)
Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 88C9E160054; Thu, 7 Jan 2021 05:34:03 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <EEBC7569-CC6C-48FA-AD71-4C47C1F8F87E@kasparetter.com>
Date: Thu, 07 Jan 2021 16:34:01 +1100
Cc: Dave Lawrence <tale@dd.org>, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, dnsext@ietf.org, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, iesg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA576190-824A-4A8B-979A-54E0F8802278@isc.org>
References: <20210104134129.E9403F40721@rfc-editor.org> <24563.26991.309998.571334@gro.dd.org> <EEBC7569-CC6C-48FA-AD71-4C47C1F8F87E@kasparetter.com>
To: Kaspar Etter <me@kasparetter.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/fAcuExhkOAQ_ZiO7JkjWj2ycT7M>
Subject: Re: [dnsext] [Errata Held for Document Update] 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: Thu, 07 Jan 2021 05:34:08 -0000


> On 5 Jan 2021, at 08:26, Kaspar Etter <me@kasparetter.com> wrote:
> 
> Thank you for proposing an improved wording. As the author of the errata, I have to say that the addition of “on input octets” would not have helped me. The statement in the errata system is correct: My “errata” was simply a “request for clarification” and not a “request for correction”.
> 
> The following response from Evan Hunt was really helpful for me:
> 
>> 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 agree that the single sentence likely doesn’t give enough context for the person who will update this RFC in the future. If I have to propose a concrete change, I would go for the following:
> 
> Old:
> 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.
> 
> New:
> No "case conversion" or "case folding" is done during such output operations, thus "preserving” the case of the domain name as it is stored in the database of the authoritative name server.
> However, to optimize output, indirect labels may be used to point to names elsewhere in the DNS answer, typically from the answer section to the question section.
> 
> I think my confusion comes from the fact that the current situation is not really satisfying in my opinion. What’s the point of output (and thus also input) case preservation in theory if you rarely get case preservation in practice?

Firstly while fixes to implementations in the DNS take a long time to filter through, they do filter through.  There is a misconception that change in the DNS is hard to do.  It isn’t.  What hard to do is getting rid of the myth that change in the DNS is hard to do.

See the difference between talking to a case preserving server to one which doesn’t.  Note every server should already be case preserving as that is a STD-13 requirement.

[beetle:~/git/bind9] marka% dig A.RooT-SerVers.Net @c.root-servers.net +noadd +nocookie

; <<>> DiG 9.15.4 <<>> A.RooT-SerVers.Net @c.root-servers.net +noadd +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60341
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 26
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;A.RooT-SerVers.Net.		IN	A

;; ANSWER SECTION:
a.root-servers.net.	3600000	IN	A	198.41.0.4

;; AUTHORITY SECTION:
root-servers.net.	3600000	IN	NS	d.root-servers.net.
root-servers.net.	3600000	IN	NS	h.root-servers.net.
root-servers.net.	3600000	IN	NS	f.root-servers.net.
root-servers.net.	3600000	IN	NS	k.root-servers.net.
root-servers.net.	3600000	IN	NS	g.root-servers.net.
root-servers.net.	3600000	IN	NS	m.root-servers.net.
root-servers.net.	3600000	IN	NS	b.root-servers.net.
root-servers.net.	3600000	IN	NS	i.root-servers.net.
root-servers.net.	3600000	IN	NS	l.root-servers.net.
root-servers.net.	3600000	IN	NS	e.root-servers.net.
root-servers.net.	3600000	IN	NS	j.root-servers.net.
root-servers.net.	3600000	IN	NS	c.root-servers.net.
root-servers.net.	3600000	IN	NS	a.root-servers.net.

;; Query time: 184 msec
;; SERVER: 192.33.4.12#53(192.33.4.12)
;; WHEN: Thu Jan 07 16:10:17 AEDT 2021
;; MSG SIZE  rcvd: 843

[beetle:~/git/bind9] marka% 


[beetle:~/git/bind9] marka% dig A.RooT-SerVers.Net @a.root-servers.net +noadd +nocookie

; <<>> DiG 9.15.4 <<>> A.RooT-SerVers.Net @a.root-servers.net +noadd +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55706
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 26
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;A.RooT-SerVers.Net.		IN	A

;; ANSWER SECTION:
A.RooT-SerVers.Net.	3600000	IN	A	198.41.0.4

;; AUTHORITY SECTION:
RooT-SerVers.Net.	3600000	IN	NS	A.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	b.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	c.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	d.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	e.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	f.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	g.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	h.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	i.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	j.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	k.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	l.RooT-SerVers.Net.
RooT-SerVers.Net.	3600000	IN	NS	m.RooT-SerVers.Net.

;; Query time: 126 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Thu Jan 07 16:01:24 AEDT 2021
;; MSG SIZE  rcvd: 825

[beetle:~/git/bind9] marka% 


> I see the following options to improve the situation:
> 1. Just say that an authoritative name server can store and return domain names in any capitalization it likes instead of indicating that the case should be preserved.
> 2. Discourage name servers (with a “SHOULD NOT”?) from pointing from the answer section to the question section of the DNS response so that the capitalization of the DNS answer can actually be used to display the domain name to the user as the owner of the domain name intended it.

It's not a question point to particular sections or not.  It’s a question of looking at the case of the domain name that is to (potentially) converted to a compression point and the case of the domain name at that target.  If they are the same you replace the domain name with the compression pointer.  If they are not you add the first label and repeat the test.

When adding the answer section in the case sensitive response the following domains exist as targets:

A.RooT-SerVers.Net.
RooT-SerVers.Net.
Net.

When you get to adding the authority section the following domains exist as targets:

A.RooT-SerVers.Net.
RooT-SerVers.Net.
Net.
a.root-servers.net.
root-servers.net.
net.

> 3. Preserve “name compression” and case by encouraging name servers to point from the question section to the answer section instead of the other way around.

This is not permitted.  Legal compression pointers only point towards the start of the message.  This is actually enforced by clients.

> If this is not possible, simply use the capitalization of the answer section in the question section so that name compression remains the same. As far as I can tell, the RFC doesn’t say anything about whether the question section has to preserve the case of the DNS query, which is probably also something that should be addressed in a future iteration of this RFC.

Why? Are we really worried about a couple of bytes of difference due to having two different representations of the QNAME in the response.  The difference above is 18 bytes.

> 4. Encourage domain names to be stored, queried, and returned in lowercase to make the behavior of ASCII domain names more similar to the behavior of IDNA2008 domain names. (Assuming that IDNs increase in importance over time, I see little reason to treat the subset of ASCII domain names differently in the long term.) Encouraging that domain names are displayed in lowercase might also be desirable in the context of mitigating homograph attacks.
> 
> I understand that this debate is beyond the scope of this errata but given the comment by Evan Hunt I have the impression that other people share my dissatisfaction with the current situation. Therefore, it might make sense to have (or revisit?) this debate in the future and then supersede RFC 4343 accordingly (instead of just changing the wording in Section 4.1.).
> 
> Best regards,
> Kaspar
> 
> 
>> On 4 Jan 2021, at 20:15, Dave Lawrence <tale@dd.org> wrote:
>> 
>> RFC Errata System writes:
>>> After discussion with the RFC author and the errata author, the
>>> conclusion is that the RFC isn't wrong but is arguably unclear for
>>> some readers. 
>> 
>> Agreed that it could be a little confusing when focusing on that one
>> sentence, despite the surrounding paragraphs trying to fill the
>> context.  Was there new proposed text?  Is this sufficient, given the
>> surrounding text?
>> 
>> Old:  No "case conversion" or "case folding" is done
>>     during such output operations, thus "preserving" case.  
>> 
>> New:  No "case conversion" or "case folding" is done on input octets
>>     during such output operations, thus "preserving" case.  
> 
> _______________________________________________
> 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