Dear dnsop,
I wrote a quick draft to specify that answers returned should be
returned in a random order:
https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
This comes out of recent experience we had where a customer saw
significant bias in how their servers were used until we
Hi Shane!
On 5 Nov 2024, at 13:13, Shane Kerr wrote:
> I wrote a quick draft to specify that answers returned should be returned in
> a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
I think that you might need to nail down what "random" means. I presume y
Folks,
Thanks very much for considering
Documenting and Managing DNSSEC Algorithm Lifecycles
draft-crocker-dnsop-dnssec-algorithm-lifecycle-01
For reference, I was motivated to propose this when I understood how the
Red Hat incident evolved. For those who haven't followed that incident,
Red Hat
Hi Shane,
On 11/5/24 13:08, Shane Kerr wrote:
I did consider the idea of periodic shuffling. That makes sense to me, since I
think we can reasonably assume that servers will not be shuffling at exactly
the same time and should have different results. It would mean slightly more
state on the s
Hi Shane
On Tue, Nov 05, 2024 at 11:56:37AM +, Shane Kerr wrote:
> Dear dnsop,
>
> I wrote a quick draft to specify that answers returned should be returned in
> a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
>
> This comes out of recent experience we
Hi Shane!
On 5 Nov 2024, at 14:08, Shane Kerr wrote:
> In the security section I do mention that you don't need
> cryptographically-secure random numbers. I could expand that a bit, if it is
> useful.
Every time I mention "random" within earshot of Lucas Pardue it invites hard
stares, I thin
Nick,
Thanks. Even if the algorithm is just an encoding format, the same issue
applies: It's important that creating new messages with that algorithm must
stop well before the receivers stop being able to receive messages in that
format.
The point of the proposed life cycle model is that doing t
On Wed, Nov 6, 2024 at 12:59 AM Steve Crocker wrote:
> Despite the reference to DNSSEC in the title, I think the life cycle
> concepts apply to the use of algorithms in all settings.
I'm wondering if you might want to make your draft more generic, and
explicitly expand it to all protocols/techn
On Tue, Nov 5, 2024 at 2:09 PM Steve Crocker wrote:
> Nick,
>
> Thanks. Even if the algorithm is just an encoding format, the same issue
> applies: It's important that creating new messages with that algorithm must
> stop well before the receivers stop being able to receive messages in that
> fo
On Tue, Nov 05, 2024 at 09:15:15PM +0800, Mukund Sivaraman wrote:
> Hi Shane
>
> On Tue, Nov 05, 2024 at 11:56:37AM +, Shane Kerr wrote:
> > Dear dnsop,
> >
> > I wrote a quick draft to specify that answers returned should be returned in
> > a random order:
> >
> > https://datatracker.ietf.o
Overall, I think this document, and its definition of the EXTRA-TEXT field as
JSON is important. To that end, I am eager to see progress in this area.
However, I think we should not quite yet ship this out of the WG.
Two specific points:
- I’d like to have a working group discussion with regards
Thanks for the reply, Steve.
On Tue, Nov 5, 2024 at 12:26 PM Steve Crocker wrote:
> Folks,
>
> Thanks very much for considering
>
> Documenting and Managing DNSSEC Algorithm Lifecycles
> draft-crocker-dnsop-dnssec-algorithm-lifecycle-01
>
> For reference, I was motivated to propose this when I u
On 5 Nov 2024, at 14:48, Joe Abley wrote:
> The idea of making a protocol change in the DNS to work around behaviour that
> might be fixable in one point release of Android and iOS
... seems less than ideal, I meant to say. Sorry, clicked send a bit early.
Perhaps both those things were obviou
Hi Steve,
On Tue, Nov 5, 2024 at 11:26 PM Steve Crocker wrote:
> Documenting and Managing DNSSEC Algorithm Lifecycles
> draft-crocker-dnsop-dnssec-algorithm-lifecycle-01
>
> I noted during the DNSOP session yesterday that two algorithms were
> selected for deprecation. I believe the message b
Jen,
Thanks. Despite the reference to DNSSEC in the title, I think the life
cycle concepts apply to the use of algorithms in all settings.
Steve
On Tue, Nov 5, 2024 at 1:52 PM Jen Linkova wrote:
> Hi Steve,
>
> On Tue, Nov 5, 2024 at 11:26 PM Steve Crocker wrote:
>
>> Documenting and Managi
Jen,
Thanks. Yes, I agree. In preparing this draft, we had a brief discussion
about generalizing. It seemed to be easier to get this version into the
system and, hopefully, approved. I would have hoped the general idea would
have been accepted quickly and easily, but it wasn't the case. (I've
> I wrote a quick draft to specify that answers returned should be
> returned in a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
>
> This comes out of recent experience we had where a customer saw
> significant bias in how their servers were used until we ran
Hi Joe!
On 05/11/2024 12.47, Joe Abley wrote:
On 5 Nov 2024, at 13:13, Shane Kerr wrote:
I wrote a quick draft to specify that answers returned should be returned in a
random order:
https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
I think that you might need to nail dow
Hi,
I think this draft could be incorporated into
draft-ietf-dnsop-structured-dns-error by defining a new c contact URI schema
for the operator or public resolver, to be used by resolvers subject to
regulatory requests, not only to public ones. E.g. not my home resolver but my
isp resolver serv
On Tue, Nov 05, 2024 at 02:09:44PM +, Steve Crocker wrote:
>Nick,
>Thanks. Even if the algorithm is just an encoding format, the same issue
>applies: It's important that creating new messages with that algorithm
>must stop well before the receivers stop being able to receive me
Hi DNSOP,
Public DNS resolvers (such as 1.1.1.1, 8.8.8.8, and others) are increasingly
subject to requirements to censor responses flowing through them. When this
happens, it's important to be transparent to end users. The mechanism in this
draft is intended to allow that in a way that addresse
shane> I wrote a quick draft to specify that answers returned should be
shane> returned in a random order:
While it seems like a good idea to have the auth shuffle, my experience
from doing tech support for BIND and having this conversation way too
often is:
- there are way too many moving parts
Dear Colleagues,
We are reaching out to inform you of important changes to the DNSSEC trust
anchor in the root zone. If you manage a validating DNS resolver or a tool that
interacts with the DNS root zone you might need to change your software to
handle the changes. This letter provides a summa
On 2024/11/05 20:59, Robert Edmonds wrote:
Overall I think it might make sense to have an informational document
that describes the problem, the mechanisms that could be used in the
DNS to address that problem (various kinds of reordering at different
points in the stack, etc.), makes operatio
edmonds> Overall I think it might make sense to have an informational
edmonds> document that describes the problem, the mechanisms that could
edmonds> be used in the DNS to address that problem (various kinds of
edmonds> reordering at different points in the stack, etc.), makes
edmonds> operational
Shane Kerr wrote:
> I wrote a quick draft to specify that answers returned should be returned in
> a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
>
> This comes out of recent experience we had where a customer saw significant
> bias in how their servers were
On Tue, Nov 05, 2024 at 09:15:15PM +0800, Mukund Sivaraman wrote:
> Hi Shane
>
> On Tue, Nov 05, 2024 at 11:56:37AM +, Shane Kerr wrote:
> > Dear dnsop,
> >
> > I wrote a quick draft to specify that answers returned should be returned in
> > a random order:
> >
> > https://datatracker.ietf.
27 matches
Mail list logo
