The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Error Reporting'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comme
I thinnk you're agreeing that we should add notifications even though we
can imagine a wide range of so-far nonexistent ways to limit the cost of
scanning.
My thought is that the notify is for the domain to be signed, so there's
no scanning, just parent checks to see whether it likes the new k
On Fri, Oct 13, 2023 at 10:48 AM John Levine wrote:
> I was looking at these two drafts. The first one says that scanning
> for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
> second one says to scan for DS bootstrap. I am experiencing cognitive
> dissonance.
>
I believe a mo
John,
On 10/16/23 18:19, John R Levine wrote:
On Mon, 16 Oct 2023, Peter Thomassen wrote:
3. the parent obtains a copy of a signaling zone and walks the signaling
records published there (at _signal.$NS, such as _signal.jo.ns.cloudflare.com),
If you think about it for a moment,
I did :-)
On Mon, 16 Oct 2023, Peter Thomassen wrote:
1. the parent receives an updated NS RRset,
3. the parent obtains a copy of a signaling zone and walks the signaling
records published there (at _signal.$NS, such as
_signal.jo.ns.cloudflare.com),
If you think about it for a moment, #3 doesn't work
On Sun, Oct 15, 2023 at 5:46 PM, Roy Arends wrote:
> Warren,
>
> Thanks for your feedback.
>
> I can add to the last line of the second paragraph in the abstract as
> follows
>
> Original:
> To mitigate this lack of feedback, this document describes a method for a
> validating recursive resolver
Moin!
On 16 Oct 2023, at 12:37, Peter Thomassen wrote:
> I share this concern (and Eric's, where the error page is an impersonation of
> the target page!), and am not convinced that the potential benefit is larger
> than the harm.
As said before an interstitial page created by the browser befor
Hi all,
For others following along: Upon Tim's suggestion towards the end of this WGLC,
I had sent notes to a handful of ICANN folks who are involved with DNSSEC, but
who may not be subscribed this list. I forwarded the WGLC message to them on
Sep 29 and extended Tim's invitation to offer rele
Nargh, I forgot my main point, which was on the suggestion in the security considerations to only diepslay
"c"/"j"/"o" iff the resolver has sufficient
reputation, according to some local policy (e.g., user configuration,
administrative configuration, or a built-in list of respectable
On 10/13/23 10:05, tirumal reddy wrote:
The above attack and possible mitigation is discussed in the security
considerations section of the draft, please see the snip below:
A client might choose to display the information in the "c", "j", and
"o" fields if and only if the encrypted
John,
On 10/13/23 19:48, John Levine wrote:
I was looking at these two drafts. The first one says that scanning
for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
second one says to scan for DS bootstrap.
No, draft-ietf-dnsop-dnssec-bootstrapping doesn't say that at all.
The
11 matches
Mail list logo
