Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

[Keith Moore <[e-mail]>]

On 2/7/22 15:00, Klaus Frank wrote:

>
> On 2022-02-07 20:51, Keith Moore wrote:
>> On 2/7/22 14:37, Dan Wing wrote:
>>
>>> Could the SPF problem dissipate if SPF records only contained DNS 
>>> names and deprecate IP addresses?
>>
>> I suspect this just would just make SPF records even less reliable 
>> than they already are, because the DNS name adds an extra layer of 
>> indirection that also has a high probability of being wrong.
>
> Not really. Using DNS is already part of the SPF standard (section 
> 5.7) via "v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all":
>
>    The <target-name> might expand to
>    "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
>    decisions possible at the level of the user and client IP address.

I'm aware of that, but common practice among mail operators seems to be 
to use IP addresses.  I'm not sure what their reasons for that are - 
they might simply want to make lookups more efficient - but it's a 
truism that every extra layer of indirection is another opportunity for 
configuration error.   (Unless perhaps all such DNS records are 
automatically updated from a network configuration database, but I don't 
think that practice is nearly universal yet.)

>
>> Also, it doesn't rid the burden of applications operating behind the 
>> NAT to be aware of the NAT. For better or worse, applications have a 
>> lot of incentive to use DoH or DoT because local resolvers are 
>> sometimes under-provisioned or unreliable, network providers 
>> sometimes spy on DNS traffic, etc.  Using DoH or DoT can result in 
>> more reliable, consistent operation with less delay due to DNS lookup 
>> time.   So if the application is going to benefit from SPF records 
>> having DNS names in them, it has to know to use the DNS64 server to 
>> lookup those DNS names and get the (possibly fake) IPv6 source 
>> addresses back.
>>
>> The general problem that DNS is often out of sync with reality (at 
>> least in part because DNS isn't federated in the same way that 
>> reality is) is hard to fix.
> What exactly do you mean Split-DNS? Which is another pitfall why using 
> DoH and DoT is problematic and (from admin perspective) not desirable. 
> And when they're used to use the same DNS infrastructure you consider 
> "out of sync" via a DoH or DoT resolver...

Split DNS is indeed a problem.  DNS was simply not designed to work that 
way.   It's Mostly Harmless IMO if the only thing that Split DNS is used 
for is to hide records of internal hosts that aren't supposed to be 
externally reachable anyway.   If the connection attempt will never 
succeed anyway, DNS Name Lookup Failure is not (much) worse than 
Connection Timed Out.   But when DNS presents different successful query 
results depending on who is asking, that's a Bad Idea.   It's not 
reasonable for a DNS server to assume that the connection attempt would 
be made from the same source IP address, or even network, that the query 
is coming from.   The very fact that DNS explicitly supports and 
encourages caching should make that clear.   DNS was never expected to 
reflect network topology.

But "DNS is out of sync with reality" is a more general problem than 
that.  It's simply that the people who maintain DNS and the people who 
maintain the applications and the hosts on which those applications run, 
are often different people, in different departments or even different 
companies.   Sometimes the problem is even worse.  I once worked for a 
company that hired a marketing firm to revamp its web site.  That 
marketing firm, or its web designers, not only updated the HTML/JS/etc 
code for the web site but also apparently arranged for new DNS hosting 
and told the network admin to change their NS records to point to the 
new DNS hosts.  And corporate marketing ordered the local IT people to 
Make It So.   That broke every other network-based app that the company 
had, because both the hired marketing firm and corporate marketing 
didn't even have any idea that there might be other uses for a company's 
domain name than to reach their web site or to find the inbound SMTP 
server.   This might seem like an unusual example, but in my experience 
this kind of problem has been quite common.

I'm aware that there's a tussle between local network admins and 
application vendors over whether to use DoT/DoH.  I firmly side with the 
application vendors, because unreliable DNS (even from major ISPs) is 
far too common.   Applications need a predictable and reasonably 
reliable environment to operate in.   From the point of view of 
application vendors, local DNS resolvers behave very inconsistently and 
with widely varying degrees of reliability, and there are lots of 
longstanding security issues with port 53.  Realistically, many 
applications have to have some support for lookup of local names anyway, 
so they still need to consult local DNS resolvers for some things.  But 
if the application knows that a particular server it's using is on the 
public Internet, using DoH/DoT exclusively to find that server, or using 
the local resolver only as a last resort, makes a lot of sense.

Keith