Draft: draft-ietf-add-ddr

Commentary: This is an improvement . Watch for existing uses of " validated " though .
A resolver, presumably an Encrypted Resolver, designated by
another resolver for use in its own place.  This designation can
be authenticated with TLS certificates.
A resolver, presumably an Encrypted Resolver, designated by
another resolver for use in its own place.  This designation can
be verified with TLS certificates.
This document focuses on discovering DoH and DoT Designated
Resolvers.  Other protocols can also use the format defined by I-
D.ietf-add-svcb-dns.  However, if any protocol does not involve some
form of certificate validation, new validation mechanisms will need
to be defined to support validating designation as defined in
authenticated.
This document focuses on discovering DoH and DoT Designated
Resolvers.  Other protocols can also use the format defined by I-
D.ietf-add-svcb-dns.  However, if any protocol does not involve some
form of certificate validation, new validation mechanisms will need
to be defined to support validating designation as defined in
verified.
Authenticated Discovery authenticated, for when a TLS certificate
can be used to validate the resolver's identity.
Verified Discovery verified, for when a TLS certificate can be
used to validate the resolver's identity.
Authenticated Discovery is a mechanism that allows automatic use of a
Designated Resolver that supports DNS encryption that performs a TLS
handshake.
Verified Discovery is a mechanism that allows automatic use of a
Designated Resolver that supports DNS encryption that performs a TLS
handshake.
There are situations where authenticated discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on non-public IP addresses such as those
defined in RFC1918 whose identity cannot be confirmed using TLS
certificates.
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on non-public IP addresses such as those
defined in RFC1918 whose identity cannot be confirmed using TLS
certificates.
Operators who choose to forward queries for "resolver.arpa" upstream
should note that client behavior is never guaranteed and use of DDR
by a resolver does not communicate a requirement for clients to use
the SVCB record when it cannot be authenticated.
Resolver owners that support authenticated discovery will need to
list valid referring IP addresses in their TLS certificates.  This
may pose challenges for resolvers with a large number of referring IP
addresses.
Operators who choose to forward queries for "resolver.arpa" upstream
should note that client behavior is never guaranteed and use of DDR
by a resolver does not communicate a requirement for clients to use
the SVCB record when it cannot be verified.
Resolver owners that support Verified Discovery will need to list
valid referring IP addresses in their TLS certificates.  This may
pose challenges for resolvers with a large number of referring IP
addresses.
If the IP address of a Designated Resolver differs from that of an
Unencrypted Resolver, clients applying Authenicated Discovery
(authenticated) MUST validate that the IP address of the Unencrypted
Resolver is covered by the SubjectAlternativeName of the Designated
Resolver's TLS certificate.
The constraints on validation of Designated Resolvers specified here
apply specifically to the automatic discovery mechanisms defined in
this document, which are referred to as Authenticated Discovery and
Opportunistic Discovery.  Clients MAY use some other mechanism to
validate and use Designated Resolvers discovered using the DNS SVCB
record.  However, use of such an alternate mechanism needs to take
into account the attack scenarios detailed here.
If the IP address of a Designated Resolver differs from that of an
Unencrypted Resolver, clients applying Verified Discovery (verified)
MUST validate that the IP address of the Unencrypted Resolver is
covered by the SubjectAlternativeName of the Designated Resolver's
TLS certificate.
The constraints on the use of Designated Resolvers specified here
apply specifically to the automatic discovery mechanisms defined in
this document, which are referred to as Verified Discovery and
Opportunistic Discovery.  Clients MAY use some other mechanism to
verify and use Designated Resolvers discovered using the DNS SVCB
record.  However, use of such an alternate mechanism needs to take
into account the attack scenarios detailed here.