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" "w
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 configure
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
l
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
> Authors : John
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 validat
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 the
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 hiera
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
>> DS-trumps-configuredKey
>>
>> But I suspect the middle one is implemented
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 tru
> 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 really, as that would mean
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
>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 configur
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 mailin
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 a format is going t
> 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 would that happen, at least so long
> 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 would that happen, at least so long
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 use
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 los
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 responds like any other
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 trust
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 non-terminal?
It's N
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 treat the signatures of this TLD?
Short answer: the resolver oug
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
__
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
24 matches
Mail list logo
