Sam writes:
> Section 4.4.2 suggests storing DNSKEYs, not DSs. I think this is bad
> advice -- DS message digest algorithms may be used for signaling (of,
> for example, use of NSEC3), so the child may want to choose the
> message digest algorithm. Rather than require the parent to
> support them all, why not just let the child provide the hash?
The text sais: Should considder if DNSKEY and/or DS are stored. It
gives a few argument for storing the DNSKEY and generating the DS. It
does not give arguments agains storing the DS.
I find it difficult to use your argument "DS message digest algorithms
may be used for signaling (of, for example, use of NSEC3)". This
signalling mechanism only exists on the drawing board and the draft
really describes the initial (testbed and workshop) experiences.
Marcos Sanz wrote:
> This reminds me of the discussion had not a long time ago about the
> epp-dnssec documents. There, we achieved consensus about the child
> providing the DS record to the parent and *optionally* key information
> (and so reflects it epp-secdns-07). IMHO operational practices should be
> coherent with that (well, or the other way round).
But that disscussion specifically pertained to the EPP protocol, which
is only used in a subset of the DNS operations. AFAIU EPP is mostly
used between registries and registrars. Although one of the signing
implementation will courteously spit out a DSset, the registrants may
still not be able to generate a DS set. These registrants will always
have access to the DNSKEY so I think it is fair to suggest to
registries to allow for the keys travel to the registries. (I could
see the registrars having a system where the DS set is generated for
the registrant through a web interface. That webinterface fetches the
DNSKEYs from the currently running zone. It selects the SEP keys,
allow the user to select one of those keys -- but has a sensible
default based on the currently configured DS RR -- and has a button to
select the hash. After the interaction with the custommer is finished
the EPP protocol takes over from there and signals the information to
the registry.)
Anyway, back to the matter at hand:
I'd be happy to extend paragraph 4.4.2 with the arguments from the EPP
discussion to only store the DS RRs (I am hesitant to refer to the EPP
document because that will keep the document waiting for the reference
to become stable, besides I could not find the argumentation for the
choice in the epp-secdns document itself -- I may have overlooked it)
Below is a suggestion. Somebody who was really deeply involved in EPP
may recall stronger, or even the real, argument :-) .
Suggestions:
> 4.4.2 Storing Keys So Hashes Can Be Regenerated
Change of title:
4.4.2 Storing Keys or Hashes?
> When designing a registry system one should consider if the DNSKEYs
> and/or the corresponding DSs are stored. Storing DNSKEYs will help
> during troubleshooting while the overhead of calculating DS records
> from them is minimal.
Insert:
On the other hand registries may be hesitant to generate data for
custommers. That could be a reason to only accept what the data
that is published in the DNS; NS and DS RRs.
> Having an out-of-band mechanism, such as a Whois database, to find
> out which keys are used to generate DS Resource Records for specific
> owners and/or zones may also help with troubleshooting.
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
