Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

"Adrien de Croy" <adrien@qbik.com> Wed, 30 March 2016 04:38 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 87E5D12DCE5 for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2016 21:38:09 -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 IZ9aak6uS90b for <dnsop@ietfa.amsl.com>; Tue, 29 Mar 2016 21:38:07 -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 9018E12DC6D for <dnsop@ietf.org>; Tue, 29 Mar 2016 21:38:06 -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 <0000685742@smtp.qbik.com>; Wed, 30 Mar 2016 17:38:03 +1300
From: Adrien de Croy <adrien@qbik.com>
To: John R Levine <johnl@taugh.com>
Date: Wed, 30 Mar 2016 04:38:03 +0000
Message-Id: <em8db5dc2e-8bce-461b-9982-359b9df7c443@bodybag>
In-Reply-To: <alpine.OSX.2.11.1603292212470.42318@ary.lan>
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/f7DedGea9hk5z4Qz6pj25idL8QE>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
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, 30 Mar 2016 04:38:09 -0000

Just looking at the justification for all of this

from that draft which quotes RFC2826

"To remain a global network, the Internet requires the existence of a 
globally unique public name space. The DNS name space is a hierarchical 
name space derived from a single, globally unique root."

"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement, and 
some facility for reservation of top-level requirement, and some 
facility for reservation of top-level
domains in the DNS is necessary."

I couldn't even find the second para in RFC2826 (search didn't yield 
it), neither does it follow logically from the first paragraph in any 
case.  Google finds the second para only in the problem statement which 
quotes it from RFC2826.  Maybe it was in an earlier draft of 2826, but 
I'd still expect it to be in google somewhere.

Is this the justification for having an extensible registry of special 
names?

Cheers

Adrien





------ Original Message ------
From: "John R Levine" <johnl@taugh.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 30/03/2016 3:17:07 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>>>I have to say I'm startled to see that people here aren't aware that
>>>.onion is entirely handled in applications.
>>
>>a google search for "DNS .onion leaks" comes up with many links, many 
>>relating to reported bugs in browsers.
>
>Yeah, that's why it'd be nice if the DNS resolver rejected them rather 
>than telling the world what you were trying to look for in .onion land.
>
>>So I don't know if we can truly claim that resolvers are being 
>>shielded from .onion by the applications.  Maybe it's better now, it 
>>would be interesting if Symantec were to update this.
>
>They aren't.  That's why it'd be nice to make that bug less leaky.
>
>>>don't leak into the DNS.  The only thing that anyone's asking DNS
>>>developers to do is to fail .onion requests rather than forwarding
>>>them along.
>>That's the problem.  Creating new requirements for DNS developers to 
>>do anything at all is a huge problem.
>
>It's not a requirement.  It's a request.  I expect it's a lot easier 
>than whatever you have to do to deal with .local.  If we adopt .alt, 
>you can stub that out too and with any luck you're done.
>
>>Having said that, I wish there was a way with a single DNS lookup one 
>>could resolve both/either IPv4 and/or IPv6 addresses from a name with 
>>a single query (e.g. the "give me any version address" query), rather 
>>than having to make 2 lookups and fail over etc.  Would basically 
>>halve the amount of DNS traffic on the network and resolve a lot of 
>>pathological cases.
>
>Surely you've been reading the draft-vavrusa-dnsop-aaaa-for-free 
>thread.
>
>R's,
>John
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop