DNSはドメイン名をIPアドレスに変換します。 外観上、このタスクは非常に単純に見えますが、実際、その解決策はおそらく地球上で最も複雑で最大の情報システムの出現につながりました。
- ドメインレジストリ
- グローバルトップレベルドメイン(gTLD)
- 異なる国コードトップレベルドメイン(ccTLD)
- そして毎年、他のすべてのトップレベルドメイン(.space、.photographyなど)のリストが増えています
これにより、すでに単純ではないシステムがさらに複雑になります。
DNSは単一のマシン(階層型、分散型、一貫性のあるデータベース)上にないため、多くの階層、オブジェクトが含まれます。 これらの階層的に構成されたオブジェクトがすべて正しく機能することを確認することが重要なタスクになります。 階層の最上部には
- ルート(。)
- グローバルドメインサーバー
- 権限のあるドメインネームサーバー
この階層の各レベルは、目的のIPアドレスを決定するプロセスで重要な役割を果たします。
- レジストリ(例:.comおよび.netをサポートするVerisign)
- レジストラ(例:GoDaddyおよびNameCheap)
- サイトにドメイン名を登録するすべての人
- インターネットサービスプロバイダー
- DNSプロバイダー
私たちは全員このシステムの一部です。それを理解し、DNSシステムがエラーや中断なしに機能できるようにする重要な側面を念頭に置くことは非常に重要です。
DNSシステムの重要な側面である「増分レコード」または「グルーレコード」について検討してください。
接着剤レコードまたは追加レコード
グルーレコードまたは増分レコードは、ドメインまたはサブドメインに割り当てられたIPアドレスを格納するAレコードです。 ドメインネームサーバーが同じドメインのサブドメインにある場合、これらのレコードは非常に重要になります。
接着剤レコードは、DNS応答の「追加レコード」セクションにあります。
これらの追加エントリがどのように機能するかの例を見てみましょう。 ネームサーバーにアドレスがあるyourdomain.comドメインがあるとします。
ns1.yourdomain.com ns2.yourdomain.com
そして、yourdomain.comのアドレスを決定するために競合が発生し、ns1.yourdomain.comからアドレスを取得する必要があります。ns1.yourdomain.comからアドレスを取得する必要があります。 無限ループになります。
それを破るには、Glueレコードが必要です。これは、yourdomain.comのアドレスのリクエストを処理するプロセスでネームサーバーのIPアドレスを直接報告します。

この例では、ctrls.inドメインネームサーバーのns1.ctrls.inおよびns1.ctrls.inのIPアドレスを持つAレコードを発行することにより、増分レコードが循環依存関係を排除する方法を確認します。
ネームサーバーアドレスに独自のサブドメインを使用しないドメインの場合、追加のエントリも役立ちます。たとえば、Wikipedia.orgでどのように機能するかなど、アドレスを決定する手順の数が減ります。

この例では、Wikipedia.orgはそのドメインのネームサーバー名としてns1.wikimedia.org、ns2.wikimedia.org、ns3.wikimedia.orgを返します。 追加のエントリは、Wikimedia.orgドメインのアドレス検索手順を省略して、すぐにIPアドレスを報告します。
ある中国の主要なCDNレコードAは、そのネームサーバーに対して誤ったIPアドレスを返しました。
DNS Expierenceチェックにより、テスト中にポーリングされたさまざまな権限ネームサーバーが正しいIPアドレスを返したことが明らかになりました。 ただし、グローバルドメインレベルのネームサーバーがポーリングされている場合、Direct DNSチェックは間違ったIPアドレスを返しました。
dig-dig "server name" root_server-グローバルネームサーバーが無効なアドレスを与えていた状況を調査することで、同じ結果が得られました。
このエラーは、ある時点で、ドメイン名登録機関が、階層の上位にあるGlueレコードの変更を転送しなかったことが判明しました。
CDNの担当者はドメインレジストラに連絡し、ドメインのGlueレコードを更新しました。 その後、更新されたレコードはすべてのgTLDサーバーにブロードキャストされ、問題は解決されました。
この事件は、この巨大なシステムのすべてのレベル、つまりDNSの作業を監視することの重要性を強調しました。 そしてここでは、問題が発生したレベルとその解決方法を特定するための適切な戦略が必要です。十分な努力がありますか、それとも能力が解決策である人々と連絡を取る必要があります。
Pingdomなどを使用してグルーDNSレコードの正確性を確認できます :検証プロセス中に、NSドメインサーバーのIPアドレスが取得され、ルートDNSサーバーのレコードがゾーンのDNSレコードで直接指定されたレコードと比較されます。