Authoritative DNS Transport Signaling

1.1. 1.1. Confidentiality

The above text discusses discovery of transport signals and authentication information in queries made by the recursive resolver. Those queries may or may not occur over encrypted or authenticated connections. Only when all the connections are authenticated are all the queries protected from active surveillance. If all the connections are opportunistically encrypted then the queries are protected from passive surveillance. Otherwise they may occur in cleartext, or a combination of circumstances may exist.¶

Such queries leak the name of the zone that the resolver wishes to ultimately query which in itself can be sensitive. During the early stages of the incremental rollout of technologies such as recursive to authoritative encrypted connections it is unlikely that fully confidential discovery will be possible due to the nature of the DNS hierarchy. However, if large TLDs and/or those hosted by large CDNs support encrypted transports a significant number of queries from busy resolvers to discovery information on TLD child zones (and below) could be performed confidentially thereby greatly improving the privacy over the current situation.¶

1.2. 1.2. Prior Art

An attempt at utilizing more modern, and in particular, more private transports between resolvers and authoritative nameservers was introduced in [RFC9539]. The idea there was to opportunistically try to send the query to the authoritative nameserver over multiple transports with no prior knowledge of whether a transport was supported in the receiving end or not.¶

The drawback with that approach is that without any significant deployment of authoritative support the resolver end will mostly spend cycles and traffic on a wasted effort. For this reason their deployment has been limited.¶

Furthermore, in Appendix B of [RFC9539] requirements for improving the defense against an active attacker are listed. The first requirement is:¶

• A signaling mechanism that tells the recursive resolver that the authoritative server intends to offer authenticated encryption.¶

This document aims to provide exactly such a mechanism while staying within the current DNS protocol. Therefore the DNS transport signaling provided will be hint-based, and as such fit well as an improvement to [RFC9539].¶

1.3. 1.3. Rationale for Using the Additional Section

See Appendix A for the rationale for using the Additional section for the transport signaling hint.¶

3.1. 3.1. Description of Problem Space

This section looks at the various configurations that need to be supported.¶

For opportunistic mode to be possible, the authoritative server needs to provide the recursive resolver with the DNS transport signaling record even when the recursive resolver does not explicitly ask for it (i.e. as a hint, in the Additional Section). For example by adding it to the result of an A or AAAA query for a name server. The recursive resolver accepts such a record and uses it to set up a secure transport.¶

There are three zones that matter in this analysis: the parent zone, the child zone, and the zone that contains the name server addresses and transport signaling records. Note that the name server addresses may be located in the child zone. And some of the three zones may be served by the same name server.¶

The parent zone contains the delegation NS RRset for the child which is not DNSSEC signed. Therefore it does not matter if the parent zone is DNSSEC signed or not in terms of validating the child’s NS RRset.¶

For the child zone there are also two possibilities, the child zone is DNSSEC secure or not.¶

For the nameserver transport signaling there are two possibilities: either the zone that holds the nameserver information is DNSSEC secure or it is DNSSEC insecure (i.e. the signaling needs to be learned opportunistically and later possibly be validated by direct query to the SVCB owner name).¶

3.2. 3.2. Behaviour of the Two Modes

3.3. 3.3. Precedence and Interaction

• Validated transport signals MUST take precedence over Opportunistic transport signals.¶

• A validated Opportunistic transport signal is equivalent to a Validated transport signal for policy and usage purposes.¶

• An Opportunistic (unvalidated) transport signal MUST NOT be used to enforce negative transport policy ("-do53"), alter addressing ("ipv4hint/ipv6hint"), or bootstrap authentication material ("tlsa").¶

3.4. 3.4. Caching and No-DTS

• Resolvers MAY cache Validated-mode SVCB information according to its TTL and MAY use the EDNS(0) No-DTS option to avoid redundant hints when sufficient information is cached.¶

• In Opportunistic mode, resolvers MAY cache positive "alpn" results subject to local policy (see Resolver Caching Strategies). When a resolver has sufficient cached information, it SHOULD set No-DTS to reduce response size and limit unnecessary hints.¶

3.5. 3.5. Summary of Permitted Use by Mode

• Opportunistic:¶

  • MAY use: alpn: "doq", "dot", "h2" and "h3" only.¶

  • MUST NOT use: alpn: "-do53", ipv4hint, ipv6hint, tlsa, or any parameter that affects addressing or authentication.¶

  • MUST support fallback to do53 (i.e. UDP/TCP).¶

• Validated:¶

  • MAY use: alpn: "doq", "dot", "h2", "h3", "-do53", ipv4hint, ipv6hint, tlsa, and other defined parameters.¶

Implementation note: - Existing resolvers that do not understand the alpn="-do53" token or the new "tlsa" parameter will ignore them and remain interoperable. Clients implementing this specification MUST follow the above mode-dependent processing and precedence rules.¶

5.1. 5.1. Trigger Conditions for Including the DTS Hint

An authoritative nameserver SHOULD include an DTS Hint when all of the following conditions are met:¶

1. Self-Identification: The responding authoritative own Fully Qualified Domain Name (FQDN) (or one of its configured aliases/identities) is found within the NS RRset for the queried zone.¶

2. Transport Capability: The responding authoritative nameserver supports one or more alternative transport protocols (e.g., DoT, DoH, DoQ) and is configured to advertise these capabilities. Or the nameserver does not (temporarily or permanently) support DNS over legacy UDP/TCP transport and is configured to advertise this fact.¶

3. SVCB not present in Answer: If the SVCB record is present in the Answer section (because it was explicitly queried for), then it does not have to be included again in the Additional section, regardless of whether the resolver has set the DTS Option or not.¶

5.2. 5.2. Multiple Server Identities

An authoritative nameserver may be known by multiple FQDNs (e.g., ns1.example.com, dns.customer.org, ns.cdnprovider.net). To facilitate condition 1 ("Self-Identification"), authoritative server implementations MAY include a configuration mechanism (e.g., an identities list) where operators can list FQDNs by which the server is known. This allows the server to correctly identify itself regardless of the specific name used in the NS RRset.¶

5.3. 5.3. Format of the DNS Transport Signal SVCB Record

The DTS Hint MUST be an SVCB record with the following characteristics:¶

• OWNER: The owner name of the SVCB record MUST be the label "_dns" followed by the FQDN of the authoritative nameserver itself, as identified in the NS RRset that triggered its inclusion (e.g., _dns.ns.dnsprovider.com.).¶

• CLASS: IN (Internet).¶

• TYPE: SVCB.¶

• TTL: The TTL of the SVCB record SHOULD be chosen by the authoritative server operator. Choice of TTL is a local configuration decision, but unless the supported transports are subject to frequent change a value on the order of 24h or more is suggested.¶

• SVCB_PRIORITY: 1. The specific priority value is not critical for this hint mechanism, but 1 indicates the highest priority for the service.¶

• SVCB_TARGET: . (root). This indicates that the DNS transport capabilities described by the SVCB record refer to the owner name of the record.¶

• SVCB_PARAMS: A set of Service Parameters indicating the supported transport protocols. This document uses the "alpn" parameter [RFC9460] for signaling DoT (alpn=dot) and DoQ (alpn=doq). It further defines the new alpn parameter token "-do53" for signaling lack of support for UDP/TCP. Resolvers MUST treat "-do53" as actionable only when the SVCB RRset has been DNSSEC-validated (Validated mode).¶

  The SVCB parameters "ipv4hint" and "ipv6hint" MAY be included. Resolvers MUST use these address hints only when the SVCB RRset has been successfully validated (Validated mode).¶

  A new "tlsa" SVCB parameter contains the corresponding TLSA record for the certificate used to secure a DoQ or DoT transport. Resolvers MUST use "tlsa" only when the SVCB RRset has been successfully validated (Validated mode).¶

  If any other parameter is present in the SVCB parameter list it must be ignored by the resolver.¶

Example 1:¶

If ns.dnsprovider.net. responds to a query for www.example.com. (in the unsigned zone example.com.) and ns.dnsprovider.net is listed in the NS RRset for example.com., it may respond with a DNS message that contains: ~~~ Header: ...¶

Answer: www.example.com. IN A 1.2.3.4¶

Authority: example.com. IN NS ns1.example.com. example.com. IN NS ns.dnsprovider.net.¶

Additional: ns.dnsprovider.net. IN A 5.6.7.8 ns.dnsprovider.net. IN RRSIG A ... _dns.ns.dnsprovider.net. IN SVCB 1 . "alpn=doq,dot,do53" _dns.ns.dnsprovider.net. IN RRSIG SVCB ... ~~~¶

Example 2: The resolver explicitly asks for the DNS transport signal for the authoritative nameserver ns.dnsprovider.net. by querying for "_dns.ns.dnsprovider.net. SVCB": ~~~ Header: ...¶

Answer: _dns.ns.dnsprovider.net. IN SVCB 1 . (alpn="doq,dot,-do53", tlsa="...") _dns.ns.dnsprovider.net. IN RRSIG SVCB ...¶

Additional: ~~~ Because the resolver uses Validated mode (by querying for the SVCB record at _dns.{nameserver FQDN} and validating the response) all data in the received SVCB record MAY be used. In this case that includes the negative transport signal "-do53", which will effectively turn off UDP/TCP use by the resolver for communicating with this particular authoritative nameserver.¶

