RFC 1034:DOMAIN NAMES - CONCEPTS AND FACILITIES
RFC-Ref

cache


Click on the red underlined text to get to the source

... Where there tradeoffs between the cost of acquiring data, the speed of updates, and the accuracy of caches, the source of the data should control the tradeoff. ...
... domain tree's structure and set information. A name server may cache structure or set information about any part of the domain tree ...
... might share a database consisting of the the zones managed by the name server and the cache managed by the resolver. ...


... bit integer in units of seconds, an is primarily used by resolvers when they cache RRs. The TTL describes how ...
... TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL ...


... a network where we want to concentrate the cache rather than having a separate cache for each client ...
... network where we want to concentrate the cache rather than having a separate cache for each client. ...
... RRs are organized in several tree structures, one for each zone, and another for the cache: ...
... if the addresses are not available from authoritative data or the cache. Go to step 4. ...
... Start matching down in the cache. If QNAME is found in the cache, copy all RRs ...
... Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If there was no delegation ...
... answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. ...
... DNS provides an optional service which allows name servers to distribute, and resolvers to cache, negative results with TTLs. For example, a name server ...
... consulting authoritative data. Similarly, a resolver can make a query with a QTYPE which matches multiple types, and cache the fact that some of the types are not present. ...
... not required to add the SOA RRs in all authoritative responses, nor are resolvers required to cache negative results. Both are recommended. All resolvers and recursive name servers are required to at least be able to ignore the SOA RR ...


... other hosts. Because a resolver may need to consult several name servers, or may have the requested information in a local cache, the amount of time that a resolver will take to complete can vary quite a bit, from milliseconds to several seconds. ...
... A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple ...
... name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches. ...
... prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches. ...
... service in a PC which lacks the resources to perform the resolver function, or can centralize the cache for a whole local network or organization. ...
... careful to never let cached information override zone data. In this discussion the term "local information" is meant to mean the union of the cache and such shared zones, with the understanding that authoritative data is always used in preference to cached data when both are present. ...
... CACHE ...
... RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards ...
... a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client. ...
... b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2. ...
... c. if the response shows a CNAME and that is not the answer itself, cache the CNAME, change the SNAME to the canonical ...
... go back to step 3. Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the ...
... Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the user interface which will force the resolver to ...
... either gives the required data or a name error. The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero. ...


... AA set, and the TTLs are different. The inference is that the data did not come from a zone, but from a cache. The difference between the authoritative TTL and the TTL ...
... TTL and the TTL here is due to aging of the data in a cache. The difference in ordering of the RRs in the answer section is not significant. ...
... query was sent to C.ISI.EDU, its response might be the same as shown above if it had its own address in its cache, but might also be: ...
... for its client. We assume that the resolver is starting without a cache, as might be the case after system boot. We further assume that the system is not one of the hosts in the data and that the host ...
... The following examples illustrate the use of a cache, so each example assumes that previous requests have completed. ...
... The resolver would look in its cache for MX RRs at ISI.EDU, but the empty cache ...
... cache for MX RRs at ISI.EDU, but the empty cache wouldn't be helpful. The resolver would recognize that it needed to query foreign servers and try to determine the best servers to ...
... domains ISI.EDU, EDU, and the root. These searches of the cache would also fail. As a last resort, the resolver would use the information from the SBELT, copying it into its SLIST structure. ...
... closer delegation to ISI.EDU than its existing SLIST (since it matches three labels). The resolver would then cache the information in this response and use it to set up a new SLIST: ...
... The resolver would add this information to its cache, and return the MX RRs to its client. ...
... RRs for 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU ...
... resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU domain are in the cache, but ISI.EDU is not an ancestor of 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) ...
... find the NS RRs in the cache for ISI.EDU when it looks for foreign servers to ask. Using this data, it would construct a SLIST of the form: ...



Google
Web
RFC-Ref