I've read draft-ietf-dnsop-serve-stale-03. In addition to the
high-level draft organization matter I mentioned in another thread,
here are my other comments on this version:
- Section 4:
The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
amended to read:
TTL [...] If the authority for the data is unavailable
when attempting to refresh, the record MAY be used as though it is
unexpired.
On understanding that this is the only real normative description,
I'd suggest making some more points explicit to prevent abusing of
this leniency:
- explicitly say "all authoritative servers" instead of just "the
authority"
- also explicitly note that this MUST NOT be allowed if at least one
authoritative server is available
- clarify whether this means a 0-TTL record can be cached and reused
under this condition (I assume it must not, but it's not very clear
to me)
- Section 5
If it
finds no relevant unexpired data and the Recursion Desired flag is
not set in the request, it SHOULD immediately return the response
without consulting the cache for expired records.
It would be nice if it clarified *what* to return in this case (if
it's intentionally left open, explicitly say so).
- Section 5
Outside the period of the resolution recheck timer, the resolver
SHOULD start the query resolution timer and begin the iterative
resolution process.
It's not clear to me how this timer is related to the 'server-stale'
behavior; this draft doesn't explain what happens when this timer
expires, for example. Also, in my understanding unbound doesn't
have this timer - it eventually gives up a resolution if all
possible external query fails with a per-query timeout, but it
doesn't cap the overall resolution time. That may not matter much
as this section doesn't seem to be normative and it's just an
implementation detail of a particular implementation, but if the
role of this timer doesn't matter either, we might rather simplify
the text by just omitting it.
- Section 6
Stale data is used only when refreshing has failed, in order to
adhere to the original intent of the design of the DNS and the
behaviour expected by operators.
I agree on this statement, but I wonder how widely this behavior is
actually implemented. As noted in Section 7, unbound doesn't behave
this way, and in my understanding it's intentional, mainly due to
a concern about related IPR. If that's more common for other open
source implementors (BIND 9 seems to work as described here, but I
don't know about others), the description won't match the actual
implementation behavior very well in reality. So I'm curious about
implementation status about this point, and if many different
implementations intentionally ignore this "caveat" for the same
reason, I think we should adjust the text to match the reality.
- Section 7
Unbound has a similar feature for serving stale answers, but will
respond with stale data immediately if it has recently tried and
failed to refresh the answer by pre-fetching.
If I understand the implementation correctly, this is not 100%
accurate: unbound always return the stale data if it's found in the
cache as long as the "serve-expired" option is enabled. So I
suggest revising the text to:
Unbound has a similar feature for serving stale answers, but will
respond with stale data immediately whenever the feature is
enabled.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
