Re: [DNSOP] Delegation into the interior of a zone?

Tony Finch <dot@dotat.at> Wed, 02 January 2019 16:10 UTC

Return-Path: <dot@dotat.at>
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 5C2E7130DD1 for <dnsop@ietfa.amsl.com>; Wed, 2 Jan 2019 08:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Y64QsqeKmKlg for <dnsop@ietfa.amsl.com>; Wed, 2 Jan 2019 08:10:02 -0800 (PST)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 046D5130E40 for <dnsop@ietf.org>; Wed, 2 Jan 2019 08:10:02 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35484) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gej5i-0007Eg-cn (Exim 4.91) (return-path <dot@dotat.at>); Wed, 02 Jan 2019 16:09:58 +0000
Date: Wed, 02 Jan 2019 16:09:57 +0000
From: Tony Finch <dot@dotat.at>
To: John Levine <johnl@taugh.com>
cc: dnsop@ietf.org
In-Reply-To: <20181227192639.21372200BFBF3A@ary.qy>
Message-ID: <alpine.DEB.2.20.1901021603440.3160@grey.csi.cam.ac.uk>
References: <20181227192639.21372200BFBF3A@ary.qy>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Lw8SWtsf228QgY2nwCkPzeCamWg>
Subject: Re: [DNSOP] Delegation into the interior of a zone?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Jan 2019 16:10:04 -0000

John Levine <johnl@taugh.com> wrote:

> That is, the two zones have the same apex, and NS records point into
> the interior of the second zone, not at the apex.  That works in BIND,
> of course, but it seems wrong.

Well, it kind-of works, but it's brittle.

* If a client queries for the NS records, the authoritative NODATA from
  the child zone will override the delegation NS records (according to
  RFC 2181 trust ranking) which will break future resolution attempts.

* Negative responses from the child zone will have the wrong SOA, causing
  SERVFAIL in the resolver's RFC 2308 response disambiguator.

* DNSSEC will not work at all.

(Any other issues I've forgotten?)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: East or southeast 3 or
4, occasionally 5 at first. Slight or moderate, occasionally smooth in Lyme
Bay. Showers later. Good.