[dns-dir] How bad an idea is this?
Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 09 July 2012 18:22 UTC
Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dns-dir@ietfa.amsl.com
Delivered-To: dns-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35CC11E8119 for <dns-dir@ietfa.amsl.com>; Mon, 9 Jul 2012 11:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level:
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-1.538, BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
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 l0j8B4FIXm0R for <dns-dir@ietfa.amsl.com>; Mon, 9 Jul 2012 11:22:48 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 356D811E8118 for <dns-dir@ietf.org>; Mon, 9 Jul 2012 11:22:45 -0700 (PDT)
Received: from mail.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 441818A031 for <dns-dir@ietf.org>; Mon, 9 Jul 2012 18:23:09 +0000 (UTC)
Date: Mon, 09 Jul 2012 14:23:07 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-dir@ietf.org
Message-ID: <20120709182306.GF75702@mail.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [dns-dir] How bad an idea is this?
X-BeenThere: dns-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-dir>
List-Post: <mailto:dns-dir@ietf.org>
List-Help: <mailto:dns-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 18:22:50 -0000
Dear colleagues, I wasn't sure where else to send this: it's not actually about the protocol, and it's not about operations as such, but it is about the (ab)use of the DNS. Suggestions for a better target welcome, but reactions to the suggestion below are even more welcome. In draft-sullivan-domain-origin-assert-00, I outline a mechanism to make claims about whether a given DNS name lies within the same administrative realm as another name. By "same administrative realm", what I mean to say is that the services at that name and at some other name are somehow subject to the same control, &c. The standard example of where this might help is with the "cookies problem", but I don't think we have to be too creative to think of ways in which it would be helpful to know that services at different names are related to one another in important ways, without really being "the same service". I received a number of comments about that draft, not least of which was that to be useful it needed finer granularity. (More exactly, the mechanism is apparently worthless without being able to specify it by scheme, port, _and_ name.) That would be easy given that I was originally inclined to create a new RRTYPE, except that I also heard over and over again that new RRTYPEs are not deployable: the provisioning software doesn't know how to do it. I have some sympathy for this, since Dyn (who partly pays for the roof over my head) has plenty of clueful staff, but avoids completely unknown RRTYPE support in its consumer-grade offerings because of the potential support headaches. As a result of this, I have been toying with reusing the SRV RRTYPE, adding some additional underscore labels to the front. This idea makes me want to tear at my clothes, but I haven't been able to think of ways in which it actually breaks anything. Does anyone have such an argument? In addition (just to make you even more queasy), it seems to me that the mechanism is going to have to be able to say "for everything under this name, the same label under that name". A wildcard isn't exactly going to work, particularly on the target side of the SRV record. I was thinking of inventing a new "prefix" (like the xn-- in IDNA) to express this sort of thing. It's yet more evidence, I think, that a real RRTYPE with its own semantics is just going to be necessary, but that probably means the mechanism will never get deployed. Thoughts? A -- Andrew Sullivan ajs@anvilwalrusden.com
- [dns-dir] How bad an idea is this? Andrew Sullivan
- Re: [dns-dir] How bad an idea is this? Patrik Fältström