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

Joe Abley <jabley@hopcount.ca> Fri, 26 October 2018 11:46 UTC

Return-Path: <jabley@hopcount.ca>
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 F202C130DE0 for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 04:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 n2dUiat2scul for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 04:46:47 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 ADA5B130DD7 for <dnsop@ietf.org>; Fri, 26 Oct 2018 04:46:46 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id a82-v6so687282lfa.4 for <dnsop@ietf.org>; Fri, 26 Oct 2018 04:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=wo5d67rwzNoRC0S8jt8zl7YN0IicZXEBQ5wRtBk6bRg=; b=ey+gqfirUjlzMg0JonbgMgsFZC8HD4hHEkrtFOKDARcAS1i1doJynhMSZgyIfnj3hG s4Ol910+xOq0V6guCZcQXDurhfS3fCKaM4XV2hwwODXVvmrwcU9/4uyWd70tReJSoiO5 Rz69BCm/Uqhh59FjakvBxskvt0bbon+N/o3pY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=wo5d67rwzNoRC0S8jt8zl7YN0IicZXEBQ5wRtBk6bRg=; b=ZZTm8t0rzGr6zOxYno6nfVOoSRcuLYfXAdxSokNOAanMIipAl1hg20Mb11WJYbNGCm wyq3OtA3uvOSdQUfKRGrtWewbjB6nEZF+YdhZhKVqCdN819eSP84YuECVMgafS/WGM79 7Y9QRT+O7NxCTQZVri7wrn1QKIVKNLlsVRSBuQfIxlWyr+TyXWqyqe8Ndcn231q24hoS P6L5+Ob3L/52ipWlEG7pRECnUyN4dKLuPLeov1oxUeLQmkX1Oxz38ntY6JrM9Tku2Inq aLvfnXsVADAL02TzCdLRq5hK8DkwCeMhq9vHVOPYNls5lpbXetsny2wWUXhlBnS6XiMN q/eg==
X-Gm-Message-State: AGRZ1gJhMemEFhG//ZhVFLj1I7AJT4cLTwPWipmqlt4PllbdDkX7bjTQ fw2h5VOP2lG0d1HsovsePr4KJrMFPB9YUiYlRYuwoM29oYY=
X-Google-Smtp-Source: AJdET5chzsHCr6AGJVJdezYlBfoZxeTIJMKhOWWReP6sz8zCL+Pc06kToa/fXiLmMCCxjdtXQWgrVIfwLTHoGSBJ8Qo=
X-Received: by 2002:a19:8c1a:: with SMTP id o26-v6mr2005077lfd.90.1540554404533; Fri, 26 Oct 2018 04:46:44 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Fri, 26 Oct 2018 04:46:43 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
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> <a1b6b9c4-6d0c-d277-2b9b-575880bc1c14@bellis.me.uk>
In-Reply-To: <a1b6b9c4-6d0c-d277-2b9b-575880bc1c14@bellis.me.uk>
Date: Fri, 26 Oct 2018 04:46:43 -0700
Message-ID: <CAJhMdTP+NbtCYQ0F1HPSqQ4b4M3tUie56_ueGZmcFECyJsOBpQ@mail.gmail.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vA09BWxWYpCJGTd1hRdqyyhpGrs>
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:46:49 -0000

On Oct 26, 2018, at 13:33, Ray Bellis <ray@bellis.me.uk>; wrote:

>   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 the name "localhost" which is often locally served as
>   127.0.0.1.

Perhaps the pertinent question is why the word "loopback" features in
that text at all.

If the group thinks that a loopback interface is the right way to
connect local-root and resolver then perhaps provide that
recommendation explicitly with rationale. The general case surely does
not require the connecting network to be a loopback interface, and the
text you quoted could be interpreted as suggesting otherwise.

(The connecting network could be a bit of Internet, or a local switch,
or virtual switch between VMs, or something implementation-specific
between containers, or...)

I think it's probably reasonable to observe that there is a dependency
between the local root server and the resolver and that if the former
is not available to the latter there might be unexpected failures.
Orchestration of workloads to reflect that dependency is arguably
easier in some of those scenarios than others seems reasonable. I
still don't think there's any need to be prescriptive about the use of
a loopback interface.

I think the whole document could be reasonably re-cast to make it more
clear that "same server" is really just one example of the use of a
local root, and that many other scenarios are plausible.

Happy to contribute if the group considers this to be a reasonable
idea and not simply the dangerous ravings of a known lunatic.


Joe