Re: [DNSOP] Resolver behaviour with multiple trust anchors

Lanlan Pan <abbypan@gmail.com> Thu, 09 November 2017 09:12 UTC

Return-Path: <abbypan@gmail.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 EE8F312ECA9 for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 01:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9Mh8HQHUq4Wh for <dnsop@ietfa.amsl.com>; Thu, 9 Nov 2017 01:12:06 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7BCAC129B1E for <dnsop@ietf.org>; Thu, 9 Nov 2017 01:12:06 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id y80so15468427wmd.0 for <dnsop@ietf.org>; Thu, 09 Nov 2017 01:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JTX/43nfzAESNYDCfFszwJMigr5CUqSlZ8X939vKAxI=; b=B9V3DbYQP6TA44XEHQpfB5NWs3AzzxoiWfT5jBKRxXkkQzU3AboSFg1F3e6ZDAnIOr qDHwf+80C2/S8pXFqIUXLpBeowGT8m6ZSmN4uE0v9zB3V7q/2ekS5jlIwJwgM80UX2nv 3WFsxqygukKw5dnAUj9T/VLQ2M8OUw3/isJor8BdMqKU+CM52m7z0+TLLTO3kV45eX4M H3KD3HCgrdd3CaQASow7RMenWfkE62iMAc8sMD5VV3HKw2aCmsapH8ewVe+r6Q+ij2qW p23KtUnzQcXfX3WmOyNx+EMuvCpC9gxsBfLVtJG0zoroCW66poJmS9TgVAl+alWVb+4t GRsg==
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:from:date :message-id:subject:to:cc; bh=JTX/43nfzAESNYDCfFszwJMigr5CUqSlZ8X939vKAxI=; b=iL78OMiZRu4v0cXzSF0actV9d9xSW7lfe2DasxD7bJ/IatInv1BUOmznBslNs8knss QiM/qSZrKvwb2sFLjJ1BOHp11UJo2TvJOGzyK8EBATmsmKL/SoJXMobv4JV21exzNv/r lzky11I1dKvho+lYEd/f2F1pMwNKWI/TXA1tdromJpF20RHoz8I7nl+x5K+cfEl9WJfY z2vWnXU20bZwmpiZ+f4GL/e/x0ZCsCJp5zbRPHaRqKqYD+B5/XtFZ6TRDOeYYJpTp1O2 a2b8gYRRbaOPf67ZjLrZ1tvpJKGGEKqf3QqTQq8MEIF/aJXxun5ZtEnyEkwau+1MR27N Nv3g==
X-Gm-Message-State: AJaThX4FOgXQnPI/EKnmelVJ7Sw9PFKCR4B+tOX47HL+zJzztyvnmieo k+UNf6X0rHWTw5uocfMNvea8X8qHQBQtfolKYzQ=
X-Google-Smtp-Source: ABhQp+R+zQjJs0U1dNFS3JFILxhwSnZEoeVkQ01syLKUhCQPJPcwXfamLMCBuZY3w4iheoyLidm1HbXHv2gJbxjTMP8=
X-Received: by 10.80.181.194 with SMTP id a60mr4263153ede.231.1510218725015; Thu, 09 Nov 2017 01:12:05 -0800 (PST)
MIME-Version: 1.0
References: <CAH1iCirbppLEX4t9QmWzUv1jkZ=aPsbMKck4S0UwUXbc_Lqv9A@mail.gmail.com>
In-Reply-To: <CAH1iCirbppLEX4t9QmWzUv1jkZ=aPsbMKck4S0UwUXbc_Lqv9A@mail.gmail.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Thu, 09 Nov 2017 09:11:54 +0000
Message-ID: <CANLjSvWsS3VnV498BNeppHKVDBNmJDMbpNeM6KcMTRj0_bCHvQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19568ea34761055d893243"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ms9g3Rgu8xq66rjt8-JAJf7C3fY>
Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Nov 2017 09:12:09 -0000

Brian Dickson <brian.peter.dickson@gmail.com>于2017年11月3日周五 上午3:58写道:

> (Apologies for neither top- nor bottom- posting, i.e. not quoting any
> other emails.)
>
> There are corner cases which exist, where desired behavior of some
> resolvers is not possible to achieve.
>
> This mostly has to do with constraints where "local policy" may have more
> than one scope.
>
> I.e. Inside a big enough org, there may be a "large" local policy which
> conflicts with local policy of  smaller sub-orgs.
>
> Here's an example:
> - Suppose an enterprise E has perimeter resolvers, which do not validate
> DNSSEC.
> - Suppose that E blocks DNS traffic to the outside world, except from
> those perimeter resolvers.
> - Now suppose a small org within E, call it E-prime, deploys DNSSEC using
> its own local trust anchor.
>
> The issue has to do with not only which trust anchor is preferred for any
> given portion of the DNS tree, but also whether the policy of "validation"
> applies, and with what scope.
>
> There may be other corner cases, but the main point is that the above
> scenario does not depend on any notion of "split DNS" per se. The E-prime
> element is, for sake of argument, still globally resolvable, but happens to
> be an "island of security". There is no split DNS.
>

no split DNS +1

very hard work: maintain many trust anchors like TLS CA, make sure
information automate update in global recursive resolvers.

limit local policy: special zone publish its own trust anchor, a small sets
of recursive resolvers configure to trust it, similar with some local root
hints for short rescue time. (if software support)


>
> I think the question may boil down to the following:
> - What local policies might operators need to configure?
> - What advice to implementers can be provided, given the possible
> complexities of what operators need?
> - Does it make sense to formalize (or at least categorize) policy logic?
> - What defaults are likely to maximize "correct" behavior, and/or minimize
> failures?
> - E.g. suppose the presence of trust anchors in non-5011 configuration
> files, vs trust anchors in 5011 configuration files, and suppose multiple
> trust anchors. Is the mere existence of a trust anchor sufficient to signal
> intent, or is it always the case that some policy needs to be declared over
> the combination of all existing trust anchors?
>
> Brian
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan