On Tue, 7 Jan 2025 17:24:57 +0100
Peter Thomassen wrote:
> Hi Stefan,
Hello Peter,
> Thanks for your feedback. The below fixes will be included in the
> revised submission that will be published soon (probably today or
> tomorrow).
Thank you for your work, my reactions are below.
> On 12/27/
On Mon, 6 Jan 2025 21:02:52 -0500
Tim Wicinski wrote:
> All
Hello,
> Welcome back from holidays, those who have returned.
> Discussions with the working group and authors and we feel these
> documents are ready to move forward. The two deprecation documents
> are short. The focus of 8624-bis i
Internet-Draft draft-ietf-dnsop-ns-revalidation-08.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: Delegation Revalidation by DNS Resolvers
Authors: Shumon Huque
Paul Vixie
Willem Toorop
Name:draft-i
wildcarding should always have been signaled by the server and synthesized in
the stub.
however, when dns was first developed, stubs were tiny and the idea of an extra
500 lines
of C to implement wildcard synthesis would have seemed crazy.
what we should do now is evolve, for example an EDNS o
On Wed, Jan 8, 2025, 10:53 AM Paul Vixie
wrote:
>
> wildcarding should always have been signaled by the server and synthesized in
> the stub. however, when dns was first developed, stubs were tiny and the idea
> of an extra 500 lines of C to implement wildcard synthesis would have seemed
> craz
On Wednesday, January 8, 2025 11:52:03 PM UTC Watson Ladd wrote:
> On Wed, Jan 8, 2025, 10:53 AM Paul Vixie
> wrote:
>
> > ...
>
> Maybe I'm missing something but if the attacker is just filling the
> cache on a recursive resolver they cooperate with the origin to get
> the responses.
that's ho
On Wed, Jan 8, 2025 at 4:00 PM Paul Vixie wrote:
>
> On Wednesday, January 8, 2025 11:52:03 PM UTC Watson Ladd wrote:
>
> > On Wed, Jan 8, 2025, 10:53 AM Paul Vixie
>
> > wrote:
>
> >
>
> > > ...
>
> >
>
> > Maybe I'm missing something but if the attacker is just filling the
>
> > cache on a recu
On Wed, Jan 8, 2025 at 1:52 PM Paul Vixie
wrote:
[...]
Paul, responding to just this piece of your note ..
if a server (recursive or forwarding) knows the wildcard signal patterns
> then it is capable of synthesis for queries from initiators who do not know
> the wildcard signal patterns. this w
It appears that Paul Vixie said:
>what we should do now is evolve, for example an EDNS option or flag to
>indicate that the
>initiator is capable of understanding wildcard signalling, and if not, the
>responder should
>synthesize as before. this would be meaningful on both stub->recursive,
>
On Wednesday, January 8, 2025 7:18:31 PM UTC John Levine wrote:
> It appears that Paul Vixie said:
>
> >what we should do now is evolve, for example an EDNS option or flag to
> >indicate that the initiator is capable of understanding wildcard
> >signalling, and if not, the responder should synth
Hi,
Thanks Shumon for the summary of the major changes to the compact-denial draft.
As Shumon pointed out, there were some useful comments that came in after IETF
Last Call. The authors have integrated those comments, which are not extensive
but not trivial.
There’s a judgment call to be made
Dear all,
In this updated version of the Delegation Revalidation by DNS Resolvers
draft, we address the issues that came up during the dnsop working group
session at the IETF 120, namely:
* We mention that the security benefits with DNSSEC validated
infrastructure data only applies when r
Greetings again. draft-ietf-dnsop-domain-verification-techniques is stuck, I
think for good reason. It has evolved to be all of "best practices", "cool
extensions", "requirements", and "examples of how people do this now". That
evolution has caused the result to have conflicting advice and uncle
Paul Vixie wrote:
wildcarding should always have been signaled by the server and synthesized in
the stub.
No. See below.
however, when dns was first developed, stubs were tiny and the idea of an extra
500 lines
of C to implement wildcard synthesis would have seemed crazy.
A lot more seri
14 matches
Mail list logo
