Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-20 Thread Paul Wouters

On Tue, 20 Jun 2023, Peter Thomassen wrote:


 My thoughts on this as in how to decide who does what, is...

 in EPP, there is a section that I've coded to look like...

 The usual drop downs are Yes/No and may require a reason

 Create a new action, "DS Managed by", give it three options
 Y=the registrY should manage the CDS scanning (Polling whatever)
 R=the registraR should manage...
 N=Implicit management by the Registrar.

This would be a change / an extension to the EPP protocol, correct?

If so, there's probably not much DNSOP can do about it, but if I'm not 
mistaken, the REGEXT WG is chartered to address such things.


Yes that would be REGEXT.

But I don't think this will help either. It's default would have to
depend on the registry capability, and then on the registrar capability.
That doesn't help the DNS Hoster if it is not the Registrar as well.

That is why we are having this problem to begin with. We want DNS
Hosters to be able to be the authoritative source of DS, because
too many registrars aren't implementing C*

There was also a proposal/draft in REGEXT that would allow the Registry
to notify the Registrar if a CDS was changed via polling/registry direct
communication. I'm not sure if that ever made it to RFC though.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-20 Thread Peter Thomassen

Hi Mark,

On 6/13/23 16:43, Mark Elkins wrote:

There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up to it.

[...]


My thoughts on this as in how to decide who does what, is...

in EPP, there is a section that I've coded to look like...

The usual drop downs are Yes/No and may require a reason

Create a new action, "DS Managed by", give it three options
Y=the registrY should manage the CDS scanning (Polling whatever)
R=the registraR should manage...
N=Implicit management by the Registrar.

This would be a change / an extension to the EPP protocol, correct?

If so, there's probably not much DNSOP can do about it, but if I'm not 
mistaken, the REGEXT WG is chartered to address such things.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-20 Thread Matthijs Mekking

Hi,

On 6/10/23 21:42, Tim Wicinski wrote:

All

The chairs have been looking at two different drafts discussing the use 
of using DNS NOTIFY to update DNSSEC information.  The two drafts are:


https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify-01 


https://datatracker.ietf.org/doc/html/draft-dsawp-notify-00 



Mr Thomassen's draft is a bit more ambitious than Mr. Levine's draft, 
but both appear to work on the problem space of DNSSEC update 
automation.  The chairs are big fans of work around making DNSSEC 
deployment more operationally resilient.


We have some questions for the WG - if DNSOP adopted one of these, would 
DNS server vendors implement it down the road? (We think so)


I would definitely want to implement a CDS notify to the parent. It 
would help getting rid of the wasteful polling and we can reuse existing 
NOTIFY code. It feels like a good Hackathon project :)


It looks to me that this mechanism consists of three parts:

1. Notify the parent of a CDS/CDNSKEY/CSYNC change.
2. Notify a signer in a multi-signer group of DNSKEY/CDS/CDNSKEY change.
3. Locating the server to notify (NOTIFY record).

It seems that John Levine's draft is mainly covering part 1, while the 
draft from Johan and Peter covers all three.


I don't know if all three parts should be covered in one document, 
although they are strongly connected to each other.


I think the part about multi-signer may face the biggest challenges (see 
my comments on the Generalized DNS Notifications draft), so I if that 
turns out to slow down things, I wouldn't mind focusing on DS automation 
first, and perhaps a successor document that can tackle the multi-signer 
scenario.


Best regards,

Matthijs

The ICANN SSAC has been looking at this issue, so the ICANN meeting this 
coming week may be a good time for technical folks to discuss some of 
these ideas.


Feedback Welcome

thanks
tim



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-13 Thread John Levine
It appears that Mark Elkins   said:
>> There are registries doing CDS scanning now, and registrars testing
>> it. I agree that the flow back to the registrar if the registry does
>> it is ugly so registrar is better where possible. We'll probably end
>> up with both since some registrars aren't up to it.
>
>My thoughts on this as in how to decide who does what, is...
>
>in EPP, there is a section that I've coded to look like...

We're talking about this at the ICANN meeting this week, and I
hope we will find something that the gTLDs will be willing to do.

Do keep in mind that there are domain boundaries other than ones at
TLD/registrant boundaries.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-13 Thread Mark Elkins


On 2023/06/13 16:09, John Levine wrote:

This is certainly the approach I'd like to see. As a Registrar, about
40% of the Domains I've registered on behalf of Registrants are under my
DNS management and thus there is no need for either Polling or
Notifies. I'd also rather be in the path of any Updates by Registrants
that outsource their DNS.

For the large fraction of domains managed by the registrar, this stuff
doesn't matter unless a registrant delegates subdomains and wants to
sign those.

There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up to it.

R's,
John


My thoughts on this as in how to decide who does what, is...

in EPP, there is a section that I've coded to look like...

The usual drop downs are Yes/No and may require a reason

Create a new action, "DS Managed by", give it three options
Y=the registrY should manage the CDS scanning (Polling whatever)
R=the registraR should manage...
N=Implicit management by the Registrar.

Set the Default to "Y" (So the Registry does the polling, etc), 
interested Registrars can change this to "R" (they will poll the remote 
DNS provider) or "N" for Domains where the Registrar manages the DNS so 
upload DS records as required. Code changes are almost Cut'n'Paste. 
Registry would also have to create one new Database field.


