DNSレコードの公開でエラーが発生したり、このサービスが短期的に動作不能になったりすると、ユーザーからのトラフィックの損失など、非常に悲しい結果につながる可能性があります。 一方、DNSは非常にスケーラブルであり、単一サーバーの障害に対して耐性があります。
DNSは重要です。専門家はこれを理解しています。 それにもかかわらず、それを管理する際の過ちは、大企業でも見られます。 そして、それらは重大な問題につながるまで気づかれません。
たとえば、プレゼンテーションを必要としないVkontakte会社のDNSエラーのリスト：
vk.comレジストラには、権限のあるドメインサーバーの次のリストがあります。
- ns1.vkontakte.ru
- ns2.vkontakte.ru
- ns3.vkontakte.ru
- ns4.vkontakte.ru
次のリストは、Vkontakteの権限のあるサーバー自体にリストされています。
- ns1.vkontakte.ru
- ns2.vkontakte.ru
- ns4.vkontakte.ru
レジストラのリストとは異なります！
さらに、サーバー
ns2.vkontakte.ru
[93.186.224.100]は、少なくとも現在はリクエストに応答しません。
SkypeとMicrosoftのエラー：
cloudapp.netへのリクエストに応じて、Authorityセクションは返されません。
特に、 skypeecs-prod-euw-0-b.cloudapp.netへのリクエスト「
AAAA
」のタイプに応じて。 このため、RFCが厳密に観察された場合にこれを実行できる期間が不明であるため、このような要求に対する否定的な応答はキャッシュできません。
TwitterおよびDynエラー：
Dynサーバー
NS
リクエストのタイプに対するplatform.twitter.comへのリクエストへの応答で、Twitterサービスはそのようなレコードが存在しないと応答します。 同時に、彼らは
CNAME
レコードで同じ名前の他のタイプのリクエストに応答します。
したがって、
NS
要求のタイプに対するこの応答をすでにキャッシュしている場合、RFC標準に厳密に従うと、他のタイプの要求の同じ名前への応答に
CNAME
をキャッシュできません。 実際、この場合、キャッシュ再帰サーバーの動作は標準によって決定されず、プログラマー自身のロジックに左右されます。
上場企業には、この記事で説明されているよりも多くのエラーがありますが、記事を過負荷にしたがらないため、私はそれらを公開しないようにしました。
公開されたすべてのエラーは、2016年5月7日に関連していました。この記事を読んだ時点では、もはやエラーではない可能性があります。