mimuret/draft-sonoda-lb-rr-00

## draft-sonoda-lb-rr-00
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
     The next line defines an entity named RFC2629, which contains the necessary XML
     for the reference element, and is used much later in the file.  This XML contains an
     anchor (also RFC2629) which can be used to cross-reference this item in the text.
     You can also use local file names instead of a URI.  The environment variable
     XML_LIBRARY provides a search path of directories to look at to locate a
     relative path name for the file. There has to be one entity for each item to be
     referenced. -->
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!-- There is also a library of current Internet Draft citations.  It isn't a good idea to
     actually use one for the template because it might have disappeared when you come to test
     this template.  This is the form of the entity definition
     &lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM
     "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs.xml">
     corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation will be
     to the most recent draft in the sequence, and is updated roughly hourly on the web site.
     For working group drafts, the same principle applies: file name starts draft-ietf-wgname-..
     and entity file is reference.I-D.ietf-wgname-...  The corresponding entity name is
     I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example).  Of course this doesn't
     change when the draft version changes.
     -->
<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp    "&#160;">
]>

<rfc category="info" docName="draft-sonoda-lb-rr-00">
  <front>
    <title abbrev="Abbreviated Title">Redirect RR</title>

    <author fullname="Manabu Sonoda" role="editor" surname="Sonoda">
      <organization>Internet Initiative Japan Inc.</organization>
      <address>
        <email>manbabu-s@iij.ad.jp</email>
      </address>
    </author>

    <date month="Jan" year="2018" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Domain Name System Operations</workgroup>
    <keyword>DNS</keyword>
    <abstract>
      <t>本文書は「LB」という新しいリソースレコードを定義する。LBは、A,AAAAのバランシング機能を提供する。</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        本文書は「LB」という新しいリソースレコードを定義する。
        LBは、A,AAAAのバランシング機能を別ドメイン名へのリダイレクトと共に提供する。
      </t>
    </section>
    <section title='Motivation'>
        現在のDNSの仕様では、A,AAAA RRはアドレス情報のみを持っており、その利用に際しアドレスごとの重み付けをすることは困難である。
        現在多く行われている手法は、非標準の方法として、Authoritative Server側で、重み付けを考慮して選択した一つのRRを返す手法である。
        これは、非標準の方法であるため、ゾーン転送機能によって重み付け情報をセカンダリサーバへ転送することができない。
        また、DNSSEC署名の観点からもOnline署名が必要になってくるため、全てのセカンダリサーバで署名鍵を持つ必要がある。

        また、実際のRRを利用するクライアントのネットワーク的な位置により、利用させたいRRを変更したいレコードも存在する。。
        重み付け同様に、現在のDNSの仕様では、A,AAAAにネットワーク的な位置情報を含めることはできない。
        現在多く行われている手法は、非標準の方法として、問い合わせを行うクライアントのIPアドレスを元に、Authoritative Server側が
        A, AAAAレコード応答を変える手法である。
        A,AAAAとネットワーク的な位置情報のマッピングはゾーン外の機能として実装されている為、セカンダリサーバに転送することができない。

        これらの問題点を解決する為、特殊なレコードとしてLBレコードを定義する。
        このレコードを使用すれば、DNS Provider実装に依存しないGlobal Load BalancingとLocal Balancingが提供できるようになります。
      </t>
    </section>

    <section title="The LB Resource Record">
      <t>LBリソースレコードのニーモニックはLBである。</t>
      <t>LBの書式を示す</t>
        <artwork align="left"><![CDATA[
                <owner> <ttl> <class> LB <rrtype> <weight> <geocode> <target>
            ]]></artwork>
      <t>この書式には、クラスの区別はなく、全てが必須フィールドである。</t>
      <t>RDATAの各要素は、以下の通り</t>
      <list>
        <t>&lt;rrtype&gt; field is a two octets, A or AAAA RRType.</t>
        <t>&lt;weight&gt; field is a 2 octets, 1 or more natural number.</t>
        <t>&lt;geocode&gt; field is a 2 octets, natural number ISO 3166-1 alpha-2 Country code
           or Continental code that AF,AN,AS,EU,NA,OC and SA
           or "0" meen all countries.</t>
        <t>&lt;target&gt; field is a &lt;domain-name&gt; [RFC1035]</t>
      </list>
    </section>
    <section title="The LB Support Flag">
      <t>Full resolverが、権威DNSに対して、LBをサポートしている事を伝える為、EDNS Header Flagsとして、LB Supportを定義する（LS)</t>
    </section>

    <section title="Authoritative Server Behavior">
      <t>Authoritative Serverに問い合わせたクエリーの中にLSが含まれている場合に以下の特別の動作を行う。</t>
      <t>qnameが一致するLBが存在し、qtype = &lt;rrtype&gt;であるLBが存在する場合は、ANSWER SECTIONとして、LB RRSETを追加する。
         この際、そのLBの&lt;target&gt;、&lt;rrtype&gt;が一致するRRがある場合でも、ANSWER SECTIONに追加してはならない。
         また、qname、qtypeに一致するRRがある場合もANSWER SECTIONに追加してはならない。
         DNSSEC署名がされている場合は、LBに対するRRSIGを返す
      </t>
      <t>Authoritative Server側で、ゾーン情報の変更、RRSETの一部応答などは行わない為、DNSSEC署名をセカンダリサーバで行う必要はない。</t>
    </section>

    <section title="Full Service Resolver Behavior">
        <list style="numbers">
          <t>スタブリゾルバからA,AAAAのクエリーを受け取る</t>
          <t>ResolverがLB RRに対応している場合、クエリーにLSを付加して問い合わせを行う。</t>
          <t>qtype=A,AAAAのレスポンスとして、ANSWER SECTIONにLB RRSetが含まれている場合特別の動作を行う。</t>
          <t>DNSSEC署名されている場合は、LB RRSetに対して、署名検証を行う。失敗（Bogus)の場合はスタブリゾルバに
             SERVFAILを返し処理を終了する。</t>
          <t>LB RRSetから、qtype = &lt;rrtype&gt;であるLB RRを選択する。</t>
          <t>&lt;geocode&gt;が0でない場合は、&lt;geocode&gt;を使用して、さらにLB RRを絞り込む。
          <t>（実装依存だが、リゾルバ自身に設定された、ネットワーク的な位置情報で絞り込むことを想定、またスタブリゾルバのIPをGeoIP Databaseを用いて位置情報を割り出し
            それに基づいて絞り込むことも可能）</t>
          </t>
          <t>qtype = &lt;rrtype&gt;であるLB RRが複数ある場合は、&lt;weight&gt;に従って、レスポンスとして返す&lt;target&gt;を選択する。
             &lt;weight&gt;は値が大きい方が優先で、比率によって、選択する&lt;target&gt;を変化させるのを期待する。</t>
          <t>選択した&lt;target&gt;をqname、&lt;rrtype&gt;をqtypeとして、”名前解決”する。名前解決の結果、qtypeが一致するRRSetが
             得られない場合、5に戻って別の&lt;target&gt;を選択する。全ての&lt;target&gt;で失敗した場合は8に飛ぶ。</t>
          <t>ターゲットを名前解決した結果を署名検証する。失敗（Bogus)の場合は、5に戻って別の&lt;target&gt;を選択する。
             全ての&lt;target&gt;で失敗した場合は8に飛ぶ。</t>
          <t>スタブリゾルバの応答として、LB RRsetをANSWER SECTIONに追加する。ターゲットを名前解決の結果、
             qtypeが一致するRRが得らた場合は、その名前解決の結果をANSWER SECTIONに追加する。また、LB RRSETと
            ターゲットが共に署名検証に成功していればAD BITを付ける。</t>
        </list>
    </section>

    <section title="IANA Considerations">
      <t>IANA is requested to assign a DNS RR data type value for the LB RR type under
         the "Resource Record (RR) TYPEs" subregistry and
         a EDNS Header Flag value fro the LB Support Flag under
         the "EDNS Header Flags (16 bits)" subregistry
         under the "Domain Name System (DNS) Parameters" registry.</t>
    </section>

    <section title="Security Considerations">
      <t>リゾルバでは、LBの&lt;target&gt;のレスポンスとして、LB,CNAME,DNAMEが返ってくることもある。その場合、多段で名前解決を行うことになるため、limitを描けるなどloopしないように注意する必要がある。</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
  </back>
