DNS Resolver Information
Extracted elements (21)
The 'exterr' key allows resolvers to proactively advertise which EDE codes they support, enabling clients to detect mismatches. If a client receives an unlisted EDE, it can re-query RESINFO to learn of updated capabilities or identify the resolver information as inaccurate and discard it.
The resolver information defined in Section 5 is scoped to properties used to infer privacy and transparency policies of a resolver. The information is not intended for end-user consumption, but for use by DNS clients in resolver selection decisions.
The TXT-style key/value format from DNS-SD (RFC 6763) was adopted for RESINFO to enable extensibility: future keys can be added without modifying the RR type itself, and unknown keys are simply ignored by clients.
If a resolver's capabilities are updated to include new EDE codes, it can terminate the TLS session to prompt the client to initiate a new connection and re-retrieve the RESINFO record, making the client aware of updated capabilities.
When 'resolver.arpa' (from RFC 9462) is used as the QNAME for RESINFO queries, the client risks receiving a positive RESINFO response from either a legitimate resolver or an attacker if the resolver passes the query upstream. This case cannot be protected by DNSSEC validation, only by an authenticated secure connection.
For the 'exterr' key, range values MUST be identified by '-'. When multiple non-contiguous values are present, these values MUST be comma-separated.
If a DNS client sees unknown keys in a RESINFO RR type, it MUST silently ignore them. The same rules for keys defined in Section 6.4 of RFC 6763 MUST be followed for RESINFO.
If a group of resolvers shares the same ADN and/or anycast address, these instances SHOULD expose a consistent RESINFO to avoid presenting contradictory capabilities to clients.
If the resolver understands the RESINFO RR type, the RRset MUST have exactly one record. Invalid records MUST be silently ignored by DNS clients.
Resolver information keys MUST either be defined in the IANA registry (Section 8.2) or begin with the substring 'temp-' for names defined for local use only.
The DNS client MUST set the Recursion Desired (RD) bit of the RESINFO query to 0. The DNS client MUST discard the response if the AA flag in the response is set to 0, indicating the resolver is not authoritative for the response.
The resolver information server behind 'infourl' MUST support only the content-type 'text/html'. The DNS client MUST reject the URL as invalid if the scheme is not 'https'. Invalid URLs MUST be ignored.
RESINFO is a new DNS resource record (RR) type that allows recursive resolvers to publish information about themselves as key/value pairs. DNS clients query for RESINFO using the Authentication Domain Name (ADN) or 'resolver.arpa' as the QNAME. The record is a property of the resolver and is not subject to recursive resolution.
The 'exterr' key lists the Extended DNS Error (EDE) codes the resolver may return per RFC 8914. Individual codes or ranges (using '-') are supported; multiple non-contiguous values MUST be comma-separated. Presence of codes like Blocked (15), Censored (16), or Filtered (17) indicates the resolver reveals filtering reasons.
The 'infourl' key provides an HTTPS URL pointing to unstructured resolver information (e.g., DoH APIs, HTTP status codes, problem reporting) for IT troubleshooting. The URL is not intended for end-user consumption as it may provide misleading information.
The 'qnamemin' key is a boolean attribute (no value) indicating the DNS resolver supports QNAME minimisation per RFC 9156 to limit privacy-sensitive data sent to authoritative name servers. Its presence alone signals the feature is enabled.
IANA has assigned RESINFO as RR TYPE value 261 in the 'Resource Record (RR) TYPEs' registry under 'Domain Name System (DNS) Parameters', with meaning 'Resolver Information as Key/Value Pairs'.
IANA has created the 'DNS Resolver Information Keys' registry under 'Domain Name System (DNS) Parameters'. Registration procedure is Specification Required. Initial entries are 'qnamemin', 'exterr', and 'infourl'. The registry MUST NOT register names beginning with 'temp-'.
An encrypted resolver may return incorrect RESINFO. If the client cannot validate the attributes, it should process them only if the encrypted resolver has sufficient reputation according to local policy (user configuration, administrative configuration, or a built-in list of reputable resolvers), limiting a malicious resolver's ability to harm with false claims.
DNS clients MUST use one of two measures to prevent DNS response forgery: (1) establish an authenticated secure connection to the DNS resolver, or (2) implement local DNSSEC validation to verify authenticity of the resolver information. Only measure (1) applies to queries for 'resolver.arpa'.
The RESINFO RR type uses the same format as DNS TXT records, as defined in Section 3.3.14 of RFC 1035 and further elaborated in Section 6.1 of RFC 6763. Key/value pairs are encoded per Section 6.3 of RFC 6763; a key with no '=' is a boolean attribute (presence-only).