AppleデバイスのコンテンツキャッシュでDNS TXTレコードを使用する
DNSゾーンファイルにTXTレコードを追加する
1つまたは複数のTXTレコードを、DNSサーバのローカルドメインのゾーンファイルに追加します。以下のゾーンにDNS TXTレコードを追加します:
ドメインに関する権威のあるゾーン
ネットワーククライアント用のデフォルト検索ドメインと一致するゾーン
例えば、組織から独自のドメインのDNSサービスが提供されていて、betterbag.comのホスト名に関する権威を組織が持っている場合は、betterbag.comゾーンファイルにキャッシュTXTレコードを追加します。
重要: ドメイン名に対して権威のあるDNSサービスをホストしていない場合は、TXTレコードを自分で追加することはできません。DNSプロバイダと協力し、TXTレコードを提供して、追加してもらってください。
BIND9 DNSを使用する場合には、生成されたTXTレコードをコピーして、DNSのゾーンファイルにペーストします。
LinuxでBIND9ベースのDNSの場合は、このファイルは/private/etc/bind/ディレクトリにあり、ゾーンファイル名が/private/etc/bind/named.conf内で定義されています（ほとんどの場合、「db.betterbag.com」です）。
Windows DNSを使用している場合は、以下のいずれかの操作を行います:
コンテンツキャッシュサービスを使用してテキストレコードを生成した場合: 生成されたコマンド内のZoneName変数をお使いのネットワークのDNSゾーン名に置き換えてから、コマンドをWindows DNSコンピュータで実行します。
テキストレコードを手動で作成した場合: Windows Server管理ツールを使用して、TXTレコード情報を手動で入力します。
DNS TXTレコードを使用して複数のパブリックIPアドレスでコンテンツを公開する
ネットワークがインターネットへの接続に複数のパブリックIPアドレスを使用していて、コンテンツキャッシュによる登録が、クライアントが検出に使用するものとは異なるアドレスを使用して行われるような場合は、それらのアドレスのリストをコンテンツキャッシュとクライアントの両方に提供する必要があります。Appleでは、これらのリストを使用して、複数のパブリックIPアドレスを使用する場合の登録および検出要求の相互確認を行います。
クライアントの手動構成を避けるため、コンテンツキャッシュはDNS TXTレコードを使用してネットワーク上のクライアント用にパブリックIPアドレス情報を公開します。TXTレコードは、クライアントで使用されるデフォルトのDNS検索ドメインに公開する必要があります。
macOS 10.15以降では、優先ローカルIPアドレスを指定して、ネットワーク上のほかのコンテンツキャッシュの影響を軽減することもできます。優先ローカルIPアドレスがTXTレコードで宣言されていない場合、すべてのクライアントは使用可能なコンテンツキャッシュを使用します。
パブリックIPアドレス範囲用のTXTレコードの正確なデータは、自動的に生成することも手動で生成することもできます。いずれの場合も、DNSレコードを編集するか、DNSプロバイダに設定を提供してゾーンファイル内にTXTレコードを作成または編集してもらう必要があります。優先ローカルIPアドレス用のTXTレコードを自動生成することはできません。これらは手動で作成する必要があります。
注記: これらのレコードは内部ネットワークでのみ必要です。外部のDNSには追加レコードは必要ありません。
DNS TXTレコードのフォーマット
TXTレコードを指定する構文と、TXTレコード内の非ASCII文字は、お使いのDNSサーバによって変わることがあります。以下に示す例は説明のみを目的としています。
コンテンツキャッシュ用のDNSテキストレコードは、DNS-SD TXTレコードと同じフォーマットです（キー値ペア）:
name._tcp 10800 IN TXT "[prs|prn|fss|fsn]=addressRanges"パブリックIPアドレス範囲にはprsキーとprnキーを使用します。優先コンテンツキャッシュのローカルIPアドレス範囲にはfssキーとfsnキーを使用します。
以下の例は、どちらも同じ2つのIPアドレス範囲（17.53.22.2～17.53.22.254までの範囲、単一のIPアドレス17.53.23.1で構成される範囲）のセットを定義しています。これらの違いは、1番目の例ではprsキーを使用し、2番目の例ではprnキーを使用していることです。
_aaplcache._tcp 10800 IN TXT "prs=17.53.22.2-17.53.22.254,17.53.23.1"_aaplcache._tcp 10800 IN TXT_aaplcache._tcp 10800 IN TXT "prn=\x24\x11\x35\x16\x02\x11\x35\x16\xfe\x14\x11\x35\x17\x01"これらのキーでは、値に指定するIPアドレス範囲のフォーマットが異なります:
prsまたはfss:
prsキーまたはfssキーの値は、カンマで区切られたIPアドレスの範囲の列で、プレゼンテーションフォーマット（ASCIIドット表記）で表されます。この構文は簡単に構成できます。範囲には、1つのIPアドレスまたはハイフンで区切られた2つのIPアドレスが含まれます。prnまたはfsn:
prnキーまたはfsnキーの値は、連結されたIPアドレス範囲の列で、バイナリのネットワークバイトオーダー形式で表されます。プレゼンテーションフォーマットで指定した場合にDNSレコードとして長すぎる範囲列には、この構文を使用します。シーケンス内の各範囲の先頭は、その後に続く範囲の種類を指定するバイトです:0x14は単一のIPv4アドレスを示します。
0x24は範囲の開始IPv4アドレスと終了IPv4アドレスを示します。
複数のレコードを連鎖させることができます。その場合は、最初のレコード_aaplcache._tcpおよび必要に応じてそれ以降のレコード_aaplcache1._tcpから_aaplcache24._tcpまでに名前を付けます。連鎖できるレコード数は最大で25です。
macOS 10.14以前を使用しているクライアントとの互換性を維持するには、fssキーまたはfsnキーを使用するレコードの前にprsキーまたはprnキーを使用するレコードを配置します。
レコードを連鎖させるには、最後のTXTレコード以外のすべてのTXTレコードに継続文字を追加します。
同じ連鎖内でprs構文とprn構文のレコードを混在させることができます。prs構文では、レコード値の末尾に「,more」と追加します。prn構文では、レコード値の末尾に「+」（0x2b）と追加します。継続文字を含まない最初のレコードが連鎖の終了を示します。
連鎖したレコードは一度に5件ずつ解決されます。つまり、最初に_aaplcache._tcpおよび_aaplcache1._tcpから_aaplcache4._tcpまでが並行して解決されます。そのすべてが継続文字で終わる場合は、次に_aaplcache5._tcpから_aaplcache9._tcpまでが解決されます。以降も同様に続きます。
以下に連鎖した3つのレコードの例を示します:
_aaplcache._tcp 10800 IN TXT "prs=17.250.1.1,17.250.2.1-17.250.2.254,more"_aaplcache1._tcp 10800 IN TXT "prn=\x24\x11\xfa\x03\x01\x11\xfa\x03\xfe+"_aaplcache2._tcp 10800 IN TXT "prs=17.250.4.5"例1
この例では、prsまたはprnのレコードとfssまたはfsnのレコードの両方が必要なシナリオを示します。
「prs=203.0.113.10-203.0.113.19」という値とローカルアドレス10.0.0.30、10.1.0.30、および10.2.0.30で展開された3つのコンテンツキャッシュを持つ「_aaplcache._tcp」という名前のDNS TXTレコードがすでにあるとします。最初の2つは共有コンテンツのみに対応し、最後の1つは共有コンテンツとiCloudコンテンツの両方に対応します。
クライアントが不正なコンテンツキャッシュを使用しないようにするために、次のように、そのレコードの末尾に「,more」を付加して2番目のレコードを追加することができます:
_aaplcache._tcp prs=203.0.113.10-203.0.113.19,more_aaplcache1._tcp fss=10.0.0.30,10.1.0.30,10.2.0.303つのコンテンツキャッシュのうち少なくとも1つがこの方式を使用していれば、共有コンテンツを探しているiOS 13、iPadOS 13.1、macOS 10.15、tvOS 13以降を搭載したデバイスはそれらのコンテンツキャッシュのみを使用します。3台がすべてオフラインの場合、共有コンテンツを探しているクライアントは、使用可能なコンテンツキャッシュを使用できます。
10.2.0.30がこの方式を使用していれば、iCloudコンテンツを探しているiOS 13、iPadOS 13.1、macOS 10.15、tvOS 13以降を搭載したデバイスはそのサーバのみを使用します。そのサーバがオフラインの場合、iCloudコンテンツを探しているクライアントは、使用可能なコンテンツキャッシュを使用します。
iOS 12以前またはmacOS 10.14以前を搭載しているデバイスは、上記の3つだけでなく、使用可能なコンテンツキャッシュを使用します。
例2
この例では、prsまたはprnのレコードが不要なシナリオを示します。
1つのパブリックIPアドレスしかなく、DNS TXTレコード機能をまったく使用しないけれど、サーバコンピュータ用に確保されているサブネット（192.168.50/24）上にいくつかのコンテンツキャッシュがあるとします。
クライアントが不正なコンテンツキャッシュを使用しないようにするために、次のように1件のレコードを設定できます:
_aaplcache._tcp fss=192.168.50.1-192.168.50.254求めるクライアントの種類（共有またはiCloud）用のコンテンツキャッシュがその範囲内で少なくとも1つは使用可能であれば、iOS 13、iPadOS 13.1、macOS 10.15、tvOS 13以降のクライアントは、そのコンテンツキャッシュのみを使用します。