IETF Logo Mail Archive

Re: [spfbis] not a migration strategy

Mark Andrews <marka@isc.org> Thu, 22 August 2013 00:56 UTC

Return-Path: <marka@isc.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624A811E8178 for <spfbis@ietfa.amsl.com>; Wed, 21 Aug 2013 17:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level:
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ5yzt1Jwl30 for <spfbis@ietfa.amsl.com>; Wed, 21 Aug 2013 17:56:08 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 878D111E817D for <spfbis@ietf.org>; Wed, 21 Aug 2013 17:56:08 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 764ECC9424; Thu, 22 Aug 2013 00:55:55 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377132967; bh=8voIG6ZlB/4Fm3Lq4iE6N6nySCa4L8jTk+STNKiyrbg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UT21LYJlgt99NGhlBardpciLxWSkdLLyZTdoKH9hxhhnnWINXKB/UXkNUpjTmzEmA zFWe9Q/L8XHWzWM/4+CV47A+dgSz8Butn6YSVfA/0lLnsIflPjxFmQKpuXF5l3/dsq RH28BYNDRFwEI9lePFpEea9FSfVo5aVnVHV5K6Ho=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 22 Aug 2013 00:55:55 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD724160482; Thu, 22 Aug 2013 00:56:07 +0000 (UTC)
Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A00041603E9; Thu, 22 Aug 2013 00:56:07 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1400438C346C; Thu, 22 Aug 2013 10:55:53 +1000 (EST)
To: John Levine <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <20130822004035.91384.qmail@joyce.lan>
In-reply-to: Your message of "22 Aug 2013 00:40:35 +0000." <20130822004035.91384.qmail@joyce.lan>
Date: Thu, 22 Aug 2013 10:55:52 +1000
Message-Id: <20130822005553.1400438C346C@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: spfbis@ietf.org
Subject: Re: [spfbis] not a migration strategy
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 22 Aug 2013 00:56:13 -0000

In message <20130822004035.91384.qmail@joyce.lan>, "John Levine" writes:
> >> > You get the nameserver vendors to add code look for TXT SPF records
> >> > and add SPF SPF records when they find them if there isn't a record
> >> > there when loading / updating a master zone.
> >> 
> >> Believe it or not, you are not the first person to think of that hack.
> >> 
> >> I did it for a while, and found that it caused more problems than it 
> >> solved.
> > 
> >With code to identify the original record or without?
> 
> Without, but the problems had nothing to do with the contents of the
> type 99 records.

Yet you don't enumerate the problems.

Did you modify the nameserver to make the changes?

When I say put it in the nameserver.  That covers loading master
zones from disk, updating the zone using UPDATE, fixing the external
tools that manipulate/check the zone the zone like dnssec-signzone,
named-checkzone and named-compilezone.  It also mean have the inline
signer code add the records.  This also means fix NSEC/NSEC3 records
add RRSIGs etc.

A simpler step would be to just refuse to serve the zone if SPF
records are not present when v=sfp1 TXT records are.  Not accept
updates that put the zone into this state.  Make it a concious
decision to break the SHOULD in RFC 4408.  I believe most people
break that SHOULD unintentionally.

Mark

> R's,
> John
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email