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
- [DNSOP] Resolver behaviour with multiple trust an… Moritz Muller
- Re: [DNSOP] [Ext] Resolver behaviour with multipl… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple trus… Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple trus… Michael StJohns
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Wouters
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Vixie
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Michael StJohns
- Re: [DNSOP] Resolver behaviour with multiple trus… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Patrik Wallstrom
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Ólafur Guðmundsson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Philip Homburg
- Re: [DNSOP] Resolver behaviour with multiple trus… Matt Larson
- Re: [DNSOP] Resolver behaviour with multiple trus… Bob Harold
- Re: [DNSOP] Resolver behaviour with multiple trus… Paul Hoffman
- Re: [DNSOP] Resolver behaviour with multiple trus… Warren Kumari
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] Resolver behaviour with multiple trus… Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple trus… Tony Finch
- Re: [DNSOP] Resolver behaviour with multiple trus… Joe Abley
- Re: [DNSOP] Resolver behaviour with multiple trus… Brian Dickson
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Mark Andrews
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Petr Špaček
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Hoffman
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Paul Wouters
- Re: [DNSOP] Resolver behaviour with multiple trus… Lanlan Pan
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Edward Lewis
- Re: [DNSOP] [Ext] Re: Resolver behaviour with mul… Ólafur Guðmundsson
- Re: [DNSOP] Resolver behaviour with multiple trus… william manning
- Re: [DNSOP] Resolver behaviour with multiple trus… william manning