Re: [spfbis] RFC6147 and RFC7208 interoperability issues
Mark Andrews <marka@isc.org> Thu, 10 February 2022 04:07 UTC
Return-Path: <marka@isc.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 22AA83A13B5; Wed, 9 Feb 2022 20:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=isc.org header.b=aYww0TrI; dkim=pass (1024-bit key) header.d=isc.org header.b=Gm+ctR0+
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 ZaQeXwWMn_sB; Wed, 9 Feb 2022 20:06:55 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1013A13B2; Wed, 9 Feb 2022 20:06:55 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 235213AB008; Thu, 10 Feb 2022 04:06:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 235213AB008
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1644466015; bh=9rTIkqkLOuroWXtieI20BXDvn6jOJAYQHMLiPm6ClFA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aYww0TrIONI8nvysplgEfIoP5z/dNGxL7a/id0ajVFIVgjNGdP6G14SHxDtFCfKLW olUj+X4Lyr35OenEYqfIELgH4o43s7pRR7dQbZX8AXk6yXvftniBN+IfBanHbU6G98 15rRO3Gc7vCwFhVQ8yb6pFYA6Idy2xirm86u3TG8=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 0BE19FE69D7; Thu, 10 Feb 2022 04:06:55 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id BF478FE69DC; Thu, 10 Feb 2022 04:06:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org BF478FE69DC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1644466014; bh=Rx7+VIpsd7yunbh8B+Ug5yBS9mEGWyi7r52W2unW464=; h=Mime-Version:From:Date:Message-Id:To; b=Gm+ctR0+TnP+B2z5gnByddrZJvNBMsf3FHEXu67PQv8pQNnYW9dAKPDY5AInksN/3 It+HOUanY5YCh3AMmAgkmfSKW9MtDtTuG59wzX/iEJivaPLuxaG9aBCwePSadgADUo oP7NKBIp63u2h/Fy+/cUJUjgayuvuQ79q+aGUhME=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VktHMqNSgex5; Thu, 10 Feb 2022 04:06:54 +0000 (UTC)
Received: from smtpclient.apple (n114-74-26-107.bla4.nsw.optusnet.com.au [114.74.26.107]) by zimbrang.isc.org (Postfix) with ESMTPSA id A9040FE69D7; Thu, 10 Feb 2022 04:06:53 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <96278466-0EFF-4931-8AA3-9B49FFAF77B3@isdg.net>
Date: Thu, 10 Feb 2022 15:06:51 +1100
Cc: Klaus Frank <klaus.frank@posteo.de>, spfbis@ietf.org, behave@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECED3F0C-8CDD-4209-9E2A-38AB6E6C8717@isc.org>
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <96278466-0EFF-4931-8AA3-9B49FFAF77B3@isdg.net>
To: Hector Santos <hsantos=40isdg.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/bcSeL6ZKHebHhXrigpGMY81Ztcg>
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: Thu, 10 Feb 2022 04:07:00 -0000
Unfortunately some resolver developers failed to read / understand RFC 1034. RFC 3597 provided a standard textual representation, which allowed nameservers to load and publish records that they didn’t know about. Handling of arbitrary records by resolvers was expected from the very beginning. New record types where expected from the very beginning. RFC 1034 3. General lookup function This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems. The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs. This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions. When the resolver performs the indicated function, it usually has one of the following results to pass back to the client: - One or more RRs giving the requested data. In this case the resolver returns the answer in the appropriate format. - A name error (NE). This happens when the referenced name does not exist. For example, a user may have mistyped a host name. - A data not found error. This happens when the referenced name exists, but data of the appropriate type does not. For example, a host address function applied to a mailbox name would return this error since the name exists, but no address RR is present. RFC 1035 The domain system is a mixture of functions and data types which are an official protocol and functions and data types which are still experimental. Since the domain system is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. The official protocol parts include standard queries, responses and the Internet class RR data formats (e.g., host addresses). Since the previous RFC set, several definitions have changed, so some previous definitions are obsolete. Mark > On 10 Feb 2022, at 04:36, Hector Santos <hsantos=40isdg.net@dmarc.ietf.org> wrote: > > You could do a independent draft tech note to show technical details, perhaps implementation details for SPF/DNS resolvers learning about IP6 related issues and coding requirements. > > In general, when dealing with unknown Resource Records (RR), the DNS server and client SHOULD be supporting RFC 3597: > > https://datatracker.ietf.org/doc/html/rfc3597 > > A small dig into RFC6147, I don’t see a reference to RFC3597. Maybe RFC6147 should be updated as well? > > See this 2012 thread I had with Microsoft when I was updating our Wildcat! SAP package for SPF RR support in its Wildcat! DNS client and local cache resolving API logic. We are not at IP6 but it sounds DNS64/NAT64 should review its level of support for RFC3597. > > https://social.technet.microsoft.com/Forums/Lync/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records > > > Hope any of this helps > > — > HLS > > > >> On Feb 6, 2022, at 1:09 PM, Klaus Frank <klaus.frank@posteo.de> wrote: >> >> Hi, >> >> we had some issues with SPF and a mail server that was behind NAT64+DNS64. I at first thought that it was just a misconfiguration. But after the DNS64 server seamed to work as intended I went to the implementation and the RFC. Thereby while reading RFC6147 I stumbled across section 5.3.3 which says "All other RRs MUST be returned unchanged." which is the cause of my issues. This section is basically ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64 implementations from addressing this limitation. >> >> Would it be possible to create an extension to RFC6147 that mandates SPF record rewrites as well? Otherwise Mail servers behind NAT64+DNS64 in IPv6 only environments won't be able to work as expected. >> >> Like: >> If the DNS64 server receives a SPF-record (within either the TXT-RR or the SPF-RR [RFC4408]) containing the "ip4" mechanism it MUST rewrites the ipv4 address according to the same rules as A-records are and synthesizes a new SPF record within the response that contains additional "ip6" entries. The original "ip4" should not be removed from the response. >> >> Sincerely, >> Klaus Frank > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [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