</rfc>
	<?xml version="1.0" encoding="UTF-8"?>
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
	The next line defines an entity named RFC2629, which contains the necessary XML
	for the reference element, and is used much later in the file. This XML contains an
	anchor (also RFC2629) which can be used to cross-reference this item in the text.
	You can also use local file names instead of a URI. The environment variable
	XML_LIBRARY provides a search path of directories to look at to locate a
	relative path name for the file. There has to be one entity for each item to be
	referenced. -->
	<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
	<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
	<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
	<!-- There is also a library of current Internet Draft citations. It isn't a good idea to
	actually use one for the template because it might have disappeared when you come to test
	this template. This is the form of the entity definition
	<!ENTITY I-D.mrose-writing-rfcs SYSTEM
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs.xml">
	corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation will be
	to the most recent draft in the sequence, and is updated roughly hourly on the web site.
	For working group drafts, the same principle applies: file name starts draft-ietf-wgname-..
	and entity file is reference.I-D.ietf-wgname-... The corresponding entity name is
	I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example). Of course this doesn't
	change when the draft version changes.
	-->
	<!-- Fudge for XMLmind which doesn't have this built in -->
	<!ENTITY nbsp " ">
	]>

	<rfc category="info" docName="draft-sonoda-lb-rr-00">
	<front>
	<title abbrev="Abbreviated Title">Redirect RR</title>

	<author fullname="Manabu Sonoda" role="editor" surname="Sonoda">
	<organization>Internet Initiative Japan Inc.</organization>
	<address>
	<email>manbabu-s@iij.ad.jp</email>
	</address>
	</author>

	<date month="Jan" year="2018" />

	<!-- Meta-data Declarations -->

	<area>General</area>

	<workgroup>Domain Name System Operations</workgroup>
	<keyword>DNS</keyword>
	<abstract>
	<t>本文書は「LB」という新しいリソースレコードを定義する。LBは、A,AAAAのバランシング機能を提供する。</t>
	</abstract>
	</front>

	<middle>
	<section title="Introduction">
	<t>
	本文書は「LB」という新しいリソースレコードを定義する。
	LBは、A,AAAAのバランシング機能を別ドメイン名へのリダイレクトと共に提供する。
	</t>
	</section>
	<section title='Motivation'>
	現在のDNSの仕様では、A,AAAA RRはアドレス情報のみを持っており、その利用に際しアドレスごとの重み付けをすることは困難である。
	現在多く行われている手法は、非標準の方法として、Authoritative Server側で、重み付けを考慮して選択した一つのRRを返す手法である。
	これは、非標準の方法であるため、ゾーン転送機能によって重み付け情報をセカンダリサーバへ転送することができない。
	また、DNSSEC署名の観点からもOnline署名が必要になってくるため、全てのセカンダリサーバで署名鍵を持つ必要がある。

	また、実際のRRを利用するクライアントのネットワーク的な位置により、利用させたいRRを変更したいレコードも存在する。。
	重み付け同様に、現在のDNSの仕様では、A,AAAAにネットワーク的な位置情報を含めることはできない。
	現在多く行われている手法は、非標準の方法として、問い合わせを行うクライアントのIPアドレスを元に、Authoritative Server側が
	A, AAAAレコード応答を変える手法である。
	A,AAAAとネットワーク的な位置情報のマッピングはゾーン外の機能として実装されている為、セカンダリサーバに転送することができない。

	これらの問題点を解決する為、特殊なレコードとしてLBレコードを定義する。
	このレコードを使用すれば、DNS Provider実装に依存しないGlobal Load BalancingとLocal Balancingが提供できるようになります。
	</t>
	</section>

	<section title="The LB Resource Record">
	<t>LBリソースレコードのニーモニックはLBである。</t>
	<t>LBの書式を示す</t>
	<artwork align="left"><![CDATA[
	<owner> <ttl> <class> LB <rrtype> <weight> <geocode> <target>
	]]></artwork>
	<t>この書式には、クラスの区別はなく、全てが必須フィールドである。</t>
	<t>RDATAの各要素は、以下の通り</t>
	<list>
	<t><rrtype> field is a two octets, A or AAAA RRType.</t>
	<t><weight> field is a 2 octets, 1 or more natural number.</t>
	<t><geocode> field is a 2 octets, natural number ISO 3166-1 alpha-2 Country code
	or Continental code that AF,AN,AS,EU,NA,OC and SA
	or "0" meen all countries.</t>
	<t><target> field is a <domain-name> [RFC1035]</t>
	</list>
	</section>
	<section title="The LB Support Flag">
	<t>Full resolverが、権威DNSに対して、LBをサポートしている事を伝える為、EDNS Header Flagsとして、LB Supportを定義する（LS)</t>
	</section>

	<section title="Authoritative Server Behavior">
	<t>Authoritative Serverに問い合わせたクエリーの中にLSが含まれている場合に以下の特別の動作を行う。</t>
	<t>qnameが一致するLBが存在し、qtype = <rrtype>であるLBが存在する場合は、ANSWER SECTIONとして、LB RRSETを追加する。
	この際、そのLBの<target>、<rrtype>が一致するRRがある場合でも、ANSWER SECTIONに追加してはならない。
	また、qname、qtypeに一致するRRがある場合もANSWER SECTIONに追加してはならない。
	DNSSEC署名がされている場合は、LBに対するRRSIGを返す
	</t>
	<t>Authoritative Server側で、ゾーン情報の変更、RRSETの一部応答などは行わない為、DNSSEC署名をセカンダリサーバで行う必要はない。</t>
	</section>

	<section title="Full Service Resolver Behavior">
	<list style="numbers">
	<t>スタブリゾルバからA,AAAAのクエリーを受け取る</t>
	<t>ResolverがLB RRに対応している場合、クエリーにLSを付加して問い合わせを行う。</t>
	<t>qtype=A,AAAAのレスポンスとして、ANSWER SECTIONにLB RRSetが含まれている場合特別の動作を行う。</t>
	<t>DNSSEC署名されている場合は、LB RRSetに対して、署名検証を行う。失敗（Bogus)の場合はスタブリゾルバに
	SERVFAILを返し処理を終了する。</t>
	<t>LB RRSetから、qtype = <rrtype>であるLB RRを選択する。</t>
	<t><geocode>が0でない場合は、<geocode>を使用して、さらにLB RRを絞り込む。
	<t>（実装依存だが、リゾルバ自身に設定された、ネットワーク的な位置情報で絞り込むことを想定、またスタブリゾルバのIPをGeoIP Databaseを用いて位置情報を割り出し
	それに基づいて絞り込むことも可能）</t>
	</t>
	<t>qtype = <rrtype>であるLB RRが複数ある場合は、<weight>に従って、レスポンスとして返す<target>を選択する。
	<weight>は値が大きい方が優先で、比率によって、選択する<target>を変化させるのを期待する。</t>
	<t>選択した<target>をqname、<rrtype>をqtypeとして、”名前解決”する。名前解決の結果、qtypeが一致するRRSetが
	得られない場合、5に戻って別の<target>を選択する。全ての<target>で失敗した場合は8に飛ぶ。</t>
	<t>ターゲットを名前解決した結果を署名検証する。失敗（Bogus)の場合は、5に戻って別の<target>を選択する。
	全ての<target>で失敗した場合は8に飛ぶ。</t>
	<t>スタブリゾルバの応答として、LB RRsetをANSWER SECTIONに追加する。ターゲットを名前解決の結果、
	qtypeが一致するRRが得らた場合は、その名前解決の結果をANSWER SECTIONに追加する。また、LB RRSETと
	ターゲットが共に署名検証に成功していればAD BITを付ける。</t>
	</list>
	</section>

	<section title="IANA Considerations">
	<t>IANA is requested to assign a DNS RR data type value for the LB RR type under
	the "Resource Record (RR) TYPEs" subregistry and
	a EDNS Header Flag value fro the LB Support Flag under
	the "EDNS Header Flags (16 bits)" subregistry
	under the "Domain Name System (DNS) Parameters" registry.</t>
	</section>

	<section title="Security Considerations">
	<t>リゾルバでは、LBの<target>のレスポンスとして、LB,CNAME,DNAMEが返ってくることもある。その場合、多段で名前解決を行うことになるため、limitを描けるなどloopしないように注意する必要がある。</t>
	</section>

	</middle>

	<!-- ***BACK MATTER *** -->

	<back>
	<section anchor="app-additional" title="Additional Stuff">
	<t>This becomes an Appendix.</t>
	</section>
	</back>
	</rfc>