It appears that Johan Stenstam said:
>Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS
>UPDATE message that carries both the data to be
>modified and the proof that the change request originated with the owner (the
>child) and has not been modified in transit…
>it
> On 30 Oct 2023, at 13:00, Johan Stenstam
> wrote:
>
> But let’s ensure that we have identified the correct scope of the problem
> rather than cherry-picking the two simplest cases.
+1
IMO the discussion of this I-D has lost focus. Let’s find it and get back on
track. :-)
> On 28 Oct 2023, at 16:40, Paul Wouters wrote:
>
> On Oct 25, 2023, at 13:14, Johan Stenstam
> wrote:
>>
>> To begin with it works equally well with or without DNSSEC.
>
> That statements seems a little odd?
Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS
On Oct 25, 2023, at 13:14, Johan Stenstam
wrote:
>
>
> To begin with it works equally well with or without DNSSEC.
That statements seems a little odd?
> Furthermore it is a cleaner solution than what we currently have (i.e. child
> zone published CDS and/or CSYNC and parent at some future
On 28 Oct 2023, at 03:44, Paul Wouters wrote:
>>> Scanners are, of course, inefficient, and notifications are a way to
>>> improve that. I just think that as we are making comparisons, with
>>> arguments whose strength is (in part) based on the number of queries
>>> needed, we should get the
On Fri, 27 Oct 2023, Johan Stenstam wrote:
Scanners are, of course, inefficient, and notifications are a way to improve
that. I just think that as we are making comparisons, with arguments whose
strength is (in part) based on the number of queries needed, we should get the
order of magnitude
> On 10/27/23 11:51, Johan Stenstam wrote:
>>> Extra vantage points are a mitigation for the (prevalent) lack of
>>> signatures during bootstrapping; once authentication is handled, there's no
>>> need for it.
>> I get that. But, as you know from both the draft and the presentation I made
>>
On 10/27/23 11:51, Johan Stenstam wrote:
Extra vantage points are a mitigation for the (prevalent) lack of signatures
during bootstrapping; once authentication is handled, there's no need for it.
I get that. But, as you know from both the draft and the presentation I made at
OARC some
Hi Peter,
> On 10/25/23 18:19, Johan Stenstam wrote:
>> With “scanners” I refer to CDS scanners and CSYNC scanners. These things
>> issue a gazillion DNS queries, over and over and over, with an extremely
>> small catch of “new CDS” or “new CSYNC” records. They get hit by rate
>> limiting
On 10/25/23 18:19, Johan Stenstam wrote:
With “scanners” I refer to CDS scanners and CSYNC scanners. These things issue a gazillion DNS queries, over and over and over, with an extremely small catch of “new CDS” or “new CSYNC” records. They get hit by rate limiting measures from the large DNS
Hi Libor,
> On 26 Oct 2023, at 12:26, libor.peltan
> wrote:
>
> Hi,
> I'm not sure if this helps the discussion, but Knot DNS implements "DS push",
> an automated DDNS update
> updating the DS (not NS) at parent.
> It's mostly intended for single-organization parent-child relations, where
>
Hi,
I'm not sure if this helps the discussion, but Knot DNS implements "DS
push", an automated DDNS update updating the DS (not NS) at parent.
It's mostly intended for single-organization parent-child relations,
where TSIG (or soon DDNSoQ) can be configured easily.
Libor
Dne 25. 10. 23 v
Just picking one of these emails.
What’s all the FUD here about?
There is *nothing* new here. CPE boxes have done UPDATE to change their
addresses to *non authoritative* servers using UPDATE for at least a decade
now. DYN DNS did this. The updates used TSIG for authentication. Mac also
> On 25 Oct 2023, at 18:58, Joe Abley wrote:
>
> On 25 Oct 2023, at 18:46, Johan Stenstam
> wrote:
>
>> I agree. But it is bad to design a system where the key CANNOT be rolled.
>
> I agree. I was just expressing doubt that you can find a single automated
> mechanism that is appropriate
Hi Paul,
> On 25 Oct 2023, at 17:20, Paul Wouters wrote:
>
> On Oct 25, 2023, at 10:11, Paul Vixie
> wrote:
>>
>
> [speaking as individual]
>
>> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone
>> modification. perhaps propose a new RCODE having the same message
On 25 Oct 2023, at 18:46, Johan Stenstam
wrote:
> I agree. But it is bad to design a system where the key CANNOT be rolled.
I agree. I was just expressing doubt that you can find a single automated
mechanism that is appropriate to use in all possible compromise scenarios.
For a hopefully
Hi,
> On 25 Oct 2023, at 17:50, Joe Abley wrote:
>
> On 25 Oct 2023, at 17:31, Johan Stenstam
> wrote:
>
>> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>>
>>> I am not at all familiar with SIG(0), so bear with me. What is the key
>>> distribution mechanism for the DNS UPDATE originator's
Hi Paul,
> On 25 Oct 2023, at 16:10, Paul Vixie
> wrote:
>
> see inline.
>
> Johan Stenstam wrote on 2023-10-25 01:09:
>> Greetings Working Group,
>> As many of you are aware Peter Thomassen, John Levine and I have been
>> working on the generalised notifications for a while. The key idea
On 25 Oct 2023, at 17:31, Johan Stenstam
wrote:
> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>
>> I am not at all familiar with SIG(0), so bear with me. What is the key
>> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931
>> suggests an unsigned KEY RR, I think?
>
Hi Joe,
> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>
> On 25 Oct 2023, at 10:10, Johan Stenstam
> wrote:
>
>> So now there’s a new draft, that further extends the same core idea (locate
>> the target for the information being sent via a DNS lookup in the parent
>> zone). However, the new
On Oct 25, 2023, at 10:11, Paul Vixie wrote:
>
[speaking as individual]
> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone
> modification. perhaps propose a new RCODE having the same message form as
> UPDATE?
I agree.
>> 2. No requirement for DNSSEC. Great as
see inline.
Johan Stenstam wrote on 2023-10-25 01:09:
Greetings Working Group,
As many of you are aware Peter Thomassen, John Levine and I have been working
on the generalised notifications for a while. The key idea there is obviously
that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child
On 25 Oct 2023, at 10:10, Johan Stenstam
wrote:
> So now there’s a new draft, that further extends the same core idea (locate
> the target for the information being sent via a DNS lookup in the parent
> zone). However, the new draft
> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes
Greetings Working Group,
As many of you are aware Peter Thomassen, John Levine and I have been working
on the generalised notifications for a while. The key idea there is obviously
that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the parent scanner
will allow the scanner to fast
24 matches
Mail list logo
