Draft: draft-ietf-add-ddr

Commentary: Three changes Re - ordered statements in the abstract to place the restriction on unencrypted bootstrapping next to the unencrypted statement ( instead of after the encrypted bootstrapping statement , which makes the restriction seem like a conflict where it excludes bootstrapping from a name instead of an IP address ) Re - ordered security considerations ( placed the " clients can opt to do other things " statement at the end after the MUSTs / SHOULDs for this doc ) s / client / clients for grammatical correctness
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  This mechanism can be used to move from
unencrypted DNS to encrypted DNS when only the IP address of a
resolver is known.  It can also be used to discover support for
encrypted DNS protocols when the name of an encrypted resolver is
known.  This mechanism is designed to be limited to cases where
unencrypted resolvers and their designated resolvers are operated by
the same entity or cooperating entities.
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  This mechanism can be used to move from
unencrypted DNS to encrypted DNS when only the IP address of a
resolver is known.  This mechanism is designed to be limited to cases
where unencrypted resolvers and their designated resolvers are
operated by the same entity or cooperating entities.  It can also be
used to discover support for encrypted DNS protocols when the name of
an encrypted resolver is known.
Since client can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
packets.  Clients should be aware that it might not be possible to
distinguish between resolvers that do not have any Designated
Resolver and such an active attack.  To limit the impact of discovery
queries being dropped either maliciously or unintentionally, clients
can re-send their SVCB queries periodically.
Since clients can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
packets.  Clients should be aware that it might not be possible to
distinguish between resolvers that do not have any Designated
Resolver and such an active attack.  To limit the impact of discovery
queries being dropped either maliciously or unintentionally, clients
can re-send their SVCB queries periodically.
The constraints on validation of Designated Resolvers specified here
apply specifically to the automatic discovery mechanisms defined in
this documents, 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.
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.