This draft should be of interest to this WG, providing an alternative to
draft-wouters-sury-dnsop-algorithm-update.
jakob
Forwarded message:
From: internet-dra...@ietf.org
To: Roy Arends , Jakob Schlyter
, Matt Larson
Subject: New Version Notification for
draft-arends-dnsop
On 19 maj 2014, at 23:45, Mark Andrews wrote:
> Everytime I have mentioned SRV records to HTTP folks they
> say it won't work as the extra lookup takes too long.
So query A//SRV in parallel and be done with it. Smart resolves will
provide additional data just for fun and everyone will be ha
On 4 okt. 2015, at 20:27, Suzanne Woolf wrote:
> On Oct 4, 2015, at 2:00 PM, David Conrad wrote:
>
>> I've since been told that the draft doesn't actually document current
>> practice (don't know the details), so this probably needs to be fixed.
>
> What "needs to be fixed"? That the draft do
On 5 okt. 2015, at 15:08, Paul Hoffman wrote:
>> As far as I'm aware, the document does document current practice.
>
> It does not. It describes a mixture of some of the current practice and some
> aspirational hopes for how things might be done. Further, it is incomplete in
> many aspects.
I
As we've seen to good summary on requirements for on a well-behaved DNS
delegation of a domain name, Patrik Wallström and myself has written an
Internet-Draft [1] describing such requirements. The requirements were
developed within the CENTR Test Requirements Task Force (TRTF) and most of the
On 8 feb. 2016, at 11:00, Ralf Weber wrote:
> I would soften some of language and have a question.
>
> 5.1. There are use cases where the serial number rarely if ever is the same
> on all servers and it's only really used inside communication for a given
> domain and not during resolution. So
(very very delayed reply, rebooting draft now...)
On 2016-03-17 at 22:45, John Kristoff wrote:
The introduction lists 8 areas of interest. All, except "7. Name
Server" have their own section in the table of contents. Oversight?
Yes, one section was missing. Fixed now.
This sentence is a
I'm happy to invite DNSOP WG members to the following event:
Wednesday, November 11, 2009 - 15:10-16:10
Room: Castleview 1
Members of the Root DNSSEC Design Team will give a technical
presentation about DNSSEC for the root zone, followed by a Q&A session.
See you in Hiroshima,
Jako
On 4 nov 2009, at 14.14, Jakob Schlyter wrote:
I'm happy to invite DNSEXT WG members to the following event:
Wednesday, November 11, 2009 - 15:10-16:10
Room: Castleview 1
Members of the Root DNSSEC Design Team will give a technical
presentation about DNSSEC for the root zone, followed
On 4 nov 2009, at 14.14, Jakob Schlyter wrote:
I'm happy to invite DNSSEC deployment list members to the following
event:
Wednesday, November 11, 2009 - 15:10-16:10
Room: Castleview 1
FYI, the room as been changed to Acacia East.
On 11 nov 2009, at 13.33, Yoshiro YONEYA wrote:
Room confliction?
yes, we might have to move again. signs will be posted.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
we've been moved (once again), this time to Cattleya West. sorry for
the fuzz.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 22 feb 2010, at 17.17, Matt Larson wrote:
> +1, total and complete agreement. I am adamantly opposed to including
> any text about SHA1 hash collisions in an NSEC3 context.
+1.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
heim!
Jakob Schlyter,
on behalf of the Root DNSSEC Design Team
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for a RESTful HTTP API or dynamic DNS UPDATE
doesn't change this. Trying to reuse DNSSEC itself for this authentication, and
still support both the initial key transfer and key rollover in case of key
compromise, does IMHO not fly.
jakob
--
Jakob Schlyter
On 2 jul 2010, at 17.11, Andrew Sullivan wrote:
> It may surprise you to learn that there are users who do not find the
> user interface for these tools, or the idea of cutting and pasting
> into BIND config files, even slightly intuitive. I've personally
> encountered situations where it took we
ffer TLSv1/SSLv3 with
RC4-SHA.
jakob
--
Jakob Schlyter
Kirei AB - www.kirei.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 30 sep 2010, at 18.51, Stephan Lagerholm wrote:
> It is not clear if the validUntil time is referring to the time when the
> key is expected to be rolled into RFC 5011 revoked state or when it is
> expected to be removed from the zone.
Once the key is revoked, it is no longer valid and cannot
e files that are published there?
I know of at least one vendor that has started to implement support to base
trust anchor fallback on the information in the TA repository. As soon as their
code and ideas are mature enough, I hope they'll share their thoughts.
On 4 okt 2010, at 17.18, Tony Finch wrote:
> This argument also implies that RFC 5011 cannot be used to roll over root
> trust anchors in the event of a compromise.
Depending on the type of compromise, a RFC 5011 may not be appropriate.
> It isn't immediately clear to me from the root KSK DPS wh
On 4 okt 2010, at 18.56, Tony Finch wrote:
> On Mon, 4 Oct 2010, Jakob Schlyter wrote:
>>
>> Depending on the type of compromise, a RFC 5011 may not be appropriate.
>
> RFC 5011 allows for smooth operation across compromise or loss of the
> active KSK, or compromise o
On 4 okt 2010, at 17.12, Marsh Ray wrote:
> Say, what's the link to the Internet Draft proposal we're discussing anyway?
https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/, among
others.
j
___
DNSOP mailing list
DNSOP@ietf.
On 1 feb 2011, at 01.40, Phillip Hallam-Baker wrote:
> My advice to Cisco would be to use their existing root to sign the published
> CSR for the DNS root KSK in the short term at least.
That's why we (the Root DNSSEC Design Team) included a CSR as one output from
the key generation ceremony.
I have read this draft, have no further comments and support it being published
as Informational.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tion for draft-jabley-dnssec-trust-anchor-05.txt
> Date: 10 september 2012 22:51:38 CEST
> To: ja...@kirei.se
> Cc: gubai...@microsoft.com, joe.ab...@icann.org
>
>
> A new version of I-D, draft-jabley-dnssec-trust-anchor-05.txt
> has been successfully submitted by Jakob Sc
On 2023-03-28 at 10:14, Mark Andrews wrote:
> Is this JST?
Yes, 13:00 – 14:00 JST.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
26 matches
Mail list logo
