On 12 Feb 2018, at 12:28, Warren Kumari wrote:
I also updated my demo implementation
(http://www.ksk-test.net) to use this naming scheme.
I would very much like to see draft-ietf-dnsop-kskroll-sentinel move
forward, but was concerned that the result might be something where an
end-user
On Wed, Feb 21, 2018 at 1:44 PM, 神明達哉 wrote:
> At Wed, 21 Feb 2018 08:53:23 -0500,
> Warren Kumari wrote:
>
>> > - General
>> > I think it's worth pointing out that SERVFAIL can be returned for
>> > various other reasons and the detection mechanism
At Wed, 21 Feb 2018 08:53:23 -0500,
Warren Kumari wrote:
> > - General
> > I think it's worth pointing out that SERVFAIL can be returned for
> > various other reasons and the detection mechanism relying on it
> > isn't reliable. This is probably okay given the purpose
On 02/21/2018 02:53 PM, Warren Kumari wrote:
> Hmmm... Good point. I personally actually preferred having these as
> "decimal" keys.
> RFC1034, Sec 5.3: The DS RR Presentation Format sayeth:
>" The Key Tag field MUST be represented as an unsigned decimal
> integer.", things like dig +multiline
On Fri, Feb 16, 2018 at 12:35 PM, John Dickinson wrote:
> Hi,
>
> I like what this draft is trying to do.
>
> I am a bit concerned about adding a invalid RR in to a otherwise correctly
> signed zone. It suspect that there may be a variation in how validating
> resolvers treat
On Wed, Feb 14, 2018 at 5:05 PM, 神明達哉 wrote:
> At Mon, 12 Feb 2018 15:28:50 -0500,
> Warren Kumari wrote:
>
>> Anyway, we've finally posted an updated version -
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>
> I've read
On 18 Feb 2018, at 20:21, Geoff Huston wrote:
Hi John,
thanks for the review of this draft
On 17 Feb 2018, at 4:35 am, John Dickinson wrote:
Hi,
I like what this draft is trying to do.
I am a bit concerned about adding a invalid RR in to a otherwise
correctly signed
Hi John,
thanks for the review of this draft
> On 17 Feb 2018, at 4:35 am, John Dickinson wrote:
>
> Hi,
>
> I like what this draft is trying to do.
>
> I am a bit concerned about adding a invalid RR in to a otherwise correctly
> signed zone. It suspect that there may be
Hi,
I like what this draft is trying to do.
I am a bit concerned about adding a invalid RR in to a otherwise
correctly signed zone. It suspect that there may be a variation in how
validating resolvers treat authoritative servers that appear to have
sent bogus data. Some might retry, retry
At Mon, 12 Feb 2018 15:28:50 -0500,
Warren Kumari wrote:
> Anyway, we've finally posted an updated version -
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
I've read draft-ietf-dnsop-kskroll-sentinel-01 (this is my first
careful read of this draft) and
On Tue, Feb 13, 2018 at 1:49 PM, Wessels, Duane wrote:
>
>> On Feb 13, 2018, at 9:10 AM, Bob Harold wrote:
>>
>> If an entry could be put in the root zone, that is signed only with the new
>> key, then could users query that and always get a yes/no
On 02/13/2018 06:10 PM, Bob Harold wrote:
> [...] If an entry could be put in the root zone, that is signed only
> with the new key, then could users query that and always get a yes/no
> answer to whether they will be affected?
I don't think that's possible. This is about the _single_ root
On Mon, Feb 12, 2018 at 3:28 PM, Warren Kumari wrote:
>
>
> Hi all,
>
> Sorry it has taken so long to get a new version of this document
> posted - you deserve better.
>
> Anyway, we've finally posted an updated version -
>
Hi all,
Sorry it has taken so long to get a new version of this document
posted - you deserve better.
Anyway, we've finally posted an updated version -
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
This version includes a (hopefully easily understood) description of
how
14 matches
Mail list logo