IPv6の互換性のためにサーバーを構成する（拒否されたiOSアプリケーションで使用されるAPIの場合）

Question

IPv6オーバーレイネットワークでは動作しないため、Appleによって拒否されたiOSアプリケーションをスタックオーバーフローに関する多くの質問があります。

ハードコードされたIPアドレスがないことを確認しており、古い到達可能性（まったくありません）または他の低レベルのネットワークフレームワーク（NSURLSessionのみを使用しています）を使用していないことを確認しました。私は自分のマシン上でNAT64テストネットワークを使いました。

これは、HTTPS（および他のネットワーク接続なし）を介してAPIと通信するXamarinアプリです。

私が見つけた答えのいくつかは、この問題の解決にはサーバーの構成変更が必要であることを示しています。

私の質問は広義にはどのような設定変更が必要ですか？具体的には、ドメイン上にAAAAレコードが必要ですか？その場合、どのように設定する必要がありますか？

私はこの問題をソフトウェア開発者としてより多く受けています。したがって、IPv6の仕組みと必要なサーバーの変更の詳細な理解は必要ありません。

Answer 1

サーバーを変更する必要はありません。 DNS64はIPv4専用サーバの翻訳を担当し、DNS64はホスト名に正しいアドレスを取得するようにしなければなりません。したがって、ホスト名を使用し、ハードコードされたアドレスではなく、IPバージョンに依存しないAPIを使用する場合、通常は機能するだけです。

失敗する可能性があるのは、Appleの方針に準拠し、DNSゾーンにダミー/偽/間違ったAAAAレコードを追加しようとする場合です。 DNS64が正しいレコードを生成するのを実際に妨げるのは、サーバが実際のIPv6を持っていて、翻訳サービスを必要としないと考えているからです。

MacOSに組み込まれたDNS64には、インターネットへの「実際の」IPv6接続がなく、このような不正なAAAAレコードは無視されますが、実際のDNS64ではそうではありません。この場合、あなたのローカルテストはうまくいくように見えますが、Appleはそれが失敗するのを見るでしょう。

実際のDNS64とNAT64サービス（https://nat64check.org/）を使用してウェブサイトをチェックするためのテストツールを作成しました。それを自由に使用してください。

必須ではありませんが、Webサービスの到達可能性を最大限に高めるには、実際にサーバーをIPv6経由でアクセス可能にし、AAAAレコードを提供することをお勧めします。これにより、サービスが信頼性とパフォーマンスを向上させるNAT64およびDNS64翻訳サービスから独立しています。また、IPv4アドレスの欠如（CGN、DS-Liteなど）を補うためにISPが最近導入する必要のある手法をバイパスできるため、IPv6を持つ他のユーザのためにも改善されます。

NATSECの問題を防ぎます.NAT64は "偽"を生成する必要があります。IPv6を介してサービスを動作させるにはAAAAが必要で、DNSSECは誰でもDNSレコードについて嘘をつけないように設計されています。実際のAAAAレコードを提供する場合、NAT64は存在する必要はなく、DNSSECは影響を受けません。

要約すると、IPv6を介してサーバーに到達可能にし、そのアドレスをAAAAレコードでDNSに公開することです。それは皆に利益をもたらすでしょう。しかし、偽のAAAAレコード（例えば、::ffff:、2001:db8:、64:ff9b:、fcまたはfdで始まるレコード）を公開しないでください。これらはIPv6を持っている皆さんを傷つけるでしょう。これは最近かなりの人数です。 IPv6を介してサービスを利用できるようにすると、そのサービスをプロダクションサービスとして扱い、それを正しく行います。