Hi there,
I've read all four documents and one thing I noticed is that we should
be less hand-wavy wrt. zone expire, people tend to get hung-up on
root-zone freshness, a lot...
How about this, in the main document, section 4, adding "It MUST NOT be
longer than...":
OLD
* A LocalRoot implementation MUST have an upper time limit beyond
which if a new copy of the IANA root zone data is not available it
will revert to sending regular DNS queries to the RSS for
performing DNS resolutions on behalf of its clients. This upper
limit value MAY be configurable and SHOULD default to the root
zone's current SOA expiry value. Once the LocalRoot
implementation's copy of the IANA root zone has been successfully
refreshed and is no longer considered expired, the resolver may
resume LocalRoot enabled resolution operations.
NEW
* A LocalRoot implementation MUST have an upper time limit beyond
which if a new copy of the IANA root zone data is not available it
will revert to sending regular DNS queries to the RSS for
performing DNS resolutions on behalf of its clients. This upper
limit value MAY be configurable and SHOULD default to the root
zone's current SOA expiry value. It MUST NOT be longer than the
root zone's current SOA expiry value. Once the LocalRoot
implementation's copy of the IANA root zone has been successfully
refreshed and is no longer considered expired, the resolver may
resume LocalRoot enabled resolution operations.
Now, the problem with the SOA expiry value is that it gets more out of
whack the longer your transfer chain is.
It seems unlikely to me that the list from
draft-hardaker-dnsop-root-zone-publication-points will list the RZM's
distribution servers, so everything is already one hop removed from the
primary.
1. I think we need to mention RFC 7314 in the main document:
"A LocalRoot implementation SHOULD (MUST?) use RFC 7314 EDNS EXPIRE
Option."
2. The distribution points MUST support RFC 7314. Not yet sure where to
put that one, does it go into
draft-hardaker-dnsop-root-zone-publication-points or
draft-hardaker-dnsop-root-zone-pub-list-guidelines?
3. Figure out what to do about http / CDNs. I suppose we could use the
"last-modified" header? Not a web person. But that we need to
stipulate *somewhere* that "last-modified" reflects the inception
time of that version of the root zone, not whenever that file was
written to the local CDN cache in Farawayistan.
I have no idea how much of a procedural headache it is to normatively
reference an Experimental RFC from Standards Track.
Florian
--
In my defence, I have been left unsupervised.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
