Hi Klaus, > On 5 Jun 2025, at 21:21, [email protected] wrote: > > Hi, > > as it has become kinda quiet arround > draft-hal-adot-operational-considerations-02 by now I'd like to follow. > > Was there an active decission to not move forward with it? > e.g. one to maybe favour DNS-over-HTTPS with SVCB-RR and HTTPS-RR > (aka. rfc9460 and rfc9461) or something?
There was a significant effort in the DPRIVE working group to try to define a way for authoritative servers to provide credentials to secure encrypted connections via existing DNS records. However no solution without significant issues could be found. As a next step the working group published: “Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS” https://datatracker.ietf.org/doc/rfc9539/ which provides a mechanism for recursives to probe authoritative servers on port 853 and then use opportunistic encryption. The hope now is that the work happening in the DELEG working group (https://datatracker.ietf.org/wg/deleg/about/) will provide a mechanism to support secure encrypted connections between recursive and authoritative servers, although the development of this protocol extension is in the _very_ early stages. There is in fact active discussion about SVCB or SVCB-like record usage there if you take a look :-) Additionally there has been significant work in the ADD working group (https://datatracker.ietf.org/wg/add/about/) developing a number of mechanisms for discovery of recursives that offer encrypted services. I would suggest reviewing the documents and activity there. Note also that a general specification for DNS-over-QUIC was also published by DPRIVE (https://datatracker.ietf.org/doc/html/rfc9250) which specifies that DoQ can be used stub-recursive, recursive to authoritatives and for zone transfers (the latter built on top of zone transfers over DoT - https://www.rfc-editor.org/rfc/rfc9103.html). I hope this helps a bit to understand the latest picture - happy to chat off-list to point you to specific documents if needed! Best regards Sara. > > As RFC9461 also mentions DoT for its SVCB-RR but I couldn't find > anything about DoT or DoH being allowed for authorative DNS servers, I > think there may be a need to update e.g. RFC8310 after all. > > In detail I was thinking about: > * Allow authoritative DNS servers to serve authoritative replies over DoT > * Extend the Scope to authoritative DNS servers as well > * Extend 6.3 to also allow using a TLS certificate issued towards the IP > of the DNS server using the iPAddress SAN entry type. > * Extend 6.6 to allow any DNS requestor (stub, forwarder, and resolvers) > to alternatively use a combination of DNSSEC and at least one of > DANE, SVCB-RR ("_dns"), HTTPS-RR (with "dohpath" svcparam), and > forward-confirmed reverse DNS lookups to discover and authenticate the > encrypte dersion of a DNS server even in absence of another DNS Server > and given only the IPAddress of the DNS server (and default port). > This effectively works by probing the connection and validating the data > using DNSSEC. Once the requestor received the servers TLS certificate > it has to perform the following additional steps for validation > depending upon the existence of specific SAN entries: > a) When at least 1 dNSName but NO iPAddress entry exists: > Causes the validation to be postponed and additional informations > using dns queries to be requested through this TLS connection first. > 1. For this the client sends a query for the above mentioned dns > records related to the dns server itself through the not yet validated > connection. > 2. DNSSEC validation MUST be performed on the received data. > In case it fails or cannot be performed the certificate validation > MUST be considered as having failed. > 3. For each of the DNS-Names discovered the validation of the > certificate is attempted, In case at least one passes it is > considered as having passed the validation. > 4. Once the certificate has passed validation this connection can be > treated to any other connection that passed validation. > 5. The actual request for which establishing this connection was > originally attempted can be sent now. > A discovered and valid dns name MAY be cached. > The data received while establishing the connection before the > certificate was fully validated MAY be discarded unconditionally, > MUST be discarded when certificate validation failed, and > MAY be cached after the certificate passed validation like any other > dns request. > b) In all other cases the certificate is validated as usual. > c) If neither an iPAddress nor a dNSName entry exist the value of the > CN MAY optionally be used instead of the dNSName for discovery > similar to a). > * A DNS64 aware requestor may use this information while performing the > discovery above to construct the ipaddress value required for > validation. The ipv4only.arpa MUST NOT be queried as part of the above > autodiscovery from the same server as being validated. In case another > resolver is available it may be used. When none is available and > validation happens to pass without it then it MAY be queried after the > connection is fully established and validated. > * When replying to a NS query, authoritative DNS servers SHOULD include > the associated SVCB-RRs (as well as the A, and AAAA records as specified > in [RFC9460]) within the Additional section of its reply. > If the zone is signed, the server SHOULD also include DNSSEC records > authenticating the existence or nonexistence of these records in the > Additional section as well. > * Same as above but for PTR queries. (Are SVCB-RRs for an IP within the > reverse lookup zone a thing? I couldn't find anything mentioning it > being valid or invalid there, so I guess they could be there, too?) > * Ideally revisit RFC8482 or add a new "public-view" to AXFR to allow > preparing a subset of the zonefile for resolvers to request for better > caching. Then a DNS resolver could just clone the this set of common > records and would thereby not just reduce server load but also speed up > connections drastically and improve user privacy as the remote would > not be able to log each and every client request. > * A resolver should always request the public-view while resolving with > the first request within a specific zone and keep the received copy in > its cache until it expires. It SHOULD also provide an option to > revalidate/update such cached copies without having to wait for the next > lookup. > > Sincerely, > Klaus Frank > > _______________________________________________ > dns-privacy mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dns-privacy mailing list -- [email protected] To unsubscribe send an email to [email protected]
