Re: [DNSOP] Resolver behaviour with multiple trust anchors

Brian Dickson <> Thu, 02 November 2017 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9787813F8FA for <>; Thu, 2 Nov 2017 12:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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] 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 fqjePI6SdPLx for <>; Thu, 2 Nov 2017 12:58:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFB0713F8EB for <>; Thu, 2 Nov 2017 12:58:38 -0700 (PDT)
Received: by with SMTP id 101so1609226ioj.3 for <>; Thu, 02 Nov 2017 12:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yo/e9CshoDL7qG5lhR6I6doH0VJCQXPbWFrLbFxQHYc=; b=iyZtR4AhxOhXH3YoqUfOarPZqk3OAU5pbu/ml209TiYk/ggiWwN4idUXrFudlkn0Em 0OZ2tFNtcfo+KCMWmOfOzaqcfeeFCo0PaZAF3aFGT1T/HiGtEtsQ04Gnml+nig87ayh8 C/9TB8xnudx6zsQQQcTHotEYK9snijtzA+iP17wkwHuuV2HtmJUWWKhv8KHNtlYF/rZS amjBv4VdV1e1ZHXrPdopcjjlXAVfawXlGoLvsRuyGIiFTwvUHHoev+MRKjIEOmSE8geA AMXnzvF5O+/K4+6BMNUY6fk25v0mEzGqa+uDxHW8F81L3o9VA6GhUCp7D+DXhh7AmXNb h+/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yo/e9CshoDL7qG5lhR6I6doH0VJCQXPbWFrLbFxQHYc=; b=FKT49kgfHspAopm798kEazhYwnCzBmG5qVKyv4SL9KC2IygjmSyX01niMUBABW+let AkMUL8pMaWajwSclJYSh2HCpis9Rxc4Io0mXJ4o8JFYmy3Z5wqfcUaVrUVXdsrC+EcWr i/riuEjLfx7sd8/G5NK2HpfBY31iSmNPAtrtPbkpwgXv/MSHynJD3vIrGhlnNdrAPR3+ pVgGrst9oTcU++HIci4bMQmJocDxEZhKVzscQp8H2GklcCJIwcUfrpYtB+xzNxVzwhNW JKW8QTDWUunuaVlmzi9aXhMmqWp0llymIgnSdj93ycCGXS1qQ+3V3EpR06I4wBIqxe42 SOSA==
X-Gm-Message-State: AMCzsaV1mkJfgGz16FgcA5yvi+2EQvEYIzIWa7ZxGLFamwNeQySBfZlw UhsJ1CgU4rPnkEht4J1+UmDIOGC3BViMAWM6BNs=
X-Google-Smtp-Source: ABhQp+QuuCDzSF9dAe9MXN5bexL95gsedQTQkRVAwDFs1C0VzGgHn2KCNTxucYJ858oCidz+4CsU7WjkT3R0N/OV22M=
X-Received: by with SMTP id q143mr4129964itc.122.1509652717688; Thu, 02 Nov 2017 12:58:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Nov 2017 12:58:37 -0700 (PDT)
From: Brian Dickson <>
Date: Thu, 02 Nov 2017 12:58:37 -0700
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="001a11473fcaf8da95055d0569fb"
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, 02 Nov 2017 19:58:41 -0000

(Apologies for neither top- nor bottom- posting, i.e. not quoting any other

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.

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
- 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?