Re: [spfbis] Proposed spf TXT record change

Mark Andrews <marka@isc.org> Wed, 10 February 2016 20:43 UTC

Return-Path: <marka@isc.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1EA1B2FB3 for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 12:43:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 WmkM9Mu_b_Tz for <spfbis@ietfa.amsl.com>; Wed, 10 Feb 2016 12:43:36 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA441B2FB5 for <spfbis@ietf.org>; Wed, 10 Feb 2016 12:43:36 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 1FE893493C4; Wed, 10 Feb 2016 20:43:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1570F160048; Wed, 10 Feb 2016 20:43:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 04BB31600AC; Wed, 10 Feb 2016 20:43:34 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YDdvv7EDslvB; Wed, 10 Feb 2016 20:43:33 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id AC1CD160048; Wed, 10 Feb 2016 20:43:33 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6DC5241D2E99; Thu, 11 Feb 2016 07:43:31 +1100 (EST)
To: "Stuart D. Gathman" <stuart@gathman.org>
From: Mark Andrews <marka@isc.org>
References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>
In-reply-to: Your message of "Wed, 10 Feb 2016 14:32:50 -0500." <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>
Date: Thu, 11 Feb 2016 07:43:31 +1100
Message-Id: <20160210204331.6DC5241D2E99@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/4fguezRi2uQJyPcx_aM9D_GAfSQ>
Cc: "Roy A. Gilmore" <rag@ragged-software.com>, spfbis@ietf.org
Subject: Re: [spfbis] Proposed spf TXT record change
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 10 Feb 2016 20:43:38 -0000

In message <alpine.LRH.2.20.1602101428440.13845@fairfax.gathman.org>;, "Stuart D. Gathman" writes:
> On Tue, 9 Feb 2016, Roy A. Gilmore wrote:
> 
> > Why should it matter if I'm a decade too late? If I'm right (and I'm not
> > saying that I am), why shouldn't the behavior be changed. RFC's aren't
> > set in stone, they are updated and/or obsoleted all the time. This
> > proposed change is trivial to implement.
> 
> As a pyspf developer, the _spf idea is *not* trivial to implement. 
> The SPF RR is trivial to implement.  The problem was braindead DNS
> servers.

No the problem is brain dead firewalls.  Apart from some load
balancers that get anything other than A (and now sometimes AAAA)
right, nameservers return NODATA or at worst NOTIMP when they don't
implement a type.  For many of the loadbalancer it is bad configuration
not that the load balancer is incapable of returning a correct
answer so you need to nag the operators of the load balancers to
correctly configure them.

The vast, vast, vast majority of nameservers have always done the
correct thing. RFC 1034 actually tells developers to return NODATA.

Nameservers put in SPF support in a timely manner.  It's still
there because there is no point in removing it.
 
> I still publish both SPF and TXT records (no SPF police are stopping
> me).  I still have the type99 code in my SPF implementation.
> Type99 is only deprecated.  If you can convince DNS server providers
> to operate correctly for unknown RR types (or failing that, to
> recognize SPF RR), and convince lots of people to publish both,
> then a switch could be reconsidered.  Especially if there is a new
> backward incompatible SPF version.

The biggest problem we had was not setting expectations.  I didn't
expect the transition to complete in 5 years (look at how long it
took before you could rely on just publishing a MX record for email)
yet we have had people saying 5 years was more than enough time in
this thread.  If you wanted a 5 year transition it required active
pushing of every to achieve that and I saw none of that.  It takes
about that long for new nameserver code to make it into OS's as the
OS vendors don't pickup the code in a timely manner.

I also expect everyone in this group to support the publication of
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-01
when it comes up as it is trying to get the remaining bad actors
weeded out of the ecosystem by actively looking for them and informing
the operators that they have a problem.  You have all seen the
issues cause by non RFC compliant code being deployed which is what
these tests are looking for.

It isn't impossible to test for whether servers answer correctly
for various types including unknown types.  See
https://ednscomp.isc.org/compliance/tld-typereport.txt
Note: there are false positives with timeouts as rate limiters kick
in.

Mark


> _______________________________________________
> 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