HTTPDNS:ネイティブ iOS シナリオでの HTTPDNS の使用

1. はじめに

モバイルネットワーク環境では、DNS ハイジャックやローカル DNS のキャッシュ汚染といった問題により、ドメイン名の解決が正しく行われず、ネットワークリクエストが失敗することがよくあります。このようなシナリオに対し、Alibaba Cloud HTTPDNS は信頼性の高い再帰的なドメイン名解決サービスを提供します。このサービスにより、モバイルアプリはローカル DNS の潜在的なリスクをバイパスし、ネットワークリクエストの成功率と安定性を向上させることができます。

しかし、iOS プラットフォームで HTTPDNS を使用する場合、リクエストを開始する前に、リクエスト内の元のドメイン名を解決済みの IP アドレスに置き換える必要があります。これは、特に HTTPS やサーバ名表示 (SNI) のような複雑なシナリオで、さらなる問題を引き起こす可能性があります。したがって、HTTPDNS を統合する前に、潜在的な問題と実行可能なソリューションを包括的に理解しておく必要があります。これにより、ビジネスで HTTPDNS を安全かつ正しく使用できるようになります。

このトピックでは、iOS で HTTPDNS を使用する際に遭遇する可能性のある主な問題について説明します。また、開発者が迅速に HTTPDNS の統合を完了できるよう、さまざまなシナリオ向けの統合ソリューションとその長所と短所を提示します。

2. iOS で HTTPDNS を使用する際の問題

モバイルアプリケーションでは、元の URL 内のドメイン名 (例: example.com) を HTTPDNS によって解決された IP アドレスに置き換えると、しばしば以下の問題が発生します。これらの問題は、HTTPS プロトコルが異なるレイヤー (TLS/SSL レイヤーと HTTP レイヤー) で Host フィールドをどのように使用するかと密接に関連しています。

• TLS/SSL レイヤー： HTTPS シナリオでは、クライアントはまず TLS/SSL ハンドシェイクを実行します。クライアントは URL の Host を使用して、以下のタスクを完了します。

  1. 証明書検証：サーバー証明書のドメイン名 (コモンネームまたはサブジェクト代替名) がリクエストされた Host と一致することを確認します。

  2. SNI：TLS 接続を確立する際、クライアントはリクエストされたドメイン名情報 (URL 内の Host) をサーバーに送信します。これにより、サーバーは対応する証明書を返すことができます。

• HTTP レイヤー： TLS ハンドシェイクが完了した後、クライアントは HTTP リクエストヘッダーに Host フィールドを含めます。これにより、リクエストの対象となる特定のサイトまたはリソースをサーバーに伝えます。URL 内のドメイン名を IP アドレスに置き換え、HTTP ヘッダーで Host を手動で設定しない場合、サーバーは実際にアクセスされているドメイン名を識別できない可能性があります。これにより、リクエストが失敗したり、異常なコンテンツが返されたりすることがあります。

HTTPS プロトコルスタックの各レイヤーにおける Host の役割に基づき、URL 内のドメイン名を HTTPDNS で解決された IP アドレスに置き換えると、以下の技術的な問題が発生します。

1. ドメイン名と証明書の不一致 HTTPS リクエストの場合、HTTPDNS で解決された IP アドレスを URL の Host として直接使用すると、TLS レイヤーで正しい証明書ドメイン名 (コモンネームまたは SAN 追加ドメイン名) を照合できず、SSL ハンドシェイクが失敗します。

2. SNI の問題 SNI シナリオでは、単一のサーバー IP アドレスが複数のドメイン名の証明書に対応する場合があります。クライアントが SSL ハンドシェイクの段階で正しいドメイン名情報を渡さず、IP アドレスのみを送信した場合、サーバーはドメイン名に一致する証明書を返すことができません。これにより、SSL ハンドシェイクが失敗します。iOS の高レベルなネットワーク API (例: NSURLSession) は SNI を直接設定するインターフェイスを公開していないため、SNI の問題は簡単な方法では解決が困難なことが多いです。

