Re: [dns-wg] DNSSEC Policy Development Process

["Olaf M. Kolkman" <]

Hello McTim.

> I don't know why the WG is asked to comment on procedure as well as
> policy, but here goes:
Input on the procedure is more than welcome. Thanks!

> What does "reasonable" mean in the below sentence on:
> http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
>
> "Is the signature validity period close to expiring and are the Times
> To Live (TTLs) a reasonable fraction of the signature validity
> period?"
This refers to draft-ietf-dnsop-dnssec-operational-practices-04  
section 4.1.1.

   o  We suggest the Maximum Zone TTL of your zone data to be a  
fraction
      of your signature validity period.
         If the TTL would be of similar order as the signature validity
         period, then all RRsets fetched during the validity period
         would be cached until the signature expiration time.  Section
         7.1 of [2] suggests that "the resolver may use the time
         remaining before expiration of the signature validity  
period of
         a signed RRset as an upper bound for the TTL".  As a result
         query load on authoritative servers would peak at signature
         expiration time, as this is also the time at which records
         simultaneously expire from caches.
         To avoid query load peaks we suggest the TTL on all the RRs in
         your zone to be at least a few times smaller than your
         signature validity period.

We currently test on the TTL being at least 2 times smaller than the  
signature validity period.


> I'm confused about this para on same page:
>
> "Web Interface Restrictions
> We will develop a web interface to make it easy to create domain
> objects with the appropriate "ds-rdata:" attributes. It will have some
> operational restrictions
>
> It will use the SEP flag to select the keys for which DSRRs are  
> needed.
>
> It will use the "ds-rdata:" attribute of the domain object currently
> available in the RIPE Whois Database to select the appropriate default
> DNSKEY RR. It will then select a new "ds-rdata:" attribute."
>
> How do you use the "currently available object" to create an object if
> this object doesn't exist until you create it?
That text applies to when a key rollover is being performed. During  
the initial upload the default is
the DNSKEY RR with the SEP flag set.


> I am clearly missing smt, but it escapes me at the moment.
>
> I support Jim's suggestion in re: generic replacement of "DLV"  
> mention.

On the issue of the DLV registries: the intention is that in the  
absence of a signed root we will try to participate in initiatives  
that allow for 'easy' trust anchor maintenance. Since DLV is the only  
technique currently under discussion so that got hard-wired into the  
procedure document. As soon as the root and intermediary zones are  
signed it is probably best to move away from these alternative key  
distribution mechanism.

At this moment there is no working DLV implementation, nor a DLV  
registry to participate in.

I hope this clarifies.

--Olaf Kolkman