Re: [DNSOP] Resolver behaviour with multiple trust anchors

william manning <> Sat, 11 November 2017 05:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF8712941D for <>; Fri, 10 Nov 2017 21:09:50 -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 Wir-VGhYbKji for <>; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA7C2128B51 for <>; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
Received: by with SMTP id m191so3988110itg.2 for <>; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=f54gPBjiDSELxu4XA6Tfg0wVj6BSHPnPegxRJ5sgTU8RyaqueW41pKQxLgL3Q41dvX bjzljNiNPQVuDvy3I/vOPSTag2a+VRucd81XhQ6TzCqSYsaGCCr43tipW9opNwDTbp4d MiuVIPxjQThWjVFmf7CD+tE8i9GzSEOGOkyqzh50+EP+yL+9cc+CBrJDK+jU/K76rSMs anbDT6I9BvKDIZYiKaiVICcXyvNhmG1a90ThOBo/MHZJnenlOzOj09zELWuAG7XRj7Yz eUNCiD753WkUtP62cFLHt7vKKodjIAqmX/wvX0DuP3NMqgRx19NCa5db5IwEsULMFtKN FYAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=leQEN/tOE0SNlF9/x6EYdO9rUUXuO4tqq4SdK8ZeWt46ZU+C9veZwxm5h94cMcze39 bBWZgG6sFA/Tq1YSFPYJPL41/a9/z24IzbkipWHxV29DXYe+Az7ZlRMRvLuUvf0Czc3t 2ijO1ojnsTQclv+95SPRut+8+iCIoNvYiFd+fK+maOJ5iUmTGifWYoLs8F/DuQd+8yLZ jHAuKDikbEyFT3dlxnhrxLHQ5fFwbpnwPIEZmdbrFppD08ha/K6J3r2X45A8WpBFWd/M Fv57wVbcOiQslDiIX2rVJlvL5mS9f2+NhpOL1M2eGzHonAHInO/fnHEDdRfVxfMdd5jq DEDg==
X-Gm-Message-State: AJaThX5OZxmoHKcHJGrUh0+pWr7BwwB/S68DG2yMibLo83TcB5lb+zbG TeVcYfmA8TPzThtJl2XrY7Ym33bde/3GvGCDUAM=
X-Google-Smtp-Source: AGs4zMaLq9mBrWo4iDv00Mvp+HbqUXg3XiUahbruzIfYoCQAYySd1GpyM36/pqXpPV/BALVz1fvXevLH0MGWfdG2VKo=
X-Received: by with SMTP id j18mr3309896iti.18.1510376987072; Fri, 10 Nov 2017 21:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Nov 2017 21:09:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: william manning <>
Date: Fri, 10 Nov 2017 21:09:46 -0800
Message-ID: <>
To: Matt Larson <>
Cc: Paul Wouters <>, Ed Lewis <>, Moritz Muller <>, Ólafur Guðmundsson <>, "" <>
Content-Type: multipart/alternative; boundary="f403045d9d8cca9c63055dae0bfe"
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: Sat, 11 Nov 2017 05:09:50 -0000

in the last 20 years, there have been a few testbeds that have explored
this space.

that suggest Matt is spot on here.   accepting any success is likely to
present the fewest problems from a user perspective.


On Thu, Nov 2, 2017 at 7:41 AM, Matt Larson <> wrote:

> The root KSK rollover project has given me a real appreciation for the
> brittleness of trust anchor configuration, even with RFC 5011. (Automated
> update support should get better over time, especially after the first KSK
> roll exposes problems, but right now it's pretty shaky, which is my
> informed opinion based on observation from the operational trenches.) In
> the real world, where trust anchors are going to go stale, an "Accept Any
> Success" (in the language of Appendix C) trust anchor policy is the safest
> operationally.
> I agree with Ed's observation that operators are, by and large, going to
> use the defaults in whatever implementation they're running, so defaults
> are important.
> Trust is always going to be a matter of local policy, so with DNSSEC
> there's never going to be a consistent output given a consistent input. The
> best we can do is give good guidance to implementors, ideally based on
> operational experience, to inform their choices for the default settings
> that operators will end up using.
> I think RFC 6840 gets it right: it acknowledges that trust anchor
> preference is a matter of local policy, but recommends an operationally
> safe default of "Accept Any Success".
> Why would one want a "Closest Encloser" trust anchor preference policy?
> I've heard two reasons in this thread:
> 1. The untrusted parent scenario: I submit there's no practical
> implication of distinguishing between the parent's control of the
> delegation and its control of the DS: the child zone is completely at the
> will of the parent zone, so if your parent has it in for you, you lose.
> This scenario is not sufficient motivation, in my opinion, to suggest
> "Closest Encloser" as a default policy.
> 2. In a split DNS context, reject answers that leak into the wrong view: I
> think using DNSSEC as a backstop to enforce split DNS policy is a dubious
> operational practice and likewise not sufficient motivation to suggest
> "Closest Encloser" as a default policy.
> In my perfect world, implementations would offer a knob to set "Closest
> Encloser" for consenting adults but default to "Accept Any Success".
> Matt
> _______________________________________________
> DNSOP mailing list