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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 09 February 2017 20:14 UTC

Return-Path: <brian.peter.dickson@gmail.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 E948D129C71 for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 12:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4x9w7E5AVFh3 for <dnsop@ietfa.amsl.com>; Thu, 9 Feb 2017 12:14:32 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB580129C63 for <dnsop@ietf.org>; Thu, 9 Feb 2017 12:14:32 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id f144so2935243pfa.2 for <dnsop@ietf.org>; Thu, 09 Feb 2017 12:14:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w8OVUCEFXfWDzqms/NHDcl5NR1bDLyPOzPUywpSrZNc=; b=UW2VhB1kSCMLuEiSuo/afie8Ri1LR51QnHFxxbk65vJlDmet9fcIZAXlTSmzvOxg5c dk2Q77rXrQwLhDREzMj9KvIEk+C+vJRE9fdaAdmV7ZxIjsY1+eD5sUH1buGOHl1udREE kl5vp/0pN48ujsjV1+3uH1XE2ZIE76uJAzNK59gGLAKjnUOIpe0zejuiKjMwiJyykpuk kR86xhYiQJJFy/utzzUu53uaGJhKLEBYVXW19bevE8b1nH6gKgz4Bn5EmyL0A2doRjCu Bq7z1jRGb2NRa4C2Hh16V9I31GOr6q7hNVnWV/aWgcSispkk+3tNCNW2zyjnarx7JyIZ Z77A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w8OVUCEFXfWDzqms/NHDcl5NR1bDLyPOzPUywpSrZNc=; b=ff2MP3Qm7v/CC9N9e+sPXS2hof3JTh4cvGZd/dXJCLuAHBjV5RJa3YMjZvgHZyXheG jkQUkMalz3W5wsXD6GrXih1E1TTQUl7LODpeuaCaikhdC6gs9nG/v3x7nve7RpG7idOI kjujMZ3Z6PublZk58Veyqs6apOS/QqhfGU88yC7gSI5POe01Ff1+Tgzm6Bkqir5fiES9 5i3ITfpx4+MWTGjGNaq3LsS1wYZPGdJFatL0MReZYJi9eRePdH4sDK0qQJInMWkjPqwW atJcY0rbppeYR1HULO+c0j8nJh4K09lDlcYDV9Uw/a8ASgmvqo/uaCJSA7uKdjAqVRFv M4zQ==
X-Gm-Message-State: AMke39kAkEoUyteE6MVol2PN14H98MgkinnmtZLhRyFdAHaI7vSxtQHB+1jAxh53L+AgYQ==
X-Received: by 10.98.0.143 with SMTP id 137mr5621937pfa.173.1486671272226; Thu, 09 Feb 2017 12:14:32 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id z127sm31224146pgz.29.2017.02.09.12.14.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 12:14:30 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <20170209195722.DC1AB636586C@rock.dv.isc.org>
Date: Thu, 9 Feb 2017 12:14:30 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0394528C-99CD-41D4-9AB6-844D1318264C@gmail.com>
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>
To: Mark Andrews <marka@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IfmTKpHP_VPbZ0S0P5s_ol1V9qo>
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:14:34 -0000

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 that they have children, which are not changed or harmed. Preventing the erroneous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be returned.

Brian

Sent from my iPhone

> On Feb 9, 2017, at 11:57 AM, Mark Andrews <marka@isc.org> wrote:
> 
> 
> In message <20170209163123.56hdbzaluekmvbh7@nic.fr>fr>, Stephane Bortzmeyer writes
> :
>> On Wed, Feb 08, 2017 at 12:36:23PM -0800,
>> Brian Dickson <brian.peter.dickson@gmail.com> wrote 
>> a message of 258 lines which said:
>> 
>>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
>>> - cache the response, and as appropriate, re-query periodically.
>>> - If a query for <anything>.onion is received, reply with the authenticated
>>> denial of existence from the root (cached in step 2)
>> 
>> Note that, if you implement RFC 7816 and RFC 8020, you already have
>> this behavior. No work for us :-)
> 
> 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.
> 
> RFC7816
> 
>   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.
> 
> Mark
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org