Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark Andrews <marka@isc.org> Mon, 06 February 2017 22:24 UTC

Return-Path: <marka@isc.org>
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 88AF4129658 for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 14:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 RUPKLB_UYYnl for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 14:24:38 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 E52FB129656 for <dnsop@ietf.org>; Mon, 6 Feb 2017 14:24:37 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 35E543493CF; Mon, 6 Feb 2017 22:24:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 25004160048; Mon, 6 Feb 2017 22:24:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E5D75160076; Mon, 6 Feb 2017 22:24:33 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id apRRQhdfEHOa; Mon, 6 Feb 2017 22:24:33 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 61844160048; Mon, 6 Feb 2017 22:24:33 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DAC32631951F; Tue, 7 Feb 2017 09:24:29 +1100 (EST)
To: Ralph Droms <rdroms.ietf@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com>
In-reply-to: Your message of "Mon, 06 Feb 2017 16:46:53 -0500." <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com>
Date: Tue, 07 Feb 2017 09:24:29 +1100
Message-Id: <20170206222429.DAC32631951F@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gBdHiqWQWlem93aeBSWr8FwXaDk>
Cc: dnsop@ietf.org, Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 06 Feb 2017 22:24:39 -0000


In message <203E2636-1391-4100-9B1A-4F2DCC9A32BB@gmail.com>, Ralph Droms writes:
> 
> > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> > 
> > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
> >> Mark, I don't think you've actually given an answer to my question.
> >> I understood that .ALT was for alternative naming systems, not for
> >> DNS locally-served zones.   We simply need to decide whether or not
> >> that's true.   I think either answer is fine; we just need to pick
> >> one.
> > 
> > I agree with this.  I will say that, when I first started working on
> > this with Warren, it was really for the use-case where people would
> > tread on the namespace as a protocol switch -- we wanted a sandbox in
> > which things like onion could live.  My memory is that only after that
> > did we start thinking of a sort of 1918-style part of the DNS as
> > well.  That may have been a mistake, since as this discussion is
> > showing the properties of an in-protocol, in-DNS namespace without
> > delegations are somewhat different to alternative-protocol uses that
> > do not rely on the DNS at all.
> 
> Andrew - I have come around to agree that the properties and requirements
> of non-DNS resolution mechanisms are different from those of DNS re
> solution that does not use the root zone as a resolution context.  I believe
> that these properties and requirements cannot be served by the single .alt
> delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt
> for use of non-DNS resolution mechanisms.
> 
> How to proceed with DNS resolution that does not use the root zone as a
> resolution context is open for discussion.
> 
> - Ralph

Whether a DNS transport is use or not for the names.  Any scheme
where names in use needs to have a insecure delegation if we expect
recursive server to answer for that namespace even if it is just
to stop query / name leaks.  That is basic DNSSEC.

.ONION needs this treatment.  If the ISP's recursive server is
answering for leaked .ONION names and the ISP's clients validating
recursive server is forwarding to the ISP's server (this is a common
configuration for some Linux distributions) then there will be
reties to all the ISP's servers.

No set of systems, when configured as specified by RFC, should ever
result in SERVFAIL being returned.  That is just poor engineering.
That will have the punters chasing configuration bugs that don't
exist.

Mark

> > Best regards,
> > 
> > A
> > 
> > -- 
> > Andrew Sullivan
> > ajs@anvilwalrusden.com
> > 
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> 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: marka@isc.org