Re: [DNSOP] Resolver behaviour with multiple trust anchors

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DA1B1200C1 for <>; Fri, 10 Nov 2017 21:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 D1jfvjJl2BzL for <>; Fri, 10 Nov 2017 21:11:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99DE1126C23 for <>; Fri, 10 Nov 2017 21:11:41 -0800 (PST)
Received: by with SMTP id d66so15662888ioe.5 for <>; Fri, 10 Nov 2017 21:11:41 -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=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=U1386XhDcb/pq3vzZvq0IgnfmRY9iu1t7d91JbX3ZRVBrRB85m44Q/a2GQ60hub7GR NQ7OESzwRWTYWMxsnf7VwOwPzgwdP/9BydPx8DWc3aaoRla1beypdC7LMdMWsy6V9v5l s9XZDmAmYeGPkilvcG5Pu/95/sHx7UjE1ZdXvfxXMtU/N/Ue2fWn/VHjzpqA8zavTr9v JBR3IogvgVkqvJARz6bBZPRNGDdeDaVdVj1+foNLFQWoU0ir3OIDwop5OX098mZHeDyQ Y8iA3jn11tv5OFG8Jq+eedJK3Jmj7r9T/HcWuk9cHsvOV6MvRWH0sqPQSIWpkMx/7sty j38A==
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=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=RrOPT8V/B67tC2NOO/0nTuoDlzCSc7m60WvIDJ8lg2OSOPHF3gFleFPoNZSL5ObJye Dxy/Qfy0Ef6eZWMM6YKYgeJhTd4LetnyLcw2w1mfLv2/zKahwbJ3CHxqPDmsmPiJWphy QkTsAFnmoVTVTsh0Sah7mzcvaJE8GKWKQfEHnsYm72eZkvZqt/KqdnUBt/sN8yQwo4KK Osz74GogfC4lYHdT8LdXyvnzd950slr2qSOtkjMcb6dQbpiWI4VVZ71DuArSXTCcE3WA /2gKo2weNv+05+8ifd3/TlAXPdQVWaUMYCj5J52PbxMttLt9fmqPzlXACZDt8I+hfEeP DHxg==
X-Gm-Message-State: AJaThX7VN0KF2/oyMgdUMOsVzdsIKHNjdNempAJTxKtQL1xXQPPA38s+ OkDowhnE65OcticlmaO0aRbdr3WwlforpXZrkHU=
X-Google-Smtp-Source: AGs4zMa0L8fG8A+IVNN/gKy7WtSWjoTSMtZ1fxCauvIpPxom6cYjgOwUGLEzCkvNbZzgcp2W+NzPRfRSFSJls0lUhIo=
X-Received: by with SMTP id n138mr2931171iod.173.1510377100895; Fri, 10 Nov 2017 21:11:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Nov 2017 21:11:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: william manning <>
Date: Fri, 10 Nov 2017 21:11:40 -0800
Message-ID: <>
To: Bob Harold <>
Cc: Matt Larson <>, Ed Lewis <>, Moritz Muller <>, Ólafur Guðmundsson <>, Paul Wouters <>, "" <>
Content-Type: multipart/alternative; boundary="94eb2c058680936b89055dae12f3"
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:11:44 -0000

in reverse order of trustworthiness:

the root
a third party - e.g. DLV
locally verified - e.g. my employer, ISP, someone I have a binding legal
relationship with


On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold <> wrote:

> On Thu, Nov 2, 2017 at 10: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
> I generally agree with you, but wonder if there is a performance penalty
> to searching every possible path before failing.  Is that a reasonable
> concern?
> How many paths are there?  I can think of:
> 1. To the root
> 2. To a local trust anchor
> 3. To a DLV provider (gone as of Sept 30?)
> If local trust anchors are checked before the root, and they are under
> operator control, then maybe "Closest Encloser" is a reasonable default.  I
> don't know where to fit DLV into that plan.
> Also, if an operator does not configure DLV or local trust anchors, then
> is root the only path?  So "Closest Encloser" and "Accept Any Success" are
> the same?
> Or am I not understanding something (no experience with this yet)?
> --
> Bob Harold
> _______________________________________________
> DNSOP mailing list