Re: [dnsext] Obsoleting SPF RRTYPE

Patrik Fältström <paf@frobbit.se> Tue, 30 April 2013 04:42 UTC

Return-Path: <paf@frobbit.se>
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 4BC1021F987E for <dnsext@ietfa.amsl.com>; Mon, 29 Apr 2013 21:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1KJy89M3Ms9 for <dnsext@ietfa.amsl.com>; Mon, 29 Apr 2013 21:42:55 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C134A21F9AD9 for <dnsext@ietf.org>; Mon, 29 Apr 2013 21:42:30 -0700 (PDT)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id 9DDB721232; Tue, 30 Apr 2013 06:42:26 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org>
Date: Tue, 30 Apr 2013 06:42:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B2DEDE4-1038-4A24-8A7C-213223A64CF9@frobbit.se>
References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <alpine.BSF.2.00.1304242309150.38677@joyce.lan> <46778ED3-35A2-44B4-BE3C-AAC4F7B314FF@virtualized.org> <92BBD83F-676D-4B05-B927-4101DD5CAD3E@neustar.biz> <72539563-0FA7-4C5E-901B-A5AFCE9CE038@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1503)
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, "dnsext@ietf.org Group" <dnsext@ietf.org>
Subject: Re: [dnsext] Obsoleting SPF RRTYPE
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 04:42:56 -0000

On 30 apr 2013, at 05:22, David Conrad <drc@virtualized.org> wrote:

>> The only concern is that pushing more data into TXT records is that, if more than one application does this and involves the same name, we are increasing the number of large RRsets pushed around.
> 
> Well, no. That's not the only concern:
> 
> 1) it moves the mechanism to uniquify a DNS response out of the DNS library and into the application, forcing every protocol-specific library or application to have to deal with uniquifying the response in their own unique (and undoubtedly in some cases fascinating) way;
> 
> 2) given individual RR order within an RRset is not guaranteed, it significantly complicates TXT RDATA parsing logic for any application that cares about TXT RRs;
> 
> 3) It means you've reduced the amount of usable space in the RDATA since you have to have some unique string in the RDATA to key off of; and
> 
> 4) because other protocols may use TXT at the same (unfortunately common) ownername, it becomes more probable that the size of the response will go over the 512 limit resulting in fragmentation or fallback to TCP increases, which imposes potential load and reachability issues, not just for SPF but for any other protocol that is using TXT at that ownername

As I have written before:

5) As multiple different usages of RR in DNS use the same owner and class, separation of the records in the query/response must be done via prefix on the owner. This implies multiple records can end up on different sides of a zone cut where a DNSSEC administrative boundary is located. For example, the MX might be signed, but the TXT for the same domain, but with a prefix, might be unsigned. The security implications of such differences in DNSSEC implications (key rollower etc) has not been investigated. I believe it is a weakness, or rather, it is a strength that all records that are "similar" can have the same owner and because of that be in the same zone.

It was not a coincidence I took the initiative to write RFC 5507. I am _really_ concerned over use of TXT the way it is done by the SPF "solution".

   Patrik