Re: [spfbis] RFC6147 and RFC7208 interoperability issues
william@leibzon.org Mon, 07 February 2022 00:42 UTC
Return-Path: <william@leibzon.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7E3A107C for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 16:42:15 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8h__nohijOfG for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 16:42:09 -0800 (PST)
Received: from relay4.hostedemail.com (relay4.hostedemail.com [64.99.140.36]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7AB3A107D for <spfbis@ietf.org>; Sun, 6 Feb 2022 16:42:09 -0800 (PST)
Received: from omf14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 52DC8219FD for <spfbis@ietf.org>; Mon, 7 Feb 2022 00:42:08 +0000 (UTC)
Received: from [HIDDEN] (Authenticated sender: william@leibzon.org) by omf14.hostedemail.com (Postfix) with ESMTPA id A52292D for <spfbis@ietf.org>; Mon, 7 Feb 2022 00:41:53 +0000 (UTC)
MIME-Version: 1.0
Date: Sun, 06 Feb 2022 16:42:07 -0800
From: william@leibzon.org
To: spfbis@ietf.org
In-Reply-To: <20220206224715.kzynnbwkt5a26wii@crankycanuck.ca>
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <8021771.rLJEViv2lv@localhost> <85cb8ec0-4316-c4db-4aed-2d49fda46f49@posteo.de> <45673006.FIhfuaby8d@localhost> <20220206224715.kzynnbwkt5a26wii@crankycanuck.ca>
Message-ID: <7ddee9f68efbef4bcf2dbfef69b0766a@leibzon.org>
X-Sender: william@leibzon.org
Content-Type: multipart/alternative; boundary="=_c9d161a7968064d7d4f327b4deb1f8b3"
X-Stat-Signature: 5etnwqtciamcrp58n7kj49texnpo1cnj
X-Rspamd-Server: rspamout01
X-Rspamd-Queue-Id: A52292D
X-Session-Marker: 77696C6C69616D406C6569627A6F6E2E6F7267
X-Session-ID: U2FsdGVkX1/yLZVVNDpXjQL2OBvSZ2dj2XfgzPQUjvo=
X-HE-Tag: 1644194513-346566
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/VlKO7eWoQtzJdvtqOuVquEXAc98>
Subject: Re: [spfbis] RFC6147 and RFC7208 interoperability issues
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 00:42:16 -0000
Yeah, I wasn't thrilled with the idea of SPF using TXT record way back when. It opened it for quite a few others who followed. Putting ip addresses there though is not something that is done for any other protocol or software I can immediately think of. I'm curious, how does DNS64 inter-operates with DNSSEC? Would that not break it and make DNSSEC folks very uncomfortable about what others could decide to do? I think it could be helpful to collect various protocol operational and similar issues for those running mail servers (and other servers) behind NAT64 and write informational RFC which would be soft of experimental best practice. I'd expect that some server software would have to add special features to be used in this setup. On 2022-02-06 14:47, Andrew Sullivan wrote: > Hi, > > I'm one of the primary offenders behind DNS64. I work for the Internet > Society but I am not speaking for them (or anyone eles) right now. > > On Sun, Feb 06, 2022 at 02:57:08PM -0500, Scott Kitterman wrote: > >> I think your original suggestion that an SPF record be modified by the >> DNS64 >> server to add ip6: mechanisms with <prefix> + <address> is a >> reasonable path >> forward, but I think it's really an RFC 6147 discussion, not so much >> RFC 7208. > > The problem with this is that it's importing the DNS64 intimate > knowledge of this protocol for TXT records, which means in effect that > DNS64 needs to start parsing arbitrary data in TXT records. (There is > a reason DNS weenies always got upset about ignoring the strong typing > in DNS, and this is an example of it.) > > DNS64, to be honest, was always sort of a hack that was intended to > make transition to v6 easier. It really basically depended on the > strong data typing of A, AAAA, and PTR records in order to give it > clear places to insert itself. "Look at every TXT record," doesn't > really support that plan. I never thought we were designing it for > long life or high degrees of robustness, and I think it is likely to be > extremely difficult to operate a modern mail server on v6-only > infrastructure and be able to talk to v4-only mail servers. In any > case, I guess it would be _possible_ to teach a DNS64 server to parse > and edit TXT records on the fly, but the idea that this is going to be > limited to SPF is, I suspect, a false hope. For that reason, my > reaction is that it wouldn't be a great idea to do. I nevertheless > sympathize with the desire, even though I am made nervous about the > implications. > >> It is not, however, without risks. RFC 7208 Section 3.4 gives advice >> on SPF >> record size. Your proposed approach would increase the record size, >> which, in >> theory, could be problematic. It might be that anything running on an >> IPv6 >> only network is modern enough that this isn't actually a problem. I >> don't >> know. > > I'd be especially worried about RRset size, because a lot of stuff in > contemporary operations is jammed into TXT records (all those > application keys, for instance). I can imagine cases where the change > could move the response size across the response size boundary, forcing > truncation and TCP fallback. > > Best regards, > > A
- [spfbis] RFC6147 and RFC7208 interoperability iss… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Marc Blanchet
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… John Levine
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Mark Andrews
- Re: [spfbis] RFC6147 and RFC7208 interoperability… John Levine
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Ángel
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [spfbis] RFC6147 and RFC7208 interoperability… John Levine
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… John Levine
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [spfbis] RFC6147 and RFC7208 interoperability… John Levine
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Andrew Sullivan
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Stuart D Gathman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Ángel
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Scott Kitterman
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Mark Andrews
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Klaus Frank
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Mark Andrews
- Re: [spfbis] RFC6147 and RFC7208 interoperability… william
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Alessandro Vesely
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Hector Santos
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Mark Andrews
- Re: [spfbis] RFC6147 and RFC7208 interoperability… Mark Andrews