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

Mark Andrews <marka@isc.org> Thu, 09 February 2017 20:45 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 93FBE12941A for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 12:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rris08IWfcdA for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 12:45:13 -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 7F06F12940D for <dnsop@ietf.org>; Thu, 9 Feb 2017 12:45:13 -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 B47503493ED; Thu, 9 Feb 2017 20:45:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A2186160042; Thu, 9 Feb 2017 20:45:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 88D0916006C; Thu, 9 Feb 2017 20:45:10 +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 lJNfqoTvdWsP; Thu, 9 Feb 2017 20:45:10 +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 A6F7E160042; Thu, 9 Feb 2017 20:45:09 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BC40D6365CBE; Fri, 10 Feb 2017 07:45:06 +1100 (EST)
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com> <20170208052544.862956356F33@rock.dv.isc.org> <FFAFD844-824C-44EA-A4B1-1AD28B4FE95C@fugue.com> <20170208060208.8C8E1635864D@rock.dv.isc.org> <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com> <20170208194208.DB02C635DD72@rock.dv.isc.org> <CAH1iCipA5nvWJqjdGUwJeeT_eU8EH8VYJU2hX1hJoiTb617K8Q@mail.gmail.com> <20170209163123.56hdbzaluekmvbh7@nic.fr> <20170209195722.DC1AB636586C@rock.dv.isc.org> <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com>
In-reply-to: Your message of "Thu, 09 Feb 2017 12:14:30 -0800." <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com>
Date: Fri, 10 Feb 2017 07:45:06 +1100
Message-Id: <20170209204506.BC40D6365CBE@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k12LRwuwBcQR-qWPerhAnhvdL50>
Cc: Ted Lemon <mellon@fugue.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
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: Thu, 09 Feb 2017 20:45:15 -0000

In message <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com>om>, Brian Dickson writ
es:
> Maybe DNS authority server software could auto-generate TXT records for what=
>  would otherwise be ENTs, or zone administrators could add them manually,
> 
> E.g. ent.example.com TXT "This object intentionally left blank."
> 
> This avoids the ENT issue.
> 
> I can't think of any way that would break anything. The issue with ENTs is t=
> hat they have children, which are not changed or harmed. Preventing the erro=
> neous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be=
>  returned.
> 
> Brian

Brian.
	There is only one time you can trust a NXDOMAIN to mean
there is no data under it.  That is when it validates as secure.

At the moment we have Ted saying that if you want privacy you MUST
also turn on DNSSEC validation and implement QNAME minimisation and
implement agressive negative caching (still a I-D).  This is all
because of ungrounded fears of people using DNS as a way to do a
opt-in experimental naming in .alt where we intend to have experimental
opt-in naming services.  Add to that it is suggested that we create
yet another TLD (.lcl) where such services would be allowed.

Mind boggling inconsistancy.

Mark


> Sent from my iPhone
> 
> > On Feb 9, 2017, at 11:57 AM, Mark Andrews <marka@isc.org> wrote:
> >=20
> >=20
> > In message <20170209163123.56hdbzaluekmvbh7@nic.fr>fr>, Stephane Bortzmeyer w=
> rites
> > :
> >> On Wed, Feb 08, 2017 at 12:36:23PM -0800,
> >> Brian Dickson <brian.peter.dickson@gmail.com> wrote=20
> >> a message of 258 lines which said:
> >>=20
> >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=3D
> =
> 1.
> >>> - cache the response, and as appropriate, re-query periodically.
> >>> - If a query for <anything>.onion is received, reply with the authentica=
> ted
> >>> denial of existence from the root (cached in step 2)
> >>=20
> >> Note that, if you implement RFC 7816 and RFC 8020, you already have
> >> this behavior. No work for us :-)
> >=20
> > Only if you are willing to break lookups for names where there are
> > missing delegations in parent zone and the parent and child zones
> > share the same nameservers or the nameserver just misimplements ENT
> > or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist
> > with RFC 2535).  All of these result in NXDOMAIN for ENT.
> >=20
> > RFC7816
> >=20
> >   A problem can also appear when a name server does not react properly
> >   to ENTs (Empty Non-Terminals).  If ent.example.com has no resource
> >   records but foobar.ent.example.com does, then ent.example.com is an
> >   ENT.  Whatever the QTYPE, a query for ent.example.com must return
> >   NODATA (NOERROR / ANSWER: 0).  However, some name servers incorrectly
> >   return NXDOMAIN for ENTs.  If a resolver queries only
> >   foobar.ent.example.com, everything will be OK, but if it implements
> >   QNAME minimisation, it may query ent.example.com and get an NXDOMAIN.
> >   See also Section 3 of [DNS-Res-Improve] for the other bad
> >   consequences of this bad behaviour.
> >=20
> > Mark
> >=20
> > --=20
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org