「私の友人」（c）は、DNSでの彼の冒険について話をしました。
背景
2016年が終わり、DNSサーバーに数百のドメインがあり、かなり前に5つの強力なDNSサーバーを異なるデータセンターで実行し始めたと想像してください。最近、家賃を引いてスペースを占有する古いDNSサーバーを最終的に取り除きたいと思います。ラックに。 ただし、それらの電源をオフにしようとした直後は、サポート用の電話が真っ赤になっているため、古いサーバーの電源をすばやく入れて、十分に理解する必要があります。
第1章
もう一度DNSゾーンをチェックし、古いアドレスがどこにも存在しないことを非常に長い間確認します。 NSごとにリクエストがあるさまざまな地域からチェックします。 どこでもすべてが正しく与えられます。 tcpdumpを使用して、古いDNSのポート53の要求を調べます。 驚くほど多くのリクエストがあることがわかりました。 そして、これらのサーバーのIPアドレスが何ヶ月も紹介されていないという事実にもかかわらずです！
新しいDNSでtcpdumpを調べますが、古いものよりもはるかに少ないリクエストがあります。 ただ奇跡！
古いDNSへのクエリを分析した後、上位10のクライアントアドレスを取得し、それが大規模な国内プロバイダー（Rostelecom、TTKなど）のBIND9（dig + short version.bind txt chaos @ serverに対応）であることがわかります。
第2章
プロバイダーのDNSサーバーを介してホームインターネットからクライアントドメインを解決し（
dig any clientsite.ru. @ns1.provider.ru
）、追加セクションで誤ったIPアドレスと巨大なTTL 345600（4日!!!） さらに、ドメイン名が委任されると、プロバイダーのDNSサーバーは正しいIPと正しいTTLで応答を開始しますが、「幸福」はこのTTLの有効期限とともに終了します。 状況は、プロバイダーが再帰としてBIND9を使用する10のうち6つのケースで再現されます。 私たちは、debianおよびubuntuでBIND9の最新バージョンを使用してテストサイトを組み立てています。状況は再現、再起動などです。 助けないで
第3章
突然、アイデアは.RUゾーンのルートサーバーを要求するようになりました（現在はa.dns.ripn.net。、B.dns.ripn.net。などです。リストは
dig ns ru.
コマンドで取得できます）。 また、無効なIPアドレス、追加セクションのTTL 345600でも同じ答えが返されます。 問題をローカライズできたので、今度はそれがどのように発生したかを理解する必要があります。
第4章
接着ゾーン（グルーレコード）に関するウィキペディアの記事を読んだ場合に備えて、DNSに関する理論を思い出してください 。 Glue Recordsは非常に長い期間（5〜6年）使用されていないため、間違った結論に至りました。ドメインの委任時に、クライアントの1つが古いDNS IPアドレスを指定できました。 分析のために、クライアントドメインのリストからwhoisを要求するスクリプトを作成する必要がありました。
残念ながら、この誤った仮定により、時間を失いましたが、他のエラーが見つかりました。 たとえば、クライアントはYandexからのドメインメールを好み、NSとYandex NSに同時にドメインを委任することができます。
第5章
翌朝、収集されたwhoisデータをもう一度分析したところ、何も見つかりませんでした。 RU-Centerに診断と仮定を連絡するだけです。 この会社との長期的な協力にも関わらず、主に経理の部分で疑問が生じたため、技術サポートの呼び出しはほとんどありませんでした。 したがって、@をサポートするメールを送信し、回答を待ちます。 メールへの回答を数時間待った後、従業員は我慢できなくなり、電話をかけることができなくなりました。 十分な量の音楽を聞いた後、私たちは手紙を見つけてチケット番号を報告する生きている人に行きます。 やった！ ただし、アプリケーションへの応答は受け取りません。 1〜2時間の頻度でさらに数回呼び出しても、結果は近づきません。 幸いなことに、一日の終わりには次のようなものが得られます。
グルーレコードの存在は、これらのIPアドレスを持つドメインの子DNSサーバーに対して以前に指定されたことを意味します。 これらのレコードを変更するには、新しいIPアドレスを持つ同じ子DNSサーバーにドメインを委任する必要があります。
とても驚きました。 グルーレコードが最後にあったのは何年も前です。 これは本当に可能ですか？ メールアーカイブを作成し、2011年にドメインが他のnsに委任されたときの手紙を見つけました。 何年もの間、それは正しく機能せず、誰も何も気づきませんでした！
第6章
それまでの間、古い鉄片を借りる最後の時間は続きます。プロバイダーのキャッシュに4日間のTTLがある場合、さらに1か月分の家賃を支払う必要があり、これは計画されたものではありません。
グルーレコードを削除するには、Ru-Centerをサポートしてください。 それらはまったく必要ありません。なぜ新しいIPアドレスにバインドする必要があるのですか？！ さらに、各NSのDNSゾーンには、複数のIPアドレス+ IPv6が示されています。 そして、私たちを混乱させる答えを得ます。 このようなもの：
アプリケーションがシステム管理部門に実行のために提出された場合、結果をお知らせします
つまり レジストラにはこの操作の準備ができていないメカニズムがあると判断します（サポート従業員のインターフェイスのボタンのように見えます）。つまり、誰も同様の問題に直面しなかった（これはありそうもない）か、グルーレコードのIPアドレスを変更して生きていた次。 ただし、NSのIPアドレスがレジストラから削除された場合、グルーレコードも削除されるのは論理的であるため、これは間違っています。 これらは、この10年の初めの古い不具合であり、長い間解決されており、おそらく運が悪かったと思われます。
第7章
翌日の正午までに、私たちはメールに慎重に興味を持っています。申し込みに対する回答はありますか？ 電話で音楽を聞いて何度かクエストを行った後、ライブの人に電話をかけますが、「システム管理部門に申請書が提出されました」以外は何も達成できません。 ほぼ1日が経過したため、新しいグルーレコードを示すアドバイスに従う以外に方法はありません。 数時間後、変更が有効になり（覚えているように、.RUはあまり頻繁に更新されません）、これらのグルーレコードを削除します（必要なく、干渉さえします）。 次の.RU更新を待っていますが、.RUルートサーバーは引き続きこれらのエントリで応答しますが、新しいIPアドレスを使用します。 グリッチが残っていますか？!!!
第8章
アプリケーションには答えがないので、翌日、再び電話の音楽を使ったクエストを行います。 特に、サポートマネージャーと連絡を取るように頼まれ、女の子は「しばらく待たなければならない」と警告し、30分後に停止して電話が切れた音楽を私たちに届けたレベルが欲しいです。 幸いなことに、営業日の終わり頃に、ついにグルーレコードが削除されたという答えが返ってきました。 ほら、仲間！
第9章
プロバイダーのキャッシュに4日間でTTLを記憶して、tcpdumpを調べます。 実際、古いDNSサーバーへの要求はますます少なくなっています。 すべてが計画通りに進みます。 待つだけです。 念のため、不必要なドメインをいくつか取り、状況の再現を試みます。 そして彼女は繰り返します！
ストーリーについては、状況を再現するためのレシピをここに残します。
最初のドメインingavto.ruを取得し、その中にns10.ingavto.ruおよびns11.ingavto.ruのAレコードを作成し、2つのDNSサーバーのIPアドレスをポイントし、レジストラからのIPアドレス（グルーレコード）でこのドメインを委任します。 .RUゾーンが更新されるのを待っています。
2番目のドメインbody-m-auto.ruを取得し、ns10.ingavto.ruおよびns11.ingavto.ruに委任します。更新を待っています。
Aレコードのns10.ingavto.ruおよびns11.ingavto.ruのアドレスを変更するゾーンで、最初のドメインを他のNSに委任します。また、更新を待っています。
その結果、ルートゾーンに.RUの不正確なグルーレコードとグリッチがあります。これについては上記で説明しています。
NSサーバーのIPアドレスをGoogleに尋ねます。
$ dig +short A ns10.ingavto.ru. @8.8.8.8 136.243.55.209 $ dig +short A ns11.ingavto.ru. @8.8.8.8 136.243.55.194
答えは、DNSゾーンに書かれているものと一致します。 ルートサーバーへのリクエストの例では、まったく異なるIPアドレスが与えられていることがわかります。
$ dig any body-m-auto.ru @a.dns.ripn.net. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any body-m-auto.ru @a.dns.ripn.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;body-m-auto.ru. IN ANY ;; AUTHORITY SECTION: BODY-M-AUTO.RU. 345600 IN NS ns11.ingavto.ru. BODY-M-AUTO.RU. 345600 IN NS ns10.ingavto.ru. ;; ADDITIONAL SECTION: ns10.INGAVTO.RU. 345600 IN A 89.249.20.188 ns11.INGAVTO.RU. 345600 IN A 89.249.24.177 ;; Query time: 42 msec ;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6) ;; WHEN: Sat Dec 10 00:00:30 MSK 2016 ;; MSG SIZE rcvd: 153
エピローグ
残念ながら、この問題はRu-Centerにのみ関連しているか、他のレジストラに関連していることがわかりませんでした。 別のレジストラで購入した実験用のドメインがいくつかある場合は、テストしてコメントを書き込んでください。
高い確率で、このような問題は.RUドメインだけでなくdomain.RFにも存在する可能性がありますが、現在テスト用のそのようなドメインはありません。
また、現時点では.RUドメインのグルーレコードを使用する価値はなく、場合によっては、そのようなレコードをクリーンアップするためのアプリケーションでレジストラに連絡するのが理にかなっているという明らかな結論を示しています。
PS Ru-Centerまたは別のレジストラで働いている専門家の誰かが状況についてコメントしてくれたら嬉しいです。