3. Host ヘッダーとサービスアドレッシング URL 内のドメイン名を IP アドレスに置き換えたものの、HTTP リクエストヘッダーの Host を元のドメイン名に明示的に設定し忘れた場合、サーバー側は HTTP レイヤーで特定のサイトやリソースを識別できない可能性があります。例えば、CDN シナリオでは、サーバーは Host フィールドに依存して正しいコンテンツを配信します。Host が IP アドレスの場合、サービスは異常になります。

4. 下位レベルのネットワークライブラリの選択 iOS の組み込み高レベル API (例: NSURLSession) は、SNI のカスタマイズや手動での証明書検証に対する拡張性が限られています。開発者が SNI を処理したり、TLS ハンドシェイクのロジックを変更したりしたい場合は、CFNetwork や libcurl のような、より低レベルのインターフェイスを使用する必要があります。しかし、これにより開発およびメンテナンスコストが増加します。

要約すると、URL 内のドメイン名を HTTPDNS で解決された IP アドレスに直接置き換えることは、HTTPS シナリオにおいて TLS レイヤーでの証明書検証と SNI 転送に影響を与えます。また、HTTP レイヤーで Host ヘッダー情報が異常になる可能性もあります。したがって、iOS で HTTPDNS を統合する際には、ネットワークリクエストの信頼性とセキュリティを確保するために、これらの問題に的を絞って対処する必要があります。

3. 推奨ソリューション：EMASCurl との統合

実際の iOS アプリケーションでは、HTTPS が標準であり、CDN、単一 IP での複数ドメイン、SNI を含むシナリオが一般的です。これらの課題に対処するため、Alibaba Cloud EMAS チームは libcurl 上に構築された iOS ネットワークライブラリである EMASCurl を提供しています。これは HTTPDNS と直接連携し、iOS での IP 直連を実装するための推奨ソリューションです。コードはオープンソースで、GitHub で入手できます。

このセクションでは、EMASCurl ソリューションのユースケース、統合アプローチ、および使用上の注意について説明します。具体的なインストール手順、インターセプト設定、API の使用方法については、GitHub の README ファイルをご参照ください。

1. インストールとインターセプト

   • 主に 2 つの方法で使用できます。

     1) 特定の NSURLSessionConfiguration で作成された NSURLSession からのリクエストをインターセプトする。

     2) システムのグローバルな [NSURLSession sharedSession] からのリクエストをインターセプトする。

2. HTTPDNS との統合

   • EMASCurlProtocolDNSResolver プロトコルを実装して、HTTPDNS の解決結果を EMASCurl に渡します。

   • resolveDomain: メソッドで、[HttpDnsService resolveHostSyncNonBlocking:] を呼び出して IP アドレスを取得します。その後、それを EMASCurl に返して SNI の設定とリクエストの送信を処理させます。

3. 証明書検証

   • EMASCurl は libcurl の証明書検証メカニズムに依存しています。提供されているインターフェイスを通じて証明書検証を拡張またはカスタマイズし、サービスの要件を満たすこともできます。

4. HTTP/3 のサポート

   • EMASCurl は、QUIC 対応の libcurl をベースにしたカプセル化バージョンである EMASCurl/HTTP3 を提供しています。必要に応じてこれを統合することで、追加の適応なしに HTTP/3 の機能を使用できます。

以下の例は、EMASCurl を HTTPDNS と統合するための基本的な方法を示しています。

@interface MyDNSResolver : NSObject <EMASCurlProtocolDNSResolver>
@end

@implementation MyDNSResolver

