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

Donald Eastlake <d3e3e3@gmail.com> Mon, 28 December 2020 21:17 UTC

Return-Path: <d3e3e3@gmail.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 75CCE3A0DE6 for <dnsext@ietfa.amsl.com>; 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 <dnsext@ietfa.amsl.com>; 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 <dnsext@ietf.org>; Mon, 28 Dec 2020 13:17:34 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id 75so10497432ilv.13 for <dnsext@ietf.org>; 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> <CAF4+nEHUBiUxF_stf8_VPOipy=vOmwtDMrLaCmEQTz9nF3ibGQ@mail.gmail.com> <611DB60D-9BA1-404C-801B-37374B653255@kasparetter.com> <20201228184205.GA6718@isc.org>
In-Reply-To: <20201228184205.GA6718@isc.org>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 28 Dec 2020 16:17:22 -0500
Message-ID: <CAF4+nEHjj3ChmDfDLsR=yhpfd4BJQmxtvsx+y3H2Hd41gftMyw@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Cc: Kaspar Etter <me@kasparetter.com>, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, IETF DNSEXT WG <dnsext@ietf.org>, Erik Kline <ek.ietf@gmail.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Olafur Gudmundsson <ogud@ogud.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: multipart/alternative; boundary="00000000000075bd9105b78ccd84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/LSTcQFEPbo-b9PIexrlcnHRrYbM>
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: Mon, 28 Dec 2020 21:17:37 -0000

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’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
>
> 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
===============================
 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.