Provided by: dnscache_1.05-15fakesync1_amd64 bug


       dnscache - a DNS cache.


       This is a reference page.  For tutorial information, see the instructions for
       workstations (,
       home computers (,
       external caches (, or
       upgrading from BIND (

       dnscache  accepts  recursive  DNS queries from local clients such as web browsers and mail
       transfer agents.  It collects responses from remote DNS servers.  It caches the  responses
       to save time later.


       Normally dnscache is set up by the dnscache-conf(8) program.

       dnscache runs chrooted in the directory specified by the $ROOT environment variable, under
       the uid and gid specified by the $UID and $GID environment variables.

       dnscache listens for incoming UDP packets and TCP connections addressed to port 53 of $IP.
       Typically $IP is, but it can also be an externally accessible IP address.

       dnscache  accepts  a  packet or connection from IP address if it sees a file named
       ip/ or ip/1.2.3 or ip/1.2 or ip/1.

       dnscache sends outgoing packets from high ports of $IPSEND.  Typically $IPSEND is,
       meaning the machine's primary IP address.

       dnscache  reads  a  seed,  up  to  128  bytes, from standard input, and passes the seed to

       dnscache reads a list of dotted-decimal root server IP addresses, one  address  per  line,
       from  servers/@.   It  also  scans the servers directory for server IP addresses for other
       domains.  If there are addresses listed in servers/, for example, then dnscache
       will  send queries for to those addresses, and will not cache records
       for from outside servers such as the root servers.

       Versions 1.03 and above: If $FORWARDONLY is set, dnscache treats servers/@ as a list of IP
       addresses  for  other  caches,  not root servers.  It forwards queries to those caches the
       same way that a client does, rather than contacting a chain of  servers  according  to  NS

Memory use

       dnscache uses a fixed-size table, under 256K, to keep track of as many as 200 simultaneous
       UDP queries and 20 simultaneous TCP connections.  It also  dynamically  allocates  memory,
       usually  just  a  few bytes but occasionally much more, for each active query.  If it runs
       out of memory handling a query, it discards that query.

       dnscache asks the operating system to reserve a 128K buffer for  bursts  of  incoming  UDP
       queries.   In versions 1.03 and above, if a new UDP query arrives when dnscache is already
       handling 200 simultaneous UDP queries, dnscache drops the oldest  query.   If  a  new  TCP
       connection  arrives  when  dnscache  is  already handling 20 simultaneous TCP connections,
       dnscache drops the oldest connection.

       dnscache uses a fixed-size cache, as controlled by the  $CACHESIZE  environment  variable.
       Roughly  5%  of  the  cache  is used for a hash table.  The rest is used for cache entries
       (including 8-byte Y2038-compliant expiration times):

       o      A sets.  22 bytes plus 4 bytes per address plus the length of the owner name.

       o      NS sets or PTR sets or CNAME sets.  22 bytes plus the length of the owner name  and
              all the data names.

       o      MX sets.  22 bytes plus 2 bytes per MX plus the length of all the names.

       o      Other  record  sets.   22  bytes plus 2 bytes per record plus the length of all the
              data strings plus the length of the owner name.

       o      Nonexistent domain or server failure.  22 bytes plus the length of the owner name.

       Sets larger than 8192 bytes are not cached.

       dnscache does not exit when it runs out of space in  its  cache;  it  simply  removes  the
       oldest entries to make more space.

Resolution and caching policies

       dnscache  relies on a configured list of root name servers.  In contrast, BIND starts from
       a ``hint file'' listing name servers, and asks those name  servers  where  the  root  name
       servers are.

       dnscache  does  not  cache  (or  pass along) records outside the server's bailiwick; those
       records could be poisoned.  Records for foo.dom, for example, are accepted only  from  the
       root servers, the dom servers, and the foo.dom servers.

       dnscache  does  not  bypass  its  cache  to  obtain  glue from the additional section of a
       response.  In particular, it will not use glue outside the  server's  bailiwick,  or  glue
       with TTL 0, or glue that violates other caching policies.

       dnscache caches records for at most a week.  It interprets TTLs above 2147483647 as 0.

       dnscache  does  not  cache  SOA records.  However, it does use SOA TTLs to determine cache
       times (up to an hour) for zero-record responses and nonexistent domains.

Responses to DNS clients

       dnscache's responses are generally much  smaller  than  BIND's  responses.   They  do  not
       include  authority  records  (NS  records  of  the source name servers and SOA records for
       negative answers) or additional records (A records relevant to NS or  MX  records).   When
       the answer section is truncated by UDP length limits, it is eliminated entirely.

       dnscache  tries  to  prevent  local users from snooping on other local users.  It discards
       non-recursive  queries;  it  discards  inverse  queries;  and  it  discards  zone-transfer
       requests.   If  $HIDETTL  is  set,  dnscache  always uses a TTL of 0 in its responses.  In
       versions before 1.03, dnscache always uses a TTL of 0 in its responses.

       According to RFC 1035, the AA bit ``specifies  that  the  responding  name  server  is  an
       authority for the domain name in question section.''

       dnscache is not an authority for any domain names.

       dnscache  never sets the AA bit (except in NXDOMAIN responses, as required by RFC 2308, to
       work around a common client bug).  In contrast, BIND often sets AA for positive  responses
       even when it is not an authority for the domain name.  (This appears to have been fixed in
       BIND 9.)

Repeated IP addresses

       If a server sends dnscache a repeated IP address, dnscache passes the repeated IP  address
       along  to the client.  The server's behavior violates RFC 2181, section 5.5, but there are
       reasonable uses of repeated IP addresses for load balancing, so dnscache does not  go  out
       of its way to remove repetitions when they occur.

       A  widespread  BIND  server bug (apparently fixed in BIND 9.1) can unintentionally produce
       repeated IP addresses.  Here is an example from one of the  BIND  company's  servers  (now

         % dnsq a
         117 bytes, 1+1+2+2 records, response, authoritative, noerror
         query: 1
         answer: 3600 A
         authority: 3600 NS
         authority: 3600 NS
         additional: 3600 A
         additional: 130768 A

       This  BIND  bug  is  the  most  common  reason for users to see repeated IP addresses from

Special names

       dnscache handles localhost internally, giving it an A record of

       dnscache handles internally, giving it a PTR record of localhost.

       dnscache handles dotted-decimal domain names internally, giving  (e.g.)  the  domain  name an A record of