+ (nullable NSString *)resolveDomain:(nonnull NSString *)domain {
    HttpDnsService *httpdns = [HttpDnsService sharedInstance];
    HttpdnsResult *result = [httpdns resolveHostSyncNonBlocking:domain
                                                      byIpType:HttpdnsQueryIPTypeBoth];
    if (!result || (!result.hasIpv4Address && !result.hasIpv6Address)) {
        return nil;
    }

    NSMutableArray<NSString *> *allIPs = [NSMutableArray array];
    if (result.hasIpv4Address) {
        [allIPs addObjectsFromArray:result.ips];
    }
    if (result.hasIpv6Address) {
        [allIPs addObjectsFromArray:result.ipv6s];
    }
    return [allIPs componentsJoinedByString:@","];
}

@end

- (void)setupEMASCurl {
    EMASCurlConfiguration *config = [EMASCurlConfiguration defaultConfiguration];

    // Configure the HTTPDNS resolver
    config.dnsResolver = [MyDNSResolver class];

    NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];

    // Install EMASCurl
    [EMASCurlProtocol installIntoSessionConfiguration:sessionConfig
                                    withConfiguration:config];

    // Create a specific session
    self.session = [NSURLSession sessionWithConfiguration:sessionConfig];
    
    // Use this session for subsequent requests
}

4. 簡略化されたシナリオ向けの統合ソリューション

平文 HTTP または SNI を使用しない HTTPS のシナリオでは、通常、システムの組み込み NSURLSession と通常のネットワークリクエストロジックを引き続き使用し、簡単な調整で HTTPDNS を統合できます。これらのソリューションは実装がより簡単で、特定のシナリオに適していますが、適用範囲は限定的です。

平文 HTTP シナリオでは TLS ハンドシェイクや証明書検証は行われませんが、SNI を使用しない HTTPS シナリオでは、依然として証明書検証を処理する必要があります。これは NSURLSession の検証プロセスをフックすることで実行できます。

5. HTTPS + SNI シナリオ向けのその他のソリューション

HTTPS + SNI シナリオでは、EMASCurl の他に、より低レベルの機能を使用して HTTPDNS の統合を実装することもできます。これらのソリューションは通常、より高い柔軟性を提供しますが、開発およびメンテナンスコストも高くなります。これらは、既存のカスタムネットワークスタックがある、より強力な低レベルの制御が必要、またはクロスプラットフォームの統一要件があるシナリオに適しています。特別な要件がない場合は、EMASCurl ソリューションの使用を推奨します。

CURL *curl_handle = curl_easy_init();
if (curl_handle) {
    // For example, get IP = 1.2.3.4 from HTTPDNS, target domain = example.com, and port = 443
    struct curl_slist *dnsResolve = NULL;
    dnsResolve = curl_slist_append(dnsResolve, "example.com:443:1.2.3.4");
    // Set the domain-to-IP mapping
    curl_easy_setopt(curl_handle, CURLOPT_RESOLVE, dnsResolve);

    // Continue to use the original domain as the URL
    curl_easy_setopt(curl_handle, CURLOPT_URL, "https://example.com");

    // Enable SSL verification
    curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 1L);
    curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYHOST, 2L);

    // Initiate the request
    CURLcode res = curl_easy_perform(curl_handle);

    // Check the result
    if (res != CURLE_OK) {
        fprintf(stderr, "curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
    }

    // Clean up
    curl_easy_cleanup(curl_handle);
    curl_slist_free_all(dnsResolve);
}

6. まとめ

SNI、複数ドメイン名、証明書検証をサポートする必要があるかどうかなど、ビジネスニーズに基づいてソリューションを選択できます。以下の表は、さまざまなソリューションを比較したものです。

ビジネスの複数ドメインのニーズ、ネットワークセキュリティ要件、互換性、メンテナンスコスト、およびサードパーティライブラリの受け入れに基づいてこれらのソリューションを評価できます。ソリューションを公開する前に、最も適切な統合ソリューションを選択し、ネットワークリクエストの可用性とセキュリティを徹底的にテストする必要があります。