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?
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]
