Re: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

Mark Andrews <> Fri, 04 July 2008 22:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 75FFE3A6AAA; Fri, 4 Jul 2008 15:34:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 642613A6994 for <>; Fri, 4 Jul 2008 15:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cu9EAwpb34D3 for <>; Fri, 4 Jul 2008 15:34:55 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by (Postfix) with ESMTP id 14F923A681E for <>; Fri, 4 Jul 2008 15:34:54 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m64MYrd3061224; Sat, 5 Jul 2008 08:34:54 +1000 (EST) (envelope-from
Message-Id: <>
To: John C Klensin <>
From: Mark Andrews <>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
In-reply-to: Your message of "Fri, 04 Jul 2008 14:35:41 -0400." <795604F9E96F8D31B307B8E1@p3.JCK.COM>
Date: Sat, 05 Jul 2008 08:34:53 +1000
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> So the "problem" isn't whether some string not listed in 2606
> can be allocated, it is how it is used after it is allocated.
> And _that_ situation has a lot more to do about "buyer beware"
> and understanding of conflicting expectations about use than it
> does about ownership. 
>     john

	I really wish it was *just* "buyer beware".  If http://museum/
	only works for some clients and not other then there really
	isn't a problem.  By "works" here I mean connects to or nowhere.

	The problem is that it isn't just "buyer beware".  If the
	buyer adds any records are looked up by search mechanisms
	as a part on normal application activity, A, AAAA and MX
	are simple examples, then *ALL* the users of the Internet
	need to be aware that they are there.

	This is a security problem, not a buyer beware problem.

	This is a namespace clash and namespace clashes are bad for
	many reasons.

	Now as far as I can see there are two solutions which attack
	the problem from different ends.

	1. ban the adding of any records which meet the above criteria.
	2. rewrite resolvers to not lookup single labels against the

	Note banning would have to be described is a manner that
	didn't preclude the negative advertisement of a service.
	It would also have to be writen to exclude records that a
	looked up with a prefix added.

	Also what is the penalty for adding banned records?


; <<>> DiG 9.3.4-P1 <<>> museum
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61108
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;museum.				IN	A

museum.			86034	IN	A

museum.			22099	IN	NS
museum.			22099	IN	NS
museum.			22099	IN	NS
museum.			22099	IN	NS
museum.			22099	IN	NS

;; Query time: 3 msec
;; WHEN: Sat Jul  5 08:22:30 2008
;; MSG SIZE  rcvd: 162

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET:
Ietf mailing list