How to optimize your network- DNS domain name resolution service

1. ドメイン名前解決サービス
デバイスが指定されたドメイン名とポートにアクセスして IoT Platform に接続する際、最初に直面する問題はアクセス先サーバーのドメイン名の DNS 名前解決です。
ドメイン名 (Domain Name) は、インターネット上のコンピューターまたはコンピューターのグループを識別するもので、ドットで区切られた一連のラベルから構成されます。その目的は、ユーザーがインターネット上のサービスに、よりシンプルかつ便利にアクセスできるようにすることです。実際のシステム実装では、ドメイン名は DNS (Domain Name System) システムを通じてサーバーの IP アドレスに変換され、マシンの IP ベースのアドレス指定と通信を容易にします。この動作をドメイン名前解決 (Domain Name System) と呼びます。

再帰クエリ
再帰クエリでは、クライアントが問い合わせたローカル DNS サーバーが、問い合わせ対象のドメイン名の IP アドレスを知らない場合、ローカル DNS サーバーは DNS クライアントとして他の上位ドメインネームサーバーにクエリを継続し、結果を取得するまでこのプロセスを繰り返します。その後、結果は下位レイヤーへ受け渡されます。


反復クエリ
反復クエリでは、クライアントが問い合わせたローカル DNS サーバーが、問い合わせ対象のドメイン名の IP アドレスを知らない場合、次のレベルのドメインネームサーバーのリストがクライアントに通知され、クライアント自身が問い合わせを行います。


実際の DNS クエリプロセス
実際の DNS クエリプロセスでは、ローカル DNS サーバーがクライアントの代理として反復クエリを実行します。ただし、ローカル DNS には名前解決の結果を決定する権限はなく、ユーザーのプロキシとして権威 DNS から名前解決の結果を取得するだけです。ローカル DNS にはキャッシュモジュールがあり、対象ドメイン名の解決結果がキャッシュされていて TTL が切れていない場合、ローカル DNS はキャッシュされた結果を返します。それ以外の場合、ローカル DNS は各ドメインレベルの権威 DNS に反復クエリを段階的に実行し、最終的な完全な名前解決結果を取得します。同時に、クライアント側でも TTL 値に基づいてキャッシュすることで、クエリ回数を削減し、名前解決プロセスを高速化できます。

pk.iot-as-mqtt.cn-shanghai.aliyuncs.com へのアクセスを例に、完全な名前解決プロセスを見ていきましょう。完全なドメイン名前解決プロセスは以下の通りです。

1. デバイス端末がローカル DNS に名前解決リクエストを送信
2. ローカル DNS は名前解決リクエストを受信後、まずルートヒントからルートドメイン (.) ネームサーバーのアドレスを取得
3. ルートドメインネームサーバーのアドレスを取得後、ローカル DNS はルートドメインネームサーバーに DNS 解決リクエストを送信
4. ルートドメインネームサーバーがトップレベルドメイン (.com) サーバーのアドレスを返答
5. ローカル DNS はトップレベルドメイン (.com) サーバーに解決リクエストを送信し、セカンドレベルドメイン (aliyuncs.com) サーバーのアドレスを取得
6. ローカル DNS はセカンドレベルドメイン (aliyuncs.com) サーバーに解決リクエストを送信し、最終的に pk.iot-as-mqtt.cn-shanghai.aliyuncs.com の IP アドレス情報を取得
7. ローカル DNS は再帰クエリで取得した IP アドレス情報を TTL に基づいてキャッシュし、デバイス端末に返答
8. デバイス端末は送信先 IP にネットワークリクエストを送信

2. DNS 名前解決の実験

2.1 DNS 名前解決の確認
ドメイン名 pk.iot-as-mqtt.cn-shanghai.aliyuncs.com にアクセスするには、まず DNS を通じてその IP アドレスが 139.196.135.135 であることを調べる必要があります。
dig コマンドを使用すると、ドメイン名に対応する IP リストを確認できます。以下に示します。

前述の図は、現在の Mac コンピュータがローカル DNS サーバーからドメイン名の IP リストを取得している様子を示しており、TTL 値 (Time to Live) は 18 秒です。


2.2 DNS 解決の完全なプロセス
DNS サーバーはドメイン名の階層に従って段階的にクエリを実行します。つまり、ルートドメインから始めて各レベルのドメインの NS レコードを順次問い合わせ、最終的な IP アドレスを特定します。プロセスは概ね以下の通りです。

