Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

Oh dear, it's even worse than I thought. Is there an errata or update 
rfc for that?

On 2022-02-07 02:45, Mark Andrews wrote:
> Despite what you quote here, DNS64 is incompatible with DNSSEC because it hijacked the CD bit for a different purpose.  For a DNSSEC validator to work through another nameserver it needs to be able to send both CD=0 and CD=1
> requests WITHOUT the records being modified.  The DNS64 working group was told this at the time but refused to listen.
>
> CD=1 to handle bad time / bad trust anchors in the upstream nameservers.
> CD=0 to handle spoofed / expired responses being sent to the upstream nameservers.
>
> in BOTH cases the client validates the responses.  If the validation fails the first way, it should attempt the
> request again with the CD bit in the other state.  If the second query fails then you have an actual DNSSEC failure.
>
> Below was just wishful thinking upon behalf of the DNS64 working group.  They wanted a signal that meant the client is performing validation and refused to accept “if DO=1 then you have to assume the client is validating."
>
>     3.  A security-aware and non-validating DNS64 receives a query with
>         the DO bit set and the CD bit clear.  Such a resolver is not
>         validating responses, likely due to local policy (see [RFC4035],
>         Section 4.2).  For that reason, this case amounts to the same as
>         the previous case, and no validation happens.
>
> Making CD into a modify the response signal was/is incompatible with how DNSSEC uses CD.
>
> Mark
>
>> On 7 Feb 2022, at 12:07, Klaus Frank <[e-mail]> wrote:
>>
>>
>> On 2022-02-07 01:42, [e-mail] wrote:
>>> 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?
>>>
>> Basically by offloading it towards the DNS64 server.
>>
>> https://datatracker.ietf.org/doc/html/rfc6147#section-6.2
>>
>> 6.2.  DNSSEC Validators and DNS64
>>
>>     An existing DNSSEC validator (i.e., one that is unaware of DNS64)
>>     might reject all the data that comes from DNS64 as having been
>>     tampered with (even if it did not set CD when querying). *If it is**
>> **   necessary to have validation behind the DNS64, then the validator**
>> **   must know how to perform the DNS64 function itself*. Alternatively,
>>     the validating host may establish a trusted connection with a DNS64,
>>     and allow the DNS64 recursive resolver to do all validation on its
>>     behalf.
>>
>>> 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.
>>>
>> "special features" is exactly what I wanted to avoid. Also I don't know if it's strictly necessary to have a dedicated RFC for how to do the migration. Besides this issue with the SPF record it's basically the same as for any other server application. Use stateless NAT64 (aka. IPv4aaS) to have a dedicated public IPv4. Put that IPv4 (prefix) into the SPF record as usual. And for now disable the SPF validation for inbound mails. The only really noteworthy thing is with filtering stuff like SIEVE that these need to be updated to include their mapped IPv6 addresses or similar. Everything else just works because of NAT64 and DNS64...
>>
>>> 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 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spfbis
>> _______________________________________________
>> spfbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis