[DNSOP] Delegation into the interior of a zone?

"John Levine" <johnl@taugh.com> Thu, 27 December 2018 19:26 UTC

Return-Path: <johnl@iecc.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 0E732130E6A for <dnsop@ietfa.amsl.com>; Thu, 27 Dec 2018 11:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MuObVCZx; dkim=pass (1536-bit key) header.d=taugh.com header.b=BUAF634f
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 voNukxhpAHFA for <dnsop@ietfa.amsl.com>; Thu, 27 Dec 2018 11:26:41 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7BC9D130E5F for <dnsop@ietf.org>; Thu, 27 Dec 2018 11:26:41 -0800 (PST)
Received: (qmail 90104 invoked from network); 27 Dec 2018 19:26:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=15ff5.5c25276f.k1812; bh=xUcYNrFikP1e8oIXa6M1+qkKJLUgaMc7Vr31giP+BE4=; b=MuObVCZx+inaTtVHBC3nSPaXC0MDMKVQ5+PVWsR+/crm8PQZCJ4CP3ntpdp2LNQzAbwH06zDd8i6eS/5CyrQFb2+4KSspj7CxEbU01VwW2lmXrlc9dTPZp4tp9oNcn95wNZQwKqAFLNoUBBKGxWV0v31JWqAFACBLyuPPikOXoiY3wkmExtr4e0NTDYWw63TrNb6hroqJ/o/+fXpc5j7f7y9RyFA5RjYEyeCsRkimmCqdyRleypnwedbDykcInp5
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=15ff5.5c25276f.k1812; bh=xUcYNrFikP1e8oIXa6M1+qkKJLUgaMc7Vr31giP+BE4=; b=BUAF634fBB03QnElizMu/dRDpfkCAkSL8/oPWPjDPrCbt3wmsv9h4DWxPWVB6HW0aUbCYeAdT+vkv5eIX485QSiH0wh9H/cBGGOIPDElVfhCNSIFCrtaJGszfeI57j+Gj3I5O6lrBLfvLqfRY/IcjlEZ5y909ozemvA6G8lJmNnFnMTYfGTpmGoqKoVY86cE7iSwUI6Bnm5xLWrWVD7DGC8Cp+77o8grhNW9pTNsDJJ6+2ImZKFst9/EuAtmpsUn
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Dec 2018 19:26:39 -0000
Received: by ary.qy (Postfix, from userid 501) id 21372200BFBF3A; Thu, 27 Dec 2018 14:26:38 -0500 (EST)
Date: Thu, 27 Dec 2018 14:26:38 -0500
Message-Id: <20181227192639.21372200BFBF3A@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RwXrWB79DyB1qzWRZ5CCmPPhWmA>
Subject: [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: Thu, 27 Dec 2018 19:26:43 -0000

Over in bind-users somone suggested a CIDR rDNS kludge in which you
delegate a bunch of names out of a rDNS zone to a second server,
and the second server answers them all from one zone, like this

$ORIGIN 1.1.1.in-addr.arpa.
@ SOA blah

10 NS otherserver
11 NS otherserver
12 NS otherserver


and on the other server

$ORIGIN 1.1.1.in-addr.arpa.
@ SOA blah

10 PTR foo
11 PTR bar
12 PTR baz

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.  I am having trouble tracking down the
specification of why it is wrong.

Any sugestions?  It would fail with DNSSEC since there's no DNSKEY
to match the delegation DS, but how wrong was it before that?

Signed,
Confused