Trust levels for RRsets in BIND cache
- Updated on 02 Nov 2017
- 4 minutes to read
When a BIND resolver receives answers from authoritative servers, it must determine whether to accept them, whether to cache them, and whether to use them when sending responses to client queries. In some cases, more than one answer may be available, and BIND must determine which is preferred, replacing cached data with more trustworthy information. In making these determinations, BIND uses a modified version of the hierarchy of trust levels originally defined in RFC 2181, section 5.4.1.
A DNS response is broken into four "sections":
- the Question section contains the original query that was sent by the client
- the Answer section contains the answer to the query, if any
- the Authority section contains information about the authoritative server sending the response
- the Additional section contains additional information that may be necessary (or at least helpful) to the client.
For example, if the response contains a simple answer to a query, then that answer will be in the Answer section. But if the response is a delegation from a parent domain to a subdomain, then the Answer section will be empty, but the Authority section will contain the NS records for the subdomain. If name servers for the subdomain are in that subdomain, then the addresses for the name servers must be included in the Additional section, enabling the resolver to query them; these address records are called "glue".
Trust levels for DNS data depend on various factors, including:
- Whether the server that supplied the data is authoritive for the zone, or is a cache or forwarder
- Which section of the DNS response contained the data in question
- Whether or not the zone is signed and a trust anchor exists that covers it
- If the zone is signed and covered by a trust anchor, whether or not the data has been validated.
Trust levels from lowest to highest are:
PENDING-ADDITIONAL: data received in the Additional section of a response, whose owner name is covered by a trust anchor and so requires validation, but has has not yet been validated. If validation proves that the zone is not signed, then this data is promoted to trust level ADDITIONAL. If the zone is proven to be signed and the data validates, this is promoted to trust level SECURE.
PENDING-ANSWER: data received in the Answer section of a response, whose owner name is covered by a trust anchor and so requires validation, but has has not yet been validated. If validation proves that the zone is not signed, then this data is promoted to trust level AUTH-ANSWER if it originated from an authoritative server, or ANSWER if it originated from a cache or other non-authoritative source. If the zone is proven to be signed and the data validates, then this is promoted to trust level SECURE.
ADDITIONAL: data received in the Additional section of a response, which is either in a zone that has been proved to be unsigned, or was not covered by a trust anchor. GLUE: address data included in additional section of a delegation response for name servers which are in or under the delegated zone.
ANSWER: data received in the Answer section of a response, sent by a server which is NOT authoritative for the answer (i.e., from a cache or or a forwarder).
AUTH-AUTHORITY: data received in the Authority section of a response from a server which is authoritative for the data.
AUTH-ANSWER: data received in the Answer section of a response from a server which is authoritative for the data.
SECURE: data which has been fully DNSSEC validated, regardless of source.
ULTIMATE: data for which this server is itself authoritative.
Some notes on GLUE data:
GLUE is Additional data, but it is specially promoted to a higher level of trust because it is necessary for resolution to work.
A name server whose name is outside the domain for which it is authoritative can be resolved by other means; if named receives a name server address for one of these in the additional section, it will not use the address until the trust level has been increased, either by validating the address and promoting it to Secure, or by sending a direct query and receiving the address at trust level ANSWER or AUTH-ANSWER.
However, a name server which is in its own domain creates a circular dependency. These server addresses are cached as GLUE and can be used by BIND when sending authoritative queries.
© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.