I got quite used to being told "stop inventing things" and as a
general principle, its not such a bad thing to be told.
But it occurs to me, inventing a way to be told authoritatively where
the zone cut should be might not be such a bad idea, if it was useful.
If the alternative is to have to
On 11/30/2022 6:16 AM, Mark Andrews wrote:
On 30 Nov 2022, at 00:07, Joe Abley wrote:
On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen
wrote:
At the IETF a few weeks back, Johan and I felt a sudden
enlightenment when it occurred to us that the same approach
could be used to
Hi Joe and others,
Let me try to respond to several comments in one place.
1. On “knowing your parent”.
I agree with Joe, in general a child is ignorant of its parent. And while there
are methods like the one Mark describes that usually work there are certainly
corners where they don’t.
On Wednesday, November 30th, 2022 at 01:46, Mark Andrews wrote:
> > On 30 Nov 2022, at 00:07, Joe Abley jab...@hopcount.ca wrote:
>
> > One question occurs to me after reading your draft: you
> > suggest in a couple of places that it's easy for a
> > nameserver that is authoritative for a child
If we are going to send NOTIFY messages just send signed UPDATE messages. I
described how to do this securely about a decade ago now.
https://datatracker.ietf.org/doc/html/draft-andrews-dnsop-update-parent-zones-04
NOTIFY messages are just going to have to be relayed to the registrar in
> On 30 Nov 2022, at 00:07, Joe Abley wrote:
>
> On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen
> wrote:
>
>> At the IETF a few weeks back, Johan and I felt a sudden
>> enlightenment when it occurred to us that the same approach
>> could be used to reduce scanning cost for
Peter,
I like the concept a lot and this is a good natural evolution,
My comments/issues
#1 this should cover normal notify as well as there is no reason parent
should have to be updates every time an external DNS provider changes its
distribution "top"
#2 I would love the examples to use a
On Tue, Nov 29, 2022 at 15:57, Paul Wouters wrote:
> The main concern at the time was they TLDs didn’t want any kind of triggers
> hitting their production nameservers.
For what it's worth, I this proposal accommodates such concerns. It allows (in
your example) the TLD operator to specify
You might want to dig into the ancient discussion thread of “timers vs
triggers”.
The main concern at the time was they TLDs didn’t want any kind of triggers
hitting their production nameservers.
Paul
Sent using a virtual keyboard on a phone
> On Nov 29, 2022, at 08:08, Joe Abley wrote:
>
On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen
wrote:
> At the IETF a few weeks back, Johan and I felt a sudden
> enlightenment when it occurred to us that the same approach
> could be used to reduce scanning cost for CDS/CSYNC scans and
> the like, while maintaining low update
Dear DNSOP,
Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation
maintenance are usually detected through scheduled scans run by the consuming
party (e.g. top-level domain registry), incurring an uncomfortable trade-off
between scanning cost and update latency.
A similar
11 matches
Mail list logo
