The Internet Utilities contains two caching proxy server dæmons that provide caching proxy service to simple DNS clients:
The Forwarding Caching Proxy Server forwards all requests for information not in its cache to a fixed list of other DNS servers. It expects those other servers to perform full recursive resolution on its behalf and return the answers, which it then returns to its clients. It stores all information obtained in its own cache.
The Resolving Caching Proxy Server performs full resolution on behalf of its clients. It obtains all information directly from the content servers for each domain, working its way to each server from the root content servers by following referrals and performing alias substitutions, saving the intermediate information and final results in its cache.
The caching proxy servers respond
All other responses depend from the contents of the cache. The servers never bypass their own caches to obtain answers. Answers are constructed by searching the cache for the requested resource record sets, and sending back-end queries to populate the cache with the appropriate information if necessary. (Queries for type "*" always cause a cache miss, except if they are for domain names whose data are being synthesised internally by the servers themselves.)
The proxy servers only return the exact information for which they were asked. They do not return extraneous information. They do not return "authority" records, because such information is unnecessary for complete responses and proxy servers only return complete responses. They do not return "additional" records because they expect to be serving clients that will only discard such extra information anyway.
If a DNS/UDP response would normally exceed the DNS/UDP datagram size limit, the proxy servers will eliminate all of the resource record sets and set the "truncated" flag in the response header to 1 .
The back-end queries issued by the proxy DNS servers use the same timeout algorithm as other DNS clients in the Internet Utilities.
The retry scheduling of a back-end query is independent of incoming queries received from clients. In particular, if a back-end query is already in progress, the receipt of an incoming query for that same resource record set from a client will not change the timeouts or the retry schedule for the back-end query. This prevents the effects of a client that repeatedly issues a query at short intervals from being passed through to the back end.
Back-end queries normally use DNS/UDP. If a response is received with the "truncated" bit in its header set to 1, the proxy DNS server ignores the content of the response and queries the same server using DNS/TCP. DNS/TCP is thus not attempted to any server unless DNS/UDP communication with that server has been successful immediately beforehand.
If the DNS/TCP transaction with the server fails, or does not enable query resolution to make any further progress, the proxy DNS servers revert to using DNS/UDP once more before switching to the next server.
The primary purpose of the proxy servers is to act as intermediaries between DNS clients and all other DNS servers. They will only accept queries from clients whose IP addresses are explicitly listed as those of authorized clients.
The caching proxy servers check for client authorization by looking for
the existence of a file named Clients\IP4\hexaddr or
Clients\IP6\hexaddr, for IP version 4 and IP version 6
addresses respectively, in both cases relative to their working directories.
The hexaddr is the hexadecimal form of the IP address, or a
byte-granular (for IPv4) or nybble-granular (for IPv6) prefix thereof.
Examples:
The existence of Clients\IP4\7F will authorize all client IP
addresses in the 127.*.*.* network. Similarly, the existence of
Clients\IP4\0A010203 will authorize the client IP address
10.1.2.3 .
Note: The client authorization mechanism is not meant to be a substitute for proper server IP address selection and IP traffic routing. Proxy DNS servers should not be listening on IP addresses reachable by the world at large. If they are, then the malicious can consume resources by making those servers do work. At the very minimum, they can cause the caching proxy servers to keep looking up client authorization files, and recording unauthorized clients in their logs (potentially causing important log information to be overwhelmed or simply scrolled off the top of the log, as well as potentially causing denial of service to legitimate clients). Do not use client authorization in place of proper IP traffic controls at your border routers.
A proxy server available to a group of machines will usually listen on an IP address in one of the site-local ranges such as 10.a.b.c. A proxy server for a single machine will listen on a machine-local IP address such as 127.0.0.1, which happens to be the default server IP address if no other is specified on the command line.
The servers do not execute programs based upon any data received from Internet, or indeed run any other programs at all. They can safely be run on a machine residing outside of a firewall.
They send all responses from the same socket on which the original queries were received.
Security of the back-ends of the proxy DNS servers depends from attackers being unable to know, and finding it difficult to guess, the port numbers and message IDs of the query/response DNS/UDP datagrams and the sequence numbers in DNS/TCP traffic. This is, unfortunately, a security problem inherent in the DNS protocol that has been known since 2001.
Security of DNS/TCP traffic is left up to the operating system, since it is the operating system that controls TCP/IP packet sequence numbering. Security of DNS/UDP traffic involves randomly selecting a DNS/UDP socket, from a pool allocated by the server at startup, and a message ID to use for the query/response. The proxy servers by default will allocate at startup 64 DNS/UDP sockets and 1 DNS/TCP socket. This provides for 64*65536 possibilities for a "blind" attacker to guess. The more DNS/UDP sockets are allocated, the harder it will be for a "blind" attacker to guess the port number and message ID for any given back-end transaction. However, each socket requires a UDP/IP port number, which constrains how many other UDP services may be in use on the same IP address(es).
The proxy servers are designed so that their memory requirements should remain constant over time. At startup, they allocate memory for a fixed-size cache. They temporarily allocate more memory when processing individual packets that they have received, which they discard when they finish handling the packet. They also temporarily allocate anywhere up to 1KiB (depending on the exact question being asked) for each active UDP query, and up to 128KiB for each active TCP query.
The cache size can be controlled by the /CACHESIZE option.
It is followed by a number, which may in turn be followed by one of the
following suffixes that controls what units that number is a multiple of:
The size is rounded up to the next multiple of the processor's hardware page size (4KiB on x86), because in practice that is the minimum granularity of all memory allocations.
Note: The k, M, and G suffixes are the official SI abbreviations for kilo-, mega-, and giga-, which are always powers of 10. The Ki, Mi, and Gi suffixes, abbreviations for kilobinary-, megabinary-, and gigabinary- respectively, are the standard suffixes for powers of 2 specified by the IEEE and the IEC.
If no suffix is present, the size is in bytes.
Cached record sets occupy the following amounts of storage (plus whatever overhead is imposed by the operating system's heap management library):
A record setsAAAA record setsMX and NS record sets
The maximum number of simultaneous UDP queries that are possible is
determined by the /UDPPROXYSOCKETS option. Each proxy uses
one UDP socket and thus one UDP port number, and can have up to 65536 UDP
queries outstanding simultaneously.
Note: If two or more clients ask the same question and cannot be served directly from the cache, the proxy servers will only issue a single back-end UDP query to fetch the data. The proxy servers do not issue multiple back-end requests for the same data as some DNS proxy servers (such as "dnscache") do.
The memory used by the caching proxy servers to store cached records has a fixed size, and is allocated when the server process is first started. When the servers run out of room in the cache for new information, they will discard as many of the least recently used cache entries as are necessary to make room.
Note: Neither the the time-to-live values of the records nor the length of time that they have existed in the cache have any effect on which records are discarded. Records are discarded based entirely on how recently they were referenced.
Cached records are also discarded if, when the cache is next searched, they have exceeded their lifetime. Time to live values are capped at 7 days when the records are first added to the cache, meaning that no record will ever live longer than 7 days.
The time-to-live values for all records that that the caching proxy servers send to their clients are equal to the time-to-live value of those records when originally obtained from the server, less the time that the records have been stored in the cache. This ensures that clients will not cache records for longer than the proxy server itself will cache them.
Note: Some badly written DNS client applications, such as Netscape Communicator, do not respect time-to-live values and will read DNS information just once and retain it internally indefinitely thereafter until the application is itself terminated. This can result in such applications using stale DNS information with no way to correct them other than terminating and restarting them. There is nothing that can be done about such programs other than complaining to their author(s).
localhost., 127.0.0.1, and ::1
Forward lookups for the name localhost. and reverse lookups
for the loopback IP addresses 127.0.0.1 and ::1 should always succeed even
if the proxy server is unable to contact other servers or the rest of
Internet, and should not waste bandwidth or bother any other servers.
Therefore, unless the /LOCALHOST- option is used, the caching proxy
servers will handle queries for the names localhost.,
1.0.0.127.in-addr.arpa., and
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
internally.
For localhost.:
They will return empty record sets for
all types of queries other than A or AAAA. For
A queries they will return a record set containing the single
IP address 127.0.0.1, marked as valid for 7 days. For AAAA
queries they will return a record set containing the single IP address
::1, marked as valid for 7 days.
For 1.0.0.127.in-addr.arpa.:
They will return empty
record sets for all types of queries other than PTR. For
PTR queries they will return a record set containing the
single name localhost., marked as valid for 7 days.
For 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.:
They will return empty record sets for all types of queries other than
PTR. For PTR queries they will return a record
set containing the single name localhost., marked as valid
for 7 days.
If the /DECIMAL+ option is used, the caching proxy servers
handle queries for names that are big-endian dotted-decimal IP addresses
(i.e. names in the form "a.b.c.d.") internally, in order to help
cope with badly written DNS client applications.
For A or "*" queries they will return a record set containing
the single IP address a.b.c.d., marked as valid for 7 days.
For AAAA or "*" queries they will return a record set
containing the single IP address 0::a.b.c.d., marked as valid for 7 days.
For any other type of queries they will return an empty record set.
If the /IMPLICITALL0+ option is used, the caching proxy
servers handle queries for 0.0.0.0.in-addr.arpa. internally.
If the /IMPLICITALL1+ option is used, the caching proxy
servers handle queries for 255.255.255.255.in-addr.arpa.
internally.
Some people think that one or other of various organizations (most popularly, ICANN) own the root of the DNS namespace. However, the simple fact of the matter is that you own the root. Everyone determines what their own namespace root is.
One can always run one's own set of . content DNS servers, using the
General-purpose Content DNS Server
and a suitably populated database. However, most people prefer to use
. content DNS servers owned and maintained by others.
There are several organizations and companies that provide publically
accessible sets of . content DNS servers, such as the Open Root Server
Confederation and the Internet Corporation for Assigned Names and Numbers
(a company with a contract with the U.S. Government Department of Defence).
One chooses between them according to which one serves up the DNS namespace
view that one prefers to see. ICANN, for example, serves up a diminutive
root, which only contains delegations for a few top-level domains (the
country-code top-level domains and the so-called "global" top-level
domains). Organizations such as the ORSC, on the other hand, serve up an
augmented root containing many more top-level domains such as
arts., sport., hotel.,
food., and news..
The Internet Utilities comes pre-supplied with configuration files,
suitable for use as Content\@ files with the
Resolving Caching Proxy Server,
listing the . content DNS servers for several organizations, including
ICANN, the ORSC, the Australian Root Server Confederation, Pacific Root,
the SuperRoot Consortium, ADNS, and AlterNIC. These files can be found
in the "Samples\Content" subdirectory.