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

From: RFC Errata System <[email-masked]>
Date: Mon, 4 Jan 2021 05:41:29 -0800 (PST)

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:
https://www.rfc-editor.org/errata/eid6361

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Kaspar Etter <[email-masked]>
Date Reported: 2020-12-22
Held by: Eric Vyncke (IESG)

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.

-- verifier note --
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.

--------------------------------------
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: Dave Lawrence <[email-masked]>
Date: Mon, 4 Jan 2021 14:15:59 -0500

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.

---

From: Kaspar Etter <[email-masked]>
Date: Mon, 4 Jan 2021 22:26:10 +0100

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? 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.
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. 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.
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 <[email-masked]> wrote:
>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Jan 2021 11:29:08 -0500

Hi,

See below.

> 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 would be fine with the suggested wording change above.

> 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…

This RFC was not intended to push for or require any particular change
in case handling.

> 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. If this is not possible, simply use the…

Maybe. I think question case in responses in the same as in the query.

> 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 incr…

This RFC was not intended to push for or require any particular change
in case handling.

> 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. Ther…

While I might agree that the current situation is inelegant, things
work fine so I'm not sure it would be worth trying to mandate
different behavior. Such a mandate would, in any case, take many many
years, quite possibly decades, before it even approached being
universally applied.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 7 Jan 2021 16:34:01 +1100

> On 5 Jan 2021, at 08:26, Kaspar Etter <[email-masked]> wrote:
> 
> 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:

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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]