Re: [DNSOP] Services and top-level DNS names

Mark Andrews <Mark_Andrews@isc.org> Mon, 07 July 2008 01:38 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3573A69DD; Sun, 6 Jul 2008 18:38:32 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E0E3A69DD for <dnsop@core3.amsl.com>; Sun, 6 Jul 2008 18:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599]
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 T7S6GDCfuWep for <dnsop@core3.amsl.com>; Sun, 6 Jul 2008 18:38:31 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id AD7B43A69B0 for <dnsop@ietf.org>; Sun, 6 Jul 2008 18:38:30 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m671cOU1073576; Mon, 7 Jul 2008 11:38:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807070138.m671cOU1073576@drugs.dv.isc.org>
To: Andras Salamon <andras@dns.net>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Mon, 07 Jul 2008 02:00:14 +0100." <20080707010014.GA1893@dns.net>
Date: Mon, 07 Jul 2008 11:38:24 +1000
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Services and top-level DNS names
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

> On Sat, Jul 05, 2008 at 01:11:36AM -0400, Brian Dickson wrote:
> > That's precisely why it makes sense to think about the partial name 
> > problem, before big problems happen for lots of ISPs.
> 
> My feeling is that search lists for DNS are a bad optimization that
> should never have happened.  After publication of RFC 1535, they
> should have been removed altogether, instead of being half-patched.
>     ftp://ftp.rfc-editor.org/in-notes/rfc1535.txt
> 
> I routinely dot-terminate domain names and disable search lists,
> and I believe software should treat any given domain name as it is
> presented, without trying to second-guess the intent.  Software should
> not try to guess intent when the syntax is unambiguous.

	no dots == local (search)
	dots == global unique

	It's only when you start treating one as the other that you
	get into problems.  This can be enforced in the getaddrinfo()
	and friends by not looking up single label tokens against
	".".  "localhost" is solvable before anyone complains about it.

> It is way too late to catch this particular horse, but removing bad
> optimizations from current software releases would still be a useful
> step to take.  It would certainly be better than continuing to keep
> them around due to some notion that inertia is invincible.

	To get rid of searching you also need to get rid of alternate
	name spaces (NIS, /etc/hosts).

	We really need to provide / encourage mechanisms for home
	networks to get domains for $0 additional cost.  With IPv6
	we will be connecting networks, not machines.  ISP's need
	to come up with schemes which can be used to plug home
	networks into the global DNS.  ISP's are going to have to
	support reverse IPv6 zones (delegate/serve).  It's only a
	small additional step to support the forward zones in
	addition to reverse zone.

	e.g.
		<identifer>.<isp>.net -> <machine>.<identifer>.<isp>.net
	or
		<identifer>.home.<isp>.net ->
			 <machine>.<identifer>.home.<isp>.net

	Where <identifer>.<isp>.net or <identifer>.home.<isp>.net
	is a dynamic zone.  <identifer> may or may not be the account
	identifier.

	Mark

> -- Andras Salamon                   andras@dns.net
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop