On 30/06/2011 10:32 AM, Stephen Morris wrote:
On 12/06/2011 20:50, George Barwood wrote:
I have updated the draft
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt
.....
I agree with Ed and think that we before adopting a solution, we
should step back and ask some basic questions such as:
1. Is there a problem?
Yes there is a problem
2. If so, do we agree on the nature of the problem?
The overall issue is that child knows what KSK's it wants to use,
but the parent publishes what that as DS, getting the information from
the child to the parent is the problem.
There are multiple possible paths for the information:
EPP: Only works when there is a EPP path from the child to the parent
but natural in the RRR (Registry/Registrar/Registrant) world when the
DNS operator has access to the Registrar.
Note in the RRR world the parent can be either Registry or Registrar.
Dynamic update: only works if parent is willing to GRANT child the right
to update the DS set.
Web interface: child needs login credentials
Vendor supplied solution: if a distributed organization uses single
solution DNS vendor that product can perform this work w/o any
standardization.
Parent scans DNSKEY: does not work for all possible KSK rollovers i.e.
algorithm removal, and if the parent scans at the wrong time, there
might be validation error due to timing.
Child sends via email: needs authentication, scaling issues
Child publishes in zone what it wants parent to publish: GB proposal
3. If we agree, is the IETF (and in particular, DNSOP) the place to
develop a solution?
Not sure there is a "proper" home for this work anywhere right now nor a
wrong place, dnsop is probably a better place for now as the possible
output of this process are BCP's as how to do things for each of the
possible channels.
Last year's discussion thread covered a number of issues: at the risk of
missing ones and losing some of the nuances of the discussion, the ones
that stood out when I reviewed it were:
* Do we need to automatically update DS records?
Current manual procedures were cited as being error-prone (i.e. people
are less likely to notice a mistake in cutting and pasting a DS record
into a web form than doing the same with an NS record), and there was
the suggestion that DS records are likely to need more frequent updating
than NS records.
It would be nice, and make the system more robust. FWIW I think NS can
be automatically maintained after we have DNSSEC by having the parent
copy what the child publishes.
So maybe we should be having a different discussion:
Does DNSSEC obsolete updating NS and DS information via EPP/Web/Email ?
In the ICANN version of the RRR the path from can quite easily be:
DNS Operator --> Registrant --> Reseller --> Registrar --> Registry
how many of these links are automated ?
does it make sense for all of them to be involved ?
* Who is the target audience?
Should the operator/registrant-registrar-registry ecosystem be the
primary or only target audience or should this approach focus on other
parent/child relationships?
I have many burns on my body from using the RRR word incorrectly, and
many people do not have the full model of roles and responsibilities for
each role.
my suggestion is to describe the process between parent and child
and then map the process onto the different operating models.
* How should we update DS records?
There was some discussion as to whether the update channel should be
from child zone to parent zone, or whether the update should go through
the registrant->registrar->registry path (or variation thereof). With
the latter, EPP was suggested.
As I explained above there is NO one solution
* If we automatically update DS records, why not NS records?
Delegations are frequently broken - if we have a mechanism for
automatically updating DS records, can we use the same mechanism to
update NS records as well?
yes and the discussion should be about consistency of information in
parent and child with the child as the source.
* What sort of security issues will arise?
If you use an in-band (i.e. DNS) solution to transfer information from
the child to the parent, how does it cope if the child zone has been
compromised?
Is this any worse than if the web account is compromised?
Account is reset, information submitted via account overwrites what is
in the DNS.
I propose that DNSSEC be the precondition.
* What sort of out-of-band communication should exist between parent and
child zones?
It was felt that some form of non-DNS communication needs to exist
between the operators of the parent and child zones to handle initial
zone configuration and to resolve emergencies and the like.
No one solution fits all possible.
But in general initial configuration MUST take place outside DNS.
* Does this raise any issues with regards to transferring secure domains
between registrars?
The problems associated with these types of transfers have been
discussed to great extent elsewhere, but they may have a bearing on the
solution.
Not an issue at all with registrar transfer, if you on the other hand
had said DNS Operators
then in general parent zone must be able to merge two DS sets before the
transfer and after transfer to switch only the DS for the new operator.
So it seems to me that the first step would be to write a draft that
defines the problem and the requirements for a solution. (The
requirements should include real-world requirements, e.g. how do we
assess the potential bypassing of a registrar in changing registry
data?) Solutions can then be measured against that.
Do I read this statement you want a requirements that only support the
RRR model ?
Does this sound a reasonable way for the WG to proceed?
Yes,
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
