<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.johani-dnsop-transport-signaling" target="https://datatracker.ietf.org/doc/html/draft-johani-dnsop-transport-signaling-02">
   <front>
      <title>Authoritative DNS Transport Signaling</title>
      <author initials="J." surname="Stenstam" fullname="Johan Stenstam">
         <organization>The Swedish Internet Foundation</organization>
      </author>
      <author initials="L." surname="Fernandez" fullname="Leon Fernandez">
         <organization>The Swedish Internet Foundation</organization>
      </author>
      <author initials="E." surname="Bergström" fullname="Erik Bergström">
         <organization>The Swedish Internet Foundation</organization>
      </author>
      <author initials="P." surname="Homburg" fullname="Philip Homburg">
         <organization>NLnet Labs</organization>
      </author>
      <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
         <organization>Sinodun IT</organization>
      </author>
      <date month="October" day="20" year="2025" />
      <abstract>
	 <t>   This document proposes a mechanism for authoritative DNS servers to
   signal their support for alternative transport protocols (e.g., DNS
   over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)).  This
   signaling may either be provided within the Additional section of
   authoritative DNS responses or be the result of direct DNS queries.

   The former, &quot;opportunistic mode&quot; is hint-based and aims to enable
   resolvers to discover alternative transports efficiently and then
   opportunistically upgrade connections to the authoritative, thereby
   improving privacy, security, and performance for subsequent
   interactions.  The mechanism is designed to not require any protocol
   change or additional queries.  It is safe, backward-compatible, and
   effective even when DNSSEC validation of the hint is not possible or
   desired.

   In certain circumstances and with additional overhead it is also
   possible to use direct queries to securely obtain authentication
   information for the authoritative that can then be used to
   authenticate an encrypted connection.

   It is also possible to establish a &quot;validated mode&quot; where the
   communication between the resolver and the authoritative server is
   provably both secure and authentic.  Validated mode may not always be
   possible, depending on whether the resolver is able to DNSSEC
   validate the signal or not.  When Validated mode is possible it does
   provide a stronger and more trustworthy connection.

   This document proposes an improvement to the opportunistic (but
   blind) testing of alternative transports suggested in RFC9539 by
   providing a mechanism by which a responding authoritative server may
   signal what alternative transports it supports.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/johanix/draft-johani-dnsop-transport-signaling
   (https://github.com/johanix/draft-johani-dnsop-transport-signaling).
   The most recent working version of the document, open issues, etc,
   should all be available there.  The authors (gratefully) accept pull
   requests.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-johani-dnsop-transport-signaling-02" />
   
</reference>
