IETF Logo Mail Archive

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

Erik Kline <ek@loon.co> Thu, 27 December 2018 19:33 UTC

Return-Path: <ek@google.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 B530E130E5F for <dnsop@ietfa.amsl.com>; Thu, 27 Dec 2018 11:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co
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 a_xEODntfoNW for <dnsop@ietfa.amsl.com>; Thu, 27 Dec 2018 11:33:05 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 6EBE5130E81 for <dnsop@ietf.org>; Thu, 27 Dec 2018 11:33:05 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id m62so25765790ith.5 for <dnsop@ietf.org>; Thu, 27 Dec 2018 11:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=ZcvLmiFtRKOeBv6rbIGgztiBjeoAnVwmOlWyDO7DS44=; b=MojC9srkuVbggytIF36/BjP4vuGniQaj55ZLk7jqp9wt9eJSmWen2PC2FIRvgURfTy kYz5fNmDk5PFEqqa0s41zwZkCyZo49LbooY5zt5cAHePnkE03fltWbhtl4SrnOxfMpa0 6j/ONgI932NGAKt8BHpTFyqClgm4aaHdC/Jnw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ZcvLmiFtRKOeBv6rbIGgztiBjeoAnVwmOlWyDO7DS44=; b=enS59ZksXvFK2FUDKB/rjJiSMvbTIxIDPO8Jc40G5QvnJpxh0K3geNK7hL2cqHDcbb 965xdx4/lKkknLUEZ40w0oKQ1QEL2eYyN2lhra8+43yDThdfLBn2Rk3pRWUBwrTF65qo Pc4JWQmpRGvtHCIIR+Yov3IiRMeaTTJIyB0IndJZbd1WEgcZwFmDBfW185nTA5Azpmrx MsXWe6SIKskBv7ivpMybk3CJ1c75kw39b0opbkQc5XEEUgcAFCKzFeTwHGU/CYM7tXcq gBZiLky12W3NuISRrwCkSCz2gSn8mqXPpDe8HCA/o3OJoyvd+liEA6Wiy1IUwxxjYRYt C2Ng==
X-Gm-Message-State: AA+aEWa8rlmSto0sGXHQlx76HK36aVI901HWWnTzzyzqfrha9i5cJbvS CrRDQqA8R/pWugfyn4Rcay54Xd6+kMw7H0j+3tqW7wgfVt8=
X-Google-Smtp-Source: AFSGD/VxjRgspRK+tYFnLL9MiI0EJV20WupXVBUWpotsDVDYz0Zb3CJGcSbmrlxPe5S0t0B1WOSwvRTtQfv56vvUOrk=
X-Received: by 2002:a02:8943:: with SMTP id u3mr15784969jaj.92.1545939184371; Thu, 27 Dec 2018 11:33:04 -0800 (PST)
MIME-Version: 1.0
References: <20181227192639.21372200BFBF3A@ary.qy>
In-Reply-To: <20181227192639.21372200BFBF3A@ary.qy>
Reply-To: ek@loon.co
From: Erik Kline <ek@loon.co>
Date: Thu, 27 Dec 2018 11:32:53 -0800
Message-ID: <CAAedzxr49jJ09Z2-Swd1k2jPQLka14cE23vP9W8QOhxdL07QgQ@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ee319a057e060309"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GXjf223EAzYFqolL6kgW7MwKZUQ>
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: Thu, 27 Dec 2018 19:33:08 -0000

On Thu, 27 Dec 2018 at 11:27, John Levine <johnl@taugh.com> wrote:

> 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
>

So, the NS listed in some zone above would be "wrong", i.e. the glue
records point to namservers hosting a zone with these different
nameservers?  Seems like a resolver being pedantic about glue records might
be nonplussed.

v2.23.0 | Report a Bug | By Email