[DNSOP] draft-hardaker-dnsop-csync-00.txt versus draft-kumari-ogud-dnsop-cds-02.txt

[Antoin Verschuren <[e-mail]>]

I have read both draft-hardaker-dnsop-csync-00.txt as draft-kumari-ogud-dnsop-cds-02.txt, and I must say I have a preference for the more general approach of draft-hardaker-dnsop-csync-00.txt.
Both documents try to accomplish the same, but draft-kumari-ogud-dnsop-cds-02.txt only tries to do so for one specific use case, and it seems it's trying to write the problem statement after presenting the sollution.

I esspecially don't agree with the text in paragraphs 1.2, 2.1, 2.2 and 2.4 of draft-kumari-ogud-dnsop-cds-02.txt.
They seem to focus only to how registrations and the RRR model is percieved, focusses esspecially on the GTLD space, but fails to give a clear definition.
With most registries, a registrant does not "buy" a domain. it may be percieved as such, but when it is not renewed in the GTLD case, you don't own it anymore, which I don't see as "buying".
In other TLD's, delegations are based on licenses, or in many cases, there is a direct contractual relationship between a regisry and registrant.
I would say to not focus on trying to translate what we see in our own experience, but try to find a good definition, if one is needed at all.
I would like to see a definition that fits all models, be it a TLD or another parent. Lets make it more general.
I would formulate a definition like this:

Registry: Entity that is responsible for a parent zone that maintains registrations of delegations in that zone.
Registrant: Entity that is responsible for a child zone that was delegated to him by a parent.
Registrar: Administrative entity that represents the parent towards a registrant for administrative maintanance of the registration data of the delegation at the parent.

Let's try to forget everyones personal  frustration with all of the examples we know.

The use case we're trying to solve is how to get data from child to parent that needs to be part of the delegation.
I think we need to make clear that there is a difference between administrative and technical data.
Technical data usually flows over the administrative channel because a delegation needs bootstrapping, and no delegation yet excists, so no secure channel is available.
When we want technical data to flow over DNS from child to parent after bootstrapping, I don't see a difference between DS, DNSKEY, NS or other other technical data.
That's why I like draft-hardaker-dnsop-csync-00.txt better, because that's the general use case.

In the general use case, we don't need to think on DS versus DNSKEY, SEP bit set or not, etc.
You just publish technical data for the parent to notice.

The question I'm still puzzled with in both proposals is how we're going to migrate from the current "pushing technical data to the parent over the administrative channel" towards "pushing technical data over the DNS for the parent to pick up". I actually think that this is not as easy as we think, and we're sticking our heads in the sand if we say this is "local policy". We allways want the administrative channel to be a back-up channel when the delegation breaks, and we need to re-bootstrap the delegation. But this leads to the question which path is authoritative. In simple words, what do I do as a parent (or parental agent) when I recieve information over the DNS that conflicts with data I receive over the administrative channel. Which data should I follow.

Some remarks to earlier discussions I saw here on the list:
It was stated that when a parent is requesting DNSKEY instead of DS, and the parent calculates the DS, the disadvantage is that the child cannot choose the digest algorithm. This is not true. The child can send the DNSKEY and signal the desired algorithm by which the parent should calculate the digest. The parent may limit the number of algorithms to choose from, but that does not mean there is no choice. The parent may have good reasons to limit the number of digest algorithms. I don't want to go into too much discussion on the DS versus DNSKEY acceptance by the parent, but we recently found another issue in provisioning that we could not have solved easily if we as parent only knew the DS.

The second remark I have is that the only use case that seems to favour DS over DNSKEY is standby keys where you don't want to publish a standby DNSKEY in your zone.
I fail to see how publishing a DS in a CDS record for your standby key is much more safer from publishing the DNSKEY of your standby key.
I would say that if you want to publish a DS for your standby key at your parent, you can allways use the administrative bootstapping channel for that.
But then still, what's the benefit over only exposing your DS over exposing your DNSKEY, when not a single signature has been created or published with that standby key?
  

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: [phone]  F: [phone]  M: [phone]
mailto:[e-mail]  xmpp:[e-mail]
http://www.sidn.nl/