インテリジェント DNS 解析が不正確な場合のトラブルシューティング - Alibaba Cloud DNS

Alibaba Cloud DNS で設定したインテリジェント DNS 解析の回線が期待どおりにトラフィックをルーティングしない場合は、このトピックの方法に従ってトラブルシューティングを行ってください。

重要

この方法は、Alibaba Cloud DNS を使用するドメインにのみ適用されます。ご利用のドメインが他のプロバイダーの DNS サーバーでホストされている場合は、DNS プロバイダーにサポートを依頼してください。

1. ローカル DNS の送信元 IP の確認

Alibaba Cloud DNS は、クライアント自身の IP アドレスではなく、クライアントのローカル DNS の送信元 IP に基づいてインテリジェント DNS 解析を実行します。

ネットワーク管理者に連絡して、詳細な DNS 送信元 IP を取得してください。
IP アドレスを取得するには、次のコマンドを数回実行します：dig +short TXT whoami.ds.akahelp.net (Linux の場合) または nslookup -q=txt whoami.ds.akahelp.net (Windows の場合)。

重要

診断コマンドは次のパラメーターを返します：

$ dig +short TXT whoami.ds.akahelp.net ok at 11:20:47# Linux 用のコマンド。
"ns" "123.126.xx.xx" # ns はローカル DNS の送信元 IP で、IPv4 または IPv6 アドレスです。
"ecs" "120.52.xx.xx/32/24" # ecs (EDNS-client-subnet) は、クエリリクエストに含まれるクライアントサブネットです。
"ip" "123.126.xx.xx" # ip は、権威 DNS サーバーが ecs から選択したクライアントの代表 IP アドレスです。ユーザーのプライバシーを保護するため、ローカル DNS は実際のクライアント IP を送信しません。

Windows コマンドの出力

C:\Users\xxx>nslookup -q=txt whoami.ds.akahelp.net
Server:  Unknown
Address:  172.20.10.1
Non-authoritative answer:
whoami.ds.akahelp.net   text =
        "ns"
        "197.234.xxx.29"
whoami.ds.akahelp.net   text =
        "ip"
        "197.239.xxx.163"
whoami.ds.akahelp.net   text =
        "ecs"
        "197.239.xxx.xxx/24/24"

Linux コマンドの出力

[root@iZbp1igkb78js3gsxxx ~]# dig +short TXT whoami.ds.akahelp.net
"ns" "2404:6800:4005:c08::xxx"
"ecs" "112.124.xxx.0/24/24"
"ip" "112.124.xxx.5"

ローカル DNS の送信元 IP を取得した後、dig <domain_name> @vip4.alidns.com +subnet=<local_DNS_egress_IP> を実行し、結果が正しいことを確認します。

説明

vip4.alidns.com パラメーターを、ご利用の実際の DNS サーバーの名前に置き換えてください。詳細については、「DNS サーバーのステータスの表示と例外の処理」をご参照ください。

2. カスタム回線の DNS レコードが有効にならない

カスタム回線は、リクエストソースの IP アドレス範囲を定義します。クライアント自身の IP アドレスではなく、クライアントのローカル DNS の送信元 IP の範囲を指定する必要があります。そうしないと、カスタム回線が一致せず、Alibaba Cloud DNS はデフォルト回線の DNS レコードを返します。

重要

ローカル DNS は複数の送信元 IP を持つことがよくあります。最も正確なカスタム回線を作成するには、ネットワーク管理者からこれらの IP の完全なリストを取得してください。
ローカル DNS の送信元 IP が少数しかない場合は、次のコマンドを数回実行して特定します：dig +short TXT whoami.ds.akahelp.net (Linux の場合) または nslookup -q=txt whoami.ds.akahelp.net (Windows の場合)
カスタム回線は IPv6 アドレスをサポートしていません。ローカル DNS の送信元 IP が IPv6 アドレスの場合、カスタム回線は一致せず、システムはデフォルト回線の DNS レコードを返します。

3. デフォルト回線の CNAME キャッシュが不正確なルーティングを引き起こす仕組み

ユースケース

デフォルト回線に CNAME レコードが設定されている。
デフォルト以外の回線に CNAME 以外の DNS レコード (A、AAAA、TXT、MX レコードなど) を設定する。

原因分析

デフォルト以外の回線の DNS レコードに対してリクエストが行われた場合：

リクエストされたレコードタイプが A で、対応する回線に AAAA レコードはあっても A レコードがない場合、システムは空の応答を返します。これは不正確なルーティングを引き起こしません。
リクエストされたレコードタイプが AAAA で、対応する回線に A レコードはあっても AAAA レコードがない場合、システムは空の応答を返します。これは不正確なルーティングを引き起こしません。
リクエストされたレコードタイプが A で、対応する回線に A または AAAA レコードがなく (TXT や MX などのレコードのみ)、システムはデフォルト回線の CNAME レコードを返します。その後、ローカル DNS はこのレコードをキャッシュし、不正確なルーティングにつながります。
リクエストされたレコードタイプが AAAA で、対応する回線に A または AAAA レコードがなく (TXT や MX などのレコードのみ)、システムはデフォルト回線の CNAME レコードを返します。その後、ローカル DNS はこのレコードをキャッシュし、不正確なルーティングにつながります。
MX や TXT などのレコードタイプのリクエストで、対応する回線にそのタイプのレコードが設定されていない場合、システムはデフォルト回線の CNAME レコードを返し、ローカル DNS はそれをキャッシュします。CNAME レコードは最も高い優先度を持つため、その後の A または AAAA クエリ (たとえデフォルト以外の回線に設定されていても) は、TTL が切れるまで、キャッシュされた CNAME レコードに誤って解決されてしまいます。これにより、不正確なルーティングが発生します。

解決策

これを修正するには、デフォルト以外の回線の A レコードと AAAA レコードに中間 CNAME レコードを使用します。例えば、ドメイン dns-example.top の場合、まず test.dns-example.top の A レコードと AAAA レコードを作成し、ご利用の IPv4 および IPv6 アドレスを指すようにします。次に、China Mobile 回線のサービスドメインに対して、test.dns-example.top を指す CNAME レコードを作成します。

重要

サブドメイン test.dns-example.top は一例です。既存の DNS レコードがない新しいサブドメインを使用してください。
CNAME レコードを追加する前に、A レコードと AAAA レコードを追加する必要があります。そうしないと、解析が停止する可能性があります。

変更前：

ホストレコード	タイプ	リクエストソース	値
@	AAAA	China Mobile	ff03:0:0:0:0:0:0:c1
@	A	China Mobile	223.5..
@	CNAME	デフォルト	www.aliyun.com

変更後：

ホストレコード	タイプ	リクエストソース	値
@	AAAA	China Mobile	ff03:0:0:0:0:0:0:c1
@	A	China Mobile	223.5..
@	CNAME	China Mobile	test.dns-example.top
@	CNAME	デフォルト	www.aliyun.com

デフォルト回線とデフォルト以外の回線の両方で CNAME レコードが使用されるようになり、これらは同じ優先度を共有します。クライアントが回線に設定されていないレコードタイプ (MX や TXT など) をリクエストすると、システムはデフォルトの CNAME の代わりに空の応答を返します。これにより、キャッシュ汚染が防止されます。