<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3315 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3646 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC3489 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3489.xml">
<!ENTITY I-D.mglt-add-rdp SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-add-rdp.xml">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc docName="draft-mglt-add-rdp-isp-00" category="info">

  <front>
    <title abbrev="DRDP">DNS Resolver Discovery Protocol (DRDP)</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>

    <date year="2020" month="July" day="28"/>

    <area>ART</area>
    <workgroup>add</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The DNS Resolving service Discovery Protocol (DRDP) enables to discover resolving services available and eventually upgrade to an encrypted resolving service.</t>

<t>DRDP requires a resolving domain or a pointer to a list of resolving domains. 
Currently ISP or CPEs do not advertise resolving domain or pointers to resolving domains which does not make possible for a DNS client to discover potential resolving services - such as encrypted DNS for example - made available by the ISP.</t>

<t>Instead, ISPs or CPE advertise via DHCP the IP address of the host with a IA Address Option <xref target="RFC3315"/> and the IP addresses of the resolver provided by the ISP with Recursive Name Server option <xref target="RFC3646"/>.</t>

<t>This document describes a procedure for a DNS client to derive resolving domains from the legacy configuration of the host.</t>

<t>This is expected to ease the deployment of encrypted DNS from ISP as it will enable OS, applications to discover resolving service put in place by the ISP even though the CPE has not been upgraded.</t>



    </abstract>


  </front>

  <middle>


<section anchor="requirements-notation" title="Requirements Notation">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

</section>
<section anchor="sec-intro" title="Introduction">

<t>This document describes how a DNS client can discover resolving services made available by a network operator. 
The procedure requires minimal changes from the network operator and results in the encryption of a significant portion of the DNS traffic. 
The limitation relies on the CPE being upgraded to support encrypted DNS to resolve local scope names.</t>

<t>The considered architecture that is currently deployed is represented below.</t>

<t>In most architecture, the CPE co-hosts an authoritative server for the local zones (such as .home.arpa or .local) that are not represented in the global DNS architecture. 
The CPE in most common deployment works as a forwarder, that is, it responds to a query when it is either authoritative for the answer or the answer is in its cache. 
In any other case, the CPE resolves the query to the resolver of the ISP represented as (do53.isp.net).</t>

<t>In most architecture, OS and CPE are provisioned IP addresses via DHCP  IA Address Option <xref target="RFC3315"/>. This IP address is used for the connectivity purpose. 
Similarly, OS and CPE are provisioned IP addresses that are used to reach the resolving service provided by the network operator via the DHCP Recursive Name Server option <xref target="RFC3646"/>. These IP addresses may be local scope or global.</t>

<t>The application - such as a web browser - does not get provisioned via DHCP but is supposed to be able to access the IP addresses provisioned on the OS.</t>

<figure><artwork><![CDATA[
                          (proxied)
+------------------+       +-----+      +------------------+
| OS / application +-------+ CPE +------+ ISP do53.isp.net |
|                  |       +-----+      |                  |
|                  +--------------------+                  |
+------------------+     (direct)       +------------------+
]]></artwork></figure>

<t>When the network operator introduces a new resolving service such as providing a DoH resolving service for example, the network operator would like to make that server available to the OS, application and the CPE.
In the figure below, the new introduced service is designated as doh.isp.net and is expected to implement DoH.</t>

<figure><artwork><![CDATA[
                          (proxied)
+------------------+       +-----+      +------------------+
| OS / application +-------+ CPE +------+ ISP do53.isp.net |
|                  |       +-----+      |                  |
|                  +--------------------+                  |
+------------------+     (direct)       +------------------+

                                        +------------------+
                                        | ISP doh.isp.net  |
                                        +------------------+
]]></artwork></figure>

<t>Because not all DNS clients will be upgraded at the same time and that DNS client, the network operator will need to support both do53.isp.net and doh.isp.net. <vspace />
One possibility would be to co-host do53.isp.net and doh.isp.net with the same IP address. Such alternative is not considered in this document as in the long term it would require the network operator to co-host under the same IP address all different variant of the resolving services. This provides a to high contrail on the infrastructure.</t>

<t>Having the DNS client try and test what is actually supported is also not considered in this document either.</t>

<t>When the CPE cannot be upgraded, only the OS or application can discover and upgrade to the doh.isp.net.
Only application/OS that support the DRDP and this document will benefit from such upgrade. 
Maximization of encrypted DNS traffic is performed if the OS/application 1) sends the DNS queries that are resolved globally to doh.isp.net 2) limiting the DNS traffic to the CPE to the one associated to the local network.</t>

<figure><artwork><![CDATA[
                         (proxied)
+------------------+       +-----+      +------------------+
| OS / application +-------+ CPE + (----+ ISP do53.isp.net | )
|                  |       +-----+      +------------------+
|                  +====================+ ISP doh.isp.net  |
+------------------+     (direct)       +------------------+

]]></artwork></figure>

<t>When the CPE can be upgraded, it is expected that it implements a DoH resolver as well as a DNS client that implement this document. 
Since the DNS client of the CPE supports this specification, it is expected that the CPE will send its traffic only to doh.isp.net.
Since the CPE is also being upgraded to provide a DoH resolving service, OS and application are expected to be connected to the CPE using the DoH resolving service using the mechanism described in this document or other appropriated mechanism. Note that such communication while encrypted MAY NOT be authenticated.  <vspace />
Authentication MAY be provided is the homenetwork enables DNSSEC ( and the distribution of the Trust Anchor) or the certificate.</t>

<figure><artwork><![CDATA[
                          (proxied)
+------------------+       +-----+      +------------------+
| OS / application +=======+ CPE +==+ (-+ ISP do53.isp.net | )
|                  |       +-----+ ||   +------------------+
|                  +====================+ ISP doh.isp.net  |
+------------------+     (direct)       +------------------+

]]></artwork></figure>

</section>
<section anchor="ip-to-pointers" title="IP to Pointers">

<t>This document describe how to generate a pointer to resolving domains (Pointer) from the Interface address (IA) (<xref target="ia"/> ) as well as from the IP address of the resolvers <xref target="resolver"/> when these IP addresses are global.</t>

<section anchor="ia" title="RD Pointer from Interface Address (IA)">

<t>This section describes the procedure to derive resolving domains (RD) or RD Pointers from an Interface Address (IA), that is the IP or network assigned by the network operator to provide connectivity to the host.</t>

<t><list style="numbers">
  <t>Get a global IA: 
If the IA IP address is an IPv4 address of local scope, the DNS client establish the public IP address used by the network operator using appropriated mechanisms such as STUN <xref target="RFC3489"/> for example. 
The exchange SHOULD be protected by (D)TLS and the DNS client considers the mapped IP address as it global IA IP address. 
In any other case, the IA IP address is global.</t>
  <t>Proceed to a reverse resolution and consider the resulting domain (IA Pointer) as a Pointer</t>
  <t>DRDP <xref target="I-D.mglt-add-rdp"/> MAY be started from the resulting pointer. 
Optionally the DNS client MAY retrieve the RD to proceed to additional verifications - see <xref target="cross-verification"/>. Note that such conversion places a lot of trust into the STUN resolution when such resolution is required.</t>
</list></t>

</section>
<section anchor="resolver" title="RD Pointer from Resolver IP address">

<t>This section describes the procedure to derive RD from the IP address of the resolving service. 
The procedure only works when the resolver is provisioned with a global IP address and MAY not be applicable for some DNS client.</t>

<t><list style="numbers">
  <t>Proceed to a reverse resolution and consider the resulting domain (Resolver Pointer) as a Pointer.</t>
  <t>DRDP <xref target="I-D.mglt-add-rdp"/> MAY be started from the resulting pointer, however, it is recommended to retrieve the RD and proceed to additional steps described in <xref target="cross-verification"/>. Note that such conversion places a lot of trust into the DHCP provisioning.</t>
</list></t>

</section>
<section anchor="cross-verification" title="Cross Verification">

<t>When the discovery of the public IA involves a third party (or is not sufficiently protected), it is RECOMMENDED to derive the Pointer from Resolvers IP as described in <xref target="resolver"/> - when that is possible.</t>

<t>In that case, the following steps SHOULD be performed:</t>

<t><list style="numbers">
  <t>Retrieve RD (RD_IA) from the IA Pointer.</t>
  <t>Retrieve RD (RD_Resolver) from the Resolver Pointer.</t>
  <t>Consider the resolving domains shared by the two Pointers as provided by your network operator and other as independent resolving domains.</t>
</list></t>

</section>
<section anchor="configuration-expected-by-the-network-operator" title="Configuration expected by the network operator">

<t>The network operator is expected to update the forward zone of the CPE as follows:</t>

<figure><artwork><![CDATA[
b._dns.cpe_isp_fqdn.isp.net  PTR  resolver.isp.net
b._dns.cpe_isp_fqdn.isp.net  PTR  third_party_delegated_resolver.isp.net

]]></artwork></figure>

<t>The network operator is expected to update the zone that corresponds to the resolving domains as follws:</t>

<figure><artwork><![CDATA[
b._dns.resolver.isp.net  PTR  resolver.isp.net
b._dns.resolver.isp.net  PTR  third_party_delegated_resolver.isp.net
]]></artwork></figure>

</section>
</section>
<section anchor="security-consideration" title="Security Consideration">

<t>Rough STUN server</t>

<t>Rough DHCP</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC3315;
&RFC3646;
&RFC2119;
&RFC8174;
&RFC3489;


    </references>

    <references title='Informative References'>

&I-D.mglt-add-rdp;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAOvZIF8AA+1a23Ibtxm+36dArRtxJDKR7SSuZjotIzq1ZqxDRLmdXGnA
XVDEeLlYA7ukGVl5lj5Ln6zfD2CxWHJpOZP0cFFNMt4TfvyH7z+Cw+EwqWSV
i1M2uZyyG2FUvhKaTaRJFS427FqrSqUqZ4eTm8n1IOGzmRYrfI67JFNpwZdY
nGk+r4bL+7wa8iwb6qwcSlMOv/46SRKuBT9l45tblqzvTxnes+T9+pSdF5XQ
haiGE1qcpLw6ZbKYqyRJVSYLfFpX8+GrpJSnCWN6norMVBtidSMMwyPwFV/L
IhNFFZ4YpSst5qZ9sFl27yst0/b7VC2XWN++l0Uui3Y3yLrkZWkZs48SXlcL
pYk5+hvif39Ja0FnMmIX8p7XeRWeO21NeCFFvvNSaZB+DaaMUUV4CjaFAJuv
nn/3DbvVvDDsjBc84+xG1ZUI36Wy2pyyKZdFxd7yWkOWY/bjWfteZdj65ZR9
/f23LHpaF5XGQkczPBdLLnPY1XI6WjpO/yI8cyMoC5YdDoeMz8AgTyvc3i5E
hCIoihmhVzIV++HERMFnObRZKZb5j5jeXm8YX4Ed+pLxImNiBeFqnucbVpf3
mmeC1vMC1FK9KSuR7dIYwWC0Jd58qKUmmtFHmYK8BSyAp6WShExLkuXSVEzN
dz41oHdWa9IyuDifXtPas+vXBu9ZoSrAHKJU0ojeXfweVu4d0my9kOkCd2CS
SC35e4EVxkhSwNwySXpOc4ntO6orVYVHkud9ShwyU4MuN5GeiA5RFB/5sgT1
IXaDOlt9zzasgl0h4ShJzgtTCZ4d063xEkeSriQYe3N27VZck6uDDUP6oycL
BV2uZQUW2PmYjf3bq7KSqmAPD3+4+eHsxYuTbx4frZW7REQgo5sgVWq1khmE
aHl05G9EWmsjV4Jdwt/YFArA56qzz7cvv318JFDcLiQZLa3J+1kmTKrlzMID
9BFz4En9OoczrHata9hcq6XlJxf3PN3AxYq5vK81t9tHugi74z/xsRQpGQSU
BYcu6aNMlLnaWL6wbMtotAtJDHNKUmuee2diV9NjhkiVy9Ru+YRzsbKuEK9Y
mfM0Nrf1Mtyo+n5hn5GtF9xBcibwzvteNnKRYCmzLBdJcgD9Wxez4ZRdqsqy
4eLDe7Fha6Uzw55dvJvePjt2/7LLK3t98/rHd+c3ryd0PX0zfvs2XCT+i+mb
q3dvJ+1Vu/Ls6uLi9eXELcZT1nmUPLsY/4Q3hKxnV9e351eX47fPSPCqAwBk
K9LXTDDroaUWpHFukgYZGa35/uz6n/84eenB9Pzk5I8Arbt5dfLdS9ysF6Jw
u6kCEcLdQo2bBKYRXBMVRDCW8lJWPDfHZEizUOuCLYQW0CkUiRSpVVanDrgH
RqRDSY8e98MWFLpQTREXPxdad/2dM2RlGOk9XEYAtkoDqWS81iFCEF3KQi4R
btIFL+5FBP5tElYVWIE0YpzWRYNo7xacGXlfyDlgC7ZLpO/IX0gg5Jk53npm
crmUDlkgC1ERH4qA05kgGRuAkkFNXRLJLS8K4Rf0VAo5oKdS2DRtnHsK8l+D
MKMJBjpdyAqOSjqoFrwi101DGnD+SggxIAvoGDyn+CRytSZy5wVbUhCM6RwH
plM1pLBgKJO52sIKCN6Mi2AUhmxgsaz+rAoIfdjE9NFCLcWI65JTYB7ZbwaO
ScI0eW3MkzfBfa5moEW6iJnyOiaupOeZ6iNoOIpJZF9DW3PibM01lHTcqOWY
ohJ2K1WRGZdLP9RUAZAn0DsKegjWEKsrayMkCp01Re3OnbTYkdBRytMFsQmV
8mLDlKWUInK2+vSWNfaB2xx8dFKIRxeFu1g5kOkwU9+8GKGIHQHJg/3Gu5pa
ZNtEqIXLSQagBJVO8gq58YnUN2LWs6PsibvagFyjGOCxwO5yhYIPwVujMiBF
TOEPOdf55st5CuCw9K0vQKuRhjppYivb7jg4SWhdlaT8FSkYQDNbmX7JNxSB
Y5fEBg6rjVtGGS6qbDhbixmbabUG33geiqh7UXUUEewxqy0WbXzwasDWNhYS
atOUbLBTi8SkfNy5miJo//LLL6GG3v07xLKPUmSD5Gi483fkPzqK7/q+Sz6R
hb/qaOAoECGrHzU3BOwYyOwTFu/8ferbue+7vsU9HLaydBbvlfkwQy5Jq8F+
ikdWsUny94Uo+tEnfaq0lVsh1j0IbjDikExvAAH1pufLqCI+7t9ureo8Qw56
b1FiK3TrTT5St/nUR5ytmiwUuLDWiCILXdsqUbhs0Wy7bgXLAnuU+QUlS+6D
VaYWwcJEeauglCSIDdkQl/zn/yj9N6H0M1p9kp+jL178yWusNTr4/k07AxAM
uPhepBy5wDWweR6VkcZ1GIiMoagC2gmjhuJ7JZfCYxqP22X7vIdoFaJbmc2Q
w7swIIKRlCNwn1wVTS8sc0qAzhFn1tF8AfVZIq5DDIy3QX3EpjY+5DSVcqWI
dKkjKgB324VQzOYKAQRrl7Yds1z5KrlfBxG/dZEJ3ceTNUIm53NBFSZbcS25
awZ7c7TxxYNP1RQJsctCooGDDCifZd4kK1nMNTeVrl25lyRvuKXU1NpNn4ua
yZpVUOvuC16e+uGLt5wreNHDqCfV5Sq+URTIbeHLC9dUBnAdu67JRU47lomi
SKejIe6iIZBtmyPIAC+gE63+CvRcpPawsxLTYMjBN+bWQ74Qc5jUdjY2hfjt
EEgv+EdUXT+Hzn6ruXD9CikHRkdOWZJK5l6qr2KRTgawoS2Uvf6pXJVxieZL
1sxXQbmtZWNcPx+4lii2YsOBVwzp2l+icAF2jUol90mibSw8VJ9MFP+xPMEO
9+UJNvjiTLFn7934+Keev6O+iPvbMoUtaLbdoOsDvksKmdz6X9Wmc9MpYMgZ
EKYFMGsL4diN7cpQBXRQbluHIhXbru+DDDHmXcW4hQbs2C6dTNXPZLPQOhAB
27ZsDRqda6uun7Y82KbTx5PdPt7Htn2lW2h+OsUW/Ceuh2ahiWqhT7vWJjhP
b1nYvl8KGnhIs2SdsVA3fCBsubYUvGhVaudqYemIRmNN2UhxhTrsumiYXi9k
LqKIcjH+iWZdtjlBw0xj3pQIUlZkybh9RIvp41nUs0njp45gzCeiZvIOk09f
n7HDUJIitFaQqI7HL7e6RgIYFyka9UHTk6c09rVAEP/VojL4qA0WdHH4G4LF
p0//q8HCTgSvCbDX/vhg3xjQTgHx3T2sjWpDdE81dkfWh57goJ3f2dO5OY2E
m1rk8Hw8YIcPD5I/PrJBHGvaRTsz/yY0GTT9zbWfjtL77cafPLVt8w8O2M2k
EdZPvANb45ithwNw5bVhhJuXtjPRqjO7/Nzs/vBmYuHdbuulQ2ju3zoMvBoF
YHXjYkiwaNI+MzKJ4llnquNjkj0kSJKTEfsrFbLNsO58fMqScz+5Gm+NiojR
69XL2A7RGOV4O8qjrkMYkMaVxGWN6zSmaCdD+9h38bA/upnQbk9v3102I5+X
r2hQHrXXftAoProBMvNDfRe7Khehsf3hZHD7dhpCVDze9tWm0z+d0HamXP54
JGiuU/DvGx7uKLWF5PMRHWGmvnWhI0QCt4dSHVr7hqvGB+q8ig4AgRsWPM7m
6gbjSfJi5KrRh4c/nw8no/hIHZrzcR1Gs2V3cLx2C+/n4NUNF12p2NUZUdEC
QR7M23eAu4NiECzLpFvNIF/I9vYMUQgwl2r0YMP4HY3ydhJaQdohpdjTJZI0
V660sAkFrDqkW4xEOrTxwdKIHtqpuu2osj3RIfx+ITLfw0GIO786QID+k7Gt
e8bcPSZxRz92TN5EvLZYk90poj8YbZAaIbhwyd+3SD71NUfBBik9si0p5uR3
wWjQZS9SvS/8HlA9pmxFLDa1JNKh/S1G1gylu0gl3vuhaipRmm5F9rsj1c6M
g90gxsgi8Yx2YX+LdgHweraOSv4s/CjC46mJvmPstnInFzRRlxryQomIgko3
MwlTUykt3blTCJWDRoXR0WcEZ9qk11/cecOO6qKEPWwA7HJd82sEfy5iH7fx
c67yXK2tY1iLREG96YNPLUxvGtPCrEi9d5TKW4cLQXJEUNv+tuE9WrEN2RFF
07MtmG9lfLPguk1xSHBt4g+jYvd+o2rdf6zpq3waBWWiFPZ3SD2/GEkcUjo/
BwhtyZ4c6846dqfd3QFvXWa8El739iTOng7GPRyVadYs5tSVk7PRXQam0lLc
oUy9m3/IirZevb69YSFSNY+/YIlF651F610m6AcQ4PBuh5CvZ3+laFYkBzWl
46PFfst6ibcF3mbmCWH3fP6Fglo5D9iUTsOosGvA6H8RcWN/XGGTnzs4aB7Z
KAMN/QsYRJzkoCcAAA==

-->

</rfc>

