Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interoperability issues

[Mark Andrews <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]