1. ルートドメインネームサーバーからトップレベルドメインネームサーバーの NS レコードと A レコード (IP アドレス) を取得
2. トップレベルドメインネームサーバーからセカンドレベルドメインネームサーバーの NS レコードと A レコード (IP アドレス) を取得
3. セカンドレベルドメインネームサーバーからホスト名の IP アドレスを取得
各ドメインレベルには固有の NS レコードがあり、NS レコードはそのレベルのドメインネームサーバーを指し示しています。これらのサーバーは下位レベルのドメインに関するさまざまなレコードを把握しています。
dig +trace を使用することで、完全な名前解決プロセスを確認できます。以下に示します。

前述の図は DNS の完全なプロセスを示しています。

1. まず、Mac コンピュータがローカル DNS サーバーからルートドメイン (.root) サーバーリストを取得
2. 次に、ルートドメインネームサーバーの 1 つ (198.41.0.4) からトップレベルドメイン (.com) サーバーリストを取得
3. その後、トップレベルドメインネームサーバーの 1 つ (192.48.79.30) からセカンドレベルドメイン (aliyuncs.com) のサーバーリストを取得
4. 最後に、セカンドレベルドメインネームサーバーの 1 つからターゲットドメイン名の IP リストを取得し、合計 3 つの IP アドレスが得られた

3. IoT シナリオにおける DNS 解決

3.1 ドメイン名前解決の潜在的問題
DNS ドメイン名前解決サービスの完全なプロセスを理解すると、従来のドメイン名前解決には以下の問題があることが分かります。

ドメインハイジャック
ドメインハイジャックは、多くの開発者を悩ませてきた問題の 1 つです。その現象は、ドメイン A が返すべき DNS 解決結果 IP1 が、悪意を持って IP2 に置き換えられ、A へのアクセスが失敗したり、安全でないサイトにアクセスしてしまうというものです。

スケジューリング精度の問題
ドメインハイジャックの問題に加え、従来のローカル DNS ベースの名前解決では、スケジューリング精度の問題も生じます。CDN ドメインアクセスのように、リージョンや通信事業者ごとにインテリジェントな解決とスケジューリングが必要なシナリオでは、正確なスケジューリングに対する要求が非常に高くなります。

名前解決の変更反映の遅延
一部のビジネスシーンでは、開発者は DNS 名前解決の変更が反映されるまでの時間に非常に敏感です (この変更操作は開発者が権威 DNS で完了させます)。たとえば、ビジネスサーバーが攻撃を受けた際に別クラスターグループにビジネス IP を切り替える必要がある場合、従来のドメイン名前解決ではこのような要求に対応できません。

大きな遅延
初回 DNS クエリやキャッシュ期限切れ後のクエリでは、最終的な解決結果を取得するために複数の DNS サーバーを再帰的に走査する必要があり、ネットワークリクエストに追加の遅延が生じます。特にモバイルインターネットシナリオでは、モバイルネットワークの品質は不均一で、弱いネットワーク環境での RTT は数百ミリ秒に達することもあります。通常のサービスリクエストにとって、この遅延は非常に大きな負担となります。一方で、名前解決のタイムアウトや名前解決の失敗は、弱いネットワーク環境ではよく発生します。DNS 解決を適切に最適化することは、ネットワークアクセス品質全体の向上に不可欠です。

3.2 Alibaba Cloud HTTPDNS サービス
Alibaba Cloud の HTTPDNS サービスは、このような背景のもとに誕生し、より安全で安定的かつ効率的な再帰 DNS サービスを提供するとともに、ドメイン名の解決プロセスを代行しています。

HTTPDNS は HTTP プロトコルを使用してドメイン名を解決し、従来の UDP ベースの DNS プロトコルを置き換えます。ドメイン名の解決リクエストは HTTPDNS サーバーに直接送信されるため、通信事業者のローカル DNS を迂回でき、エンドユーザーの IP 情報を権威 DNS に直接伝達できます。これにより、ローカル DNS の干渉を回避でき、権威 DNS で変更された解決結果は HTTPDNS に迅速に同期され、元のキャッシュレコードを上書きして、ユーザーの秒レベルでのドメイン名前解決切り替えを実現します。


3.3 IoT シナリオでの DNS 実践
IoT Platform コンソールでプロダクトを作成すると、対応するデバイスに指定されたアクセスドメイン名が生成されます。次の図に示します。


次に、HTTPDNS コンソールに IoT デバイスアクセス用のドメイン名解決サービスを追加する必要があります。下の図に示します。


その後、HTTPDNS の IP に直接アクセスして、デバイスアクセスドメイン名の IP リストを取得します。次の図を参照してください。

最後に、IoT デバイスはこの IP リスト内の IP に直接アクセスし、IoT Platform との MQTT ロングコネクションを確立できます。