Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March

[Steve Crocker]

Folks,

I am organizing a panel session within the DNSSEC Workshop during the upcoming ICANN meeting in Cancún in March on the subject of DNSSEC provisioning.  There are two related but somewhat distinct topics.  One is the update of the DS record when the DNS provider rolls the key.  The other is how multiple DNS providers coordinate when each is signing the zone.  Various proposals exist to solve each of these problems, but none has been fully accepted, and each suffers from a gap in the provisioning process.

Depending on who is on the panel and we can cover either both topics or just the first topic.  I also intend to organize a session on these topics in Paris in May at the ICANN Global Domains Division Summitt and/or the DNS Symposium.  Also, the dnssec-pr...@shinkuro.com mailing list is specific devoted to these two topics.

Please let me know if you're interested in participating and if you have a position on how to address these problems.

Details

What is the path forward for automating solutions to these two provisioning problems?  Are new protocols needed?  What changes are required of registrars, DNS providers and/or registries? 

 

With respect to updating DS records, the solution space is basically a two by two matrix, with a subordinate third dimension:

• Are new DS records pushed upward, i.e. is the transmission initiated by the DNS provider, or are new DS records pulled upward by the registry or registrar?
  
  
• Is the registry or the registrar involved on the upper end of the transmission?

The subordinate third dimension is whether the KSK, DS or both are communicated.

The solution in RFC 8078 is the pull/registry solution with support for both KSK and DS.  It was developed by a couple of DNS providers and is on the IETF standards track, but, so far as I can tell, is being adopted by a relatively few ccTLDs and is not gaining any traction within the gTLD community.  In contrast, GoDaddy has suggested its Domain Connect software could be extended to allow a push/registrar solution for DS updates.

 

With respect to coordination among multiple DNS providers, Shumon Huque, et al's Internet-Draft  https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec-01 [tools.ietf.org] sets for a scheme for multiple DNS providers to coordinate cross-signing of the same zone when it's served from multiple providers.

 

I have both a general and a specific interest in this.  The general interest is in seeing some sort of solution be adopted in order to facilitate smoother operation and greater adoption of DNSSEC.  My specific interest is a guess that if the registrant could add the names of his DNS providers into the registration details, it would make both of these coordination processes much easier.

Thanks,

Steve Crocker

[sivasubramanian muthusamy]

On the point immediately above:

I am a Registrant, with five or six of my own domain names under a "Reseller" account which manages only these few accounts. I have found creation of various  DNS/Mx records, some in the Domain Control panel, and some in the Web hosting control panel to be tasks that are not 'user-friendly' for the average Registrant. Besides, with a view to avoid errors that might interfere with the site's functionality, I have always found it convenient to ask the Master reseller to create / update all necessary records. 

Is there a way of making these tasks expected of the Registrant to be as easy as ordering icecream from an online icecream vendor? Or come up with an alternate method of enabling the non-technical Registrant (for this purpose, over 90% of the global Internet users) to maintain and announce their DNS records as good as an advanced expert does?

Sivasubramanian M

Thanks,

Steve Crocker

--
You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.
To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zvLpW6MYR-oeAEw9wjxg9AmUGh3hRN3%3D8NuCRezamGXCRg%40mail.gmail.com.

[Steve Crocker]

Tony,

Thanks!  I have taken the liberty of copying the dnssec-pr...@shinkuro.com mailing list.  If you would like to join the list, let me know.

Some comments and questions in line below.

On Mon, Jan 27, 2020 at 11:42 AM Tony Finch <d...@dotat.at> wrote:

Steve Crocker <st...@shinkuro.com> wrote:
>
> Please let me know if you're interested in participating and if you have
> a position on how to address these problems.

I'm in the process of trying to persuade management to send me to Paris in
May, so this is somewhat provisional. But I have opinions :-) 

Firstly, RFC 7344/8078 CDS/CDNSKEY should be seen as a protocol between a
zone's key management and signing system, and the zone's delegation
management system. Although it was designed to span the child/parent
boundary, it is also great within a child's systems for disentangling two
distinct parts by providing a standard interface between them. So the code
that a child uses to manage its secure delegation doesn't need to ask the
signer about any key timing metadata, it can just look at the zone apex.

I don't understand the model and roles you have in mind when you refer to the zone's key management and signing system on the one hand and the zone's delegation management system on the other hand.  I'm not objecting, just asking for clarification.  I suspect it will be helpful to lay out the key roles so everyone has a good picture of all the moving parts.

The more tools we have that do useful things with CDS/CDNSKEY, the more
incentive there is to deploy them. WRT delegation management I think we
should aim for the least restrictive deployment model possible. That is,
registrars AND registries should be encouraged to act on CDS/CDNSKEY
records. I don't want the registr*s to be able to point fingers at each
other saying, well, we'd like to support it but the other kind of registr*
is holding us back.

If I understand the point you're making, the DNS provider could generate the CDS and/or CDNSKEY records and then either the registrar or the registry could pull those records.  The only coordination that would be needed is for the registry and registrar to agree on which one one will be polling.  It seems logical to me that the registry is the one who decides.  Thus, I can imagine, say, .CH does its own polling but another registry, say .COM, has the registrar do the work.  For the sake of argument, let's imagine GoDaddy is a registrar for both .CH and .COM.  It would have to know that it must do the polling for .COM and must not do the polling for .CH.  This seems to me to be feasible, although I believe some registrars prefer to have complete knowledge of the data passed to the registry.

WRT CDS vs CDNSKEY, there are enough registries that require DNSKEY that
signers must generate both, and client-side tools must be prepared to use
either CDS or CDNSKEY. Although I would prefer it if registries could all
agree on one way to do things, that seems too much of a hurdle :-)

Yes, the DNS provider can produce both CDS and CDNSKEY records, although I can see two possible problems.

I can imagine a small but potentially annoying issue with respect to timing if both records are required by the client.  What happens if one of these is put into the zone before the other and the client sees the first one but not the second when it polls?

A more serious potential problem is related to the algorithms.  The registry might require the use of a crypto hash algorithm for computing the DS record that is not supported by the DNS provider.  I guess we could insist that in order to introduce a new DS algorithm, every DNS provider has to have the capability of computing it.  This would require a global schedule for introducing new DS algorithms.  Hmm.. I guess this would be required no matter whether the DNS provider computes the DS record because there's the same requirement on the validation side.  That is, no registry should use a new DS algorithm until all of the validators have the capability of checking it.

