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
- Re: [spfbis] Proposed spf TXT record change Scott Kitterman
- [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Roy A. Gilmore
- Re: [spfbis] Proposed spf TXT record change Dotzero
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Dave Crocker
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change William Leibzon
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change Stuart D. Gathman
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Mark Andrews
- Re: [spfbis] Proposed spf TXT record change Murray S. Kucherawy
- Re: [spfbis] Proposed spf TXT record change Dotzero
- Re: [spfbis] Proposed spf TXT record change John Levine
- Re: [spfbis] Proposed spf TXT record change Hector Santos
- Re: [spfbis] Proposed spf TXT record change Alessandro Vesely
- Re: [spfbis] Proposed spf TXT record change Frank Ellermann