IETF Logo Mail Archive

Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 07 February 2022 15:45 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6C3A0CCC for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 07:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=yitter.info header.b=juNGuKla; dkim=pass (1024-bit key) header.d=yitter.info header.b=kaw/RugF
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 CvPnOvtYJNLH for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 07:45:51 -0800 (PST)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F370B3A0C86 for <behave@ietf.org>; Mon, 7 Feb 2022 07:45:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id CD565BD5C8 for <behave@ietf.org>; Mon, 7 Feb 2022 15:45:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644248719; bh=fu6t9JahbHWlMTNfx65ZNQqTJ0X2tXnTZm7eH/TLLfM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=juNGuKlaSV1PCQk2ITIUSzH7s0G5o8Od2eQz/7b3FlsN9aU4Uqdqbn1KczFERhufo B6Z9UEJhAMGPQT/CTZbI2StOFqSbSd3F2j5AhElnyuM8Yp/m8A33VTQq1HYsJGIwnk QI6gQLmo0wlWXvFqShMJSv0sciwvX/2RIDsNo4Go=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDIS-M3yY4xc for <behave@ietf.org>; Mon, 7 Feb 2022 15:45:18 +0000 (UTC)
Date: Mon, 07 Feb 2022 10:45:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644248718; bh=fu6t9JahbHWlMTNfx65ZNQqTJ0X2tXnTZm7eH/TLLfM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kaw/RugFcbdhQdFeB3xTjoPUmU8bdVqQQgNUXuok3CJfnzvz2GuOluS2S4ithutHk jqmhxflsthBGHyGPxB9IqrnLNSbhQDHzA1gFRKtWFxXOklCtIUdyan+dP2xaYBf8pj GCn/ONtUDqzC/SAn1Cy3+00j0BWS+iKUfXcHP6fk=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: behave@ietf.org
Message-ID: <20220207154516.qja5bfjtsxnpkvo6@crankycanuck.ca>
Mail-Followup-To: behave@ietf.org
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <ff858dee-a21a-a50d-72a5-da7915ac2de4@network-heretics.com> <71b5cdb0-78af-0f77-debc-84e178fe5e3a@posteo.de> <dc15ccc0-3a67-563d-cf0f-08dcc7575fd2@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <dc15ccc0-3a67-563d-cf0f-08dcc7575fd2@it.uc3m.es>
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/t8rB2xculySM1ykIXfaC0nj-Ls4>
Subject: Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 15:46:08 -0000

[ObDisclaimer: again, speaking just for myself]

On Mon, Feb 07, 2022 at 07:41:31AM +0100, marcelo bagnulo braun wrote:
>
>I guess one operative question is whether this issue can be dealt with 
>an errata or should require an update in the spec.

There is no error in the text of the RFC: it works as intended.  If people want to change DNS64 to parse TXT records and start fooling with the RDATA in there according to some heuristics, then that is a protocol change and not something that can be handled via errata.

The data types that DNS64 changes are well-defined types with well-defined semantics for the RDATA.  TXT records, by contrast, can contain whatever somebody wants, and there is no reaason to suppose that SPF is the only case where an IPv4 address might be in there.  The fact that SPF overloaded TXT to try to put structured data in it means that SPF needs to understand something about the data structure it is dealing with, so it's the SPF handler that needs to be made DNS64-aware just as a validating resolver behind DNS64 needs to be DNS64 aware.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.23.0 | Report a Bug | By Email