Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson
A new version of
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson
A new version of
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson
A new version of I-D,
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson
A new version of
Dear WG,
After the October 26, IETF DNSOP interim WG on DNS Error Reporting, the
document editors have made the following changes to reflect the discussion:
Change 1) Due to qname minimisation, the reporting agent may not know that the
reported string has been shortened. There were a few
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Error Reporting
Authors : Roy Arends
Matt Larson
On Tue, 9 Nov 2021, Peter Thomassen wrote:
On 11/9/21 3:56 PM, Paul Wouters wrote:
Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!). The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the
Moin!
On 9 Nov 2021, at 17:12, Petr Špaček wrote:
>> 4. New requirement
> I think section 4 should not require full blown _loop_ detection, but any
> sort of limit should be good enough for compliance.
>
> I mean, implementing a loop detection algorithm in hot path might not be a
> good idea,
On 09. 11. 21 18:57, Viktor Dukhovni wrote
On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
I don't see need to specify _a_ value here. I think better approach is
acknowledge current state of things. What about something like this?
---
As for November 2021, the limit of 150 iterations for
> On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
>
> I don't see need to specify _a_ value here. I think better approach is
> acknowledge current state of things. What about something like this?
>
> ---
> As for November 2021, the limit of 150 iterations for treating answer as
> insecure is
An updated agenda for DNSOP has been published. We had to swap some
presentations due to the availability of presenters.
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-01
Best regards
Suzanne, Tim and Benno
On 03/11/2021 22:37, Benno Overeinder wrote:
All,
The DNSOP
On 08. 11. 21 8:49, Giovane C. M. Moura wrote:
Folks,
Loops in DNS are an old problem, but as our tsuname[0,1] disclosure last
May shows, they are still a problem.
We wrote a new draft that adds a new requirement to existing solutions:
recursive resolvers must detect and negative cache
Hi Paul,
On 11/9/21 3:56 PM, Paul Wouters wrote:
Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!). The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains
On Tue, 9 Nov 2021, Peter Thomassen wrote:
[ cut hashing or not discussion, can be done later ]
You can't bootstrap in-baliwick anyway, can you?
There seems to be a misunderstanding: The not-in-bailiwick limitation
means that a nameserver can't bootstrap its own domain, for lack for a
On Tue, 2021-11-09 at 04:55 +0100, Peter Thomassen wrote:
> The problem occurs because bootstrapping records cannot be at the
> apex (as to not overload the meaning of apex CDS/CDNSKEY records),
> but by "inheriting" the structure under dedyn.io, a situation arises
> where this condition is not
On 08. 11. 21 14:41, Wes Hardaker wrote:
Petr Špaček writes:
Thanks for the detail notes Petr, very helpful.
From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been
16 matches
Mail list logo
