IETF Logo Mail Archive

Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

Bjørn Mork <bjorn@mork.no> Fri, 26 October 2018 11:58 UTC

Return-Path: <bjorn@mork.no>
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 B60C0130DEB for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 04:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 QNaIr4ODxhhO for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 04:58:03 -0700 (PDT)
Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 137B9130DE1 for <dnsop@ietf.org>; Fri, 26 Oct 2018 04:58:02 -0700 (PDT)
Received: from miraculix.mork.no ([IPv6:2a02:2121:281:75f0:c8fa:53ff:fe7c:53d8]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id w9QBvsRB017028 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Oct 2018 13:57:54 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1540555074; bh=EKU50/fWwBHZu/jemULtPQwnvL8loubGMX5XAY5eAhI=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=LhzoNCcSq5T3L5aqebQ1ezFxtTyINDEUK6g0z7LCOB8TMSeB7AstMWzknjoQVC0aP 6fgAaeqTuYY7iXxDTyWOYVSAOyL5AKZp7k9BQ2sSyq5GdES5EpjZ27dNInN0DwZak8 7KZNAwajnNKVVHksJTxson8kmRfvCmYAC5NTYcqs=
Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from <bjorn@mork.no>) id 1gG0kO-0000Iz-HA; Fri, 26 Oct 2018 13:57:48 +0200
From: Bjørn Mork <bjorn@mork.no>
To: Tony Finch <dot@dotat.at>
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
Organization: m
References: <47597960-3D11-4007-947D-19DBC7AF2BAC@icann.org> <75129a2d-8f91-48ca-dc27-7d6dfde685e0@bellis.me.uk> <alpine.DEB.2.20.1810261210150.24450@grey.csi.cam.ac.uk>
Date: Fri, 26 Oct 2018 13:57:48 +0200
In-Reply-To: <alpine.DEB.2.20.1810261210150.24450@grey.csi.cam.ac.uk> (Tony Finch's message of "Fri, 26 Oct 2018 12:14:33 +0100")
Message-ID: <8736ss6htv.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.2 at canardo
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8K92tAgSIM_Ysxs_Km3V3DeRCdQ>
Subject: Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis
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: Fri, 26 Oct 2018 11:58:06 -0000

Tony Finch <dot@dotat.at> writes:
> Ray Bellis <ray@bellis.me.uk> wrote:
>>
>> I'd like to see examples of configurations where the local root copy
>> *isn't* on the same host.
>
> It's basically the same as the examples in RFC 7706, but you use the other
> host's address instead of 127.12.12.12. RFC 7706 even says,
>
>    The examples here use a loopback address of 127.12.12.12, but typical
>    installations will use 127.0.0.1.  The different address is used in
>    order to emphasize that the root server does not need to be on the
>    device at "localhost".

This might be just me, but I find that paragraph very confusing.
127.12.12.12 is just as unroutable as 127.0.0.1, and must therefore
belong to the local host. And "localhost" as in the DNS name makes no
sense at all in this context.

When it comes to using 127.0.0.1 for this purpose, I believe you should
recommend some caution.  It's not uncommon to stick "nameserver
127.0.0.1" into the /etc/resolv.conf on recursive servers.  And many
admin fingers will automatically type "dig @127.0.0.1" when they want to
query the local server.  This will give unexpected results if you put a
non-recursive view on that address.

I'd also like to repeat my previous comment on the BIND example config:
Configuring a "static-stub" root zone has some unexpected consequences.
It makes the server refuse non-recursive queries for root instead of
redirecting.  Not a big problem, but it does make "dig +trace" fail with
such a server as starting point. It would be nice to see this issue
discussed in the RFC, including justification of the "static-stub" zone
type.  The reason for that choice is not obvious.  To me, at least.



Bjørn

v2.23.0 | Report a Bug | By Email