From shane@isc.org Fri Sep 7 02:31:21 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4B21F874A for ; Fri, 7 Sep 2012 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7FqUovMZkdu for ; Fri, 7 Sep 2012 02:31:21 -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 37B1621F86F4 for ; Fri, 7 Sep 2012 02:31:21 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9C171C9632 for ; Fri, 7 Sep 2012 09:31:09 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-desktop (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BE63A216C6E for ; Fri, 7 Sep 2012 09:31:08 +0000 (UTC) (envelope-from shane@isc.org) Date: Fri, 7 Sep 2012 11:30:56 +0200 From: Shane Kerr To: dnsext@ietf.org Message-ID: <20120907113056.6e5496d3@shane-desktop> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:31:21 -0000 All, Someone pointed out on another mailing list that the SPF RR type is being deprecated. I checked it out, and sure enough, RFC 4408-bis requires TXT records, and recommends not including the SPF RR type. The rationale is in RFC 6686: http://tools.ietf.org/html/rfc6686#appendix-A I can't see any real answer to the concerns about firewalls and other software. -- Shane From paf@frobbit.se Fri Sep 7 02:46:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168E21F8703 for ; Fri, 7 Sep 2012 02:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlimSMGQgG68 for ; Fri, 7 Sep 2012 02:46:27 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 69D5721F86F7 for ; Fri, 7 Sep 2012 02:46:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 976DE1631BE05; Fri, 7 Sep 2012 11:46:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1gvdCPtwKqi; Fri, 7 Sep 2012 11:46:22 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 33E901631BDEC; Fri, 7 Sep 2012 11:46:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120907113056.6e5496d3@shane-desktop> Date: Fri, 7 Sep 2012 11:46:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120907113056.6e5496d3@shane-desktop> To: Shane Kerr X-Mailer: Apple Mail (2.1486) Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:46:28 -0000 On 7 sep 2012, at 11:30, Shane Kerr wrote: > Someone pointed out on another mailing list that the SPF RR type is > being deprecated. I checked it out, and sure enough, RFC 4408-bis > requires TXT records, and recommends not including the SPF RR type. >=20 > The rationale is in RFC 6686: >=20 > http://tools.ietf.org/html/rfc6686#appendix-A >=20 > I can't see any real answer to the concerns about firewalls and other > software. If we can not deploy new things, together with people giving up like = this, is not a very positive view of the future. Patrik From nweaver@icsi.berkeley.edu Fri Sep 7 05:23:42 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D464C21F8811 for ; Fri, 7 Sep 2012 05:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEsAlU0RMgQY for ; Fri, 7 Sep 2012 05:23:42 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3DF21F880C for ; Fri, 7 Sep 2012 05:23:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 143DF2C400E; Fri, 7 Sep 2012 05:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xX9SUzEv6xa6; Fri, 7 Sep 2012 05:23:41 -0700 (PDT) Received: from [10.0.1.2] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 97AE42C4004; Fri, 7 Sep 2012 05:23:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 7 Sep 2012 05:23:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120907113056.6e5496d3@shane-desktop> To: Shane Kerr X-Mailer: Apple Mail (2.1278) Cc: DNSEXT Working Group Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:23:43 -0000 On 7 sep 2012, at 11:30, Shane Kerr wrote: > Someone pointed out on another mailing list that the SPF RR type is > being deprecated. I checked it out, and sure enough, RFC 4408-bis > requires TXT records, and recommends not including the SPF RR type. >=20 > The rationale is in RFC 6686: >=20 > http://tools.ietf.org/html/rfc6686#appendix-A >=20 > I can't see any real answer to the concerns about firewalls and other > software. There are many obstacles for DNSSEC and other DNS enhancements. = Firewalls blocking novel RRTYPEs (without, eg, blocking DNSSEC in = general) is generally not one of them, or way way way down in the list. The server side does have a fault, not making it easy to SPECIFY novel = types, but once a novel type is queried for, it tends to work reliably = through the whole path to the client. From ajs@anvilwalrusden.com Fri Sep 7 07:28:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4FA21F85EF for ; Fri, 7 Sep 2012 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8rz6ka+Slzz for ; Fri, 7 Sep 2012 07:28:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1656521F85C7 for ; Fri, 7 Sep 2012 07:28:46 -0700 (PDT) Received: from mx1.yitter.info (nat-05-mht.dyndns.com [216.146.45.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 012358A031 for ; Fri, 7 Sep 2012 14:28:44 +0000 (UTC) Date: Fri, 7 Sep 2012 10:28:45 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120907141916.GA16938@mx1.yitter.info> References: <20120907113056.6e5496d3@shane-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:28:47 -0000 On Fri, Sep 07, 2012 at 11:46:19AM +0200, Patrik Fältström wrote: > > If we can not deploy new things, together with people giving up like this, is not a very positive view of the future. Maybe. I'm co-chair of SPFBIS, and I wasn't able to marshal good arguments for keeping the RRTYPE. But I note that there's something special about this case: the original protocol offered _two_ ways to achieve the functionality. It used both TXT and SPF. This actually created an interoperation issue. Those publishing an SPF record could use TXT or SPF or both. Those looking up an SPF record could ask for TXT or SPF or both. The arragement in RFC 4408, then, makes it possible for a publisher to offer the record and a client to request the record, and for the record still not to be received (pub uses SPF, client asks for TXT, record isn't seen). This meant that we had do do _something_ about the state of affairs, and given the almost complete lack of use of type 99, ditching it seemed to make sense. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Sep 7 09:06:24 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57821E8043 for ; Fri, 7 Sep 2012 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5125J4MBsCpc for ; Fri, 7 Sep 2012 09:06:22 -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 36E2F21E8040 for ; Fri, 7 Sep 2012 09:06:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id E0748C9468; Fri, 7 Sep 2012 16:06:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8a3:347b:e0b5:ee67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9B189216C6E; Fri, 7 Sep 2012 16:06:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 747DB248C4C5; Sat, 8 Sep 2012 02:05:59 +1000 (EST) To: Nicholas Weaver From: Mark Andrews References: <20120907113056.6e5496d3@shane-desktop> In-reply-to: Your message of "Fri, 07 Sep 2012 05:23:40 MST." Date: Sat, 08 Sep 2012 02:05:59 +1000 Message-Id: <20120907160559.747DB248C4C5@drugs.dv.isc.org> Cc: DNSEXT Working Group Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:06:24 -0000 In message , Nicholas Weaver writes: > > On 7 sep 2012, at 11:30, Shane Kerr wrote: > > > Someone pointed out on another mailing list that the SPF RR type is > > being deprecated. I checked it out, and sure enough, RFC 4408-bis > > requires TXT records, and recommends not including the SPF RR type. > > > > The rationale is in RFC 6686: > > > > http://tools.ietf.org/html/rfc6686#appendix-A > > > > I can't see any real answer to the concerns about firewalls and other > > software. > > There are many obstacles for DNSSEC and other DNS enhancements. Firewalls blocking novel RRTYPEs (without, eg, blocking DNSSE > C in general) is generally not one of them, or way way way down in the list. > > The server side does have a fault, not making it easy to SPECIFY novel types, but once a novel type is queried for, it tends t > o work reliably through the whole path to the client. And the analysis is fault as there is a 3.2/3.4/4.8% deployment rates of the SPF record in participating sites. Why would you need a web tool to change TXT to SPF as the rdata is syntactically identical? Alexa domains list is problematical for any type other than A, additionally depending upon the methodology used to check you can get significantly different failure rate as that list contains a higher than normal percentage of DNS load balancers. Seeing few queries for SPF record when there are TXT records present does not indicate anything about SPF record support in clients as there is no need to try SPF if TXT is present. Lack of code could also be a contributing factor libspf2 took until October 2008 to add type SPF lookups. https://github.com/shevek/libspf2/blame/master/src/libspf2/spf_server.c We shipped BIND 9.4.0 in Feb 2007 and it included SPF support. RFC 4408 April 2006 TXT was already well established for SPF before we could convince any to go down the SPF path. You can't rush a migration from one record type to another see A to MX which took much, much longer that SPF was given before defeat was called. I actually expect to see SPF queries to rise as the early mover machines get replaced with modern hardware and with that have a software refresh. There is a lot of inertia in the DNS but it does move and moves faster if you don't start with a migration. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Fri Sep 7 12:47:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB71221F84BF for ; Fri, 7 Sep 2012 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh2pHvjMgv3V for ; Fri, 7 Sep 2012 12:47:23 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1948B21F845F for ; Fri, 7 Sep 2012 12:47:22 -0700 (PDT) Received: (qmail 8395 invoked by uid 399); 7 Sep 2012 19:47:11 -0000 Received: from unknown (HELO ?192.168.0.100?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 7 Sep 2012 19:47:11 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <504A4F3A.8060008@dougbarton.us> Date: Fri, 07 Sep 2012 12:47:06 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <20120907113056.6e5496d3@shane-desktop> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:47:23 -0000 On 09/07/2012 02:46 AM, Patrik Fältström wrote: > > On 7 sep 2012, at 11:30, Shane Kerr wrote: > >> Someone pointed out on another mailing list that the SPF RR type is >> being deprecated. I checked it out, and sure enough, RFC 4408-bis >> requires TXT records, and recommends not including the SPF RR type. >> >> The rationale is in RFC 6686: >> >> http://tools.ietf.org/html/rfc6686#appendix-A >> >> I can't see any real answer to the concerns about firewalls and other >> software. > > If we can not deploy new things, together with people giving up like this, is not a very positive view of the future. This was discussed on ietf@ a while ago. The consensus I read from that discussion (possibly because I agreed with it) was that the fail for SPF was allowing 2 provisioning methods, instead of just using the new RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: issue. Doug From johnl@iecc.com Fri Sep 7 16:00:37 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1414121E8047 for ; Fri, 7 Sep 2012 16:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNo0Hk765htz for ; Fri, 7 Sep 2012 16:00:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1AB21E8044 for ; Fri, 7 Sep 2012 16:00:36 -0700 (PDT) Received: (qmail 76391 invoked from network); 7 Sep 2012 23:00:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Sep 2012 23:00:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504a7c8f.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=SiZAa08t5BMbisu5a7ArVfEe7TVIhiebXAcvBgjnXjk=; b=aQmLrCMNOmKb8YDl3oKdvUzSVeBWmmRet8j7qIIt/wBlFuoHceOVDMqfoVHhruytHrf82e8ZL5l835vw+V2PNI08uoolH8n5g766oh/HvoSxHEV+oJMN3o3NTNY0A69GW2voMGilwKaA+DVWPLndE0NPVR+SAkS6DogexbXBlmA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504a7c8f.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=SiZAa08t5BMbisu5a7ArVfEe7TVIhiebXAcvBgjnXjk=; b=Dl8n6IpTHKzNpkSrcnHDcd0HXPrIzK4GBu4M8EVE9VR0IyIhE0j8vymkSE7+o9PHQIZwPd1KHYXlfU9MmTfX6McS/KFYw57sLTah2AFNtpYLMznyDf1JUerV7P6CHbh5EvDZ7UWyg+xeLyK0gVpci/2pSnwaqumsEgVZW+/7LSU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Sep 2012 23:00:09 -0000 Message-ID: <20120907230009.28162.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <504A4F3A.8060008@dougbarton.us> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 23:00:37 -0000 >This was discussed on ietf@ a while ago. The consensus I read from that >discussion (possibly because I agreed with it) was that the fail for SPF >was allowing 2 provisioning methods, instead of just using the new >RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: issue. It's true that we wouldn't be having this discussion if SPF required type 99 records, since nobody would have deployed it and it would have disappeared without a trace. The problem is that it's too hard for people to use new record types, in particular because the provisioning systems that most people use do not have any practical way to add new RR types for people who aren't DNS weenies. Often there's no way to add them even if you are a DNS weenie. (Helpful hint: if you were about to argue that it's not hard to add new RR types, don't bother. In the real world, it is.) Perhaps this would be a good time to take another look at draft-levine-dnsextlang-02.txt. It's hardly a magic bullet, but as far as I'm aware it's the first attempt in a long time, perhaps ever, to address the provisioning problem. R's, John From michael@rancid.berkeley.edu Fri Sep 7 17:36:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE37521F8530 for ; Fri, 7 Sep 2012 17:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuF4763lJJWn for ; Fri, 7 Sep 2012 17:36:13 -0700 (PDT) Received: from burnttofu.net (cl-960.qas-01.us.sixxs.net [IPv6:2001:4830:1600:3bf::2]) by ietfa.amsl.com (Postfix) with ESMTP id 156B721F852E for ; Fri, 7 Sep 2012 17:36:12 -0700 (PDT) Received: from sponge.es.net ([IPv6:2001:470:1f05:17a6:d69a:20ff:fefd:6b88]) (authenticated bits=0) by burnttofu.net (8.14.5/8.14.5) with ESMTP id q880ZvCP072032 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Sep 2012 00:36:09 GMT (envelope-from michael@rancid.berkeley.edu) Message-ID: <504A92EB.4090306@rancid.berkeley.edu> Date: Fri, 07 Sep 2012 17:35:55 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20120907113056.6e5496d3@shane-desktop> <20120907141916.GA16938@mx1.yitter.info> In-Reply-To: <20120907141916.GA16938@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (burnttofu.net [IPv6:2001:4830:1600:3bf::2]); Sat, 08 Sep 2012 00:36:09 +0000 (UTC) Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 00:36:13 -0000 On 09/07/12 07:28, Andrew Sullivan wrote: > On Fri, Sep 07, 2012 at 11:46:19AM +0200, Patrik Fältström wrote: >> >> If we can not deploy new things, together with people giving up like this, is not a very positive view of the future. > > Maybe. > > I'm co-chair of SPFBIS, and I wasn't able to marshal good arguments > for keeping the RRTYPE. But I note that there's something special > about this case: the original protocol offered _two_ ways to achieve > the functionality. It used both TXT and SPF. > > This actually created an interoperation issue. Those publishing an > SPF record could use TXT or SPF or both. Those looking up an SPF > record could ask for TXT or SPF or both. The arragement in RFC 4408, > then, makes it possible for a publisher to offer the record and a > client to request the record, and for the record still not to be > received (pub uses SPF, client asks for TXT, record isn't seen). > > This meant that we had do do _something_ about the state of affairs, > and given the almost complete lack of use of type 99, ditching it > seemed to make sense. I am sure this was discussed in SPFBIS, but I am wondering why they couldn't have gone the route of MX (vs. A) from the perspective of the queryer: First ask for the SPF record, and if it doesn't exist, ask for the TXT record. In this situation, you only have to change the specification of the software doing the lookups; SPF publishers can still have the flexibility to use either record. Principle of least change, etc... michael From marka@isc.org Fri Sep 7 18:55:34 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026A421E8042 for ; Fri, 7 Sep 2012 18:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68xTOJRiUKpQ for ; Fri, 7 Sep 2012 18:55:33 -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 673B321E8040 for ; Fri, 7 Sep 2012 18:55:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1E2C8C9465; Sat, 8 Sep 2012 01:55:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8a3:347b:e0b5:ee67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D385A216C25; Sat, 8 Sep 2012 01:55:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1A6FA248DC8B; Sat, 8 Sep 2012 11:55:13 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> In-reply-to: Your message of "07 Sep 2012 23:00:09 GMT." <20120907230009.28162.qmail@joyce.lan> Date: Sat, 08 Sep 2012 11:55:12 +1000 Message-Id: <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 01:55:34 -0000 In message <20120907230009.28162.qmail@joyce.lan>, "John Levine" writes: > >This was discussed on ietf@ a while ago. The consensus I read from that > >discussion (possibly because I agreed with it) was that the fail for SPF > >was allowing 2 provisioning methods, instead of just using the new > >RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: issue. > > It's true that we wouldn't be having this discussion if SPF required > type 99 records, since nobody would have deployed it and it would have > disappeared without a trace. > > The problem is that it's too hard for people to use new record types, > in particular because the provisioning systems that most people use do > not have any practical way to add new RR types for people who aren't > DNS weenies. Often there's no way to add them even if you are a DNS > weenie. (Helpful hint: if you were about to argue that it's not hard > to add new RR types, don't bother. In the real world, it is.) Which is a fault of the provisioning system not the DNS. Lots of povisioning systems don't even support the set of RR types in RFC 1034. The DNS has a standard method that allows the introduction of arbitary records that does not require provisioning systems to change anything when a new type is introduced (RFC 3597). It may not be the most elegant but it works. > Perhaps this would be a good time to take another look at > draft-levine-dnsextlang-02.txt. It's hardly a magic bullet, but as > far as I'm aware it's the first attempt in a long time, perhaps ever, > to address the provisioning problem. As for draft-levine-dnsextlang-02.txt there was nothing stopping anyone implementing something like this in the past. Standardising this does run the risk of forcing new records to match what is describeable in that language. You need to base32hex without padding. For the record our DHCP product has a similar system and it still needs extending occasionally to support new DHCP option codes. We also get called "to heavy" in part because we are extensible like this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Fri Sep 7 20:10:58 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5B21F8551 for ; Fri, 7 Sep 2012 20:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcvOh0zQ0rn0 for ; Fri, 7 Sep 2012 20:10:57 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 845C021F8550 for ; Fri, 7 Sep 2012 20:10:57 -0700 (PDT) Received: (qmail 24143 invoked by uid 399); 8 Sep 2012 03:10:46 -0000 Received: from unknown (HELO ?192.168.0.102?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 8 Sep 2012 03:10:46 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <504AB73D.2070807@dougbarton.us> Date: Fri, 07 Sep 2012 20:10:53 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: John Levine References: <20120907230009.28162.qmail@joyce.lan> In-Reply-To: <20120907230009.28162.qmail@joyce.lan> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 03:10:58 -0000 On 9/7/2012 4:00 PM, John Levine wrote: >> This was discussed on ietf@ a while ago. The consensus I read from that >> discussion (possibly because I agreed with it) was that the fail for SPF >> was allowing 2 provisioning methods, instead of just using the new >> RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: issue. > > It's true that we wouldn't be having this discussion if SPF required > type 99 records, since nobody would have deployed it and it would have > disappeared without a trace. All of the new record types deployed in the last several years (particularly DNSSEC-related ones) give us a lot more hope than that. I realize that you have a draft you'd like to get published, but repeating the same oft-refuted arguments won't help that effort. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From sm@resistor.net Sat Sep 8 00:48:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7621F852C for ; Sat, 8 Sep 2012 00:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9SlaSYVXw6N for ; Sat, 8 Sep 2012 00:48:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069F621F852B for ; Sat, 8 Sep 2012 00:47:59 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q887lpOD018382; Sat, 8 Sep 2012 00:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347090476; bh=qh14CSV4fi2yUqJwknJivFyxTOWum0Tw/Ni2m1cqtW4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NlXBK8ow6ROhf9KlU98fpMIfAC0brRQI/YpJtmVXuu3r9VK1Ry1eCoPUc3MZnmhYA VWQ2SdlG5YeuoPDSCMEMXB/KYKJzjtioP8lrh5Ougi0OxJn4bi7n9ujSPhAfJ8OWTX 9mpyrrAUJPlE9r+TP4vvuFuMJJlsOcaWXbhNkYns= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347090476; i=@resistor.net; bh=qh14CSV4fi2yUqJwknJivFyxTOWum0Tw/Ni2m1cqtW4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Jz9q6GbgJFWO1ZyJqUsCOtE5l5Mvox3UvGlEq6D+xW6PN4x+Vbn3TGuDOiZDZJD5u kgR8MRRWJcwuuy8J3mWTZJYeuCk6EFhoDKFPphzc9e5W+0f7kFgUSHJIzYvGkgvIfG CYaYkLGPlbxy81fuM01aE9h0LjKm5K+HYYF3K2f4= Message-Id: <6.2.5.6.2.20120908001638.0a941188@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 08 Sep 2012 00:47:26 -0700 To: Doug Barton From: SM In-Reply-To: <504A4F3A.8060008@dougbarton.us> References: <20120907113056.6e5496d3@shane-desktop> <504A4F3A.8060008@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 07:48:01 -0000 Hi Doug, At 12:47 07-09-2012, Doug Barton wrote: >This was discussed on ietf@ a while ago. The consensus I read from that >discussion (possibly because I agreed with it) was that the fail for SPF >was allowing 2 provisioning methods, instead of just using the new >RRTYPE from day 1. This is a similar problem to the Header: vs X-Header: I thought so too at first. There are a few issues DNS-wise which didn't make sense. I read the relevant mailing list archive and found a possible explanation for the two provisioning methods and some other issues. It was one of these decisions which was _the_ alternative at the time. With hindsight, I might say that using only the RRTYPE from day 1 would have been better. I wouldn't call it process failure. It was a different time, the DNS environment was different and the work wasn't easy. Regards, -sm From johnl@taugh.com Sun Sep 9 07:21:00 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C5B21F84F8 for ; Sun, 9 Sep 2012 07:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLK4rjr7ueiK for ; Sun, 9 Sep 2012 07:20:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6117621F847B for ; Sun, 9 Sep 2012 07:20:59 -0700 (PDT) Received: (qmail 40937 invoked from network); 9 Sep 2012 14:20:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9fe8.504ca5ca.k1209; bh=8biCQEjhUuQvyW6fkzP+aRtgyPPAr4K6aNHl4q+EitQ=; b=ZRvTqOTts6laGNYHgfanyx0Ygy2nkVz6Bxw3qAAy8uP16h3iji6Nr226oygwjMQ987+h/gngoeeHnc646flanRFwep645la9LJY3UYwtM3PbKuukKe5by4UtM42kr9M0A00J6nzuJ32hDX+IBO+VDMl7UAUvqLLcRpSLBz8dH78= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=9fe8.504ca5ca.k1209; bh=8biCQEjhUuQvyW6fkzP+aRtgyPPAr4K6aNHl4q+EitQ=; b=F56K1C9blJU6hikasYBmnZbqYXFg56+NZkelVxEWTZmwxaNQwrtQEOAUbI85f7MjU8W5+eU/HASVeBxXtJlhl0Y+YmcRUBtHxovuA98XGb98n6V6hUgoiRipZ1u8ZTcsyMQz2XWf1XXSTRzJQh2kRmaUvQJIwx6582/JyMRNk48= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 9 Sep 2012 14:20:36 -0000 Date: 9 Sep 2012 10:20:58 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 14:21:00 -0000 > Which is a fault of the provisioning system not the DNS. Right. And as long as provisioning systems don't support new RR types, they're not going to get deployed in in the real world. I'm getting the impression that I'm the only one here who thinks that it might be a good idea to try and solve that problem. That's sad. R's, John From ogud@ogud.com Sun Sep 9 10:52:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B821F8484 for ; Sun, 9 Sep 2012 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o51l9WzjqAaU for ; Sun, 9 Sep 2012 10:52:04 -0700 (PDT) Received: from smtp178.iad.emailsrvr.com (smtp178.iad.emailsrvr.com [207.97.245.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D421F847A for ; Sun, 9 Sep 2012 10:52:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 75575F80A4 for ; Sun, 9 Sep 2012 13:52:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp57.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 4EB57F8099 for ; Sun, 9 Sep 2012 13:52:03 -0400 (EDT) Message-ID: <504CD740.6070305@ogud.com> Date: Sun, 09 Sep 2012 13:52:00 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:52:05 -0000 On 09/09/2012 10:20, John R Levine wrote: >> Which is a fault of the provisioning system not the DNS. > > Right. And as long as provisioning systems don't support new RR types, > they're not going to get deployed in in the real world. > > I'm getting the impression that I'm the only one here who thinks that it > might be a good idea to try and solve that problem. That's sad. > I think that people here feel powerless to address that problem :-( but your draft will hopefully empower them. Olafur ps: remember to add the int64 type to the next version. From Ed.Lewis@neustar.biz Sun Sep 9 12:30:05 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B996B21F8567 for ; Sun, 9 Sep 2012 12:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.333 X-Spam-Level: X-Spam-Status: No, score=-99.333 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jITqy84IpTeC for ; Sun, 9 Sep 2012 12:30:05 -0700 (PDT) Received: from smtp155.ord.emailsrvr.com (smtp155.ord.emailsrvr.com [173.203.6.155]) by ietfa.amsl.com (Postfix) with ESMTP id 296D521F8566 for ; Sun, 9 Sep 2012 12:30:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id A8B561600C8; Sun, 9 Sep 2012 15:30:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp28.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id BE2B21600C7; Sun, 9 Sep 2012 15:30:03 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> Date: Sun, 9 Sep 2012 15:29:36 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 19:30:05 -0000 At 11:55 +1000 9/8/12, Mark Andrews wrote: >Which is a fault of the provisioning system not the DNS. I think this is a case of barking up the wrong tree. I don't have a complete history, but I once had a real close seat to the action leading up to this. By that I mean I was part of an interim MARID WG meeting in June of 2004 where the situation came to a boil. At that point in time, the SPF effort had been under way for quite awhile. The prototype code written by a group of people relied on the use of the TXT record because (and this I don't know) they either couldn't get a RR type allocated or they failed to ask for one. At that time in IETF history it was very difficult to get a new RR type allocated, I do know that, and the document that is now RFC 5057 was just emerging as a response to what was happening and I was asked to go to the meeting to argue its points. The MARID WG was trying to publish a document including the use of the TXT record. When the message was delivered that this was not good for the DNS an all out IETF-brawl raged. The story was that the group had gone to great lengths the develop, deploy, use, document multiple independent implementations to get to the point where they could publish and qualify for a RR type (which is what it took then). They were right - the red-tape of the time encouraged overloading the TXT record and discouraged "the right way to go." To compromise the WG was granted a new type and allowed to go forward with a specification allowing TXT or SPF. On the DNS end, a more liberal process was put in place to get new types allocated - the template system we have in place now. And until now, that was the end of the story for me. The rest of this are observations I'll throw on the table. The forward-looking plan to accommodate backwards compatibility seems to have allowed the "problem" to fester. With "problem" being defined as overloading the TXT record. Looking on the bright side, this is a "problem" only for the DNS, not for anyone else - which is why no one else seems to have cared to fix this "problem." Provisioning systems? No, they are not the issue. Even if it were easier to put the SPF record into the DNS, this doesn't address the security filters that are fairly DNS ignorant. That problem sits in a whole 'nuther bin. Longer back in time there was a decision (from the Security Area AD in the 90's, Jeffery Schiller) to not approach security as a cohesive problem, I recall Schiller's talk at Danvers (IETF 32) including the analogy of "eggs in one basket." He (it may have been a committee decision, but he was the head then) wanted security to be tackled protocol by protocol. This seemed like a good idea at the time, sort of a "defense in depth" approach (which I think was a strong theme). Now, with 20/400 hindsight, it seems that this forward-looking plan has backfired. We know that the DNS protocol, relying as it does on UDP, is a security nightmare. Even if we DNSSEC it, that won't stop DDoS, for example. So what has happened while the DNS has tried to take care of itself, other protocols and operators have but protections in place against the DNS. By limiting the DNS to only what they understand it to be doing, they feel they are protected. The result is shackles have been placed on DNS, preventing innovation within the protocol from having the desired impact. This long story is to say that it isn't provisioning. It's the dynamics of how applications are deployed and the (old-time) red tape choking them and the nature of the DNS to be a threat to the rest of the network that are bigger problems here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From johnl@taugh.com Sun Sep 9 13:42:36 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D5021F8523 for ; Sun, 9 Sep 2012 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ciBSfEE9RSv for ; Sun, 9 Sep 2012 13:42:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CC22B21F8518 for ; Sun, 9 Sep 2012 13:42:35 -0700 (PDT) Received: (qmail 18685 invoked from network); 9 Sep 2012 20:42:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=48fc.504cff39.k1209; bh=G/yYeTDVuE57afcBgLviC9ECJusrIi6AjcRpHp1+c5A=; b=bpU8erQNjXpOtOt3ox7OwyciYXhReZbuE4132igsOBEBPSasF+M+mY7/ELKAvZ05vqoiH89LBZ2Bh+Gpy8U7rr5SYR8RHInL1oAKMLMVN691JuWRae974MtsXjSt6L2rMqhmCB+d5M27kkZE2jFZ3G4slp75T6auwaENOeyOeqI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=48fc.504cff39.k1209; bh=G/yYeTDVuE57afcBgLviC9ECJusrIi6AjcRpHp1+c5A=; b=v7CcbdoRqg0UICxbYckNc1hTGDJisaHRqPrSptp87P1OkanjS5mOetXmnSZ+Nx1hby1OZHFZ4FTSbEFvS0qKlbISVWiS+z9QwkN140ZI6Efxt3GYMwxSBv9qLcgp/Ri+8QEF7DzCE9ec8YFaio/4l/dk/gXTNlCNsp/90peO6vI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 9 Sep 2012 20:42:11 -0000 Date: 9 Sep 2012 16:42:33 -0400 Message-ID: From: "John R Levine" To: "Edward Lewis" In-Reply-To: References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 20:42:36 -0000 > At that point in time, the SPF effort had been under way for quite awhile. > The prototype code written by a group of people relied on the use of the TXT > record because (and this I don't know) they either couldn't get a RR type > allocated or they failed to ask for one. SPF was basically a done deal by the time it got anywhere near the IETF. They used the text record because it let them get their work done. If they had asked, we would probably have told them to use a TXT record with a prefix. When we did DKIM, which was an IETF effort to smoosh together two somewhat incompatible predecessors, we used TXT records with a prefix. Partly that was because one of the predecessors used them, but mostly it was because we knew that in practice, if DKIM required that people provision a new RR, it would have no chance of widespread deployment. > This long story is to say that it isn't provisioning. It's the dynamics of > how applications are deployed and the (old-time) red tape choking them and > the nature of the DNS to be a threat to the rest of the network that are > bigger problems here. Provisioning may not be the only issue, but it's serious enough that untill we make provisioning orders of magnitude easier, there's no point in fixing anything else. DNSSEC, which seems to be the poster child for how easy it allegedly is to add new RRs, is finally succeeding despite needing new RRs and upgrades to every bit of DNS software, only because there's no other plausible approach to fixing the problem. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From Ed.Lewis@neustar.biz Sun Sep 9 15:33:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6521F8592 for ; Sun, 9 Sep 2012 15:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBZ7dj1HboRp for ; Sun, 9 Sep 2012 15:33:02 -0700 (PDT) Received: from smtp168.iad.emailsrvr.com (smtp168.iad.emailsrvr.com [207.97.245.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCE21F84B2 for ; Sun, 9 Sep 2012 15:33:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E422E3D811D; Sun, 9 Sep 2012 18:33:01 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp56.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 2AC583D8106; Sun, 9 Sep 2012 18:33:01 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> Date: Sun, 9 Sep 2012 18:32:31 -0400 To: John R Levine From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:33:03 -0000 At 16:42 -0400 9/9/12, John R Levine wrote: >DNSSEC, which seems to be the poster child for how easy it allegedly is to >add new RRs, is finally succeeding despite needing new RRs and upgrades >to every bit of DNS software, only because there's no other plausible >approach to fixing the problem. And not just because there's no other way, there was a concerted, funded effort to *make sure* it happened. DNSSEC came out of the lab in 1998. There was immediate concern by powers that be that DNSSEC wasn't easily picked up, so a new funded effort began which fostered the workshops that followed (1999-2004 or so) and the new rounds of RFCs. And once that all happened and DNSSEC didn't, more and more work was done to make it so, eventually. Entropy is hard to fight. (And, I don't mean to say provisioning is not a problem. It's not the important one in the SPF case.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From dougb@dougbarton.us Sun Sep 9 15:38:37 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B46F21F85AE for ; Sun, 9 Sep 2012 15:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNKn4rXKoROS for ; Sun, 9 Sep 2012 15:38:36 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6143021F849B for ; Sun, 9 Sep 2012 15:38:36 -0700 (PDT) Received: (qmail 14644 invoked by uid 399); 9 Sep 2012 22:38:21 -0000 Received: from unknown (HELO ?192.168.0.102?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 9 Sep 2012 22:38:21 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <504D1A65.9090102@dougbarton.us> Date: Sun, 09 Sep 2012 15:38:29 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Edward Lewis References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:38:37 -0000 On 9/9/2012 12:29 PM, Edward Lewis wrote: > The MARID WG was trying to publish a document including the use of the > TXT record. When the message was delivered that this was not good for > the DNS an all out IETF-brawl raged. The story was that the group had > gone to great lengths the develop, deploy, use, document multiple > independent implementations to get to the point where they could publish > and qualify for a RR type (which is what it took then). They were right > - the red-tape of the time encouraged overloading the TXT record and > discouraged "the right way to go." Not only is that my recollection, it matches the recounted history dragged up recently on ietf@. > To compromise the WG was granted a new type and allowed to go forward > with a specification allowing TXT or SPF. On the DNS end, a more > liberal process was put in place to get new types allocated - the > template system we have in place now. And this is where the mistake was made. Once they got the new RR type they should have dropped the TXT record. What's arguable is whether or not the ramifications of that choice were foreseeable. However, rather than beating the dead SPF horse what I'm eager for is that we learn the lessons from that experience, and not repeat them. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From marka@isc.org Sun Sep 9 16:15:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AA821F8599 for ; Sun, 9 Sep 2012 16:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO+Gi0wyshe2 for ; Sun, 9 Sep 2012 16:15:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C2F8721F85A7 for ; Sun, 9 Sep 2012 16:15:20 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 337D35F993F; Sun, 9 Sep 2012 23:15:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6c6d:991a:9505:c698]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D0626216C25; Sun, 9 Sep 2012 23:15:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id ED5A0249FFF7; Mon, 10 Sep 2012 09:14:57 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 09 Sep 2012 15:29:36 -0400." Date: Mon, 10 Sep 2012 09:14:56 +1000 Message-Id: <20120909231457.ED5A0249FFF7@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 23:15:25 -0000 In message , Edward Lewis writes: > At 11:55 +1000 9/8/12, Mark Andrews wrote: > > >Which is a fault of the provisioning system not the DNS. > > I think this is a case of barking up the wrong tree. > > I don't have a complete history, but I once had a real close seat to > the action leading up to this. By that I mean I was part of an > interim MARID WG meeting in June of 2004 where the situation came to > a boil. By June 2004 we already had private types available in the DNS (RFC 2929) because I was already using them. The private version of DLV (65323) was committed to named's tree in March 2004. commit 50105afc551903541608b11851d73278b23579a3 Author: Mark Andrews Date: Wed Mar 10 02:19:58 2004 +0000 1589. [func] DNSSEC lookaside validation. enable-dnssec -> dnssec-enable I had also started the process of getting a formally allocated type for DLV. I prototyped with a private type then moved to a formally allocated type. > At that point in time, the SPF effort had been under way for quite > awhile. The prototype code written by a group of people relied on > the use of the TXT record because (and this I don't know) they either > couldn't get a RR type allocated or they failed to ask for one. At > that time in IETF history it was very difficult to get a new RR type > allocated, I do know that, and the document that is now RFC 5057 was > just emerging as a response to what was happening and I was asked to > go to the meeting to argue its points. > > The MARID WG was trying to publish a document including the use of > the TXT record. When the message was delivered that this was not > good for the DNS an all out IETF-brawl raged. The story was that the > group had gone to great lengths the develop, deploy, use, document > multiple independent implementations to get to the point where they > could publish and qualify for a RR type (which is what it took then). There was NEVER a time were you required have even a *single* implementation to get a new RR allocated. It helped if you had a implementation but it was not required. > They were right - the red-tape of the time encouraged overloading the > TXT record and discouraged "the right way to go." The red tape had basically gone by then, but not the perception of red tape. The bar to get a new type was extremely low. DLV (32769) got allocated under the rules that were in existance at that time and DLV was a very controversial type as people though it was a end run around the working group and various email about its progress were not sent so I was left waiting when I shouldn't have been. An experimental type was a no brainer under the rules that were in place but no one was willing to do that. You just needed to meet "Specification Required". Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. > To compromise the WG was granted a new type and allowed to go forward > with a specification allowing TXT or SPF. On the DNS end, a more > liberal process was put in place to get new types allocated - the > template system we have in place now. And until now, that was the > end of the story for me. People complained about a system without even trying to use the system. > The rest of this are observations I'll throw on the table. > > The forward-looking plan to accommodate backwards compatibility seems > to have allowed the "problem" to fester. With "problem" being > defined as overloading the TXT record. Looking on the bright side, > this is a "problem" only for the DNS, not for anyone else - which is > why no one else seems to have cared to fix this "problem." > > Provisioning systems? No, they are not the issue. Even if it were > easier to put the SPF record into the DNS, this doesn't address the > security filters that are fairly DNS ignorant. That problem sits in > a whole 'nuther bin. > > Longer back in time there was a decision (from the Security Area AD > in the 90's, Jeffery Schiller) to not approach security as a cohesive > problem, I recall Schiller's talk at Danvers (IETF 32) including the > analogy of "eggs in one basket." He (it may have been a committee > decision, but he was the head then) wanted security to be tackled > protocol by protocol. This seemed like a good idea at the time, sort > of a "defense in depth" approach (which I think was a strong theme). > Now, with 20/400 hindsight, it seems that this forward-looking plan > has backfired. > > We know that the DNS protocol, relying as it does on UDP, is a > security nightmare. Even if we DNSSEC it, that won't stop DDoS, for > example. So what has happened while the DNS has tried to take care > of itself, other protocols and operators have but protections in > place against the DNS. By limiting the DNS to only what they > understand it to be doing, they feel they are protected. The result > is shackles have been placed on DNS, preventing innovation within the > protocol from having the desired impact. > > This long story is to say that it isn't provisioning. It's the > dynamics of how applications are deployed and the (old-time) red tape > choking them and the nature of the DNS to be a threat to the rest of > the network that are bigger problems here. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Sun Sep 9 16:35:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA821F849B for ; Sun, 9 Sep 2012 16:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW+LxojHcjOQ for ; Sun, 9 Sep 2012 16:35:00 -0700 (PDT) Received: from smtp148.dfw.emailsrvr.com (smtp148.dfw.emailsrvr.com [67.192.241.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70A21F844B for ; Sun, 9 Sep 2012 16:35:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E011C18022C; Sun, 9 Sep 2012 19:34:59 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 19C2C180221; Sun, 9 Sep 2012 19:34:58 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20120909231457.ED5A0249FFF7@drugs.dv.isc.org> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120909231457.ED5A0249FFF7@drugs.dv.isc.org> Date: Sun, 9 Sep 2012 19:34:43 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 23:35:01 -0000 At 9:14 +1000 9/10/12, Mark Andrews wrote: >An experimental type was a no brainer under the rules that were in >place but no one was willing to do that. You just needed to meet >"Specification Required". > > Specification Required - Values and their meaning must be > documented in an RFC or other permanent and readily available > reference, in sufficient detail so that interoperability > between independent implementations is possible. > I think this is an unfair criticism of the folks involved. Not everyone is well steeped in the DNS RFCs. Sorry, but that's true. We, who are on namedroppers day in and day out live and breath this stuff. But not others. If you think the rules were a no brainer in 2004...ask yourself why so many changes were made in the wake of the MARID WG issues? (They may not have been the only ones with this problem.) Private types were known and dismissed because they only added fuel to the failure. The group that pioneered SPF did the right thing. Wrote code, deployed, tested, then documented. That's the IETF way, or it once was. They got screwed for doing that. Whether it was a private type ot TXT record, trying to redeploy with SPF is the same burden. Note I say this as the person back then trying to convince them to change from TXT to SPF. Maybe it was the Stockholm Syndrome (http://en.wikipedia.org/wiki/Stockholm_syndrome) but I have become sympathetic to the plight (...to overdramatize this.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From marka@isc.org Sun Sep 9 17:00:56 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF121F85DA for ; Sun, 9 Sep 2012 17:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v3ssj4W6dq9 for ; Sun, 9 Sep 2012 17:00:55 -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 4BFD521F85BB for ; Sun, 9 Sep 2012 17:00:55 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2BA00C9432; Mon, 10 Sep 2012 00:00:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6c6d:991a:9505:c698]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D61E3216C25; Mon, 10 Sep 2012 00:00:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7E8A724A0468; Mon, 10 Sep 2012 10:00:45 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120909231457.ED5A0249FFF7@drugs.dv.isc.org> In-reply-to: Your message of "Sun, 09 Sep 2012 19:34:43 -0400." Date: Mon, 10 Sep 2012 10:00:45 +1000 Message-Id: <20120910000045.7E8A724A0468@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:00:56 -0000 In message , Edward Lewis writes: > At 9:14 +1000 9/10/12, Mark Andrews wrote: > > >An experimental type was a no brainer under the rules that were in > >place but no one was willing to do that. You just needed to meet > >"Specification Required". > > > > Specification Required - Values and their meaning must be > > documented in an RFC or other permanent and readily available > > reference, in sufficient detail so that interoperability > > between independent implementations is possible. > > > > I think this is an unfair criticism of the folks involved. Not > everyone is well steeped in the DNS RFCs. Sorry, but that's true. > We, who are on namedroppers day in and day out live and breath this > stuff. But not others. They got told the rules had changed but they refused to listen. > If you think the rules were a no brainer in 2004...ask yourself why > so many changes were made in the wake of the MARID WG issues? (They > may not have been the only ones with this problem.) Private types > were known and dismissed because they only added fuel to the failure. Because there was a perception that there was a problem. There was no documented evidence of a problem because no one (apart from myself as far as I am a aware) attempted to use the system. It wasn't worth fighting about this when people decide they needed to tweak the system again. > The group that pioneered SPF did the right thing. Wrote code, > deployed, tested, then documented. That's the IETF way, or it once > was. They got screwed for doing that. Whether it was a private type > ot TXT record, trying to redeploy with SPF is the same burden. Which is why there was supposed to be a overlap period. libspf NEVER added support for type 99. libspf2 took 2 years to add support for type 99 after the RFC was published. The SPF community failed here. Nameservers and associated tool chains shipped with SPF support before the libraries were updated. libspf and libspf2 could have been update the day the type code was allocated as they used libresolv and the type code is just a integer as far as that library is concerned. #ifndef T_SPF #define T_SPF 99 #endif > Note I say this as the person back then trying to convince them to > change from TXT to SPF. Maybe it was the Stockholm Syndrome > (http://en.wikipedia.org/wiki/Stockholm_syndrome) but I have become > sympathetic to the plight (...to overdramatize this.) > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Sun Sep 9 17:36:30 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FBD21F85F9 for ; Sun, 9 Sep 2012 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx1qbo3TMmJ2 for ; Sun, 9 Sep 2012 17:36:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0488B21F85F7 for ; Sun, 9 Sep 2012 17:36:29 -0700 (PDT) Received: (qmail 58394 invoked from network); 10 Sep 2012 00:36:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e419.504d360d.k1209; bh=D1nzpdDWbvrRXgGuxgMWIwDnC3bg3NyZTYZBqPD+aZQ=; b=f3vdVn+WA1PEjJFC6XIPXA/A2TBntUCU5yRl85PdAFN4vp8DtQrCQ3C9TYXU9KwHMS9Hr5CeQ3XXcpomSCEfxHdvwXCEi/Q2fOzSUX3QpHk6IGrROg4WWzTCwOLPes/4P7TYTa3NkCqpU78BCd/T7Pp7mhu8QxuUKK6+5dGk20U= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e419.504d360d.k1209; bh=D1nzpdDWbvrRXgGuxgMWIwDnC3bg3NyZTYZBqPD+aZQ=; b=P2epDWRIQbEuRxRvOv0Ew/QjVXk2e3u8BxcAUjRdqTj/B29SfywmV0alW4WkZY8lwlwjQF13Ee83KLGJUBA7AduT5t6hZXjts4f6KIbdwo5Rs+NW6UbvhIBUo+l+CRrKyMa/8fZFYR8sKMhMWqdwp9feP8VlU0VhHG9QiuvGXno= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 10 Sep 2012 00:36:07 -0000 Date: 9 Sep 2012 20:36:28 -0400 Message-ID: From: "John R Levine" To: "Edward Lewis" In-Reply-To: References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-205317373-1347237389=:41528" Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:36:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-205317373-1347237389=:41528 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > (And, I don't mean to say provisioning is not a problem. It's not the > important one in the SPF case.) Having been there at the time, I can say that if it were easy to provision new RRs, there would have been some chance that type 99 would catch on. Since it wasn't, it was DOA. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-205317373-1347237389=:41528 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTAwMDM2 MjhaMCMGCSqGSIb3DQEJBDEWBBRFtG9V64/lTXruHAvTs7tD88ue2jB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQCOLwfpu8maa46ZUHXkrWo1RRUq993P8VCbnLYSaOjZi7zXvjYseFa5pta/ 9I8AG4dD4MXNoit+CLziHB8HS0Eg5GzAicn23ejqhNotX05+a4ok9SPgGaXX L+AXut0UaPLA84FJeOcebxtHLjBYP2O9cKhdmlwuCjmNYJgqIWVUJhliSfbM zAses/KL/oMfMjqELf3fpKnF7fqi7AGMymqTmq+5UpqO6/DKIOOARM8L485w dJbJGidXGylOvxT5UW89DqN9qWRXyBaVlJmX6FqFJAzM/4Jdep4mhEUz8c8e emODmQvf93Z6Bc9jB+fgsVGdwm9BileyZK3iaGyGFiWf --3825401791-205317373-1347237389=:41528-- From marka@isc.org Sun Sep 9 20:17:41 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808D321F84D6 for ; Sun, 9 Sep 2012 20:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l61x7nkI+ozd for ; Sun, 9 Sep 2012 20:17:41 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2C21F845F for ; Sun, 9 Sep 2012 20:17:40 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 65DDD5F984C; Mon, 10 Sep 2012 03:17:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6c6d:991a:9505:c698]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5CE6A216C6D; Mon, 10 Sep 2012 03:17:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6DE4824A0DEA; Mon, 10 Sep 2012 13:17:17 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> In-reply-to: Your message of "09 Sep 2012 20:36:28 -0400." Date: Mon, 10 Sep 2012 13:17:16 +1000 Message-Id: <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:17:41 -0000 In message , "John R Levine" wri tes: > > > (And, I don't mean to say provisioning is not a problem. It's not the > > important one in the SPF case.) > > Having been there at the time, I can say that if it were easy to provision > new RRs, there would have been some chance that type 99 would catch on. > Since it wasn't, it was DOA. What makes you think having a standardised RR description language will get any more buy in from the registrars than RFC 3597 has had? Most nameserver vendors already support RFC 3597, the exception is Microsoft[1]. This is despite people complaining about the lack of support for nearly a decade now. [1] http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/6d937082-53a3-470a-8407-ddbe75dbc166 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Sun Sep 9 20:43:28 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EA221F8526 for ; Sun, 9 Sep 2012 20:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws808Tin9X3p for ; Sun, 9 Sep 2012 20:43:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 939D021F84F8 for ; Sun, 9 Sep 2012 20:43:24 -0700 (PDT) Received: (qmail 87446 invoked from network); 10 Sep 2012 03:43:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15595.504d61d9.k1209; bh=bXCiugcWybzWnMsiSZqD6+mhFeH4GH/GPoeuRO5cvKs=; b=BnsW5r9/wLGLlXGGgqur8hsGG0Rf5BC+B/d/hOFuL7IMDpXVSi57q+MxN5T4PfQ0RPauQSc2cUczg5AzwAxf4CmmHS97MCTIsVFKdFi2gBkgRezQA38vXy8r1RTubeL3+1Iq35RtrRgk7N80Lk9dH1WZgLEwWIMhJugnJb606UU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15595.504d61d9.k1209; bh=bXCiugcWybzWnMsiSZqD6+mhFeH4GH/GPoeuRO5cvKs=; b=un4HCPHKbtmy2LZyz6hdXib/pXDU3tkkN62O2hWUXvVH6G7zx32qPNhIK3ut3q03nmaGZxtxYdrQvHZGKTtcUg5UJrBMP6tVrbFcfzrcDOXahGMCR8hzjQ58qyM0wlH7bq0oaqpefJ5VOhyunayN/z35mBatD2vG7XPemP9T54A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 10 Sep 2012 03:42:59 -0000 Date: 9 Sep 2012 23:43:21 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:43:28 -0000 > What makes you think having a standardised RR description language > will get any more buy in from the registrars than RFC 3597 has had? Disregarding the detail that no sane person wants to put an SPF record in a TLD, the registrars I know (and yes, I know some) have few customers who are prepared to deal with stuff like this: foo TYPE731 \# 6 abcd ( ef 01 23 45 ) You and I can do it, most people setting up DNS for an organization can't. I sure wouldn't want to do it very often. (I had my DNS provisioning stuff do type 99 records for a while, by the simple but effective kludge of looking for TXT records that started with v=spf1 and adding matching SPF records, but I took them out because too much client software barfed.) The point of my proposal is that it offers a syntax that is at least somewhat possible for normal humans to type, and allows some error checking at the time the data are entered, e.g., numeric values are in range, domain names are syntactically valid. I don't care whether people do that or someone comes up with something better, but telling people to write hex glop suggests an unfamiliarity with normal DNS users. R's, John From marka@isc.org Sun Sep 9 21:12:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8667C21F854C for ; Sun, 9 Sep 2012 21:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka91rhVruXrb for ; Sun, 9 Sep 2012 21:12:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C1AF021F84E7 for ; Sun, 9 Sep 2012 21:12:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B33565F9977; Mon, 10 Sep 2012 04:11:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6c6d:991a:9505:c698]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DBCC7216C25; Mon, 10 Sep 2012 04:11:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CBEB624A14B6; Mon, 10 Sep 2012 14:11:49 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> In-reply-to: Your message of "09 Sep 2012 23:43:21 -0400." Date: Mon, 10 Sep 2012 14:11:49 +1000 Message-Id: <20120910041149.CBEB624A14B6@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 04:12:03 -0000 In message , "John R Levine" wri tes: > > What makes you think having a standardised RR description language > > will get any more buy in from the registrars than RFC 3597 has had? > > Disregarding the detail that no sane person wants to put an SPF record in > a TLD, the registrars I know (and yes, I know some) have few customers who > are prepared to deal with stuff like this: > > foo TYPE731 \# 6 abcd ( > ef 01 23 45 ) > > You and I can do it, most people setting up DNS for an organization can't. > I sure wouldn't want to do it very often. (I had my DNS provisioning > stuff do type 99 records for a while, by the simple but effective kludge > of looking for TXT records that started with v=spf1 and adding matching > SPF records, but I took them out because too much client software barfed.) So there was client software that looked for SPF records then barfed when it got them or client software that made ANY queries then barfed because it had a unknown type in the response or ... > The point of my proposal is that it offers a syntax that is at least > somewhat possible for normal humans to type, and allows some error > checking at the time the data are entered, e.g., numeric values are in > range, domain names are syntactically valid. I don't care whether people > do that or someone comes up with something better, but telling people to > write hex glop suggests an unfamiliarity with normal DNS users. Hex goop is for "immediate use" until the interface can be upgraded. It needs to be there because you still have to get someone else to do something to support new types even if it is updating a configuration file. Nothing has stopped developers doing what you are suggesting anytime in the last 20+ years. What makes you think they will add support for it now just because it is a RFC. It's not like most of the RR types went beyond a the simple set of primatives you have already? This is not to say we wouldn't add support to named for this but I don't think named is the problem here. We already have a not too complicated method of adding new types that others have used. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@taugh.com Sun Sep 9 21:15:03 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9A21F84E7 for ; Sun, 9 Sep 2012 21:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onxHPE8CzZ7K for ; Sun, 9 Sep 2012 21:15:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 121E321F84EF for ; Sun, 9 Sep 2012 21:15:01 -0700 (PDT) Received: (qmail 91704 invoked from network); 10 Sep 2012 04:14:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16637.504d6943.k1209; bh=+eqQQdaEGbO2/MtbfitzgwX7xuQhDgAFu3pHZhdkRFk=; b=fqY+rbIgGCtxpO7nm2khgD6KRm4VRJX4zwlgC2XSIha5gaKeeOwPhheYywLN218zs4HJhu3F95KuuASbHZB3E2jdYEo1ME1bzhVsKhmzsqy+n83H4qEkU0I7hpeP3kDPqQGC50PQEh3HQtRJg/jEH+rtLjJsPiHr6gQ2b/9aBJ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16637.504d6943.k1209; bh=+eqQQdaEGbO2/MtbfitzgwX7xuQhDgAFu3pHZhdkRFk=; b=eTZttiu86QZ49jTLOHhB25yxr8iUfl15NM9UxudyC9kGDe+2YV8FxKkSk4mfb1BnUxwVwKJjKkg3bGTI0Nl08tbjk7SLmZZCMpvejfYYBoazmwpDk6BsKSq1rLK+L73xzuP8UoEmQUUlKXrDpvp+KfuGQAEeyebm9MA2kj17ZSM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 10 Sep 2012 04:14:37 -0000 Date: 10 Sep 2012 00:14:59 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" In-Reply-To: <20120910041149.CBEB624A14B6@drugs.dv.isc.org> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> <20120910041149.CBEB624A14B6@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 04:15:03 -0000 >> of looking for TXT records that started with v=spf1 and adding matching >> SPF records, but I took them out because too much client software barfed.) > > So there was client software that looked for SPF records then barfed when > it got them or client software that made ANY queries then barfed because > it had a unknown type in the response or ... Antique BIND libraries, as I recall. > Nothing has stopped developers doing what you are suggesting anytime > in the last 20+ years. What makes you think they will add support > for it now just because it is a RFC. It's not like most of the RR > types went beyond a the simple set of primatives you have already? Having said "provisioning software" about 100 times already, I give up. R's, John From marka@isc.org Sun Sep 9 21:30:40 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0426D21F854D for ; Sun, 9 Sep 2012 21:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz24hUDFSeZH for ; Sun, 9 Sep 2012 21:30:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0021F854C for ; Sun, 9 Sep 2012 21:30:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AC5D35F997B; Mon, 10 Sep 2012 04:30:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6c6d:991a:9505:c698]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AC141216C6F; Mon, 10 Sep 2012 04:30:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7EC7724A1B3C; Mon, 10 Sep 2012 14:30:24 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120910031717.6DE4824A0DEA@drugs.dv.isc.org> <20120910041149.CBEB624A14B6@drugs.dv.isc.org> In-reply-to: Your message of "10 Sep 2012 00:14:59 -0400." Date: Mon, 10 Sep 2012 14:30:24 +1000 Message-Id: <20120910043024.7EC7724A1B3C@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 04:30:40 -0000 In message , "John R Levine" wri tes: > > Nothing has stopped developers doing what you are suggesting anytime > > in the last 20+ years. What makes you think they will add support > > for it now just because it is a RFC. It's not like most of the RR > > types went beyond a the simple set of primatives you have already? > > Having said "provisioning software" about 100 times already, I give up. Provisioning software has developers. Deciding whether to do something like this or not has been a obvious design question for over a decade now. We thought about whether to take this route back when we were starting with BIND 9 (1998). We decided to go the C code route and have seperate files for each type which had all the type specific code. > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon Sep 10 04:59:23 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6308C21F8666 for ; Mon, 10 Sep 2012 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4Weeu5p6glJ for ; Mon, 10 Sep 2012 04:59:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3121F8658 for ; Mon, 10 Sep 2012 04:59:22 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4EB508A031 for ; Mon, 10 Sep 2012 11:59:21 +0000 (UTC) Date: Mon, 10 Sep 2012 07:59:19 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120910115918.GB83857@mx1.yitter.info> References: <20120907230009.28162.qmail@joyce.lan> <20120908015513.1A6FA248DC8B@drugs.dv.isc.org> <20120909231457.ED5A0249FFF7@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 11:59:23 -0000 On Sun, Sep 09, 2012 at 07:34:43PM -0400, Edward Lewis wrote: > If you think the rules were a no brainer in 2004...ask yourself why > so many changes were made in the wake of the MARID WG issues? Also, go read the namedroppers archives, if you can find them, from that era. They support what Ed is saying. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Sep 10 05:03:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5A21F866C for ; Mon, 10 Sep 2012 05:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE+3xD2CZxPE for ; Mon, 10 Sep 2012 05:03:13 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6521F862B for ; Mon, 10 Sep 2012 05:03:13 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D4C778A031 for ; Mon, 10 Sep 2012 12:03:12 +0000 (UTC) Date: Mon, 10 Sep 2012 08:03:11 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120910120310.GC83857@mx1.yitter.info> References: <20120907113056.6e5496d3@shane-desktop> <20120907141916.GA16938@mx1.yitter.info> <504A92EB.4090306@rancid.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <504A92EB.4090306@rancid.berkeley.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] SPF - case study for process fail or...? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:03:14 -0000 On Fri, Sep 07, 2012 at 05:35:55PM -0700, Michael Sinatra wrote: > I am sure this was discussed in SPFBIS, but I am wondering why they > couldn't have gone the route of MX (vs. A) from the perspective of > the queryer: First ask for the SPF record, and if it doesn't exist, > ask for the TXT record. In this situation, you only have to change > the specification of the software doing the lookups; SPF publishers > can still have the flexibility to use either record. Principle of > least change, etc... Maintaining two records in the system is harder, and makes the system more complicated. The use of TXT seems to be working, and effectively nobody is using the SPF type now. So TXT it is. If people feel strongly about this, I encourage you to make the arguments on the spfbis list, _after_ reading the archives of the discussion from when this was changed. Be prepared to argue with Dave Crocker about the DNS. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Mon Sep 24 11:11:01 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7B61F0429; Mon, 24 Sep 2012 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsITqD28KQ5j; Mon, 24 Sep 2012 11:11:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36C1F040A; Mon, 24 Sep 2012 11:11:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120924181101.31331.42360.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2012 11:11:01 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-09.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:11:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-09.txt Pages : 8 Date : 2012-09-24 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scottr.nist@gmail.com Mon Sep 24 11:16:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D085C21F8807 for ; Mon, 24 Sep 2012 11:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKuxirQbZRn9 for ; Mon, 24 Sep 2012 11:16:01 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98321F87E8 for ; Mon, 24 Sep 2012 11:16:01 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 24 Sep 2012 14:15:29 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.379.0; Mon, 24 Sep 2012 14:13:57 -0400 Received: from [129.6.224.45] ([129.6.224.45]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q8OIFbbf006321 for ; Mon, 24 Sep 2012 14:15:37 -0400 From: Scott Rose Content-Type: multipart/alternative; boundary="Apple-Mail=_C73EAA42-520F-4874-ABE0-D3BE6BB34F56" Date: Mon, 24 Sep 2012 14:15:37 -0400 References: <20120924181101.31331.85562.idtracker@ietfa.amsl.com> To: Message-ID: <48FE5A3D-440C-402D-97B0-5E899A5CFD76@gmail.com> MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [dnsext] Fwd: New Version Notification for draft-ietf-dnsext-dnssec-algo-signal-09.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:16:02 -0000 --Apple-Mail=_C73EAA42-520F-4874-ABE0-D3BE6BB34F56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" This updated version addresses the (single) set of comments we received = from the -08 version. The biggest parts were to strengthen some of the = 2119 language for non-validating stub resolvers and servers reception of = the options. Scott (& Steve) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-dnsext-dnssec-algo-signal-09.txt > Date: September 24, 2012 2:11:01 PM EDT > To: scottr.nist@gmail.com > Cc: steve@shinkuro.com >=20 >=20 > A new version of I-D, draft-ietf-dnsext-dnssec-algo-signal-09.txt > has been successfully submitted by Scott Rose and posted to the > IETF repository. >=20 > Filename: draft-ietf-dnsext-dnssec-algo-signal > Revision: 09 > Title: Signaling Cryptographic Algorithm Understanding = in DNSSEC > Creation date: 2012-09-24 > WG ID: dnsext > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-0= 9.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal > Htmlized: = http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-09 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-09= >=20 > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which digital > signature and hash algorithms they support. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_C73EAA42-520F-4874-ABE0-D3BE6BB34F56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" This = updated version addresses the (single) set of comments we received from = the -08 version.  The biggest parts were to strengthen some of the = 2119 language for non-validating stub resolvers and servers reception of = the options.

Scott (& = Steve)

Begin forwarded message:

Subject: New Version Notification for = draft-ietf-dnsext-dnssec-algo-signal-09.txt
Date: September 24, 2012 = 2:11:01 PM EDT
=

A new version of I-D, = draft-ietf-dnsext-dnssec-algo-signal-09.txt
has been successfully = submitted by Scott Rose and posted to the
IETF = repository.

Filename: = draft-ietf-dnsext-dnssec-algo-signal
Revision: = 09
Title: = = Signaling Cryptographic Algorithm Understanding in = DNSSEC
Creation date: 2012-09-24
WG ID: = dnsext
Number of pages: 8
URL: =             http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsse= c-algo-signal-09.txt
Status: =          http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal
Htmlized:        http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-09Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo= -signal-09

Abstract:
  The DNS Security = Extensions (DNSSEC) were developed to provide origin
=   authentication and integrity protection for DNS data by = using digital
  signatures.  These digital signatures = can be generated using
  different algorithms.  This = draft sets out to specify a way for
  validating = end-system resolvers to signal to a server which digital
=   signature and hash algorithms they = support.





The IETF = Secretariat


scott.rose@nist.gov
+1 = 301-975-8439
Google Voice: +1 = 571-249-3671
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= --Apple-Mail=_C73EAA42-520F-4874-ABE0-D3BE6BB34F56-- From internet-drafts@ietf.org Fri Sep 28 02:24:02 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB221F8578; Fri, 28 Sep 2012 02:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FWGxASLxohn; Fri, 28 Sep 2012 02:24:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D902221F856D; Fri, 28 Sep 2012 02:24:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928092401.32214.95717.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 02:24:01 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-20.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 09:24:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSEC Author(s) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-20.txt Pages : 21 Date : 2012-09-28 Abstract: This document is a collection of technical clarifications to the DNSSEC document set. It is meant to serve as a resource to implementors as well as a repository of DNSSEC errata. This document updates the core DNSSEC documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSEC specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-bis-updates-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From weiler@watson.org Fri Sep 28 02:25:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1715D21F8592 for ; Fri, 28 Sep 2012 02:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qoXFqrzwEir for ; Fri, 28 Sep 2012 02:25:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB2521F8588 for ; Fri, 28 Sep 2012 02:25:50 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q8S9Pn3Q018697 for ; Fri, 28 Sep 2012 05:25:49 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q8S9Pml0018692 for ; Fri, 28 Sep 2012 05:25:48 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 28 Sep 2012 05:25:48 -0400 (EDT) From: Samuel Weiler To: dnsext@ietf.org In-Reply-To: <20120928092401.32214.95717.idtracker@ietfa.amsl.com> Message-ID: References: <20120928092401.32214.95717.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 28 Sep 2012 05:25:49 -0400 (EDT) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-20.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 09:25:51 -0000 This revision clarifies some language in Section 4.1 in an attempt to resolve GenART comments. There is nothing to see here; move along. -- Sam From iesg-secretary@ietf.org Fri Sep 28 11:47:10 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB50A21F85A0; Fri, 28 Sep 2012 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EteSyb5A3F-9; Fri, 28 Sep 2012 11:47:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694EB21F84DC; Fri, 28 Sep 2012 11:47:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928184710.15284.94169.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 11:47:10 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Domain Name System (DNS) IANA Considerations) to Best Current Practice X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 18:47:11 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Sun Sep 30 07:53:25 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7621F861B; Sun, 30 Sep 2012 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHp1mvVn5Qlm; Sun, 30 Sep 2012 07:53:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF421F845A; Sun, 30 Sep 2012 07:53:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120930145325.21053.67854.idtracker@ietfa.amsl.com> Date: Sun, 30 Sep 2012 07:53:25 -0700 Cc: dnsext@ietf.org Subject: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 14:53:25 -0000 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Extension Mechanisms for DNS (EDNS(0))' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS(0) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. This IETF Last Call is a second Last call for this document, to address process issues with the first Last Call. The document has been updated since the first Last Call to address comments received during the Last Call and during IESG review. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ballot/ No IPR declarations have been submitted directly on this I-D.