Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document)

Keith Moore <> Wed, 19 October 2011 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18DE321F8B4E; Wed, 19 Oct 2011 06:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yNFuZRJLHH-g; Wed, 19 Oct 2011 06:48:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 22A4421F8B5C; Wed, 19 Oct 2011 06:48:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B4F5420E58; Wed, 19 Oct 2011 09:48:49 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([]) by compute3.internal (MEProxy); Wed, 19 Oct 2011 09:48:49 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=9t0F312M2ZXsV+O5xsM0MIAhPUU=; b=uP 0PZPHXPQoD9Bd8L6H5ZvS2sdmUhJiIIC2WPD8hVXXx99aykrh2i7b4oFW7+55p3e RpLMKEA+OoC1IkFf98XPpEPBD0luhyXcKSywJd6YWNyj9oa/ajz0IEkZsAQ6AW+Y k8KcxkpFR86/utCNVrTuC3tez7LaW3By1iUKZIHwk=
X-Sasl-enc: uomQefLftWEkbnnMVAiBfZec6wUFII8JnV/hVNkHhdy4 1319032129
Received: from [] ( []) by (Postfix) with ESMTPA id 76B1F407CA3; Wed, 19 Oct 2011 09:48:48 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <>
In-Reply-To: <>
Date: Wed, 19 Oct 2011 09:48:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <> <> <> <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [mif] bare names (was: [dnsext] 2nd Last Call for MIF DNS server selection document)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 13:48:51 -0000

On Oct 19, 2011, at 9:26 AM, Andrew Sullivan wrote:

> Note: I trimmed the cc:s down to just the lists, but if we're going to
> pursue this dicussion we probably ought to follow up in mif, since
> that's where the draft comes from.  That's why I set reply-to.  Also,
> I sent this first from the wrong address, so apologies to those who
> see it twice.
> On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote:
>> I don't see why IETF should give a flying *#&(*#$ what the owners of
>> brand-name gTLDs want.  Brand-name gTLDs are an exceedingly stupid
>> idea, and treating single label names as anything other than local
>> abbreviations flies in the face of 25+ years of practice.
> If you said, "25+ years of practice illustrating how broken the
> search-path mechanism is," I'd agree with you.

I agree that search paths are somewhat broken.   What's not broken is the idea of using single-label names as local names.  

> I think it is largely true that single-label domain names are going to
> fail to work in all sorts of amusing ways that will surprise gullible
> people who forked over a pile of cash for the privilege of registering
> them.  Nevertheless, the search path mechanism has never worked very
> well and is notoriously unreliable in the face of split-brain DNS.

split-brain DNS is an abomination that should be eradicated from the planet.

> Still, too many people continue to rely on the search path for this
> document to be the place to deprecate it.  But I agree with Ray (and
> apparently Paul Vixie) that the mechanism ought to go away.

I don't think it should necessarily go away.  But perhaps it needs to be better defined, and/or more advice needs to be given to applications about how to deal with single-label names.

> Now that Ray has mentioned it, however, perhaps a sentence along these
> lines in the second paragraph of 4.6 would be useful:
>    It should be noted that the DNS search list mechanism may cause
>    surprising results when used with more than one network at a time.
> That addresses the other point that Ray was making: search list-style
> bare names are often broken if you're not on the right network, and
> the point of this draft is precisely that you're _not_ on only one
> network, so it isn't clear what "the right network" is.

and sometimes, single-label names are set up to work correctly on multiple networks - the salient point being that the meaning of the name might be inherently context-sensitive.

>> The best thing that IETF could do is to make sure that use of
>> single-label gTLDs is so unreliable that no megacorporation would
>> dare use them.
> And clearly that will work, because the IETF has a long record of
> success of standing before the tide and telling it to stop.

this isn't a tide.  this is a small number of parties bent on abuse of the Internet.  they deserve to fail.