Draft: draft-ietf-add-ddr

Commentary: Thank you  , I still wonder about the use of " public address " . Is it defined as opposed of RFC 1918 private address ? How would ULA and IPv[46 ] qualify as they are not RFC 1918 ? -éric 
 RFC 1918 does define " public " Should we clarify further ? Do you have suggested text ? 
 [ Interesting that my email reply did not make it ] Tommy , I saw this text about “ public host ” but the DDR text is about “ public address ” I know that I am close to split hair ... but let ’s rather be explicit is a PS doc ;-) -éric 
 Thanks for the clarification ! I switched the text from " non - public addresses " to " private addresses " , since private addresses are explicitly defined in 1918 . ( It does actually mention public addresses , too , but less often ) 
 Thanks for the change , but what about ULA & LLA ? 
 I updated the text to include both private and local addresses , and references 
 Now , just to be complete , would you mind replying to my email ? So , I could proceed with IETF Last Call ( assuming SVCB and DNR also replied ) . 
  , I saw this text about “ public host ” but the DDR text is about “ public address ” I know that I am close to split hair ... but let ’s rather be explicit is a PS doc ;-) 
 LGTM
When DNS clients wish to use encrypted DNS protocols such as DNS-
over-TLS (DoT) RFC7858 or DNS-over-HTTPS (DoH) RFC8484, they require
additional information beyond the IP address of the DNS server, such
as the resolver's hostname, non-standard ports, or URL paths.
However, common configuration mechanisms only provide the resolver's
IP address during configuration.  Such mechanisms include network
provisioning protocols like DHCP RFC2132 and IPv6 Router
Advertisement (RA) options RFC8106, as well as manual configuration.
When DNS clients wish to use encrypted DNS protocols such as DNS-
over-TLS (DoT) RFC7858, DNS-over-QUIC (DoQ) RFC9250, or DNS-over-
HTTPS (DoH) RFC8484, they require additional information beyond the
IP address of the DNS server, such as the resolver's hostname, non-
standard ports, or URI templates.  However, common configuration
mechanisms only provide the resolver's IP address during
configuration.  Such mechanisms include network provisioning
protocols like DHCP RFC2132 RFC8415 and IPv6 Router Advertisement
(RA) options RFC8106, as well as manual configuration.
A DNS resolver using any encrypted DNS transport.  This includes
current mechanisms such as DoH and DoT as well as future
mechanisms.
A DNS resolver using TCP or UDP port 53.
A DNS resolver using any encrypted DNS transport.  This includes
current mechanisms such as DoH, DoT, and DoQ, as well as future
mechanisms.
A DNS resolver using TCP or UDP port 53 without encryption.
This document focuses on discovering DoH, DoT, and DoQ 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.
Because this query is for an SUDN, which no entity can claim
ownership over, the ServiceMode SVCB response MUST NOT use the "."
value for the TargetName.  Instead, the domain name used for DoT or
used to construct the DoH template MUST be provided.
Because this query is for an SUDN, which no entity can claim
ownership over, the ServiceMode SVCB response MUST NOT use the "."
value for the TargetName.  Instead, the domain name used for DoT/DoQ
or used to construct the DoH template MUST be provided.
Designated Resolvers SHOULD be accessible using the IP address
families that are supported by their associated Unencrypted
Resolvers.  If an Unencrypted Resolver is accessible using an IPv4
address, it ought to provide an A record for an IPv4 address of the
Designated Resolver; similarly, if it is accessible using an IPv6
address, it ought to provide a AAAA record an IPv6 address of the
Designated Resolver.  The Designated Resolver can supported more
address families than the Unencrypted Resolver, but it ought not to
support fewer.  If this is not done, clients that only have
connectivity over one address family might not be able to access the
Designated Resolver.
Opportunistic Discovery opportunistic, for when a resolver is
accessed using a non-public IP address.
Opportunistic Discovery opportunistic, for when a resolver's IP
address is a private or local address.
However, if a given Unencrypted Resolver designates a Designated
Resolver that uses a public IP address and can be verified using the
mechanism described in verified, it MAY be used on different network
connections so long as the subsequent connections over other networks
can also be successfully verified using the mechanism described in
verified.  This is a tradeoff between performance (by having no delay
in establishing an encrypted DNS connection on the new network) and
functionality (if the Unencrypted Resolver intends to designate
different Designated Resolvers based on the network from which
clients connect).
However, if a given Unencrypted Resolver designates a Designated
Resolver that does not use a private or local IP address and can be
verified using the mechanism described in verified, it MAY be used on
different network connections so long as the subsequent connections
over other networks can also be successfully verified using the
mechanism described in verified.  This is a tradeoff between
performance (by having no delay in establishing an encrypted DNS
connection on the new network) and functionality (if the Unencrypted
Resolver intends to designate different Designated Resolvers based on
the network from which clients connect).
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  A client MAY use information from the
SVCB record for "dns://resolver.arpa" with this "opportunistic"
approach (not validating the names presented in the
SubjectAlternativeName field of the certificate) as long as the IP
address of the Encrypted Resolver does not differ from the IP address
of the Unencrypted Resolver.  Clients SHOULD use this mode only for
resolvers using non-public IP addresses.  This approach can be used
for any encrypted DNS protocol that uses TLS.
There are situations where Verified Discovery of encrypted DNS
configuration over unencrypted DNS is not possible.  This includes
Unencrypted Resolvers on private IP addresses RFC1918, Unique Local
Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291,
whose identity cannot be confirmed using TLS certificates.
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "dns://resolver.arpa" with this "opportunistic" approach
(not validating the names presented in the SubjectAlternativeName
field of the certificate) as long as the IP address of the Encrypted
Resolver does not differ from the IP address of the Unencrypted
Resolver.  Clients SHOULD use this mode only for resolvers using
private or local IP addresses.  This approach can be used for any
encrypted DNS protocol that uses TLS.
A DNS client that already knows the name of an Encrypted Resolver can
use DDR to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted Resolver alongside the resolver IP address.
A DNS client that already knows the name of an Encrypted Resolver can
use DDR to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted Resolver alongside the resolver IP address, such as
by using Discovery of Network Resolvers (DNR) I-D.ietf-add-dnr.
Clients MUST NOT use "resolver.arpa" as the server name either in the
TLS Server Name Indication (SNI) (RFC8446) for DoT or DoH
connections, or in the URI host for DoH requests.
Clients MUST NOT use "resolver.arpa" as the server name either in the
TLS Server Name Indication (SNI) (RFC8446) for DoT, DoQ, or DoH
connections, or in the URI host for DoH requests.
Note that since IP addresses are not supported by default in the TLS
SNI, resolvers that support discovery using IP addresses will need to
be configured to present the appropriate TLS certificate when no SNI
is present for both DoT and DoH.
Note that since IP addresses are not supported by default in the TLS
SNI, resolvers that support discovery using IP addresses will need to
be configured to present the appropriate TLS certificate when no SNI
is present for DoT, DoQ, and DoH.