HTTPDNS:ベストプラクティス

シナリオ：特定の HTTPDNS サービスノードが利用不可の場合

背景情報

自然災害、インターネットサービスプロバイダー (ISP) によるブロッキング、ネットワーク障害などの極端な状況では、HTTPDNS の単一のサービスエントリーポイントが利用できなくなり、ドメイン名の名前解決に影響を及ぼす可能性があります。

ソリューション

1. 起動 IP アドレスのフェールオーバー

   • アプリケーション内に複数の起動 IP アドレスまたはドメイン名を埋め込み、HTTPDNS との継続的な接続性を確保します。

   • リクエストが失敗した場合、次の起動 IP アドレスが自動的に使用されます。

2. サービス IP アドレスリストの動的更新

   以下のフローチャートは、起動 IP アドレスにリクエストを送信してサービス IP アドレスを取得する方法を示しています。

詳細については、「スケジューリングサービスインターフェイス」をご参照ください。

3. フェールオーバーポリシー

   HTTPDNS を使用すると、IP ローテーションメカニズムが実装されます。ある IP アドレスが到達不能な場合、システムは次の IP アドレスにローテーションしてリトライするため、1 つのサービス IP アドレスが利用できなくなっても HTTPDNS は影響を受けません。サーバーに名前解決リクエストが送信されると、システムはグローバルサービス IP アドレスリストから利用可能なサービス IP アドレスを取得します。現在のサービス IP アドレスを使用した名前解決が成功した場合、SDK はそのライフサイクル全体でこの IP アドレスを名前解決に使用し続けます。現在のサービス IP アドレスを使用した名前解決が失敗した場合、システムはグローバルサービス IP アドレスリストの次の IP アドレスに切り替えてリトライします。リトライも失敗した場合、システムは null を返し、再度別のサービス IP アドレスへの切り替えを試みます。

すべての HTTPDNS サービス IP アドレスが応答しない場合は、オペレーティングシステムのネイティブ DNS チェーンであるローカル DNS の使用にフォールバックします。Android で OkHttp をネットワークライブラリとして使用して HTTPDNS を統合する場合、次のコードを使用してローカル DNS で名前解決できます。

List<InetAddress> result = okhttp3.Dns.SYSTEM.lookup(host);

val result: List<InetAddress> = Dns.SYSTEM.lookup(host)

iOS の場合は、Host の置換やリクエストのインターセプトを避け、元のリクエストは変更しないようにします。

NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];
// リクエストを送信します。
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
    if (error) {
        NSLog(@"error: %@", error);
    } else {
        NSLog(@"response: %@", response);
    }
}];
[task resume];

var request = URLRequest(url: url)
// リクエストを送信します。
let session = URLSession.shared
let task = session.dataTask(with: request) { (data, response, error) in
    if let error = error {
        print("error: \(error)")
    } else {
        print("response: \(response?.description ??  "")")
    }
}
task.resume()

4. ノンブロッキング名前解決

   アプリで非同期メソッドを使用して HTTPDNS にアクセスします。これにより、ビジネスが名前解決の結果を待つために中断される必要がなくなります。

シナリオ：頻繁なクエリによるパフォーマンスのボトルネック

背景情報

各ネットワークリクエスト中に HTTPDNS にドメイン名の名前解決をリクエストすると、ビジネスのレイテンシーと帯域幅の消費が大幅に増加します。ドメイン名の名前解決結果には TTL (Time To Live) キャッシュ値があることを考慮すると、この値に基づいてキャッシュを実装できます。

ソリューション

1. ローカルキャッシュ

   • DNS 標準 RFC 1034 によると、名前解決の結果は TTL 値に基づいてキャッシュできます。

2. 事前解決

2. コネクションの再利用

   HTTP クライアントのコネクション再利用機能を有効にすることで、TCP 接続の確立にかかる時間を短縮し、HTTPDNS の名前解決レイテンシーを低減できます。

3. 永続キャッシュ

   前回取得した名前解決の結果を永続的にキャッシュできます。アプリの再起動後、名前解決の結果は永続化レイヤーから優先的に読み込まれます。これにより、初回の読み込み速度が向上します。

シナリオ：ISP をまたぐ名前解決によるアクセスレイテンシー

背景情報

CDN で高速化されたドメイン名や、インテリジェントルーティング解決が設定されたドメイン名を使用する場合、クライアントが DNS 名前解決で取得した IP アドレスを TTL 値に基づいてキャッシュしていると、ネットワーク環境が変化したときに問題が発生する可能性があります。たとえば、4G ネットワークから Wi-Fi に切り替わった場合 (またはその逆) などです。このような場合、キャッシュされた IP アドレスは新しいネットワーク環境の最適ルートと一致しなくなり、ビジネス関連のネットワークリクエストでパフォーマンスが低下する可能性があります。

ソリューション

1. ネットワーク環境の監視

   • クライアントネットワークの変更 (例：Wi-Fi からモバイルデータへの切り替え) を監視します。

   • ローカルキャッシュを積極的にリフレッシュして、名前解決の結果が現在のネットワーク環境と互換性があることを確認します。

2. 速度テストとソート

   ICMP または TCP の非同期テストを使用して名前解決の結果をランク付けし、応答時間が最も速い IP アドレスを優先します。

シナリオ：名前解決リクエストのハイジャックまたは漏洩

背景情報

認証メカニズムのない名前解決 API は、第三者によってトラフィックを盗まれ、コストが発生する可能性があるため、セキュリティリスクをもたらします。

ソリューション

1. 認証解決

   認証付きの API 操作を使用してドメイン名を解決することを推奨します。HTTPDNS コンソールで、認証なしの API 操作を無効にするかどうかを選択できます。

   • これらの操作を呼び出してドメイン名を解決すると、HTTPDNS はシークレットキーを使用して暗号化された文字列を生成し、その文字列を認証のためにリクエストに含めます。シークレットキーはリクエストに含まれないため、漏洩リスクが低減され、名前解決リクエストのセキュリティが確保されます。

   • 詳細については、「認証アクセスを実装する」をご参照ください。

2. HTTPS を使用したセキュアな通信

   • HTTPS プロトコルを使用する場合、カスタム証明書検証が必要です。検証は 203.107.1.1 または resolvers-cn.httpdns.aliyuncs.com を指すように設定する必要があります。

   • Android での実装については、「Android での HttpURLConnection を用いた HTTPDNS のベストプラクティス」をご参照ください。

   • iOS のシナリオについては、「iOS 向け HTTPDNS SDK の統合」をご参照ください。