Connected: An Internet Encyclopedia
RFC 1034 - 5.3.1. Stub resolvers

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1034
Up: 5. RESOLVERS
Up: 5.3. Resolver internals
Prev: 5.3. Resolver internals
Next: 5.3.2. Resources

### 5.3.1. Stub resolvers

One option for implementing a resolver is to move the resolution function out of the local machine and into a name server which supports recursive queries. This can provide an easy method of providing domain 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.

All that the remaining stub needs is a list of name server addresses that will perform the recursive requests. This type of resolver presumably needs the information in a configuration file, since it probably lacks the sophistication to locate it in the domain database. The user also needs to verify that the listed servers will perform the recursive service; a name server is free to refuse to perform recursive services for any or all clients. The user should consult the local system administrator to find name servers willing to perform the service.

This type of service suffers from some drawbacks. Since the recursive requests may take an arbitrary amount of time to perform, the stub may have difficulty optimizing retransmission intervals to deal with both lost UDP packets and dead servers; the name server can be easily overloaded by too zealous a stub if it interprets retransmissions as new requests. Use of TCP may be an answer, but TCP may well place burdens on the host's capabilities which are similar to those of a real resolver.

Next: 5.3.2. Resources

Connected: An Internet Encyclopedia
RFC 1034 - 5.3.1. Stub resolvers