[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