RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 2647
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Sam Bretheim
Date Reported: 2010-11-29
Verifier Name: Brian Haberman
Date Verified: 2012-04-30

Section 2.1 says:

   ("."), which can be expressed as and \046 or \.  It is advisable to

It should say:

   ("."), which can be expressed as \046 or \.  It is advisable to

Status: Held for Document Update (3)

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 6361
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Kaspar Etter
Date Reported: 2020-12-22
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-04

Section 4.1 says:

No "case conversion" or "case folding" is done during such output operations, thus "preserving" case.

It should say:

?

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.

Errata ID: 7290
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2022-12-26
Held for Document Update by: Murray Kucherawy
Date Held: 2023-06-01

Section 5 says:

A scheme has been adopted for "internationalized domain names" and "internationalized labels" as described in [RFC3490, RFC3454, RFC3491, and RFC3492]. It makes most of [UNICODE] available through a separate application level transformation from internationalized domain name to DNS domain name and from DNS domain name to internationalized domain name. Any case insensitivity that internationalized domain names and labels have varies depending on the script and is handled entirely as part of the transformation described in [RFC3454] and [RFC3491], which should be seen for further details.

It should say:

A scheme has been adopted for "internationalized domain name labels" (and "internationalized domain names" (IDNs) more generally) as described in [RFC5890, RFC5891, RFC5893, RFC5894], and documents that update and clarify them. It makes selected [UNICODE] characters and code point sequences available through a separate application level transformation from internationalized domain name to DNS domain name and from DNS domain name to internationalized domain name. Because of ambiguities among possible definitions of case and case relationships once one moves beyond ASCII, the IDNA specifications prohibit characters that could be interpreted as "upper case", making discussions of case insensitivity irrelevant. See the documents cited for further details.

Notes:

In trying to research something else, I reread RFC 4343. It still references IDNA2003 (RFC 3490ff) as the authority for IDNs and says a few things that are misleading, or worse, under IDNA2008. In retrospect, RFC 5890 should have updated 4343 and adjusted the language of its Section 5. The author of 5890 clearly screwed up (i.e., mea culpa) and the WG and broader IETF review, especially by DNS-related groups, did not catch the problem.

The "corrected" text above is merely an example of how this might be remedied. The issue is clearly (at least to me) one to be "held for document update" of either RFC 4343 or 5890 but it seems worth inserting a pointer into the errata list to warn those who might want to look for it.

Errata ID: 5112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rich Tom
Date Reported: 2017-09-12
Held for Document Update by: Warren Kumari
Date Held: 2017-09-13

Section 3 says:

comparisons on name lookup for DNS queries should be case insensitive

It should say:

comparisons on name lookup for DNS queries must be case insensitive

Notes:

--- Original report ---
Some authoritative DNS servers and/or mitigation devices/software silently drop queries that have uppercase letters in them. Furthermore, the clarification of the case insensitive comparison in the following two sentences after that particular sentence use the term MUST. I suspect some readers of the RFC are reading the word "should" and aren't reading the rest of the paragraph.

---- WK Update ----
The full quote is: "According to the original DNS design decision, comparisons on name
lookup for DNS queries should be case insensitive [STD13]. ", and the title of this (RFC4343) is "Domain Name System (DNS) Case Insensitivity Clarification" -- seeing as the whole point of this document is to clarify the original spec, I think that readers will read the RFC2119 bits.

However, I do agree that this could be better worded, and future updates of this document should probably reword this to make it clearer.

Status: Rejected (1)

RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006

Note: This RFC has been updated by RFC 5890

Source of RFC: dnsext (int)

Errata ID: 119
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bruce Lilly
Date Reported: 2006-02-26
Rejected by: Brian Haberman
Date Rejected: 2012-04-30

Section 1 says:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

It should say:

   The key words "MUST" and "MAY" in this document are to be
   interpreted as described in [RFC2119].

Notes:


Other than in the above-quoted sentence, there are no
instances of "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD",
"SHOULD NOT", "RECOMMENDED", or "OPTIONAL" in the RFC (and the
instances above surely cannot be interpreted as described in RFC
2119; they are mere labels in the context of that sentence).
--VERIFIER NOTES--
The keyword paragraph is standard, and although words are mentioned that are later not used, this is not an error.

Report New Errata



Advanced Search