Re: [dnsext] the same in old days, was making names the same NEED protocol changes?

John Levine <johnl@iecc.com> Sun, 27 February 2011 18:26 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3B13A6A1E for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 10:26:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.606
X-Spam-Level:
X-Spam-Status: No, score=-110.606 tagged_above=-999 required=5 tests=[AWL=0.593, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6gpSbLdki7c for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 10:26:24 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id F22113A6A19 for <dnsext@ietf.org>; Sun, 27 Feb 2011 10:26:23 -0800 (PST)
Received: (qmail 5466 invoked from network); 27 Feb 2011 18:27:21 -0000
Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Feb 2011 18:27:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=198a.4d6a9788.k1102; i=johnl@user.iecc.com; bh=aTsiwqJjIrAPyKpdYxlNog7TdN9sW8RR2UuJ4UR0Qb8=; b=AUeop+UOsnpMsGrlSG8ZeooiL85JThfVL57MANuypCZlwBQ+tndYAsDcFs3uXNVLcnd+bc+c5piy3AA06O0KTxW6ti9NUCvNCM8qdZ5BCDvCp+reMiUIxz/N+LpmhNCswjNRYsEfKmdH8tsnC1M/1fpHXhslZLFZm0puXdjaHkk=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: Sun, 27 Feb 2011 18:27:20 -0000
Message-ID: <20110227182720.6537.qmail@joyce.lan>
From: John Levine <johnl@iecc.com>
To: dnsext@ietf.org
In-Reply-To: <alpine.LSU.2.00.1102251802350.5244@hermes-1.csi.cam.ac.uk>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 27 Feb 2011 18:26:25 -0000

>So far as I can tell the main question is, what is the question and is
>BNAME the answer?

Looking back into the mists of history (that would be the 1980s for
you old timers), for about the first decade of the DNS, servers didn't
care what their names were.  If you want to add a new name to a TELNET
or FTP or SMTP or POP or IMAP server, just add an A or CNAME record
and you're done.  Even web servers didn't care about their names until
HTTP 1.1 and HTTPS in the mid 1990s.  Mail servers always knew what
domains they could handle mail for, but the CNAME rule pushed alias
resolution into mail clients.  For most purposes, the client handed
the name to the DNS, the DNS gave back an answer that let the client
connect to the server, and that was it.

But life now is not so simple.  We have several major protocols, mail,
http, and https, that pass domain names as part of the data stream
that are not (currently at least) resolved by DNS queries.

When I read a lot of the arguments here, particularly the ones about
what TLD operators want, it's like being in a time warp.  If it were
still 1987, and the only problem were locating the server, then
something like BNAME would probably do it.  But it's not, if we don't
also have a plan for the protocols with domain names in the data
stream, it's a cruel joke on the users.

If the question is how can we make one subtree an alias that resolves
to the same DNS results as a canonical subtree AND allows the
application servers to tell what names are aliases to a canonical
name, BTREE is pretty close.  The primary shortcoming I see is a
security issue: anyone can set a BNAME to make a random name
equivalent to one of mine.  It's possible to handle this outside the
DNS, by manually configuring the server to know what names it can
handle, or hackery, e.g., only accept BNAMEs served from specific name
servers that we trust.  But that's not great for users, since they
will see baffling error messages like "mail relay refused".

So I'd also want some way for the canonical domain to state in the DNS
what aliases it accepts.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly