On Mon, Jun 29, 2015 at 8:03 PM, manning wrote:
> Why, yes, I still do. (and it can be found in the IEtF archives)
> https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
>
> As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does
> it matter if the origin IP
Paul Wouters wrote:
>
> You would only add it to the question for DNSKEY of the root.
Yes.
> Maybe only after you determined a validation failure, so you clearly
> have the wrong trust anchor.
No, the point of this option is to signal to the root what trust anchors
are in use by the population
On Tue, 30 Jun 2015, Warren Kumari wrote:
I have been planning to write a draft to address 1 by having validators send
the DS of known TA's in an edns0 option code. This info, could then be
logged by the authoritative nameservers.
Inserting it in edns0 implies (I think) that all of the queries
On Tue, Jun 30, 2015 at 10:53 AM, Edward Lewis wrote:
> On 6/30/15, 9:57, "Tony Finch" wrote:
>
>>John Dickinson wrote:
>>>
>>> I have been planning to write a draft to address 1 by having validators
>>>send
>>> the DS of known TA's in an edns0 option code. This info, could then be
>>>logged
>>>
On Tue, Jun 30, 2015 at 9:34 AM, John Dickinson wrote:
>
>
> On 29/06/2015 21:48, Warren Kumari wrote:
>>
>> I'd appreciate any feedback, the draft announcment is here:
>> Name: draft-wkumari-dnsop-trust-management
>> Revision: 00
>> Title: Simplified Updates of DNS Securi
On 6/30/15, 9:57, "Tony Finch" wrote:
>John Dickinson wrote:
>>
>> I have been planning to write a draft to address 1 by having validators
>>send
>> the DS of known TA's in an edns0 option code. This info, could then be
>>logged
>> by the authoritative nameservers.
>
>Good idea, though just the k
unless, of course, DNSSEC allowed for signing individual records instead of
zones.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 30June2015Tuesday, at 6:57, Tony Finch wrote:
> John Dickinson wrote:
>>
>> I have been planning to write a draft to address
John Dickinson wrote:
>
> I have been planning to write a draft to address 1 by having validators send
> the DS of known TA's in an edns0 option code. This info, could then be logged
> by the authoritative nameservers.
Good idea, though just the key tags should be enough. (I think key
management
Olafur Gudmundsson wrote:
>
> I do not yet propose what name or record is used for this experiment but
> having it an “address of an object” would be good as that enables
> testing from browsers. (CNAME is just as good as an address)
But my point is you can't find out a validator's RFC 5011 state
On 29/06/2015 21:48, Warren Kumari wrote:
I'd appreciate any feedback, the draft announcment is here:
Name: draft-wkumari-dnsop-trust-management
Revision: 00
Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors
Document date: 2015-06-29
Group: Indi
> On Jun 30, 2015, at 8:53 AM, Tony Finch wrote:
>
> Olafur Gudmundsson wrote:
>
>> There is much simpler way.
>> Just add record to the rootzone that is only signed by the new key.
>> If resolver returns AD bit it has the new key.
>
> I don't think this works.
>
> If the new key is publis
Olafur Gudmundsson wrote:
> There is much simpler way.
> Just add record to the rootzone that is only signed by the new key.
> If resolver returns AD bit it has the new key.
I don't think this works.
If the new key is published in the root zone's DNSKEY RRset then it will
be signed by the old k
On 29June2015Monday, at 19:07, David Conrad wrote:
And yes, this will fail if any of the loopback drafts are deployed.
>>> Sorry, I must be missing something obvious. Why?
>> As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does
>> it matter if the origin IP of the root
>>> And yes, this will fail if any of the loopback drafts are deployed.
>> Sorry, I must be missing something obvious. Why?
> As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does it
> matter if the origin IP of the root zone being served
> is sporadically distributed? It se
Why, yes, I still do. (and it can be found in the IEtF archives)
https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does it
matter if the origin IP of the root zone being served
is sporadically distribute
Atlas probes can help us we can even measure this from webpages,
cellphones, OS updates can add a test etc.
Olafur
On Jun 29, 2015 7:33 PM, "Warren Kumari" wrote:
> On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson
> wrote:
> > There is much simpler way.
> > Just add record to the rootzone th
Olafur Gudmundsson wrote:
>
> There is much simpler way.
> Just add record to the rootzone that is only signed by the new key.
> If resolver returns AD bit it has the new key.
>
> All that is needed is to sign a Rrset for a long time and add it at to
> the rootzone and make sure no ZSK signs it.
On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson
wrote:
> There is much simpler way.
> Just add record to the rootzone that is only signed by the new key.
> If resolver returns AD bit it has the new key.
>
> All that is needed is to sign a Rrset for a long time and add it at to the
> rootzone a
On Mon, Jun 29, 2015 at 5:59 PM, Ralf Weber wrote:
> Moin!
>
> On 29 Jun 2015, at 22:48, Warren Kumari wrote:
>>
>> I've written a draft that proposes a different way of performing root
>> key rollover that exposes who all has which key - this allows one to
>> know that 99.8% of resolvers have the
Bill,
> This looks very much like the draft that Olaf, Johan, and I wrote at the same
> time MSJ was proposing what we have now.
> You might want to talk to either Olaf or Johan for more details.
Don't suppose anyone has a copy of that draft?
> And yes, this will fail if any of the loopback dra
There is much simpler way.
Just add record to the rootzone that is only signed by the new key.
If resolver returns AD bit it has the new key.
All that is needed is to sign a Rrset for a long time and add it at to the
rootzone and make sure no ZSK signs it.
Olafur
On Jun 29, 2015 4:49 PM, "Warren
This looks very much like the draft that Olaf, Johan, and I wrote at the same
time MSJ was proposing what we have now.
You might want to talk to either Olaf or Johan for more details. And yes,
this will fail if any of the loopback drafts are deployed.
manning
bmann...@karoshi.com
PO Box 12317
Moin!
On 29 Jun 2015, at 22:48, Warren Kumari wrote:
I've written a draft that proposes a different way of performing root
key rollover that exposes who all has which key - this allows one to
know that 99.8% of resolvers have the new key, who has the old one,
and who will break.
It does this by
Hi all,
So, there is a project underway to roll the DNSSEC root key. There has
been much written about this, including SAC063
(https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a
DNSSEC Root KSK Rollover Plan Design Team, various consultations with
the community, many presentations a
24 matches
Mail list logo
