Russ Allbery wrote: > Russ Allbery <[email protected]> writes: > >> A new version of I-D, draft-allbery-afs-srv-records-00.txt has been >> successfuly submitted by Russ Allbery and posted to the IETF repository. >> Filename: draft-allbery-afs-srv-records >> Revision: 00 >> Title: DNS SRV Resource Records for AFS >> Creation_date: 2009-10-03 >> WG ID: Independent Submission >> Number_of_pages: 9 > > David Boyes raised the excellent point that this draft doesn't talk about > TTLs. As I suspect everyone reading this list already knows, once an > existing AFS client decides on a VLDB server to talk to, it never redoes > the DNS query and hence isn't going to honor TTLs on SRV records. Although this is an implementation detail, as a point of fact the Windows cache manager records AFSDB record TTL values and uses them to timeout the server lists. It is true that the Unix cache manager does not do so and this should be fixed but that is not a topic for this list. > I think we have two options: document this behavior, or specify something > more fully correct that requires that the AFS client know the TTL (could > be tricky in a lot of resolver stacks) or redo the query each time it > wants to talk to the VLDB (which seems like a lot of DNS traffic). This document inherits all of the requirements of RFC 2782 "DNS SRV RR" and the meaning of "TTL" from RFC 1035:
TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.
As such, it is expected that the TTL will be processed in accordance
with that standard.
It should also be noted that AFSDB records as defined in RFC 1183 also
contain a TTL record
with an equivalent meaning.
> Documenting is certainly much easier for existing implementations.
>
> What do people think?
>
I do not think that documenting an implementation deficiency is
appropriate for a protocol standard.
In my opinion, opening a ticket in the OpenAFS RT would be appropriate.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