There's a broader issue of the structure of the market: at the moment,
specialist hosting providers are in a difficult position because it's hard
for them to do interesting things with the DNS if they are not either the
domain's owner or its registrar. And being a registrar is fiendishly
difficult. Cloudflare is a good example of this: they originally
championed RFC 7344/8078 (as an independent hosting provider), but
eventually became big enough to justify becoming a registrar, since that
was a faster way to solve their problems.

Yes, this is precisely what I have in mind when I suggest it would be useful to list DNS providers in the registration data.  It seems to me that would simplify operation for everyone.

A related awkwardness is that implementation of CSYNC and CDNSKEY would
help hosting providers, but I expect registrars don't particularly want
their hosting business to be eroded by a protocol that makes it easier for
their customers to move their web sites (etc.) elsewhere.

Yes, I have heard the argument that registrars don't want this to happen because it reduces their ability to control the registrant's choice of service providers.  I'm not sure how much resistance there actually is as opposed to rumors of such resistance.  

That's probably enough positioning for now...

Again, thanks!

Steve

 

Tony.
--
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
partnership and community in all areas of life

[Tony Finch]

Steve Crocker <st...@shinkuro.com> wrote:
>
> Thanks! I have taken the liberty of copying the
> dnssec-pr...@shinkuro.com mailing list. If you would like to
> join the list, let me know.

I think I've already subscribed, but if I haven't, please add me!

> I don't understand the model and roles you have in mind when you refer
> to the zone's key management and signing system on the one hand and the
> zone's delegation management system on the other hand.

To be super concrete, I use BIND for key management and zone signing. BIND
doesn't come with any tools for talking to registr(ar|ie)s so I have my
own. My delegation scripts just look at zone files to find out what the
delegation should be - they don't need access to the key files, which for
BIND normally implies access to the secret keys (if, like me, you don't
have an HSM!). So my signer can run on an isolated system that can't talk
to the outside world, whereas my delegation scripts can run on a separate
system with a different security posture. And my delegation scripts don't
need to be changed if I switch signer to Knot DNS or whatever, because the
scripts get information about what the DS records should be using an open
standard, rather than signer-specific utilities.

> If I understand the point you're making, the DNS provider could generate
> the CDS and/or CDNSKEY records and then either the registrar or the
> registry could pull those records. The only coordination that would be
> needed is for the registry and registrar to agree on which one one will be
> polling. It seems logical to me that the registry is the one who decides.

Right, though my argument is that if the registry fails to act then that
should be taken as a de facto decision that registrars can/should do so.

> This seems to me to be feasible, although I believe some registrars
> prefer to have complete knowledge of the data passed to the registry.

Is there an EPP mechanism for registries to tell registrars about changes
like this?

> I can imagine a small but potentially annoying issue with respect to
> timing if both records are required by the client. What happens if one
> of these is put into the zone before the other and the client sees the
> first one but not the second when it polls?

I think there are a couple of more general questions underlying this:

RFCs 7344 and 8078 leave quite a lot of the business logic unspecified,
such as the polling interval, the hold-down time (if any), CDS vs CDNSKEY
vs both, how carefully to check all the nameservers, etc. Do we need one
blessed way?

And how to communicate changes to the domain owner or operator, and how
much to communicate? "How" might be tricky if you are a thin registry, or
if the owner, operator, and registrar are all different people. For "how
much" I can see arguments for everything between prolix and mute - leave
error reporting to Zonemaster and DNSviz...

I don't have strong opinions about either quesion.

> A more serious potential problem is related to the algorithms. The
> registry might require the use of a crypto hash algorithm for computing
> the DS record that is not supported by the DNS provider.