6.1. 6.1. When Sending Queries

1. OPT-OUT Possibility: If the resolver already thinks that it knows the transport capabilities of the authoritative nameserver it is about to send a query to it may opt out from DNS transport signaling by including an EDNS(0) "No-DTS" option in the query.¶

   It is important to be aware that using the No-DTS option consistently will make the resolver blind to any changes in the transport signals, which is clearly not acceptable. Hence any use of "No-DTS" should be restricted to only be used within the TTL of an already received and parsed DTS Hint.¶

6.2. 6.2. When Receiving Responses

1. Opportunistic Parsing: When receiving an authoritative DNS response, the resolver SHOULD parse the Additional section for SVCB records.¶

2. Owner Check: If an SVCB record is found whose owner name matches the "_dns" label followed by an authoritative nameserver name for the zone to which the query belongs, the resolver MAY consider this an DTS Hint.¶

3. DNSSEC Validation (Optional but Recommended):¶

   • The resolver SHOULD attempt to DNSSEC validate the DTS Hint. This involves validating the SVCB record itself and its corresponding RRSIG (if present) against the DNSSEC chain of trust for the zone that owns the SVCB record (e.g., dnsprovider.com for _dns.ns.dnsprovider.com).¶

   • If validation succeeds: The DTS Hint is considered a trusted signal. The resolver MAY then use all the transport signals provided in the SVCB record when deciding on alternative transport choices for subsequent queries to that specific authoritative nameserver.¶

   • If validation fails, or no RRSIG is present: The DTS Hint MUST be treated as an unvalidated hint. The resolver MAY still opportunistically attempt to use the signaled alternative transports, but MUST be prepared for immediate fallback to traditional transports (UDP/TCP) if the connection fails. This is particularly relevant for scenarios like vanity names (e.g., ns.customer.com where customer.com is an unsigned zone, but the underlying server ns.dnsprovider.com is capable).¶

4. Prioritization: * Any DNSSEC-validated SVCB record found via explicit query (e.g., _dns.ns.example.com for a queried domain) MUST take precedence over any unvalidated DTS Hint.¶

• The DTS Hint is a mechanism to discover capabilities opportunistically, not to override trusted delegation or service configuration.¶

1. Fallback: Resolvers MUST always be prepared to fall back to traditional UDP/TCP transport if an attempt to use an alternative transport based on an DTS Hint (especially an unvalidated one) fails or times out.¶

6.3. 6.3. Upgrading the DNS Transport Signal

If an unvalidated opportunistic transport signal has been received the resolver may choose to upgrade that signal, either immediately or when the transport signal is close to expiration from the resolver cache. An upgraded transport signal allows the resolver to operate in Validated mode, and then use all the information in the SVCB record (including "-do53", ipv4hint/ipv6hint, and tlsa).¶

6.4. 6.4. Authentication of the Authoritative Nameserver

Authentication of the authoritative nameserver is not an explicit goal in opportunistic mode. The reason is that as an opportunistic mechanism it will not always be possible to do such authentication.¶

However, even without strong authentication of the authoritative server the proposed mechanism still provides benefits (privacy, potential performance improvements) and for that reason cryptographic verification of the server identity is not a requirement.¶

In validated mode authentication of the authoritative nameserver is done by validation of the DNSSEC RRSIG over the SVCB record containing the DTS Hint.¶

Finally, validating the server cert against a list of well-known public Certificate Authorities is possible, but there is no standardized way to determine which CAs are appropriate for DNS server certificates.¶

6.5. 6.5. Resolver Caching Strategies

Resolvers implementing the DNS DTS Hint mechanism have several options for caching the transport signals received via DTS Hints.¶

A suggested primary strategy is to set the EDNS(0) No-DTS option when no transport signaling information is needed. This may be because the resolver already knows the authoritative nameserver's transport capabilities from a previous response (with a TTL that has not expired) or for some other reason.¶

The primary caching strategy SHOULD be "Standard DNS Cache", i.e. treat the SVCB record like any other DNS record, caching it according to its TTL. This is the simplest approach and will simply cause the resolver to fall back to UDP for one query if the transport signal data has expired.¶

For a more detailed analysis of possible caching logic, see [RFC9539], section 4.¶

Note that the resolver always has the option of not using the EDNS(0) No-DTS option whenever the cache entry is getting close to expiry.¶

Given the variety of deployment scenarios and operational requirements, this document does not mandate a specific caching strategy. Implementers SHOULD choose a strategy that best fits their operational needs, considering factors such as:¶

• The importance of minimizing connection attempts¶

• The impact of failed connection attempts¶

• The computational cost of different caching strategies¶

• The memory requirements of maintaining cache state¶

