Connected: An Internet Encyclopedia
6.1.3.1 Resolver Implementation

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1123
Up: 6. SUPPORT SERVICES
Up: 6.1 DOMAIN NAME TRANSLATION
Up: 6.1.3 SPECIFIC ISSUES
Prev: 6.1.3 SPECIFIC ISSUES
Next: 6.1.3.2 Transport Protocols

6.1.3.1 Resolver Implementation

6.1.3.1 Resolver Implementation

A name resolver SHOULD be able to multiplex concurrent requests if the host supports concurrent processes.

In implementing a DNS resolver, one of two different models MAY optionally be chosen: a full-service resolver, or a stub resolver.

  1. Full-Service Resolver

    A full-service resolver is a complete implementation of the resolver service, and is capable of dealing with communication failures, failure of individual name servers, location of the proper name server for a given name, etc. It must satisfy the following requirements:

  2. Stub Resolver

    A "stub resolver" relies on the services of a recursive name server on the connected network or a "nearby" network. This scheme allows the host to pass on the burden of the resolver function to a name server on another host. This model is often essential for less capable hosts, such as PCs, and is also recommended when the host is one of several workstations on a local network, because it allows all of the workstations to share the cache of the recursive name server and hence reduce the number of domain requests exported by the local network. At a minimum, the stub resolver MUST be capable of directing its requests to redundant recursive name servers. Note that recursive name servers are allowed to restrict the sources of requests that they will honor, so the host administrator must verify that the service will be provided. Stub resolvers MAY implement caching if they choose, but if so, MUST timeout cached information.


Next: 6.1.3.2 Transport Protocols

Connected: An Internet Encyclopedia
6.1.3.1 Resolver Implementation