Re: [DNSOP] Alternative Special-Use TLD problem statement draft

"Adrien de Croy" <adrien@qbik.com> Wed, 06 April 2016 20:48 UTC

Return-Path: <adrien@qbik.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6E512D0BC for <dnsop@ietfa.amsl.com>; Wed, 6 Apr 2016 13:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92zHG2sNKEv0 for <dnsop@ietfa.amsl.com>; Wed, 6 Apr 2016 13:48:22 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D99112D149 for <dnsop@ietf.org>; Wed, 6 Apr 2016 13:48:20 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v8.5.6 (Build 4877)) with SMTP id <0000692472@smtp.qbik.com>; Thu, 07 Apr 2016 08:48:19 +1200
From: Adrien de Croy <adrien@qbik.com>
To: Philip Homburg <pch-dnsop@u-1.phicoh.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Date: Wed, 06 Apr 2016 20:48:19 +0000
Message-Id: <em11200959-d7c7-42af-95ce-93dfe4d4b0a9@bodybag>
In-Reply-To: <m1anp1K-0000CzC@stereo.hq.phicoh.net>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/JKrrQm9dposecwdiBS7stRWMeWo>
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Adrien de Croy <adrien@qbik.com>
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Wed, 06 Apr 2016 20:48:24 -0000


------ Original Message ------
From: "Philip Homburg" <pch-dnsop@u-1.phicoh.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 7/04/2016 3:05:26 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>In your letter dated Wed, 6 Apr 2016 09:21:31 -0300 you wrote:
>>>  Strong dissensus here. The problem is there is no safe way to have 
>>>AND
>>>  KEEP such a name.
>>
>>Also, it would make very difficult to DNS programmers to keep track of
>>all these "special but not special" domain names.
>
>Personally, I consider naming systems developed outside the IETF a 
>problem.
>
>There should be no register, because they should not exist.
+1

>
>So any hint that there is a process for non-IETF naming systems should
>be removed.
>
>Naming at the root of the name space should develop very slowly. Slow
>enough that everybody (local name resolution, but also security 
>mechanisms)
>can adapt.
>
>These systems should be considered carefully for all implications 
>before they
>are deployed. And not just pop up.
I agree.

DNS namespace has worked basically unchanged for decades.

It's battle-hardened.

Now we decide that the DNS namespace is the one and only namespace and 
that we want other resolution protocols so therefore the DNS namespace 
has to be perverted.

And when I see arguments like the IETF should assign root names so that 
organisations who can't afford lawyers can retain perpetual rights over 
a branch of the namespace I have to shake my head.

At the very least can we not segment this off into a single root?

E.g.

have a separate registry for other protocols which all fit under .notdns

I think the security implications of a resolver checking some internet 
source for a machine readable list of the latest special use names have 
not even been considered, and I think it has the potential for some 
serious problems.  What problem(s) are we trying to solve, and what 
problems are we creating by trying to solve it.

Adrien

>
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop