Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

In message <59f8d666.9000...@redbarn.org>, Paul Vixie writes: > > > Paul Wouters wrote: > > On Tue, 31 Oct 2017, Edward Lewis wrote: > > > ... > ConfiguredKey-trumps-DS > ... > >> > >>> It better, it is the only working solution :) > >> > >> Can you elaborate...why would it be the "only"

Re: [DNSOP] Resolver behaviour with multiple trust anchors

In message <121cdbc2-d68c-48ee-a56e-46c61fc21...@sidn.nl>, Moritz Muller writes : > > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 10/31/2017 4:51 PM, Paul Hoffman wrote: And once again we see the folly of the words "implementation choice" when trying to come up with a coherent DNS. The full quote makes the situation murkier: it is a combination of implementation choice plus configuration options. Some folks on this

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

On Mon, Oct 30, 2017 at 7:29 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : BULK DNS Resource Records >

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 31 Oct 2017, at 12:23, Michael StJohns wrote: But sadly - the language in RFC6840 section 5.10 is controlling... basically, any implementation can do whatever it wants. A DNSSEC validator may be configured such that, for a given response, more than one trust anchor could be used to

Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

Paul Wouters wrote: On Tue, 31 Oct 2017, Edward Lewis wrote: ... ConfiguredKey-trumps-DS ... It better, it is the only working solution :) Can you elaborate...why would it be the "only" "working" solution? The idea of the hierarchical model has always been that if you don't trust

Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

On Tue, 31 Oct 2017, Edward Lewis wrote: Any-TrustedKey-works ConfiguredKey-trumps-DS DS-trumps-configuredKey But I suspect the middle one is implemented It better, it is the only working solution :) Can you elaborate...why would it be the "only" "working" solution? The idea of the

Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" wrote: > On Oct 31, 2017, at 22:25, Ólafur Guðmundsson wrote: >> >> There are three ways to treat this case: >> Any-TrustedKey-works >> ConfiguredKey-trumps-DS

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 10/31/2017 5:39 AM, Moritz Muller wrote: Hi, Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a

Re: [DNSOP] Resolver behaviour with multiple trust anchors

> On Oct 31, 2017, at 22:25, Ólafur Guðmundsson wrote: > > > There are three ways to treat this case: > Any-TruestedKey-works > ConfiguredKey-trumps-DS > DS-trumps-configuredKey > > I think the Last one is the "most" correct from an operational expectation, Not

Re: [DNSOP] Resolver behaviour with multiple trust anchors

There are three ways to treat this case: Any-TruestedKey-works ConfiguredKey-trumps-DS DS-trumps-configuredKey I think the Last one is the "most" correct from an operational expectation, but the first one is least likely to run into errors, But I suspect the middle one is implemented Olafur On

Re: [DNSOP] Resolver behaviour with multiple trust anchors

>It sounds like clarification is needed if even one (much less three) >systems treat such a signature as Bogus. My reading of RFC 4035 is that >any chain that successfully leads to a trust anchor should return >Secure, even if a different chain returns Bogus. If extra trust anchors are

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

Joe Abley wrote: If a format is going to be specified that specifically prohibits a zone cut, doesn't it make more sense to choose one that can't possibly involve one because there are no potential label boundaries? +1. -- P Vixie ___ DNSOP

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

On 31 Oct 2017, at 11:01, Ray Bellis wrote: > On 31/10/2017 14:56, Joe Abley wrote: > >> Perhaps I missed something, but how do you ensure that _ta is an >> empty non-terminal? > > By having that be part of the required server logic to implement the > sentinel mechanism? If

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: > > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >>> IIRC we discussed it, and were concerned that _ta. could be cached as >>> nonexistent by servers implementing QNAME minimization. >> >> How

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: > > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >>> IIRC we discussed it, and were concerned that _ta. could be cached as >>> nonexistent by servers implementing QNAME minimization. >> >> How

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

On 31/10/2017 14:56, Joe Abley wrote: > Perhaps I missed something, but how do you ensure that _ta is an > empty non-terminal? By having that be part of the required server logic to implement the sentinel mechanism? That said, I'm not sure this would be consistent with the draft's proposed

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

On 31/10/2017 14:34, Tony Finch wrote: > It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) > > The problem occurs if you have a validator behind a cache. The cache will > prevent downstream id._ta. queries from reaching the root, so any > downstream trust anchor variation will be

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

On Oct 31, 2017, at 07:27, Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >> IIRC we discussed it, and were concerned that _ta. could be cached as >> nonexistent by servers implementing QNAME minimization. > > How would that happen, at least so long as _ta

Re: [DNSOP] Resolver behaviour with multiple trust anchors

On 31 Oct 2017, at 2:39, Moritz Muller wrote: Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

Ray Bellis wrote: > On 30/10/2017 17:40, Evan Hunt wrote: > > > IIRC we discussed it, and were concerned that _ta. could be cached as > > nonexistent by servers implementing QNAME minimization. > > How would that happen, at least so long as _ta responds like any other > empty

Re: [DNSOP] [Ext] Resolver behaviour with multiple trust anchors

On 10/31/17, 05:39, "DNSOP on behalf of Moritz Muller" wrote: >Now, for example due to a key rollover at the TLD, the manually configured >trust anchor of the TLD does not match the DS in the root anymore. > >How should a resolver

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

On 30/10/2017 17:40, Evan Hunt wrote: > IIRC we discussed it, and were concerned that _ta. could be cached as > nonexistent by servers implementing QNAME minimization. How would that happen, at least so long as _ta responds like any other empty non-terminal? Ray

[DNSOP] Resolver behaviour with multiple trust anchors

Hi, Together with my colleagues I have been stumbling upon a, for me, unclear case when validating trust anchors. Assuming that a resolver has enabled DNSSEC validation and has the root keys configured. Additionally, it has configured manually a trust anchor for a TLD (that has also published