複数のCNAMEを持つ


11

歴史的な理由により、5レベルのCNAMEを持つDNSドメインがあります。高可用性などのために外部委託されたものもありますが、それはここでのポイントではありません。私の質問は、5つのCNAMEがDNSリゾルバーにとって過剰であることですか?異なるDNSドメインを指す2〜3レベル以上のネストされたCNAMEを持つ有名なWebサイトを見つけることができませんでした。

CNAMEホップは次のようになります。(例としてxyzを使用しています)

www.xyz.com-> xyz.akadns.net-> xyz.worldwide.akadns.net-> xyz.cedexis.net-> xyz.msedge.net-> host1.msedge.net(最終A \ AAAAレコード)

私が使用している場合が他のサイトには、彼らのために罰金を操作するときに、多くのクライアントが当社のウェブサイトにDNS解決の問題について文句を言う見ていhttp://check-host.net/check-dns?host=www.xyz.comを私たちのDNSをテストします解決。

常に世界中でうまく機能しているようです。私の結論は、ほとんどの場合、上記のホップの1つが解決に失敗すると、ローカルISPプロバイダーのDNSリゾルバーが台無しになるということです。これらのクライアントコンピューターでは、nslookupが失敗するのは、Webサイトのみであり、散発的です。

この種のマルチレベルCNAMEは一般的に悪い設計ですか?


1
私は数年前にアカマイで働いていましたが、ある顧客が特定のルーターに5レベルのネストの問題があると報告しました。ルータのファームウェアは最終的に修正されたと思います。
バーマー

回答:


15

この種のマルチレベルCNAMEは一般的に悪い設計ですか?

CNAMEからCNAMEへのチェーンは禁止されていませんが、既に経験しているように、非常に堅牢なソリューションではありません。

CNAMEを追加するたびにリゾルバの再帰の深さが増加し、その深さは常に無制限ではありません。また、ループを作成したり、ループ検出アルゴリズムをトリガーしたりするリスクがあります。

ユーザーネームサーバーで実行する必要があるクエリの数とクエリの印象を得るには、DNSトレースを実行します。

dig +trace www.example.com 

またはWindows

nslookup -debug www.example.com

10

HBrujinは正しいのですが、実際のところ、再帰の深さは、他のものよりもずっと悪いdig +traceです。再帰の深さは、しばしば冷笑され、あまりにつまらないものですが、それらの人々は、あなたが〜5 CNAMEレコードを解決しているだけではないことを忘れています。これは、CNAMEレコードのターゲットを解決すると、パス内のすべてのネームサーバーを検索する必要が生じるためです。

CNAMEターゲットは別のドメインに住んでいますか?ネームサーバーに再帰する必要があります。これには、NSレコードの検索だけでなくA(AAA)、グルーが存在しない検索も必要です。以下のためのネームサーバでくださいこれらのネームサーバーは、さまざまなトップレベルドメインに住んでいますか?それらのTLDがネームサーバーを共有しない場合、接着剤レコードが含まれない可能性があり、他のTLDのネームサーバーも再帰する必要があります。等々。

CNAMEチェーンに追加されるすべてのレコードは、再帰する必要のあるネームサーバーの数に応じて、必要なルックアップの数に指数関数的に追加できます。これらの一連のCNAME+ NS+ A(AAA)レコード検索は、めちゃくちゃ複雑になり、空のキャッシュで150レベルをはるかに超える深さに達する可能性があります。これは、再帰の深さの制限が非常に厄介になる可能性があり、空のキャッシュでドメインを検索する一時的な障害を引き起こし、すぐには明らかにならないことが多い理由です。

要するに、あなたはこれを行うことができますが、注意して進め、この性質のフィードバックを真剣に受け止めてください。インターネット上の再帰的なDNSサーバーが再起動またはパージされる頻度を制御することはできません。


私のクライアントソフトウェアは、リモートHTTP呼び出しを行う多数のマシン上にあります。クライアントからすべてのCNAMEを再試行して、リゾルバーの再帰の深さ\負荷を減らしても問題はありませんか?これは良いアプローチに聞こえますか、何か不足していますか?CNAMEは地域を越えて変更されないことを知っています。
ヴィシャルナイドゥ

良いアプローチではありません。通常、データの検索に失敗したサーバーは、一時的に障害をキャッシュします。クエリは将来(たとえば、5分後)に再び成功する可能性がありますが、すぐに再試行しても成功する可能性は低いです。DNSレコードの名前を提供していただければ、これが本当に再帰の深さの問題なのか、それともそれほど明白でないのかをお知らせできます。私たちが間違ったウサギの穴を下るのは嫌だ。
アンドリューB

0

マルチレベルCNAMEは、実際にはしばしば便利です。リダイレクトの各レベルは、潜在的に異なる管理ゾーンまたはまったく異なる組織での制御レベルを提供します。これは技術的に必要なことではありませんが、組織の問題を回避できます。

他の人々がこれを困難にする可能性があると指摘しているように、これらは対処できます:

  • すべてのDNSサーバーを監視します。たぶん1つが故障しています。外部サーバーだけでなく外部サーバーも監視します。問題をアカマイまたは他のベンダーに報告する必要がある場合があります。

  • TTLsは、キャッシングを許可するのに十分高い値に設定する必要がありますが、アプリケーションに十分な速度でトラフィックをシフトできるように低く設定する必要があります


2
監視の推奨事項を理解しているかわかりません。再帰の深さの制限は製品ごとに異なるだけでなく、それらを監視することをどのように提案しますか?誰かの再帰的なインフラの根本的な原因を簡単に特定することはできません。
アンドリューB
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.