Re: [DNSOP] Resolver behaviour with multiple trust anchors

Lanlan Pan <> Thu, 09 November 2017 09:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE8F312ECA9 for <>; Thu, 9 Nov 2017 01:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Mh8HQHUq4Wh for <>; Thu, 9 Nov 2017 01:12:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BCAC129B1E for <>; Thu, 9 Nov 2017 01:12:06 -0800 (PST)
Received: by with SMTP id y80so15468427wmd.0 for <>; Thu, 09 Nov 2017 01:12:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id a60mr4263153ede.231.1510218725015; Thu, 09 Nov 2017 01:12:05 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lanlan Pan <>
Date: Thu, 09 Nov 2017 09:11:54 +0000
Message-ID: <>
To: Brian Dickson <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="94eb2c19568ea34761055d893243"
Archived-At: <>
Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Nov 2017 09:12:09 -0000

Brian Dickson <>于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
> - 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
致礼  Best Regards

潘蓝兰  Pan Lanlan