The chosen strategy SHOULD be documented in the implementation's configuration options to allow operators to make informed decisions about its use.¶

11.1. 11.1. No-DTS EDNS(0) Option

This document defines a new EDNS(0) option, entitled "No-DTS", assigned a value of TBD in the "DNS EDNS0 Option Codes" registry.¶

   +-------+--------------------------+----------+----------------------+
   | Value | Name                     | Status   | Reference            |
   +-------+--------------------------+----------+----------------------+
   | TBD   | No-DTS                   | Standard | ( This document )    |
   +-------+--------------------------+----------+----------------------+

Note to the RFC Editor: In this section, please replace occurrences of "(This document)" with a proper reference.¶

11.2. 11.2. SVCB/HTTPS Parameter: tlsa

This document requests registration of a new SVCB/HTTPS parameter in the "SVCB and HTTPS Parameters" registry:¶

   +-------+--------+--------------------+----------------------+
   | Key   | Name   | Meaning            | Reference            |
   +-------+--------+--------------------+----------------------+
   | TBD   | tlsa   | Carries TLSA data  | ( This document )    |
   +-------+--------+--------------------+----------------------+

Presentation and wire format: The value carries one or more TLSA RRs associated with the nameserver endpoint. Exact encoding and size limits are defined by this document (TBD). Use of this parameter is appropriate only when the containing SVCB RRset is DNSSEC-validated (see Section 3).¶

11.3. 11.3. The New SVCB alpn Token "-do53"

This document updates the "alpn" SVCB parameter with one additional token, "-do53", used to signal lack of support for UDP/TCP, i.e. a negative transport capability. Note that at present support for UDP/TCP is required for authoritative nameservers.¶

The "-do53" token has two use cases. The first is for temporary service interruptions (i.e. a busy nameserver that only supports UDP/TCP transport may signal alpn="-do53" prior to being offline for maintenance). The second is for a future where a significant fraction of authoritative DNS traffic has migrated to encrypted transports and it may be reasonable to not support every transport at every nameserver.¶

IANA is requested to add the "-do53" token to the list of defined tokens for the "SVCB and HTTPS Parameters" registry entry for "alpn" and reference this document. A new ALPN ID must be allocated for "-do53".¶

13.1. A.1. Opportunistic Mode Via the Additional Section

When designing a mechanism that relies on sending new information in DNS responses without changing the current DNS protocol, the Additional section has the major advantage of being ignored by legacy software. This property makes it possible to essentially deploy the proposed mechanism immediately, as it will not cause problems with existing DNS infrastructure.¶

• Existing authoritative nameservers will not provide any DTS Hint in the Additional section.¶

• Existing resolvers will actively ignore any DTS Hint in the Additional section.¶

Only DNS nameservers (authoritative or recursive) that are aware of the proposed mechanism will use it.¶

The downside is that it is not possible to strictly rely on anything specific being present in the Additional section, as it may be stripped off by a middle man or even by the sending nameserver (eg. due to packet size constraints). For this reason it is not possible to provide more than an opportunistic transport signal when the signal is not explicitly queried for.¶

This is usually a major issue and the primary reason that data in the Additional section is actively ignored by resolvers. In this particular case, though, even an untrusted transport signal is better than no signal at all. Furthermore, the only effect of a forged or otherwise incorrect transport signal is a, typically failed, connection attempt to an authoritative nameserver that does not support the advertised transport. This will cause immediate fallback to "Do53", i.e. traditional DNS over UDP/TCP and the non-availability of the advertised transport will be remembered by the resolver (for some suitable time).¶

Hence, using the Additional section for opportunistic transport
signaling has vastly more benefits than drawbacks.¶

13.2. A.2. Validated Mode Via the Additional Section

If the transport signal is present in the Additional section, it may or may not be possible to validate it (if it has a DNSSEC signature).¶

This is necessary to bee able to trust more sensitive signals. A positive signal inserted by an on-path attacker (eg. claiming DoQ support when this is false) would not be catastrophic. However, a false negative alpn="-do53" signal (eg. claiming no Do53 support while such support is present) would be potentially catastrophic. For this reason (ability to trust more sensitive signals) the connection between resolver and authoritative server must be in Validated Mode.¶

15.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6891]

Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/rfc/rfc6891>.

[RFC7435]

Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/rfc/rfc7435>.

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9250]

Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/rfc/rfc9250>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9461]

Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.

[RFC9539]

Gillmor, D. K., Ed., Salazar, J., Ed., and P. Hoffman, Ed., "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS", RFC 9539, DOI 10.17487/RFC9539, February 2024, <https://www.rfc-editor.org/rfc/rfc9539>.

15.2. Informative References

[I-D.draft-ietf-deleg]

April, T., Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-ietf-deleg-05, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-deleg-05>.