--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-13 Thread John Levine
It appears that Mark Elkins   said:
>> What has changed is the start of some Registrars taking on the role of 
>> "agent" for Registrants doing DNSSEC. ...
>> So, the NOTIFY target could be such an agent (Registrar) who then 
>> forwards the appropriate update to the TLD via EPP.
>> I.e. the target would not be the TLD itself (directly).

That was the thought. There's a certain amount of hand waving about
how you find the NOTIFY target but no more than there is now for SOA
NOTIFY.

>This is certainly the approach I'd like to see. As a Registrar, about 
>40% of the Domains I've registered on behalf of Registrants are under my 
>DNS management and thus there is no need for either Polling or 
>Notifies. I'd also rather be in the path of any Updates by Registrants 
>that outsource their DNS.

For the large fraction of domains managed by the registrar, this stuff
doesn't matter unless a registrant delegates subdomains and wants to
sign those.

There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up to it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-12 Thread Mark Elkins

On 2023/06/12 08:49, Brian Dickson wrote:



On Sun, Jun 11, 2023 at 8:09 PM Paul Wouters > wrote:



On Jun 10, 2023, at 15:42, Tim Wicinski mailto:tjw.i...@gmail.com>> wrote:
>
> 
> All
>
> The chairs have been looking at two different drafts discussing
the use of using DNS NOTIFY to update DNSSEC information.

Interesting, as the reason for using CDS et. all was because TLD
operators didn’t want to receive and process NOTIFYs. Has this
changed ?

Related also the infamous “triggers vs timers”, where most TLDs
didn’t want triggers. Has this changed?

> We have some questions for the WG - if DNSOP adopted one of
these, would DNS server vendors implement it down the road? (We
think so)

I don’t think that’s the right question. What to TLD operators want?


What has changed is the start of some Registrars taking on the role of 
"agent" for Registrants doing DNSSEC.
This mostly applies to CDS/CDNSKEY but might eventually also encompass 
some or all of CSYNC (modulo perhaps the update(s) being DNSSEC signed 
using an existing KSK).


So, the NOTIFY target could be such an agent (Registrar) who then 
forwards the appropriate update to the TLD via EPP.

I.e. the target would not be the TLD itself (directly).

(This is very early in the discussions among 
experimenters/implementers, but certainly seems feasible, and might 
reduce latency on updates and load on agents.)


Brian



This is certainly the approach I'd like to see. As a Registrar, about 
40% of the Domains I've registered on behalf of Registrants are under my 
DNS management and thus there is no need for either Polling or 
Notifies.. I'd also rather be in the path of any Updates by Registrants 
that outsource their DNS.





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-12 Thread Brian Dickson
On Sun, Jun 11, 2023 at 8:09 PM Paul Wouters  wrote:

>
> On Jun 10, 2023, at 15:42, Tim Wicinski  wrote:
> >
> > 
> > All
> >
> > The chairs have been looking at two different drafts discussing the use
> of using DNS NOTIFY to update DNSSEC information.
>
> Interesting, as the reason for using CDS et. all was because TLD operators
> didn’t want to receive and process NOTIFYs. Has this changed ?
>
> Related also the infamous “triggers vs timers”, where most TLDs didn’t
> want triggers. Has this changed?
>
> > We have some questions for the WG - if DNSOP adopted one of these, would
> DNS server vendors implement it down the road? (We think so)
>
> I don’t think that’s the right question. What to TLD operators want?
>

What has changed is the start of some Registrars taking on the role of
"agent" for Registrants doing DNSSEC.
This mostly applies to CDS/CDNSKEY but might eventually also encompass some
or all of CSYNC (modulo perhaps the update(s) being DNSSEC signed using an
existing KSK).

So, the NOTIFY target could be such an agent (Registrar) who then forwards
the appropriate update to the TLD via EPP.
I.e. the target would not be the TLD itself (directly).

(This is very early in the discussions among experimenters/implementers,
but certainly seems feasible, and might reduce latency on updates and load
on agents.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-11 Thread Paul Wouters

On Jun 10, 2023, at 15:42, Tim Wicinski  wrote:
> 
> 
> All 
> 
> The chairs have been looking at two different drafts discussing the use of 
> using DNS NOTIFY to update DNSSEC information. 

Interesting, as the reason for using CDS et. all was because TLD operators 
didn’t want to receive and process NOTIFYs. Has this changed ?

Related also the infamous “triggers vs timers”, where most TLDs didn’t want 
triggers. Has this changed?

> We have some questions for the WG - if DNSOP adopted one of these, would DNS 
> server vendors implement it down the road? (We think so)

I don’t think that’s the right question. What to TLD operators want?

Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Multiple drafts discussing the use of DNS NOTIFY

2023-06-10 Thread Tim Wicinski
All

The chairs have been looking at two different drafts discussing the use of
using DNS NOTIFY to update DNSSEC information.  The two drafts are:

https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify-01

https://datatracker.ietf.org/doc/html/draft-dsawp-notify-00

Mr Thomassen's draft is a bit more ambitious than Mr. Levine's draft, but
both appear to work on the problem space of DNSSEC update automation.  The
chairs are big fans of work around making DNSSEC deployment more
operationally resilient.

We have some questions for the WG - if DNSOP adopted one of these, would
DNS server vendors implement it down the road? (We think so)

The ICANN SSAC has been looking at this issue, so the ICANN meeting this
coming week may be a good time for technical folks to discuss some of these
ideas.

Feedback Welcome

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop