<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
    <!ENTITY RFC8484 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8484.xml'>
        <!ENTITY RFC7858 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7858.xml'>
        <!ENTITY I-D.ietf-dprive-dnsoquic PUBLIC '' 'https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dprive-dnsoquic.xml'>
        <!ENTITY RFC5730 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml'>
        <!ENTITY RFC5731 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml'>
        <!ENTITY RFC5732 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5732.xml'>
        <!ENTITY RFC5733 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5733.xml'>
        <!ENTITY RFC7451 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7451.xml'> 
	    <!ENTITY RFC7942 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml'>
		<!ENTITY RFC8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-zhang-add-requirement-discusses-00" ipr="trust200902">
    <!-- category values: info, bcp, info, exp, and historic -->
    <front>
        <title abbrev="Discussion of Requirements for ADD">Discussion of Requirements for ADD</title>
        <author fullname="Man Zhang" initials="M" surname="Zhang">
            <organization></organization>
            <address>
                <postal>
                    <street>4 South 4th Street, Zhongguancun, Haidian District</street>
                    <city>Beijing</city>
                    <region>Beijing</region>
                    <code>100190</code>
                    <country>China</country>
                </postal>
                <email>zhangman@cnnic.cn</email>
            </address>
        </author>
        
        <date day="25" month="December" year="2020" />
        <area>Internet</area>
        <workgroup>Internet Engineering Task Force</workgroup>
		
        <keyword>add</keyword>
        <abstract>
		<!-- This document describes an Extensible Provisioning Protocol (EPP) for provisioning and management of registry organization extensions for domain names, hosts and contacts stored in a shared central repository.-->
            <t>
			This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology.</t>
        </abstract>
    </front>
	
    <middle>
        <section title="Introduction">
            <t>Several DNS encryption technologies have been introduced, including DNS-over-TLS and DNS-over-HTTPS and so on. The work of the Adaptive DNS Discovery working group includes supporting client discovery of encrypted DNS resolution services and communication mechanisms for selection decisions.
			</t>
			<t>Since the proposal of the draft plan should be guided by the existing problems, the working group should first reach a consensus on the problems to be solved and the principles applicable to each problem, and then promote follow-up work on this basis.
			</t>
			<t>This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology.</t>
			
        </section>
        <section title="Conventions Used in This Document">
            <t>Encrypted DNS: DNS-over-HTTPS<xref target="RFC8484"></xref>, DNS-over-TLS<xref target="RFC7858"></xref> or any other encrypted DNS technology that the IETF may publish, for example, DNS-over-QUIC <xref target="I-D.ietf-dprive-dnsoquic"></xref>.
			</t>
		</section>
        <section title="Discover and use of encrypted DNS services">
            <t>The DNS client accesses the recursive server with discovery function, and the discussion is divided into the following situations:</t>
            
			    <section title="The client automatically obtains DNS resolution service">
                    <t>1) Ordinary DNS resolution service</t>
					<t>The client can automatically obtain the common DNS recursive resolution server address through DHCP.</t>
					<t>2) Encrypted DNS resolution service</t>
					<t>The client can choose several types of encryption resolution services currently provided (such as DOH/DOT, etc.), and accept the default configuration of the recursive server. 
					</t>
					<t>The encrypted DNS recursive resolution server address can be automatically set through DHCP/RA/PPP and other protocols.
					</t>
				</section>
				<section title="The client has been configured with parameters">
                    <t>If the client has been configured with parameters, the following two aspects are initially considered for configuration parameters:</t>
					<t>1) For general DNS resolution services, the client can update and configure the encrypted DNS recursive resolution server type and address. This method is suitable for common networks and specific networks.
					</t>
					<t>2) Users can set to use the specified encrypted DNS resolution service when accessing certain specific domain names. Set up a list of mapping relationships between domain names and DNS resolution service addresses.
					</t>
				</section>
				<section title="Configuration examples">
				    <figure>
                        <artwork>
                        <![CDATA[
*Normal DNS resolution (single choice)
  -Obtain DNS server address automatically (single choice)
  -Use the following DNS server address (single choice)
    First choice: ____._____.____.____
    Alternative: ____._____.____.____
	
*Encrypted DNS resolution (single choice)
  -Type: DOT/DOH
  -Obtain DNS server address automatically (single choice)
  -Use the following encrypted DNS server address (single choice)
    First choice: ____._____.____.____
    Alternative: ____._____.____.____

 ]]>
                        </artwork>
                    </figure>	
					<figure>
                        <artwork>
                        <![CDATA[

Domain name       Type     Address
www.google.com    DOT      xxx.xxx.xxx.xxx
                        ]]>
                        </artwork>
                    </figure>	
                    
				</section>
            <!--removed<section title="Organization Name">
                <t>Organization name provides the name of the organization. Its corresponding element is &lt;orgext:name&gt; which refers to the &lt;org:name&gt; element defined in <xref target="ID.draft-ietf-regext-org"></xref>.</t>
            </section>-->
        </section>
        <section title="Encrypted DNS resolution service list">
            
            <section title="Provide a public encrypted DNS resolution service address list">
                <t>We can provide an encrypted DNS recursive resolution server address list, which can be publicly maintained and updated regularly. The priority of selecting an encrypted DNS resolver is determined by the server's own design. Currently Mozilla maintains a similar list relationship.</t>
			</section>
			
            <section title="Provide encrypted DNS resolution configuration for some specific domain names">
                <t>If some companies or institutions want to use their own encrypted DNS resolution service when accessing their own domain names, they will provide the resolution server through the mapping relationship.
				</t>
				
			</section> 
           
        </section>
        
        <section title="IANA Considerations" anchor="Iana">
            <t>To be added.</t> 
        </section>
		
        <section title="Security Considerations" anchor="security">
            <t>To be added.</t>
        </section>
		<section title="Acknowledgment" anchor="acknowledgment">
			<t>The authors would like to thank Jiankang Yao, and Linlin Zhou for their careful review and valuable comments.</t>
		</section>
    </middle>
    <back>
        
	<references title="Informative References">
		&RFC8484; 
		&RFC7858; 
		&I-D.ietf-dprive-dnsoquic;
		
			<!--<reference anchor="ID.draft-ietf-regext-reseller-ext"
		   target='http://tools.ietf.org/html/draft-ietf-regext-reseller-ext'>
				<front>
					<title>Extensible Provisioning Protocol (EPP) Reseller Mapping</title>
					<author initials="L" surname="Zhou" fullname="Linlin Zhou">
						 <organization>CNNIC</organization>
					</author>
					<author initials="N" surname="Kong" fullname="Ning kong">
						 <organization>CNNIC</organization>
					</author>
					<author initials="J" surname="Wei" fullname="Junkai Wei">
						 <organization>CNNIC</organization>
					</author>
					<author initials="X" surname="Lee" fullname="Xiaodong Lee">
						 <organization>CNNIC</organization>
					</author>
					<author initials="J" surname="Gould" fullname="James Gould">
						 <organization>Verisign, Inc.</organization>
					</author>
					<date month="Dec" year="2016"/>
				</front>
			</reference>-->
		</references>
		
    </back>
</rfc>