As an example of deprecating a digest type, I recently updated BIND's
dnssec-cds utility to suppress SHA-1 more thoroughly (RFC 8624 section
3.3). The new logic is to generate SHA-2 digests from CDNSKEY if there are
only SHA-1 CDS records, and drop the SHA-1 digests if the CDS records have
both. (It doesn't do SHA-384 by default.)

The situation for new digest types is fairly simple for dnssec-cds: it is
required to be able to validate the proposed new delegation, to ensure
that it doesn't break things (RFC 7344 section 4.1 bullet 3), so it will
report an error if it is asked to work with a post-quantum experiment or
whatever. In that situation I guess the owner of the child zone either has
to update the traditional way (if that involves less checking) or wait...

It's OK if the parent introduces a new digest type before it's widely
supported by validators. It's OK if the parent deprecates old and busted
digests before its child does. There isn't a need for everyone to move in
lock step, provided there's always at least one ~universally supported
digest type. It's best if the parent checkers aren't holding everyone back
from adopting the new hotness.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

The Minch: South or southwest, veering west later, 5 to 7. Moderate or rough
in south, slight or moderate in north. Squally wintry showers, occasionally
thundery. Moderate or good, occasionally poor.

[Tony Finch]

Steve Crocker <st...@shinkuro.com> wrote:
>

[ I'm not sure if the first copy of this message went out properly, so
sorry if this is a duplicate! ]

> I don't understand the model and roles you have in mind when you refer
> to the zone's key management and signing system on the one hand and the
> zone's delegation management system on the other hand.

To be super concrete, I use BIND for key management and zone signing. BIND
doesn't come with any tools for talking to registr(ar|ie)s so I have my
own. My delegation scripts just look at zone files to find out what the
delegation should be - they don't need access to the key files, which for
BIND normally implies access to the secret keys (if, like me, you don't
have an HSM!). So my signer can run on an isolated system that can't talk
to the outside world, whereas my delegation scripts can run on a separate
system with a different security posture. And my delegation scripts don't
need to be changed if I switch signer to Knot DNS or whatever, because the
scripts get information about what the DS records should be using an open
standard, rather than signer-specific utilities.

> If I understand the point you're making, the DNS provider could generate
> the CDS and/or CDNSKEY records and then either the registrar or the
> registry could pull those records. The only coordination that would be
> needed is for the registry and registrar to agree on which one one will be
> polling. It seems logical to me that the registry is the one who decides.

Right, though my argument is that if the registry fails to act then that
should be taken as a de facto decision that registrars can/should do so.

> This seems to me to be feasible, although I believe some registrars
> prefer to have complete knowledge of the data passed to the registry.

Is there an EPP mechanism for registries to tell registrars about changes
like this?

> I can imagine a small but potentially annoying issue with respect to
> timing if both records are required by the client. What happens if one
> of these is put into the zone before the other and the client sees the
> first one but not the second when it polls?

I think there are a couple of more general questions underlying this:

RFCs 7344 and 8078 leave quite a lot of the business logic unspecified,
such as the polling interval, the hold-down time (if any), CDS vs CDNSKEY
vs both, how carefully to check all the nameservers, etc. Do we need one
blessed way?

And how to communicate changes to the domain owner or operator, and how
much to communicate? "How" might be tricky if you are a thin registry, or
if the owner, operator, and registrar are all different people. For "how
much" I can see arguments for everything between prolix and mute - leave
error reporting to Zonemaster and DNSviz...

I don't have strong opinions about either quesion.

> A more serious potential problem is related to the algorithms. The
> registry might require the use of a crypto hash algorithm for computing
> the DS record that is not supported by the DNS provider.

As an example of deprecating a digest type, I recently updated BIND's
dnssec-cds utility to suppress SHA-1 more thoroughly (RFC 8624 section
3.3). The new logic is to generate SHA-2 digests from CDNSKEY if there are
only SHA-1 CDS records, and drop the SHA-1 digests if the CDS records have
both. (It doesn't do SHA-384 by default.)

The situation for new digest types is fairly simple for dnssec-cds: it is
required to be able to validate the proposed new delegation, to ensure
that it doesn't break things (RFC 7344 section 4.1 bullet 3), so it will
report an error if it is asked to work with a post-quantum experiment or
whatever. In that situation I guess the owner of the child zone either has
to update the traditional way (if that involves less checking) or wait...

It's OK if the parent introduces a new digest type before it's widely
supported by validators. It's OK if the parent deprecates old and busted
digests before its child does. There isn't a need for everyone to move in

lock step, provided there's always at least one almost universally

supported digest type. It's best if the parent checkers aren't holding
everyone back from adopting the new hotness.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

Cape Wrath to Rattray Head including Orkney: Southerly or southwesterly 4 to
6, occasionally 3 for a time in south. Slight or moderate in south, moderate
or rough in north, occasionally very rough in far northwest. Wintry showers,
rain for a time in south. Good, occasionally poor.

[Jothan Frakes]

A related awkwardness is that implementation of CSYNC and CDNSKEY would
help hosting providers, but I expect registrars don't particularly want
their hosting business to be eroded by a protocol that makes it easier for
their customers to move their web sites (etc.) elsewhere.

Yes, I have heard the argument that registrars don't want this to happen because it reduces their ability to control the registrant's choice of service providers. 

I fear the way it was worded that one might draw a conclusion registrars might control ot limit registrants, which is not the case.

To build upon this and clarify, registrars would only need this ability to control the DNS server in order to comply with things we are compelled to by contract or compliance with ICANN (at least in G TLDs) such as expiry, UDRP/URS or other things we are directed to do.

There are certainly business models where the domain name is locked into settings within a package or class of service offered, and the registrant chooses to be locked in.  Not my model, but they exist.

Some registrars implement Siva's ice cream utopian model and offer a spectrum of services with the control of the pri/sec DNS being critical to provisioning and delivering them.

I'm not sure how much resistance there actually is as opposed to rumors of such resistance.  

There should be discussion on this.  There will be inconvenient truths to hear 

[Steve Crocker]

Tony,

Thanks.  Bear with me as I try to get synch my vocabulary with yours.  See inline below.

On Mon, Jan 27, 2020 at 1:45 PM Tony Finch <d...@dotat.at> wrote:

Steve Crocker <st...@shinkuro.com> wrote:
>
> Thanks!  I have taken the liberty of copying the
> dnssec-pr...@shinkuro.com mailing list.  If you would like to
> join the list, let me know.

I think I've already subscribed, but if I haven't, please add me!

You're now added. 

> I don't understand the model and roles you have in mind when you refer
> to the zone's key management and signing system on the one hand and the
> zone's delegation management system on the other hand.

To be super concrete, I use BIND for key management and zone signing. BIND
doesn't come with any tools for talking to registr(ar|ie)s so I have my
own. My delegation scripts just look at zone files to find out what the
delegation should be - they don't need access to the key files, which for
BIND normally implies access to the secret keys (if, like me, you don't
have an HSM!). So my signer can run on an isolated system that can't talk
to the outside world, whereas my delegation scripts can run on a separate
system with a different security posture. And my delegation scripts don't
need to be changed if I switch signer to Knot DNS or whatever, because the
scripts get information about what the DS records should be using an open
standard, rather than signer-specific utilities.

If I understand your terminology, by "delegation" you mean there's a master file that has the NS, MX, A, AAAA ,et al records.  I think you're calling this the zone file.  Your delegation script copies these into the various name servers.  Meanwhile, there's a separate signing process that has access to the private parts of the KSK and ZSK keys.  It creates the relevant key RRsets as well as DNS and DNSKEY records.  (Apologies if my terminology or spelling is off a bit.  Please correct as needed.)

> If I understand the point you're making, the DNS provider could generate
> the CDS and/or CDNSKEY records and then either the registrar or the
> registry could pull those records.  The only coordination that would be
> needed is for the registry and registrar to agree on which one one will be
> polling.  It seems logical to me that the registry is the one who decides.

Right, though my argument is that if the registry fails to act then that
should be taken as a de facto decision that registrars can/should do so.

It seems to me there should be a very clear understanding as to who's going to do what.

 

> This seems to me to be feasible, although I believe some registrars
> prefer to have complete knowledge of the data passed to the registry.

Is there an EPP mechanism for registries to tell registrars about changes
like this?

Good question.  I don't know.  We can find out, but even if the mechanism exists, it will take agreement between the registries and registrars to agree to for the registry to update the registrars. 

> I can imagine a small but potentially annoying issue with respect to
> timing if both records are required by the client.  What happens if one
> of these is put into the zone before the other and the client sees the
> first one but not the second when it polls?

I think there are a couple of more general questions underlying this:

RFCs 7344 and 8078 leave quite a lot of the business logic unspecified,
such as the polling interval, the hold-down time (if any), CDS vs CDNSKEY
vs both, how carefully to check all the nameservers, etc. Do we need one
blessed way?

Agreed on all counts.  With respect to whether we need (just) one way, it seems to me that it's ok to have more than one way, but it's vital that all of the parties involved know who's going to do what.   

I think I introduced a red herring.  It seems to me the sequence for introducing a new algorithm is roughly:

1. Community defines a new algorithm and gets it assigned an algorithm number
2. New algorithm gets included in libraries
3. Validating software and DS generating software is updated to recognize and use the new algorithm.
4. IETF declares new algorithm is widely enough supported to be ok to use.
5. Registries can then choose to use the new algorithm.

This process takes a while, probably a small number of years.

Steve

[Hollenbeck, Scott]

Yes: https://tools.ietf.org/html/rfc5910

Scott

[Richard Merdinger]

Scott,

Is there a mechanism for registrars to be notified and have the ability to authorize changes rather than be notification post facto?  Analogy being getting a credit card statement indicating what charges have gone through as opposed to getting notified of a requested transaction that can be approved to proceed before damage is done.

Thanks,

—Rich

Get Outlook for iOS

---

From: 'Hollenbeck, Scott' via DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Sent: Monday, January 27, 2020 1:16:37 PM
To: d...@dotat.at <d...@dotat.at>; st...@shinkuro.com <st...@shinkuro.com>
Cc: dnssec-pr...@shinkuro.com <dnssec-pr...@shinkuro.com>
Subject: RE: [dnssec-coord] Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March

 

Notice: This email is from an external sender.

--
You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.

To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/783394d4d4964f749f8ac0009b187fe5%40verisign.com.

[Jothan Frakes]

Rich, I like this approach -

I had a few European registrars mention they use this type of registry polling to synch their settings with those which the cctld registry has received update to DNSSEC records.

As long as the DNS server names are not changed, the resistance drops.  

It is far less contentious to fiddle with the DNSSEC records.

To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/DM6PR02MB4108415D54766C17D97ED999DA0B0%40DM6PR02MB4108.namprd02.prod.outlook.com.

[Tony Finch]

Steve Crocker <st...@shinkuro.com> wrote:
>

[ I've re-ordered a bit to try to keep my clarifications together ]

> If I understand your terminology, by "delegation" you mean there's a master
> file that has the NS, MX, A, AAAA ,et al records. I think you're calling
> this the zone file.

Right.

> Meanwhile, there's a separate signing process that has access to the
> private parts of the KSK and ZSK keys. It creates the relevant key
> RRsets as well as DNS and DNSKEY records. (Apologies if my terminology
> or spelling is off a bit. Please correct as needed.)

Right.

> Your delegation script copies these into the various name servers.

Not quite: copying to nameservers is handled by the normal zone transfer
protocol.

My delegation scripts talk to registry / registrar interfaces [*] to
ensure that the delegation in the parent zone is correct wrt the
authoritative zone file. The delegation scripts need CDS/CDNSKEY records
to do this because there are points in most rollover schemes when the DS
records need to be either a subset or a superset of the KSKs in the DNSKEY
RRset. And DS/KSK mismatches are required for algorithm rollovers like
the one I recently completed.

( There are minor cavets related to glue records too, but that's outside
the scope of this discussion. )

[*] e.g. EPP, or provider-specific APIs such as RIPE's or Gandi's or
OpenSRS, or web site automation for the more desperate cases. I haven't
had to send any faxes...


[ on registries vs registrars ]

> It seems to me there should be a very clear understanding as to who's
> going to do what.

I mostly agree. In my fantasy world, keen registrars will start doing RFC
7344 updates as soon as they can, and they can stop if/when the registry
takes on the job. There will need to be some co-ordination, but in my
fantasy world that will work magically well *handwave*

[ But it's a convergent and idempotent process, so it doesn't matter that
much if multiple whos do it. But that might be confusing. ]


[ on flexibility in RFCs 7344 / 8078 ]

> Agreed on all counts. With respect to whether we need (just) one way, it
> seems to me that it's ok to have more than one way, but it's vital that all
> of the parties involved know who's going to do what.

Certainly, third-party debugging tools could potentially be more helpful
if they know (for example) that this registry has a 24h hold-down period
before it puts a CDS update into effect, so any mismatch during that time
is to be expected.

[Hollenbeck, Scott]

Not currently, Rich. Doing anything here would require additional specification/protocol work either in EPP or somewhere else.

 

Scott

[Richard Merdinger]

Thanks, Scott; that’s what I thought but I wanted to ask the expert 😊

 

 

Richard Merdinger

VP, Domains

rmerd...@godaddy.com

[Steve Crocker]

Folks,

First, apologies for a bit of redundancy.

This is addressed to both people who previously agreed to be on the provisioning panel in Cancún and people who said they were interested in the topic but would not be in Canún.  Since the ICANN meeting will now be virtual instead of physically in Cancún, I am reopening the panel.

The panel will be done remotely using Zoom using its webinar features.  The panel will take place on Wednesday, 11 March.  The panel will be forty minutes.  There is still some discussion whether the slot will be from 1030  to 1110 EDT (GMT-4) or from 1110 to 1150.  I expect to get this nailed down early next week.

If you would like to be included in the panel, let me know and summarize what you'd like to say.  Given the very tight time constraints, I'd like each panelist to use only a single slide.  I will need your slides in advance, and I plan to have a brief rehearsal Zoom session with the panelists a day or two before the actual session, i.e. on Monday or Tuesday, 10 or 11 March.

I will start off the panel with a description of the problem DS update issue and, if time permits, the cross-signing issues.  A draft of my slides is attached.  These are still a work in progress and will evolve.

Some of you previously agreed to be on the panel.  Please recommit.

Some of you indicated you were interested but would not be in Cancún.  Given the time constraints, it had not seemed feasible to include both onsite and remote panelists.  Now, all panelists will be remote, so if you are interested, you are hereby invited to join.

I am looking for representation from 3rd party DNS providers, registrars and registries, and I am particularly interested in having both the ccTLD and gTLD communities represented.

Here's a bit more on the topic of the panel.

The panel is on the subject of DNSSEC provisioning.  There are two related but somewhat distinct topics.  One is the update of the DS record when the DNS provider rolls the key.  The other is how multiple DNS providers coordinate when each is signing the zone.  Various proposals exist to solve each of these problems, but none has been fully accepted, and each suffers from a gap in the provisioning process.

What is the path forward for automating solutions to these two provisioning problems?  Are new protocols needed?  What changes in rules, contracts, etc. are needed or useful? 

With respect to updating DS records, the solution space is basically a two by three matrix, with a subordinate third dimension:

• Are new DS records pushed upward, i.e. is the transmission initiated by the DNS provider, or are new DS records pulled upward by the registry or registrar?
  
  

•  Is the registry, registrar or registrant involved on the upper end of the transmission?

The subordinate third dimension is whether the KSK, DS or both are communicated..

The solution in RFC 8078 is the pull/registry solution with support for both KSK and DS.  It was developed by a couple of DNS providers and is on the IETF standards track, but, so far as I can tell, is being adopted by a relatively few ccTLDs and is not gaining any traction within the gTLD community.  In contrast, GoDaddy has suggested the Domain Connect software could be extended to allow a push/registrar solution for DS updates.

[Ólafur Guðmundsson]

I will be able to participate and I can be schizophrenic and talk about the space from both 

a) Only 3 party DNS Provider 

and 

b) Registrar and multiple services provider 

Olafur 

--

You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.

To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zvLWGv3VCtEsMw-A7YAh-wGk9%2BM9P947uzq4xsus8TWq6A%40mail.gmail.com.

--

Ólafur Gudmundsson | Engineering Director 

www.cloudflare.com blog.cloudflare.com

[Steve Crocker]

Excellent!  Thanks.

Steve

[Jothan Frakes]

I can join as a registrar and multiple services provider, and 

to describe a user journey in working to configure a domain name with DNSSEC using a variety of 3P DNS Providers who offer DNSSEC 

I also have some (brief) talking points about the impetus of DNSSEC adoption being important as a foundational layer upon which new innovation is enabled, such as Authentication/Identification and integration into blockchain space.

Jothan Frakes
Tel: +1.206-355-0230

To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zv%2BYdjdiVq5zSe5%3DVgoPbU%3D14decieaPigPMGfzxM_w-pA%40mail.gmail.com.

[Steve Crocker]

Great!  Thanks.

Steve

[Richard Merdinger]

Steve,

GoDaddy is still committed, but I have arranged for an internal DNS expert to participate.  He is extremely familiar with the subject matter and will be much more able to engage in the multi-signor problem.  His name is Brian Dickson, and he is cc’d here. 

 

--Rich

 

From: Steve Crocker <st...@shinkuro.com>
Sent: Friday, February 28, 2020 9:22 AM
To: DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Cc: Stephen D. Crocker <st...@shinkuro.com>
Subject: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting

 

Notice: This email is from an external sender.

 

Folks,

--

[Brian P. Dickson]

Confirmed, I’m the new rep for GoDaddy on this panel.

 

So, a small clarification on the Domain Connect proposal:

• The Domain Connect (extension) would be for the initial DS Record needed to transition a zone from insecure to secure.
• It is not being proposed for maintaining DS records when the key rolls.

 

I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.

 

Push/Pull DS:

 

The DS maintenance push/pull issue:

• This should be exclusively focused on mechanisms for signaling and/or conveying updated records.
• We see no reason to deviate from the use of the CDS and/or CDNSKEY records and signatures, for the content used by the registries for processing the updates.
• The security properties of CDS and CDNSKEY are essential to the security of updating the records at the TLD.
• CDS is preferred (to avoid pre-publishing DNSKEY data itself), but some registries currently require DNSKEYs be supplied.
• It should not be mandated that both always be supplied
• The only interoperability required is Zone to Registry, so each implementer/operator should be free to choose (publish both, or only one, or always CDS and sometimes CDNSKEY where required by the registry)
• There is no value added by adding any other parties in the path, other than the DNS operator (zone manager) and the Registry. It has to start at the former and end at the latter. If we can agree on mechanisms, this could quickly remove one dimension from the problem/solution space.

 

I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.

E.g.

• Is the registry concerned about polling load requirements only?
• Would registries be okay with pulling the updated records if they get signaled that a given zone has a new CDS or CDNSKEY?
• Perhaps signal with a new OPTYPE specific to this mechanism?
• Similar to NOTIFY but limited to only this purpose?
• Would it be desirable by some registries for the “push” party to supply the updated records as DNS data sent directly?
• I.e. similar to UPDATE, but specific to this use case? Answer section containing the CDS/CDNSKEY and RRSIG records?
• How would registries want to protect their notification channel against abuse or DOS attacks? Suggested methods:
• DNS Cookies
• IP ACLs derived from zone apex information
• SOA record field (e.g. MNAME)
• New RRTYPE(S) at the apex
• New underscore name holding ACL-specific A/AAAA records
• Queried dynamically, or polled periodically, or pushed similar to the DS/DNSKEY mechanism?
• Would need to be signed
• Which of the above would be mandatory vs optional (e.g. DNS Cookies)?
• We think standardizing on ALWAYS publishing CDS (and optionally CDNSKEY, possibly dependent on parent domain) would be wise, and simplify the implementers’ choices
• This ensures that registries can migrate between push/pull models without adversely affecting zone publishing mechanisms
• This reduces the architecture discussions to a much simpler, “How to signal a pull by the registry, and/or how to push records to the registry”

 

Cross-Signing:

 

We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.

 

One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the  KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.

 

I look forward to the panel, and if possible feedback by registry operators between now and then.

 

Brian

[Steve Crocker]

Brian,

Very glad to have you on board.  I will put you on the panel instead of Rich.

Thanks for your very meaty message.  My comments are embedded in line.

Steve

On Fri, Feb 28, 2020 at 2:53 PM Brian P. Dickson <bdic...@godaddy.com> wrote:

Confirmed, I’m the new rep for GoDaddy on this panel.

 

So, a small clarification on the Domain Connect proposal:

• The Domain Connect (extension) would be for the initial DS Record needed to transition a zone from insecure to secure.
• It is not being proposed for maintaining DS records when the key rolls.

Interesting.  See comment/question below re using it just for the first time. 

 

I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.

Good.

 

 

Push/Pull DS:

 

The DS maintenance push/pull issue:

• This should be exclusively focused on mechanisms for signaling and/or conveying updated records.

I sense there is an implied or understood alternative that some people may want.  From past discussions with Rich, I think I heard some 3rd party DNS providers wanted to update NS records or perhaps other records, not just DS records.  Is this what you're alluding to?

 

• We see no reason to deviate from the use of the CDS and/or CDNSKEY records and signatures, for the content used by the registries for processing the updates.

I thought it was the position of registrars such as GoDaddy that they needed to be in the loop -- at least informed after the fact -- whenever the DS record changed in order to have an accurate copy of the data in the registry.  It seems you are not requiring this.  Do I understand correctly?

 

• The security properties of CDS and CDNSKEY are essential to the security of updating the records at the TLD.
• CDS is preferred (to avoid pre-publishing DNSKEY data itself), but some registries currently require DNSKEYs be supplied.
• It should not be mandated that both always be supplied
• The only interoperability required is Zone to Registry, so each implementer/operator should be free to choose (publish both, or only one, or always CDS and sometimes CDNSKEY where required by the registry)

Yes, it seems to me it would be ok for each registry to specify whether it wants CDS, DNSKEY or both.  Of course, there would have to be some way for the 3rd party DNS provider to find out which of these is required for the registry.

•  There is no value added by adding any other parties in the path, other than the DNS operator (zone manager) and the Registry. It has to start at the former and end at the latter. If we can agree on mechanisms, this could quickly remove one dimension from the problem/solution space.

As I said above, I thought there was substantial resistance within the gTLD registrar community to the idea they would not be in the loop.  You're obviously in a much better position to speak to this than I am.  Moreover, I don't have any reason to take a side on this.  I'm just trying to keep track of the various competing ideas.

• I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.

E.g.

• Is the registry concerned about polling load requirements only?
• Would registries be okay with pulling the updated records if they get signaled that a given zone has a new CDS or CDNSKEY?
• Perhaps signal with a new OPTYPE specific to this mechanism?
• Similar to NOTIFY but limited to only this purpose?
• Would it be desirable by some registries for the “push” party to supply the updated records as DNS data sent directly?
• I.e. similar to UPDATE, but specific to this use case? Answer section containing the CDS/CDNSKEY and RRSIG records?
• How would registries want to protect their notification channel against abuse or DOS attacks? Suggested methods:
• DNS Cookies
• IP ACLs derived from zone apex information
• SOA record field (e.g. MNAME)
• New RRTYPE(S) at the apex
• New underscore name holding ACL-specific A/AAAA records
• Queried dynamically, or polled periodically, or pushed similar to the DS/DNSKEY mechanism?
• Would need to be signed
• Which of the above would be mandatory vs optional (e.g. DNS Cookies)?
• We think standardizing on ALWAYS publishing CDS (and optionally CDNSKEY, possibly dependent on parent domain) would be wise, and simplify the implementers’ choices
• This ensures that registries can migrate between push/pull models without adversely affecting zone publishing mechanisms
• This reduces the architecture discussions to a much simpler, “How to signal a pull by the registry, and/or how to push records to the registry” 

These are all excellent questions.

I'll offer one thought that reflects my technical bias, but let me quickly add that I don't have a reason to push in either direction.  I tend to prefer "push" solutions because it feels to me the control is more certain, and it's also likely to be quicker.  A polling solution seems to me to require longer periods to allow time for the polling cycle to take place, and it also seems to me that if polling doesn't take place, it won't be obvious until it's too late.

 

Cross-Signing:

 

We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.

 

One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the  KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.

Model 1 is essentially a single authoritative 3rd party provider, with others acting as secondaries to the first.  That's the less interesting and less general case.  The real challenge is how to deal with multiple 3rd party providers, each of which generates and uses its own keys.  One important advantage of having co-equal operation is it makes it easy to transition from one provider to another.  If there is a single master, the problem of transitioning from one provider to another remains unsolved.

Cross-signing requires both the exchange of keys in order to inlcude them in Keyset, the full set of DS records has to exist in all of the copies of the zone, right?

 

I look forward to the panel, and if possible feedback by registry operators between now and then.

For those who have read this far, let me add that this panel discussion is really part of an ongoing process.  The discussion and ideas developing for this panel will be carried forward for further development on this mailing list and at meetings in the future.

Thanks,

Steve

[Brian P. Dickson]

 

 

From: Steve Crocker <st...@shinkuro.com>
Date: Friday, February 28, 2020 at 5:16 PM
To: "Brian P. Dickson" <bdic...@godaddy.com>
Cc: Richard Merdinger <rmerd...@godaddy.com>, DNSSEC Provisioning <dnssec-pr...@shinkuro.com>, "Stephen D. Crocker" <st...@shinkuro.com>
Subject: Re: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting

 

Notice: This email is from an external sender.

 

Brian,

 

Very glad to have you on board.  I will put you on the panel instead of Rich.

 

Thanks for your very meaty message.  My comments are embedded in line.

 

Steve

 

 

On Fri, Feb 28, 2020 at 2:53 PM Brian P. Dickson <bdic...@godaddy.com> wrote:

Confirmed, I’m the new rep for GoDaddy on this panel.

 

So, a small clarification on the Domain Connect proposal:

• The Domain Connect (extension) would be for the initial DS Record needed to transition a zone from insecure to secure.
• It is not being proposed for maintaining DS records when the key rolls.

 

Interesting.  See comment/question below re using it just for the first time. 

 

I’m interested in being involved in discussions on both the Push/Pull DS topic, and on the cross-signing topic.

 

Good.

 

 

Push/Pull DS:

 

The DS maintenance push/pull issue:

• This should be exclusively focused on mechanisms for signaling and/or conveying updated records.

I sense there is an implied or understood alternative that some people may want.  From past discussions with Rich, I think I heard some 3rd party DNS providers wanted to update NS records or perhaps other records, not just DS records.  Is this what you're alluding to?

 

[bpd] Actually, no, I meant only that either a push occurs, or a “signal” is sent that triggers a pull (which is a different model than “poll”). Adding other records to the set of things to get updated (DNS operator -> Registry) is certainly open for discussion. I think there would need to be some investigation by participants to the impact of individual record types, and whether those align with their process flows.

 

But if there’s consensus, I think updating NS is also a possible thing. (IMHO, it would need to be a new record type, call it “CNS”, to avoid causing further NS issues over and above the parent/child zone cut overloading and non-authoritative-vs-authoritative thing.)

 

The important thing would be that everyone would need to accept the registry as being the “source of truth” at all times, for records that propagate this way. That might require changes to how some registrars handle NS updates, for example, where the registrar might currently consider itself the source of truth.

 

•  
• We see no reason to deviate from the use of the CDS and/or CDNSKEY records and signatures, for the content used by the registries for processing the updates.

I thought it was the position of registrars such as GoDaddy that they needed to be in the loop -- at least informed after the fact -- whenever the DS record changed in order to have an accurate copy of the data in the registry.  It seems you are not requiring this.  Do I understand correctly?

 

[bpd] Yes, you understand this correctly. The DS record copy in the registrar really only is required at the time it is being sent to the registry, either at set-up time or if the registrant is manually updating it. Once the DS in the registry has been updated or set, the registrar copy is redundant. It is likely an issue for updating how DS (and possibly DNSKEY) values are treated, which might in some cases require registrars to update some of their code. However, if/when the DNS operator to registry path is used, any discrepancy between the registrar and registry is technically moot (as the registrar value is no longer being used).

 

•  
• The security properties of CDS and CDNSKEY are essential to the security of updating the records at the TLD.
• CDS is preferred (to avoid pre-publishing DNSKEY data itself), but some registries currently require DNSKEYs be supplied.

• It should not be mandated that both always be supplied
• The only interoperability required is Zone to Registry, so each implementer/operator should be free to choose (publish both, or only one, or always CDS and sometimes CDNSKEY where required by the registry)

Yes, it seems to me it would be ok for each registry to specify whether it wants CDS, DNSKEY or both.  Of course, there would have to be some way for the 3rd party DNS provider to find out which of these is required for the registry.

 

[bpd] I concur. Hopefully a standard can be established that would allow for discovery of registry DNSSEC requirements and parameters. E.g. what algorithms are supported, what key sizes, is the registry using NSEC or NSEC3 or something else, maybe information about whether the authority servers for the registry do minimal responses, maybe information about NSID structure/scope, anything else that might be helpful for either automation purposes or human diagnostic purposes. When there were 7 TLDs, it wasn’t a big deal, but today…

 

•  There is no value added by adding any other parties in the path, other than the DNS operator (zone manager) and the Registry. It has to start at the former and end at the latter. If we can agree on mechanisms, this could quickly remove one dimension from the problem/solution space.

As I said above, I thought there was substantial resistance within the gTLD registrar community to the idea they would not be in the loop.  You're obviously in a much better position to speak to this than I am.  Moreover, I don't have any reason to take a side on this.  I'm just trying to keep track of the various competing ideas.

 

[bpd] I’d be interested in hearing the positions of other registrars, and rationale(s). I think the restriction to these changes is that it is only applicable if DNSSEC is being used, and the updates involve signed data from the apex of the zone. Any changes to non-DNSSEC zones would be excluded from these methods of updating the registry, for obvious reasons (security).

 

• I think what is needed to advance the discussion is feedback from representatives of registries, on what requirements they have, so that proposals can be evaluated against those requirements.

E.g.

• Is the registry concerned about polling load requirements only?
• Would registries be okay with pulling the updated records if they get signaled that a given zone has a new CDS or CDNSKEY?

• Perhaps signal with a new OPTYPE specific to this mechanism?
• Similar to NOTIFY but limited to only this purpose?

• Would it be desirable by some registries for the “push” party to supply the updated records as DNS data sent directly?

• I.e. similar to UPDATE, but specific to this use case? Answer section containing the CDS/CDNSKEY and RRSIG records?

• How would registries want to protect their notification channel against abuse or DOS attacks? Suggested methods:

• DNS Cookies
• IP ACLs derived from zone apex information

• SOA record field (e.g. MNAME)
• New RRTYPE(S) at the apex
• New underscore name holding ACL-specific A/AAAA records
• Queried dynamically, or polled periodically, or pushed similar to the DS/DNSKEY mechanism?
• Would need to be signed

• Which of the above would be mandatory vs optional (e.g. DNS Cookies)?
• We think standardizing on ALWAYS publishing CDS (and optionally CDNSKEY, possibly dependent on parent domain) would be wise, and simplify the implementers’ choices

• This ensures that registries can migrate between push/pull models without adversely affecting zone publishing mechanisms
• This reduces the architecture discussions to a much simpler, “How to signal a pull by the registry, and/or how to push records to the registry” 

These are all excellent questions.

 

I'll offer one thought that reflects my technical bias, but let me quickly add that I don't have a reason to push in either direction.  I tend to prefer "push" solutions because it feels to me the control is more certain, and it's also likely to be quicker.  A polling solution seems to me to require longer periods to allow time for the polling cycle to take place, and it also seems to me that if polling doesn't take place, it won't be obvious until it's too late.

 

[bpd] I think it’s six of one, half-a-dozen of the other. Even if updates to the registry happen very quickly and propagate to all the TLD’s servers, there is still the latency for updates caused by resolver caches. Absent a “big red button”, that’s always a problem, especially for the TTL of TLD records. (I think that is a problem that could stand some work, but there’s no obvious solution just yet.) Affirmative state change is good, however, so I think either a true “push”, or a similar “notify” type mechanism (which would include an acknowledgement response) is potentially beneficial. A lot of uncertainty is how receptive TLD operators are to this kind of mechanism, so it’s probably a bit early to go too far down this road just yet.

 

Cross-Signing:

 

We agree that using Shumon’s proposal makes sense, and think this is mostly going to be about implementation and if necessary making clarifications or updates to the proposed standard.

 

One possible addition to the proposal is a variant on Model 1, where one of the multiple providers is acting as an agent for the zone owner, call them the  KSK-operator (KO), and ZSK-only-operator(s). This would facilitate automation similar to that used for the single-signer case, and only require inter-provider API(s) for obtaining ZSKs, signing keysets, and pushing signatures to ZOOs. I don’t think it should be mandatory, i.e. that the original Model 1 (with zone owner responsibility) should also be supported, or perhaps where the zone owner operates a “hidden-KO” DNS server or something to that effect.

 

Model 1 is essentially a single authoritative 3rd party provider, with others acting as secondaries to the first.  That's the less interesting and less general case.  The real challenge is how to deal with multiple 3rd party providers, each of which generates and uses its own keys.  One important advantage of having co-equal operation is it makes it easy to transition from one provider to another.  If there is a single master, the problem of transitioning from one provider to another remains unsolved.

 

[bpd] I need to think about this a bit more, but one method might be a transition like this: model 1 (old primary) -> model 2 (co-primary) -> model 1 (new primary). Model 2 is more complex to operate/maintain, I think? So as long as the transition mechanism is well-defined (with a small number of api calls), there’s possibly value in having a slight preference for one of the providers to be the primary, as it simplifies some aspects of the cross-signing.

 

Cross-signing requires both the exchange of keys in order to inlcude them in Keyset, the full set of DS records has to exist in all of the copies of the zone, right?

 

[bpd] Cross-signing requires the KSK private key, plus all of the public keys for the ZSKs and the KSK (repeated for all the algorithms and key roll additions etc).

If only one KSK is used, that KSK signs the keysets, and each provider’s zone contains the same keyset and RRSIG(dnskey set).

If multiple KSKs are used (one per provider), the keyset in each operator’s zone will be that operator’s KSK, plus all of the ZSKs, and that KSK signs that unique dnskey set.

(I think one variant could be that all the zones include all the KSKs, but only one KSK is used to sign the dnskey set (the KSK for that operator). Not sure if that is better in terms of consistency.)

 

The DS set only has to match the set of (active) KSKs, regardless of the quantity of ZSKs. The DS is only in the parent zone (the TLD).

 

The main thing is that a validator gets a set of DNSKEYs which includes all the ZSKs and an appropriate set of KSKs (one currently, possibly more than one). The signature is calculated using the KSK (or each KSK if more than one is present), and compared to the RRSIG received. Plus, the hash of the KSK(s) is compared to the set of DS records. There has to be one match for validation to succeed, on both the hash and on the RRSIG validation.

 

Basically, all that really matters is that each operator’s DNSKEY set is returned to a resolver, and that all of the records are present before doing the signature calculation/validation step. This prevents an attacker from doing a downgrade attack by filtering some of the DNSKEY records. All of the ZSKs are needed from all the operators, because of cached RRSIGs and the need to be able to validate them, regardless of which operator they were obtained from.

 

I look forward to the panel, and if possible feedback by registry operators between now and then.

 

For those who have read this far, let me add that this panel discussion is really part of an ongoing process.  The discussion and ideas developing for this panel will be carried forward for further development on this mailing list and at meetings in the future.

 

Thanks,

 

Steve

 

[bpd] Yep, and looking forward to all of that.

 

Brian

[Erwin Lansing]

Catching up after some travel. If I do my timezone calculations right, I should still be able to participate, that said, even for a ccTLD registry, wrt DNSSEC we are probably even more quirky than most. More on that in a separate email.

While I’m here, let me answer a random question:

On 29 Feb 2020, at 02.16, Steve Crocker <st...@shinkuro.com> wrote:

As I said above, I thought there was substantial resistance within the gTLD registrar community to the idea they would not be in the loop.  You're obviously in a much better position to speak to this than I am.  Moreover, I don't have any reason to take a side on this.  I'm just trying to keep track of the various competing ideas.

From some discussions I had, when pushed, it turns out the real issue (some) registrars had, was about data consistency, not necessarily having to be in the loop. If there was an easy way (EPP Poll?) to signal any changes in the registry down to the registrar, they might be convinced, even if, as pointed out earlier, the data in the registrar system is redundant.

Erwin

[Gavin Brown]

I am happy to recommit to my (online) participation. I will be talking about our experiences of deploying CDS scanning in .SK, and how we are planning to deploy the same technology on our gTLD platform (combined with the change poll extension to notify registrars).

G.

> --
> You received this message because you are subscribed to the Google Groups "DNSSEC Provisioning" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dnssec-provisio...@shinkuro.com.
> To view this discussion on the web visit https://groups.google.com/a/shinkuro.com/d/msgid/dnssec-provisioning/CABf5zvLWGv3VCtEsMw-A7YAh-wGk9%2BM9P947uzq4xsus8TWq6A%40mail.gmail.com.

> <ICANN Cancün 2020-02-27.pptx>

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6AE.

[Brian P. Dickson]

[bpd] Follow-up comment/question in-line below…

 

From: 'Erwin Lansing' via DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Reply-To: Erwin Lansing <er...@lansing.dk>
Date: Monday, March 2, 2020 at 1:11 AM
To: Steve Crocker <st...@shinkuro.com>
Cc: DNSSEC Provisioning <dnssec-pr...@shinkuro.com>
Subject: Re: Reworking the DNSSEC provisioning session for the now virtual ICANN meeting

 

Notice: This email is from an external sender.

 

Catching up after some travel. If I do my timezone calculations right, I should still be able to participate, that said, even for a ccTLD registry, wrt DNSSEC we are probably even more quirky than most. More on that in a separate email.

 

[bpd] I think the nature of the specific data, i.e. DS (or DNSKEY), can be described as being not just redundant, but actually ephemeral. It is used exactly once, during the set-up, and never again. The only time a registrar would send DS or DNSKEY data to a registry after the initial set-up, would be if the data changed and a new DS or DNSKEY was being submitted. Thus, the actual DATA in the registrar is use-once-only. It is safe to discard once the transaction succeeds. Even if updates happen via another channel, those are one-way updates which are also ephemeral in nature. There is literally zero benefit for a registrar in tracking those, as those would never be re-used once the registry has applied them (which would need to be the case before the registry notified the registrar in that potential scenario/model.)

 

[bpd] Given the above, I think it would be helpful to have a session somewhere with registrars to communicate these kinds of details, listen to their concerns, and address those concerns. Is there a good place or event for those sorts of discussions?

 

Brian