|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.|
Nonexistent domain or server failure.
22 bytes plus the length of the owner name.
dnscache does not exit when it runs out of space in its cache; it simply removes the oldest entries to make more space.
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 servers 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 servers 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.
dnscaches responses are generally much smaller than BINDs 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.)
If a server sends dnscache a repeated IP address, dnscache passes the repeated IP address along to the client. The servers 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 companys servers (now fixed):
% dnsq a ns-ext.vix.com ns-ext.vix.com
117 bytes, 1+1+2+2 records, response, authoritative, noerror
query: 1 ns-ext.vix.com
answer: ns-ext.vix.com 3600 A 220.127.116.11
authority: vix.com 3600 NS ns-ext.vix.com
authority: vix.com 3600 NS ns1.gnac.com
additional: ns-ext.vix.com 3600 A 18.104.22.168
additional: ns1.gnac.com 130768 A 22.214.171.124
This BIND bug is the most common reason for users to see repeated IP addresses from dnscache.
dnscache handles localhost internally, giving it an A record of 127.0.0.1.
dnscache handles 126.96.36.199.in-addr.arpa internally, giving it a PTR record of localhost.
dnscache handles dotted-decimal domain names internally, giving (e.g.) the domain name 188.8.131.52 an A record of 184.108.40.206.