BIND Trust Anchor Telemetry in BIND 9.9.10, 9.10.5 and 9.11.0
  • 27 Sep 2018
  • 4 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

BIND Trust Anchor Telemetry in BIND 9.9.10, 9.10.5 and 9.11.0

  • Dark
    Light
  • PDF

Article Summary

In BIND 9.9.10, 9.10.5 and 9.11.0 we introduced a new trust anchor telemetry feature whereby DNSSEC-validating resolvers can signal which keys they have configured (trusted or managed keys) to the zone owners in which those keys reside. Typically this will be the Key Signing Key (KSK) for the root zone, but some resolver operators may have opted to include other apexes of trust, (usually where there is not an unbroken DNSSEC-signed chain of trust from the root zone to a specific lower level name space that is DNSSEC-signed).

4424.    [experimental]    Named now sends _ta-XXXX.<trust-anchor>/NULL queries
                           to provide feedback to the trust-anchor administrators
                           about how key rollovers are progressing as per
                           draft-ietf-dnsop-edns-key-tag-02.  This can be
                           disabled using 'trust-anchor-telemetry no;'.
                           [RT #40583]

This feature has been provided to help DNSSEC-signed zone operators for whom DNSSEC-validating resolvers are known or likely to have configured trust anchors. By monitoring the telemetry queries received following the introduction of a new key, they will be able to evaluate whether or not it is safe to remove the old key (or the old key's DNSSEC signatures).

Providing telemetry also indirectly helps DNSSEC-validating resolvers by giving responsible zone operators the data that they need to ensure safe key rollovers.

How does the telemetry feature work?

A BIND server configured to provide trust anchor telemetry will send specially-formed queries once per day to domains for which trust anchors have been configured via trusted-keys, managed-keys, dnssec-validation auto, or dnssec-lookaside auto.

  • Trust anchor queries are only sent by DNSSEC-validating BIND resolvers.
  • Resolvers that do not perform DNSSEC validation will not send telemetry information, even if they have trust anchors configured (that they are not using).

Will trust anchor telemetry impact resolver performance?

Performance of resolvers should not be affected - each 24 hours there will only be one additional query for each trust anchor configured by the resolver.

Does providing trust anchor telemetry have any loss of privacy implications for a resolver?

A resolver that is performing DNSSEC validation that relies on configured trust anchors will already be sending queries to the servers that are monitoring for the telemetry queries. The receiving server will therefore be aware that this resolver is validating because it will be receiving DNSKEY queries from it. The only additional information that a resolver providing telemetry is revealing about itself is which trust anchors it is configured to use.

What do trust anchor telemetry queries look like?

The format of the name being queried is _ta-XXXX where 'XXXX' is the hexadecimal representation of the key ID, usually seen in decimal format.

If there are multiple keys to be reported, then the query instead will be a series of keys separated by hyphens, e.g.: _ta-XXXX-YYYY.

So for example:

  • A validating resolver using KSK-2010 (key ID 19036) would send a query for _ta-4a5c.
  • A validating resolver using KSK-2017 (key ID 20326) would send a query for _ta-4f66.
  • A validating resolver configured to use both KSK-2010 and KSK-2017 would query for _ta-4a5c-4f66.

Can I disable this feature?

Trust anchor telemetry is enabled by default (for DNSSEC-validating resolvers) in BIND 9.10.5 and higher and 9.11.0 and higher. It can be disabled by adding the following option to named.conf:

trust-anchor-telemetry no;

What do authoritative zone operators do when receiving trust anchor telemetry queries?

The signalling that BIND has implemented is provided simply by a resolver sending a specially constructed query to the authoritative zone nameservers. This will be responded to normally by the authoritative zone server(s). Some zone administrators may have added RRsets to their zone in anticipation of the telemetry queries they might receive, whereas others may simply respond with NXDOMAIN. Zone operators who are likely to be receiving trust anchor telemetry queries should ensure that they are not inadvertently applying rate limiting filters (although the rate of telemetry queries received is unlikely to trigger a rate limiting response or drop).

Zone operators expecting to receive trust anchor telemetry queries should also be aware that some resolvers may have deployed aggressive NSEC/NSEC3 negative caching (https://tools.ietf.org/html/rfc8198), in which case if the response code to a key tag query is NXDOMAIN, this may result in some resolvers sending less frequent trust anchor usage information.

How the authoritative server administrators collect the telemetry information is unspecified, but might be achieved by logging queries received, or by adding instrumentation specific to their server's DNS implementation.

Who is using trust anchor telemetry now?
The root nameserver operators have been collecting and analyzing received trust anchor telemetry to inform their processes during the 2017 root KSK rollover: https://www.icann.org/resources/pages/ksk-rollover.

Is BIND also going to implement trust anchor telemetry using EDNS option signalling?

RFC 8145 documents two alternative mechanisms for providing trust anchor telemetry: https://tools.ietf.org/html/rfc8145.

We have no plans at this time to implement trust anchor telemetry via EDNS options.

If you have a significant use case for the EDNS-based alternate signalling mechanism that you require for your production environment, please submit a feature request to our BIND engineering team for evaluation:

https://www.isc.org/community/report-bug/