[要約] RFC 8501は、IPv6におけるインターネットサービスプロバイダーの逆DNSに関するガイドラインです。このRFCの目的は、IPv6ネットワークでの逆DNSの実装と運用に関するベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) L. Howard
Request for Comments: 8501 Retevia
Category: Informational November 2018
ISSN: 2070-1721
Reverse DNS in IPv6 for Internet Service Providers
インターネットサービスプロバイダーのIPv6での逆引きDNS
Abstract
概要
In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.
IPv4では、インターネットサービスプロバイダー（ISP）は通常、利用可能なすべてのアドレスに対して1つのPTRレコードをゾーンに事前設定することにより、顧客にIN-ADDR.ARPA情報を提供します。この手法はIPv6では拡張されません。このドキュメントでは、IP6.ARPAゾーンの管理におけるISPのさまざまなアプローチと考慮事項を分析します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8501.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8501で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Wildcard Match . . . . . . . . . . . . . . . . . . . . . 5
2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Dynamically Generate PTR When Queried ("On the Fly") . . 9
3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations and Recommendations . . . . . . . . . . . . . 10
5. Security and Privacy Considerations . . . . . . . . . . . . . 11
5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5.3. Considerations for Other Uses of the DNS . . . . . . . . 12
5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 12
5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
[RFC1912] recommended that "every Internet-reachable host should have a name" and says "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all". While the need for a PTR record and for it to match is debatable as a best practice, some network services (see Section 4) still do rely on PTR lookups, and some check the source address of incoming connections and verify that the PTR and A records match before providing service.
[RFC1912]は、「すべてのインターネット到達可能ホストに名前を付ける必要がある」ことを推奨し、「PTRレコードとAレコードが一致しないと、DNSにまったく登録されていないのと同様にインターネットサービスが失われる可能性がある」と述べています。 PTRレコードと一致する必要性はベストプラクティスとして議論の余地がありますが、一部のネットワークサービス（セクション4を参照）は依然としてPTRルックアップに依存しており、着信接続のソースアドレスをチェックして、PTRとAレコードはサービスを提供する前に一致します。
Individual Internet users on the residential or consumer scale, including small and home businesses, are constantly connecting to or moving around the Internet. For large ISPs who serve residential users, maintenance of individual PTR records is impractical.
小規模およびホームビジネスを含む、住宅規模または消費者規模の個々のインターネットユーザーは、常にインターネットに接続している、またはインターネット上を移動しています。住宅ユーザーにサービスを提供する大規模ISPの場合、個々のPTRレコードの保守は非現実的です。
Administrators at ISPs should consider whether customer PTR records are needed, and if so, evaluate methods for responding to reverse DNS queries in IPv6.
ISPの管理者は、顧客のPTRレコードが必要かどうかを検討し、必要な場合は、IPv6の逆DNSクエリに応答する方法を評価する必要があります。
ISPs that provide access to many residential users typically assign one or a few IPv4 addresses to each of those users and populate an IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some ISPs also configure forward zones with matching A records so that lookups match. For instance, if an ISP Example.com aggregated 192.0.2.0/24 at a network hub in one region, the reverse zone might look like:
多くの住宅ユーザーにアクセスを提供するISPは、通常、各ユーザーに1つまたはいくつかのIPv4アドレスを割り当て、IPv4アドレスごとに1つのPTRレコードをIN-ADDR.ARPAゾーンに設定します。一部のISPでは、ルックアップが一致するように、一致するAレコードでフォワードゾーンも構成します。たとえば、ISP Example.comが1つのリージョンのネットワークハブで192.0.2.0/24を集約した場合、逆ゾーンは次のようになります。
1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
1.2.0.192.IN-ADDR.ARPA。 IN PTR 1.string.region.example.com。
2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
2.2.0.192.IN-ADDR.ARPA。 IN PTR 2.string.region.example.com。
3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
3.2.0.192.IN-ADDR.ARPA。 IN PTR 3.string.region.example.com。
.
。
.
。
.
。
254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
254.2.0.192.IN-ADDR.ARPA。 IN PTR 254.string.region.example.com。
The conscientious Example.com might then also have a zone:
良心的なExample.comにもゾーンがある場合があります。
1.string.region.example.com. IN A 192.0.2.1
1.string.region.example.com。 A 192.0.2.1
2.string.region.example.com. IN A 192.0.2.2
2.string.region.example.com。 IN 192.0.2.2
3.string.region.example.com. IN A 192.0.2.3
3.string.region.example.com。 IN 192.0.2.3
.
。
.
。
.
。
254.string.region.example.com. IN A 192.0.2.254
254.string.region.example.com。 IN 192.0.2.254
Many ISPs generate PTR records for all IP addresses used for customers, and many create the matching A record.
多くのISPは、顧客に使用されるすべてのIPアドレスのPTRレコードを生成し、多くのISPは一致するAレコードを作成します。
A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
2001：0db8：0f00：0000：0012：34ff：fe56：789aのサンプルエントリは次のようになります。
a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2 .IP6.ARPA. IN PTR 1.string.region.example.com.
a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2 .IP6.ARPA。 IN PTR 1.string.region.example.com。
ISPs will often delegate an IPv6 prefix to their customers. Since 2^^80 possible addresses could be configured in a single /48 zone alone, it is impractical to write a zone with every possible address entered, even with automation. If 1000 entries could be written per second, the zone would still not be complete after 38 trillion years.
ISPは多くの場合、IPv6プレフィックスを顧客に委任します。 2 ^^ 80の可能なアドレスを単一の/ 48ゾーンだけで構成できるため、自動化を使用しても、すべての可能なアドレスを入力してゾーンを書き込むことは現実的ではありません。 1秒あたり1000のエントリを書き込むことができる場合、ゾーンは38兆年後もまだ完成していません。
Furthermore, it is often impossible to associate hostnames and addresses, since the 64 bits in the Interface Identifier portion of the address are frequently assigned using Stateless Address Autoconfiguration (SLAAC) [RFC4862] when the host comes online, and they may be short-lived.
さらに、ホストがオンラインになると、アドレスのインターフェイス識別子部分の64ビットがステートレスアドレス自動構成（SLAAC）[RFC4862]を使用して頻繁に割り当てられ、それらが短命になる可能性があるため、ホスト名とアドレスを関連付けることはしばしば不可能です。 。
[RFC1912] is an Informational RFC that says "PTR records must point back to a valid A record" and further that the administrator should "Make sure your PTR and A records match." Herein are considerations for how to follow this advice for AAAA and PTR records.
[RFC1912]は、「PTRレコードは有効なAレコードを指し示す必要がある」という情報RFCであり、管理者は「PTRレコードとAレコードが一致していることを確認する」必要があるとしています。ここに、AAAAおよびPTRレコードに関するこのアドバイスに従う方法に関する考慮事項があります。
Several options exist for providing reverse DNS in IPv6. All of these options also exist for IPv4, but the scaling problem is much less severe in IPv4. Each option should be evaluated for its scaling ability, compliance with existing standards and best practices, and availability in common systems.
IPv6でリバースDNSを提供するには、いくつかのオプションがあります。これらのオプションはすべてIPv4にも存在しますが、IPv4ではスケーリングの問題はそれほど深刻ではありません。各オプションは、スケーリング能力、既存の標準とベストプラクティスへの準拠、および一般的なシステムでの可用性について評価する必要があります。
Some ISP DNS administrators may choose to provide only an NXDOMAIN response to PTR queries for subscriber addresses. In some ways, this is the most accurate response, since no name information is known about the host. However, providing a negative response to PTR queries does not satisfy the expectation in [RFC1912] for entries to match. Users of services that are dependent on a successful lookup will have a poor experience. For instance, some web services and Secure Shell (SSH) connections wait for a DNS response, even NXDOMAIN, before responding. For the best user experience, then, it is important to return a response, rather than time out with no answer. On the other hand, external mail servers are likely to reject connections, which might be an advantage in fighting spam.
一部のISP DNS管理者は、加入者アドレスのPTRクエリに対してNXDOMAIN応答のみを提供することを選択する場合があります。ある意味では、これは最も正確な応答です。これは、ホストに関する名前情報が不明であるためです。ただし、PTRクエリに否定的な応答を提供することは、エントリが一致するという[RFC1912]の期待を満たしません。成功した検索に依存しているサービスのユーザーは、エクスペリエンスが低下します。たとえば、一部のWebサービスとSecure Shell（SSH）接続は、応答する前に、DNS応答（NXDOMAINでさえ）を待ちます。したがって、最高のユーザーエクスペリエンスを得るには、応答なしでタイムアウトするのではなく、応答を返すことが重要です。一方、外部メールサーバーは接続を拒否する可能性が高く、これはスパムとの闘いに有利な場合があります。
When evaluating this option, DNS administrators should consider the uses for reverse DNS records and the number of services affecting the number of users.
このオプションを評価する場合、DNS管理者は逆DNSレコードの使用とユーザー数に影響を与えるサービス数を考慮する必要があります。
The use of wildcards in the DNS is described in [RFC4592], and their use in IPv6 reverse DNS is described in [RFC4472].
DNSでのワイルドカードの使用は[RFC4592]で説明されており、IPv6リバースDNSでのそれらの使用は[RFC4472]で説明されています。
While recording all possible addresses is not scalable, it may be possible to record a wildcard entry for each prefix assigned to a customer. Consider also that "inclusion of wildcard NS RRSets in a zone is discouraged, but not barred". [RFC4592]
可能なすべてのアドレスを記録することはスケーラブルではありませんが、顧客に割り当てられた各プレフィックスのワイルドカードエントリを記録することが可能な場合があります。 「ゾーンにワイルドカードNS RRSetsを含めることはお勧めしませんが、禁止されていない」ことも考慮してください。 [RFC4592]
This solution generally scales well. However, since the response will match any address in the wildcard range (/48, /56, /64, etc.), a forward DNS lookup on the response given will not be able to return the same hostname. This method therefore fails the expectation in [RFC1912] that forward and reverse will match. DNSSEC [RFC4035] scalability is limited to signing the wildcard zone, which may be satisfactory.
このソリューションは一般に拡張性が高いです。ただし、応答はワイルドカード範囲（/ 48、/ 56、/ 64など）の任意のアドレスと一致するため、指定された応答に対するDNSの前方参照では、同じホスト名を返すことができません。したがって、このメソッドは、[RFC1912]の順方向と逆方向が一致するという期待に失敗します。 DNSSEC [RFC4035]のスケーラビリティは、ワイルドカードゾーンの署名に限定されており、満足できる場合があります。
One way to ensure that forward and reverse records match is for hosts to update DNS servers dynamically once interface configuration is complete (whether by SLAAC, DHCPv6, or other means), as described in [RFC4472]. Hosts would need to provide both AAAA and PTR updates and would need to know which servers would accept the information.
[RFC4472]で説明されているように、インターフェイスの構成が完了すると（SLAAC、DHCPv6、またはその他の方法で）、ホストがDNSサーバーを動的に更新して、順方向と逆方向のレコードを確実に一致させる1つの方法です。ホストは、AAAAとPTRの両方の更新を提供する必要があり、どのサーバーが情報を受け入れるかを知る必要があります。
This option should scale as well or as poorly as IPv4 dynamic DNS (DDNS) does. Dynamic DNS may not scale effectively in large ISP networks that have no single master name server, but a single master server is not best practice. The ISP's DNS system may provide a point for Denial-of-Service attacks, including many attempted DDNS updates. Accepting updates only from authenticated sources may mitigate this risk, but only if authentication itself does not require excessive overhead. No authentication of dynamic DNS updates is inherently provided. Implementers should therefore consider use of TSIG [RFC2845], or at least ingress filtering, so that updates are only accepted from customer address space from internal network interfaces. They should also rate limit the number of updates from a customer per second and consider impacts on scalability. UDP is allowed per [RFC2136], so connection reliability is not assured, though the host should expect an ERROR or NOERROR message from the server; TCP provides transmission control, but the updating host would need to be configured to use TCP.
このオプションは、IPv4ダイナミックDNS（DDNS）の場合と同じか、不十分にスケーリングする必要があります。動的DNSは、単一のマスターネームサーバーを持たない大規模なISPネットワークでは効果的に拡張されない可能性がありますが、単一のマスターサーバーはベストプラクティスではありません。 ISPのDNSシステムは、試行された多くのDDNS更新を含む、サービス拒否攻撃のポイントを提供する可能性があります。認証されたソースからの更新のみを受け入れると、このリスクを軽減できますが、認証自体に過度のオーバーヘッドが必要ない場合に限られます。動的DNS更新の認証は本質的に提供されません。したがって、実装者はTSIG [RFC2845]、または少なくとも入力フィルタリングの使用を検討する必要があります。これにより、内部ネットワークインターフェイスからの顧客アドレススペースからのみ更新が受け入れられるようになります。また、1秒あたりの顧客からの更新の数をレート制限し、スケーラビリティへの影響を考慮する必要があります。 UDPは[RFC2136]で許可されているため、ホストはサーバーからのERRORまたはNOERRORメッセージを予期する必要がありますが、接続の信頼性は保証されません。 TCPは伝送制御を提供しますが、更新ホストはTCPを使用するように構成する必要があります。
Administrators may want to consider user creativity if they provide hostnames, as described in Section 5.5, "User Creativity".
管理者は、5.5項「ユーザーの創造性」で説明されているように、ホスト名を提供する場合、ユーザーの創造性を検討する必要があります。
There is no assurance of uniqueness if multiple hosts try to update with the same name ("mycomputer.familyname.org"). There is no standard way to indicate to a host what server it should send DDNS updates to; the master listed in the SOA is often assumed to be a DDNS server, but this may not scale.
複数のホストが同じ名前（ "mycomputer.familyname.org"）で更新を試みた場合、一意性は保証されません。 DDNS更新を送信するサーバーをホストに示す標準的な方法はありません。多くの場合、SOAにリストされているマスターはDDNSサーバーであると想定されていますが、これは拡張できない場合があります。
In the simplest case, a residential user will have a single host connected to the ISP. Since the typical residential user cannot configure IPv6 addresses or resolving name servers on their hosts, the ISP should provide address information conventionally -- i.e., using their normal combination of Router Advertisements (RAs), DHCP, etc. The ISP should also provide a DNS Recursive Name Server and Domain Search List as described in [RFC3646] or [RFC8106]. In determining its Fully Qualified Domain Name (FQDN), a host will typically use a domain from the Domain Search List. This is an overloading of the parameter; multiple domains could be listed, since hosts may need to search for unqualified names in multiple domains without necessarily being a member of those domains. Administrators should consider whether the Domain Search List actually provides an appropriate DNS suffix(es) when considering use of this option. For the purposes of dynamic DNS, the host would concatenate its local hostname (e.g., "hostname") plus the domain(s) in the Domain Search List (e.g., "customer.example.com"), as in "hostname.customer.example.com".
最も単純なケースでは、住宅ユーザーはISPに接続された単一のホストを持っています。一般的な住宅ユーザーはホストでIPv6アドレスを設定したりネームサーバーを解決したりできないため、ISPは通常の方法でアドレス情報を提供する必要があります。つまり、ルーターアドバタイズ（RA）やDHCPなどの通常の組み合わせを使用します。ISPはDNS [RFC3646]または[RFC8106]で説明されている、再帰的なネームサーバーとドメイン検索リスト。完全修飾ドメイン名（FQDN）を決定する際、ホストは通常、ドメイン検索リストのドメインを使用します。これはパラメータのオーバーロードです。ホストは、必ずしもそれらのドメインのメンバーでなくても、複数のドメインで非修飾名を検索する必要がある場合があるため、複数のドメインをリストすることができます。管理者は、このオプションの使用を検討する場合、ドメイン検索リストが実際に適切なDNSサフィックスを提供するかどうかを検討する必要があります。ダイナミックDNSの目的で、ホストはローカルホスト名（「ホスト名」など）とドメイン検索リスト（「customer.example.com」など）のドメインを連結します。 .example.com」。
Once it learns its address and has a resolving name server, the host must perform an SOA lookup on the IP6.ARPA record to be added in order to find the owner and eventually the server that is authoritative for the zone (which might accept dynamic updates). Several recursive lookups may be required to find the longest prefix that has been delegated. The DNS administrator must designate the Primary Master Server for the longest match required. Once found, the host sends dynamic AAAA and PTR updates using the concatenation defined above ("hostname.customer.example.com").
ホストがアドレスを学習してネームサーバーを解決したら、ホストはIP6.ARPAレコードでSOAルックアップを実行して、所有者、そして最終的にはゾーンに対して権限のあるサーバー（動的更新を受け入れる可能性があるサーバー）を見つける必要があります。 ）。委任された最長のプレフィックスを見つけるために、いくつかの再帰的なルックアップが必要になる場合があります。 DNS管理者は、必要な最長一致のためにプライマリマスターサーバーを指定する必要があります。検出されると、ホストは上記で定義された連結（ "hostname.customer.example.com"）を使用して動的AAAAおよびPTR更新を送信します。
In order to use this alternative, hosts must be configured to use dynamic DNS. This is not default behavior for many hosts, which is an inhibitor for a large ISP. This option may be scalable, although registration following an outage may cause significant load, and hosts using privacy extensions [RFC4941] may update records daily. It is up to the host to provide matching forward and reverse records and update them when the address changes.
この代替手段を使用するには、動的DNSを使用するようにホストを構成する必要があります。これは多くのホストのデフォルトの動作ではなく、大規模ISPの阻害要因です。このオプションはスケーラブルである可能性がありますが、停止後の登録は大きな負荷を引き起こす可能性があり、プライバシー拡張[RFC4941]を使用するホストは毎日レコードを更新する可能性があります。一致する順方向レコードと逆方向レコードを提供し、アドレスが変更されたときにそれらを更新するかどうかは、ホスト次第です。
Residential customers may have a gateway, which may provide DHCPv6 service to hosts from a delegated prefix. ISPs should provide a DNS Recursive Name Server and Domain Search List to the gateway, as described above and in [RFC3646] and [RFC8106]. There are two options for how the gateway uses this information. The first option is for the gateway to respond to DHCPv6 requests with the same DNS Recursive Name Server and Domain Search List provided by the ISP. The alternate option is for the gateway to relay dynamic DNS updates from hosts to the servers and domain provided by the ISP. Host behavior is unchanged; the host sends the same dynamic updates, either to the ISP's server (as provided by the gateway) or to the gateway for it to forward. The gateway would need to be capable of and configured to use dynamic DNS.
住宅顧客は、委任されたプレフィックスからホストにDHCPv6サービスを提供できるゲートウェイを持っている場合があります。上記および[RFC3646]と[RFC8106]で説明されているように、ISPはDNS再帰ネームサーバーとドメイン検索リストをゲートウェイに提供する必要があります。ゲートウェイがこの情報を使用する方法には、2つのオプションがあります。最初のオプションは、ゲートウェイがISPが提供する同じDNS再帰ネームサーバーとドメイン検索リストを使用してDHCPv6要求に応答することです。代替オプションは、ゲートウェイが動的DNS更新をホストからISPが提供するサーバーとドメインにリレーすることです。ホストの動作は変更されていません。ホストは同じ動的更新を、ISPのサーバー（ゲートウェイによって提供されるもの）またはゲートウェイに転送して送信します。ゲートウェイは、動的DNSを使用できるように構成されている必要があります。
An ISP may delegate authority for a subdomain, such as "customer12345.town.AW.customer.example.com" or "customer12345.example.com", to the customer's gateway. Each domain thus delegated must be unique within the DNS. The ISP may also then delegate the IP6.ARPA zone for the prefix delegated to the customer, as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA". Then, the customer could provide updates to their own gateway, with forward and reverse. However, individual hosts connected directly to the ISP rarely have the capability to run DNS for themselves; therefore, an ISP can only delegate to customers with gateways capable of being authoritative name servers. If a device requests a DHCPv6 Prefix Delegation, that may be considered a reasonably reliable indicator that it is a gateway, rather than an individual host. It is not necessarily an indicator that the gateway is capable of providing DNS services and therefore cannot be relied upon as a way to test whether this option is feasible. In fact, this kind of delegation will not work for devices complying with [RFC6092], which includes the requirement, "By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server".
ISPは、「customer12345.town.AW.customer.example.com」や「customer12345.example.com」などのサブドメインの権限を顧客のゲートウェイに委任する場合があります。このように委任された各ドメインは、DNS内で一意である必要があります。次に、ISPは、顧客に委任されたプレフィックスのIP6.ARPAゾーンを委任することもできます（例：2001：db8：f00 :: / 48） "0.0.f.0.8.bd0.1.0.0.2.IP6.ARPA 」次に、顧客はフォワードとリバースを使用して、自分のゲートウェイに更新を提供できます。ただし、ISPに直接接続されている個々のホストがDNSを実行する機能を持っていることはほとんどありません。したがって、ISPは、信頼できるネームサーバーになることができるゲートウェイを持つ顧客にのみ委任できます。デバイスがDHCPv6プレフィックス委任を要求する場合、それは個々のホストではなく、ゲートウェイであることを合理的に信頼できる指標と見なすことができます。これは、ゲートウェイがDNSサービスを提供できることを必ずしも示すものではないため、このオプションが実行可能かどうかをテストする方法として信頼することはできません。実際、この種類の委任は[RFC6092]に準拠したデバイスでは機能しません。これには、「デフォルトでは、外部インターフェイスで受信した受信DNSクエリは、統合されたDNS解決サーバーで処理してはならない」という要件が含まれます。
If the customer's gateway is the name server, it provides its own information to hosts on the network, as described in [RFC2136], which is often done for enterprise networks.
顧客のゲートウェイがネームサーバーの場合、[RFC2136]で説明されているように、ネットワーク上のホストに独自の情報を提供します。これは、企業ネットワークでよく行われます。
An ISP could provide authoritative responses as a secondary server to the customer's master server. For instance, the home gateway name server could be the master server, with the ISP providing the only published NS authoritative servers.
ISPは、信頼できる応答をセカンダリサーバーとして顧客のマスターサーバーに提供できます。たとえば、ホームゲートウェイネームサーバーがマスターサーバーになり、ISPが公開されたNS権限のあるサーバーのみを提供するようになります。
To implement this alternative, users' residential gateways must be capable of acting as authoritative name servers capable of dynamic DNS updates. There is no mechanism for an ISP to dynamically communicate to a user's equipment that a zone has been delegated, so user action would be required. Most users have neither the equipment nor the expertise to run DNS servers, so this option is unavailable to the residential ISP.
この代替手段を実装するには、ユーザーの住宅用ゲートウェイが、動的DNS更新が可能な権限のあるネームサーバーとして機能できる必要があります。 ISPがゾーンが委任されていることをユーザーの機器に動的に通信するメカニズムはないため、ユーザーの操作が必要になります。ほとんどのユーザーはDNSサーバーを実行するための機器も専門知識も持っていないため、このオプションは住宅用ISPでは利用できません。
An ISP's name server that receives a dynamic forward or reverse DNS update may create a matching entry. Since a host capable of updating one is generally capable of updating the other, this should not be required, but redundant record creation will ensure that a record exists. ISPs implementing this method should check whether a record already exists before accepting or creating updates.
動的なフォワードまたはリバースDNSアップデートを受信するISPのネームサーバーは、一致するエントリを作成する場合があります。一方を更新できるホストは、通常、もう一方を更新できるため、これは必須ではありませんが、冗長なレコードを作成すると、レコードが確実に存在します。このメソッドを実装するISPは、更新を受け入れるか作成する前に、レコードがすでに存在するかどうかを確認する必要があります。
This method is also dependent on hosts being capable of providing dynamic DNS updates, which is not default behavior for many hosts.
この方法は、動的DNS更新を提供できるホストに依存しています。これは、多くのホストのデフォルトの動作ではありません。
An ISP's DHCPv6 server may populate the forward and reverse zones when the DHCP request is received if the request contains enough information [RFC4704].
ISPのDHCPv6サーバーは、要求に十分な情報が含まれている場合にDHCP要求を受信すると、フォワードゾーンとリバースゾーンにデータを入力することがあります[RFC4704]。
However, this method will only work for a single host address (IA_NA); the ISP's DHCP server would not have enough information to update all records for a prefix delegation. If the zone authority is delegated to a home gateway that used this method, the gateway could update records for residential hosts. To implement this alternative, users' residential gateways would have to support the FQDN DHCP option and would have to either have the zones configured or send DDNS messages to the ISP's name server.
ただし、この方法は単一のホストアドレス（IA_NA）に対してのみ機能します。 ISPのDHCPサーバーは、プレフィックス委任のすべてのレコードを更新するのに十分な情報を持っていません。ゾーンの権限がこの方法を使用したホームゲートウェイに委任されている場合、ゲートウェイは住宅用ホストのレコードを更新できます。この代替手段を実装するには、ユーザーのレジデンシャルゲートウェイがFQDN DHCPオプションをサポートし、ゾーンを構成するか、DDNSメッセージをISPのネームサーバーに送信する必要があります。
A user may receive an address or prefix from a RADIUS server [RFC2865], the details of which may be recorded via RADIUS Accounting data [RFC2866]. The ISP may populate the forward and reverse zones from the accounting data if it contains enough information. This solution allows the ISP to populate data concerning allocated prefixes as per Section 2.2 (wildcards) and customer premise equipment (CPE) endpoints. However, as with Section 2.3.5, it does not allow the ISP to populate information concerning individual hosts.
ユーザーは、RADIUSサーバー[RFC2865]からアドレスまたはプレフィックスを受信できます。その詳細は、RADIUSアカウンティングデータ[RFC2866]を介して記録できます。 ISPは、十分な情報が含まれている場合、アカウンティングデータからフォワードゾーンとリバースゾーンを生成する場合があります。このソリューションにより、ISPはセクション2.2（ワイルドカード）および顧客宅内機器（CPE）エンドポイントに従って割り当てられたプレフィックスに関するデータを入力できます。ただし、セクション2.3.5と同様に、ISPは個々のホストに関する情報を入力できません。
For customers who are able to run their own DNS servers, such as commercial customers, often the best option is to delegate the reverse DNS zone to them, as described in [RFC2317] (for IPv4). However, since most residential users have neither the equipment nor the expertise to run DNS servers, this method is unavailable to residential ISPs.
[RFC2317]（IPv4の場合）で説明されているように、商用の顧客など、独自のDNSサーバーを実行できる顧客の場合、多くの場合、リバースDNSゾーンを委任することが最良のオプションです。ただし、ほとんどの住宅ユーザーはDNSサーバーを実行するための機器も専門知識も持っていないため、住宅ISPはこの方法を利用できません。
This is a general case of the specific case described in Section 2.3.3. All of the same considerations still apply.
これは、セクション2.3.3で説明されている特定のケースの一般的なケースです。同じ考慮事項のすべてが引き続き適用されます。
Common practice in IPv4 is to provide PTR records for all addresses, regardless of whether a host is actually using the address. In IPv6, ISPs may generate PTR records for all IPv6 addresses as the records are requested. Several DNS servers are capable of this.
IPv4の一般的な方法は、ホストが実際にアドレスを使用しているかどうかに関係なく、すべてのアドレスにPTRレコードを提供することです。 IPv6では、ISPは、レコードが要求されると、すべてのIPv6アドレスのPTRレコードを生成できます。いくつかのDNSサーバーがこれに対応しています。
An ISP using this option should generate a PTR record on demand and cache or prepopulate the forward (AAAA) entry for the duration of the Time to Live of the PTR. Similarly, the ISP would prepopulate the PTR following a AAAA query. To reduce exposure to a Denial-of-Service attack, state or storage should be limited. Alternatively, if an algorithm is used to generate a unique name, it can be employed on the fly in both directions. This option has the advantage of assuring matching forward and reverse entries while being simpler than dynamic DNS. Administrators should consider whether the lack of user-specified hostnames is a drawback. It may be possible to allow user-specified hostnames for some records and generate others on the fly; looking up a record before generating on the fly may slow responses or may not scale well.
このオプションを使用するISPは、オンデマンドでPTRレコードを生成し、PTRの存続時間の間、転送（AAAA）エントリをキャッシュまたは事前入力する必要があります。同様に、ISPはAAAAクエリに続いてPTRを事前入力します。サービス拒否攻撃の危険性を減らすには、状態またはストレージを制限する必要があります。あるいは、アルゴリズムを使用して一意の名前を生成する場合は、その場で双方向に使用できます。このオプションには、ダイナミックDNSよりもシンプルでありながら、一致するフォワードエントリとリバースエントリが保証されるという利点があります。管理者は、ユーザー指定のホスト名がないことが欠点であるかどうかを検討する必要があります。一部のレコードにユーザー指定のホスト名を許可し、その場で他のレコードを生成することが可能です。オンザフライで生成する前にレコードを検索すると、応答が遅くなるか、適切にスケーリングされない場合があります。
DNSSEC [RFC4035] signing records on the fly may increase load; unsigned records can indicate that these records are less trusted, which might be acceptable.
DNSSEC [RFC4035]オンザフライでレコードに署名すると、負荷が増える可能性があります。署名されていないレコードは、これらのレコードの信頼性が低いことを示している可能性があり、これは許容できる場合があります。
Another consideration is that the algorithm used for generating the record must be the same on all servers for a zone. In other words, any server for the zone must produce the same response for a given query. Administrators managing a variety of rules within a zone might find it difficult to keep those rules synchronized on all servers.
別の考慮事項は、レコードの生成に使用されるアルゴリズムは、ゾーンのすべてのサーバーで同じでなければならないということです。つまり、ゾーンのサーバーはすべて、特定のクエリに対して同じ応答を生成する必要があります。ゾーン内のさまざまなルールを管理する管理者は、それらのルールをすべてのサーバーで同期させることが難しい場合があります。
It is possible to create a user interface, such as a web page, that would allow end users to enter a hostname to associate with an address. Such an interface would need to be authenticated; only the authorized user could add/change/delete entries. If the ISP changes prefixes assigned to customers, the interface would need to specify only the host bits. The backend would therefore need to be integrated with prefix assignments so that when a new prefix was assigned to a customer, the DNS service would look up user-generated hostnames, delete the old record, and create the new one.
エンドユーザーがホスト名を入力してアドレスに関連付けることができるWebページなどのユーザーインターフェイスを作成することが可能です。このようなインターフェースは認証される必要があります。許可されたユーザーのみがエントリを追加/変更/削除できます。 ISPが顧客に割り当てられたプレフィックスを変更する場合、インターフェイスはホストビットのみを指定する必要があります。したがって、バックエンドをプレフィックス割り当てと統合して、新しいプレフィックスが顧客に割り当てられたときに、DNSサービスがユーザー生成のホスト名を検索し、古いレコードを削除して、新しいレコードを作成できるようにする必要があります。
Considerations about some records being static and others dynamic or dynamically generated (Section 2.5) and the creativity of users (Section 5.5) still apply.
一部のレコードが静的で、他のレコードが動的または動的に生成される（2.5節）およびユーザーの創造性（5.5節）に関する考慮事項が引き続き適用されます。
There are six common uses for PTR lookups:
PTRルックアップの一般的な用途は6つあります。
Rejecting mail: A PTR with a certain string may indicate "This host is not a mail server", which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior.
メールの拒否：特定の文字列を含むPTRは「このホストはメールサーバーではありません」を示している可能性があります。 PTRがないと、目的の動作になります。
Serving ads: "This host is probably in town.province." An ISP that does not provide PTR records might affect somebody else's geolocation (also see privacy consideration about location).
広告を配信する：「このホストはおそらくtown.provinceにあります。」 PTRレコードを提供しないISPは、他の誰かの地理位置情報に影響を与える可能性があります（位置に関するプライバシーの考慮事項も参照）。
Accepting SSH connections: The presence of a PTR may be inferred to mean "This host has an administrator with enough clue to set up forward and reverse DNS". This is a poor inference.
SSH接続の受け入れ：PTRの存在は、「このホストには、フォワードDNSとリバースDNSをセットアップするための十分な手掛かりを持つ管理者がいる」ことを意味すると推測されます。これは貧弱な推論です。
Log files: Many systems will record the PTR of remote hosts in their log files to make it easier when reading logs later to see what network the remote host uses.
ログファイル：多くのシステムでは、リモートホストのPTRをログファイルに記録して、後でログを読み取ってリモートホストが使用しているネットワークを簡単に確認できるようにします。
Traceroute: The ability to identify an interface and name of any intermediate node or router is important for troubleshooting.
Traceroute：中間ノードまたはルーターのインターフェイスと名前を識別する機能は、トラブルシューティングに重要です。
Service discovery: [RFC6763] specifies "DNS-Based Service Discovery", and Section 11 specifically describes how PTRs are used.
サービスディスカバリ：[RFC6763]は「DNSベースのサービスディスカバリ」を指定し、セクション11ではPTRの使用方法を具体的に説明しています。
As a general guideline, when address assignment and name are under the same authority, or when a host has a static address and name, AAAA and PTR records should exist and match. For residential users, if these use cases are important to the ISP, the administrator will then need to consider how to provide PTR records.
一般的なガイドラインとして、アドレス割り当てと名前が同じ権限下にある場合、またはホストに静的アドレスと名前がある場合、AAAAレコードとPTRレコードが存在し、一致している必要があります。住宅ユーザーの場合、これらの使用例がISPにとって重要である場合、管理者はPTRレコードを提供する方法を検討する必要があります。
The best accuracy would be achieved if ISPs delegated authority along with address delegation, but residential users rarely have domain names or authoritative name servers.
ISPがアドレスの委任と共に権限を委任した場合に最高の精度が達成されますが、住宅ユーザーがドメイン名または権限のあるネームサーバーを持っていることはほとんどありません。
Dynamic DNS updates can provide accurate data, but there is no standard way to indicate to residential devices where to send updates, whether the hosts support DDNS, or whether it scales.
動的DNS更新は正確なデータを提供できますが、ホストがDDNSをサポートするかどうか、またはスケーリングするかどうか、更新を送信する場所を住宅用デバイスに示す標準的な方法はありません。
An ISP has no knowledge of its residential users' hostnames and therefore can either provide a wildcard response or a dynamically generated response. A valid negative response (such as NXDOMAIN) is a valid response if the four cases above are not essential; delegation where no name server exists should be avoided.
ISPは、住宅ユーザーのホスト名を認識していないため、ワイルドカード応答または動的に生成された応答を提供できます。上記の4つのケースが必須ではない場合、有効な否定応答（NXDOMAINなど）は有効な応答です。ネームサーバーが存在しない委任は避けてください。
Some people think the existence of reverse DNS records, or matching forward and reverse DNS records, provides useful information about the hosts with those records. For example, one might infer that the administrator of a network with properly configured DNS records was better informed, and by further inference more responsible, than the administrator of a less thoroughly configured network. For instance, most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match. If they match, but information higher in the stack (for instance, mail source) is inconsistent, the packet is questionable. However, these records may be easily forged unless DNSSEC or other measures are taken. The string of inferences is questionable and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6.
一部の人々は、逆引きDNSレコードの存在、または正引きと逆引きDNSレコードの一致が、それらのレコードを持つホストに関する有用な情報を提供すると考えています。たとえば、DNSレコードが適切に構成されているネットワークの管理者は、より完全に構成されていないネットワークの管理者よりも、より詳細な情報を得て、さらに責任があると推論することができます。たとえば、ほとんどのメールプロバイダーは、フォワードDNSエントリとリバースDNSエントリが一致しない限り、ポート25で着信接続を受け入れません。それらが一致しても、スタックの上位にある情報（メールソースなど）に一貫性がない場合、パケットは疑わしいものです。ただし、DNSSECまたは他の手段を講じない限り、これらのレコードは簡単に偽造される可能性があります。一連の推論は疑わしいものであり、信頼性を評価するための他の手段（肯定的な評判など）がIPv6で主流になる場合は不要になる可能性があります。
Providing location information in PTR records is useful for troubleshooting, law enforcement, and geolocation services, but for the same reasons, it can be considered sensitive information.
PTRレコードで位置情報を提供することは、トラブルシューティング、法執行機関、地理位置情報サービスに役立ちますが、同じ理由から、機密情報と見なすことができます。
The security considerations for using dynamic DNS are described in [RFC3007]. DNS Security Extensions are documented in [RFC4033].
動的DNSを使用するためのセキュリティの考慮事項は、[RFC3007]で説明されています。 DNSセキュリティ拡張機能は[RFC4033]で文書化されています。
Interactions with DNSSEC are described throughout this document.
DNSSECとの相互作用は、このドキュメント全体で説明されています。
Several methods exist for providing encryption keys in the DNS. Any of the options presented here may interfere with these key techniques.
DNSで暗号化キーを提供する方法はいくつかあります。ここに示すオプションのいずれかは、これらの主要な技術を妨害する可能性があります。
Given the considerations in [RFC8117], hostnames that provide information about a user compromise that user's privacy. Some users may want to identify their hosts using user-specified hostnames, but the default behavior should not be to identify a user, their location, their connectivity, or other information in a PTR record.
[RFC8117]の考慮事項を考慮すると、ユーザーに関する情報を提供するホスト名は、そのユーザーのプライバシーを侵害します。一部のユーザーは、ユーザー指定のホスト名を使用してホストを識別したい場合がありますが、デフォルトの動作では、ユーザー、場所、接続、またはPTRレコード内のその他の情報を識別しないでください。
Though not precisely a security consideration, administrators may want to consider what domain will contain the records and who will provide the names. If subscribers provide hostnames, they may provide inappropriate strings. Consider "ihate.example.com" or "badword.customer.example.com" or "celebrityname.committed.illegal.acts.example.com".
厳密にはセキュリティ上の考慮事項ではありませんが、管理者は、どのドメインにレコードが含まれ、誰が名前を提供するかを検討する場合があります。サブスクライバーがホスト名を提供すると、不適切な文字列が提供される可能性があります。 「ihate.example.com」または「badword.customer.example.com」または「celebrityname.committed.illegal.acts.example.com」を検討してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.
[RFC1912] Barr、D。、「Common DNS Operational and Configuration Errors」、RFC 1912、DOI 10.17487 / RFC1912、1996年2月、<https://www.rfc-editor.org/info/rfc1912>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメインネームシステムの動的更新（DNS UPDATE）」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月、<https://www.rfc-editor.org/info/rfc2136>。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、DOI 10.17487 / RFC2845、2000年5月、<https： //www.rfc-editor.org/info/rfc2845>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866] Rigney、C。、「RADIUS Accounting」、RFC 2866、DOI 10.17487 / RFC2866、2000年6月、<https://www.rfc-editor.org/info/rfc2866>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/info/rfc3007>.
[RFC3007] Wellington、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<https://www.rfc-editor.org/info/rfc3007>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<https://www.rfc-editor.org / info / rfc3646>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< https://www.rfc-editor.org/info/rfc4035>。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.
[RFC4592]ルイス、E。、「ドメインネームシステムにおけるワイルドカードの役割」、RFC 4592、DOI 10.17487 / RFC4592、2006年7月、<https://www.rfc-editor.org/info/rfc4592>。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>.
[RFC4704] Volz、B。、「IPv6（DHCPv6）クライアントの完全修飾ドメイン名（FQDN）オプションの動的ホスト構成プロトコル」、RFC 4704、DOI 10.17487 / RFC4704、2006年10月、<https：//www.rfc- editor.org/info/rfc4704>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<https：// www .rfc-editor.org / info / rfc8106>。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.
[RFC2317] Eidnes、H.、de Groot、G。、およびP. Vixie、「Classless IN-ADDR.ARPA delegation」、BCP 20、RFC 2317、DOI 10.17487 / RFC2317、1998年3月、<https：// www。 rfc-editor.org/info/rfc2317>。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, <https://www.rfc-editor.org/info/rfc4472>.
[RFC4472] Durand、A.、Ihren、J。、およびP. Savola、「運用上の考慮事項とIPv6 DNSに関する問題」、RFC 4472、DOI 10.17487 / RFC4472、2006年4月、<https：//www.rfc-editor。 org / info / rfc4472>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、Ed。、 "Recommended Simple Security Capability in Customer Premises Equipment（CPE）for Providing Residential IPv6 Internet Service"、RFC 6092、DOI 10.17487 / RFC6092、January 2011、<https：//www.rfc -editor.org/info/rfc6092>。
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017, <https://www.rfc-editor.org/info/rfc8117>.
[RFC8117] Huitema、C.、Thaler、D。、およびR. Winter、「現在のホスト名の実践は有害であると考えられています」、RFC 8117、DOI 10.17487 / RFC8117、2017年3月、<https://www.rfc-editor.org/ info / rfc8117>。
Acknowledgements
謝辞
The author would like to thank Alain Durand, JINMEI Tatuya, David Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris Roosenraad, Fernando Gont, John Levine, and many others who discussed and provided suggestions for this document.
著者は、Alain Durand、JINMEI Tatuya、David Freedman、Andrew Sullivan、Chris Griffiths、Darryl Tanner、Ed Lewis、John Brzozowski、Chris Donley、Wes George、Jason Weil、John Spence、Ted Lemon、Stephan Lagerholm、Steinar Haugに感謝します。 、マーク・アンドリュース、クリス・ルーセンラード、フェルナンド・ゴント、ジョン・レバイン、およびこのドキュメントについて話し合い、提案を行った多くの人々
Author's Address
著者のアドレス
Lee Howard Retevia Fairfax, VA 22032 United States of America
リーハワードレテビアフェアファックス、バージニア州22032アメリカ合衆国
Email: lee.howard@retevia.net