少し分解しましょう。
（例えば、TLDゾーンのNSレコードexample.com NS ...ではcom）されている委任を記録。
（例えば、TLDゾーン内のAとAAAAレコードns1.example.com A ...ではcom）であるグルーレコード。
ゾーン自体（つまりexample.com NS ...、example.com）内のNSレコードは権限レコードです。
ゾーン自体（ns1.example.com A ...in example.com）のAおよびAAAAレコードは、単純で単純なアドレスレコードです。
（再帰的な）リゾルバーがゾーンのデータのキャッシュなしでルートゾーンキャッシュ（名前解決プロセスのブートストラップに使用されます）のみで開始すると、最初に.、次にに進みcom.ます。comサーバは、で応答します権威セクションの応答基本的に言って、「私は知らないが、知っている誰かのためにここを見て」のためのサーバと同じ、.およそ致しますcom。このクエリ応答には権限がなく、入力済みの回答セクションは含まれません。それはあり、いわゆる含める追加を特定のサーバーが知っているホスト名のアドレスマッピングを提供するセクション（グルーレコードから、または再帰リゾルバーの場合、以前にキャッシュされたデータから）。リゾルバーはこの委任応答を受け取り、必要に応じてNSレコードのホスト名を解決し、権限が委任されたDNSサーバーへのクエリに進みます。深い委任階層がある場合、このプロセスは何度も繰り返されますが、最終的には「信頼できる回答」フラグが設定されたクエリ応答になります。
リゾルバは（一般に、うまくいけば）解決しようとしているホスト名を分割してそれについて少しずつ尋ねようとはせず、単にそれを知っている「最良の」サーバーに単に送信することに注意することが重要です。インターネット上の平均的な権限のあるネームサーバーは、大半の有効なDNS名に対して権限がないため、応答は、他のDNSサーバーを指す権限のない委任応答になります。
現在、ゾーンに対して権限を持つために、サーバーは委任レコードまたは権限レコードで指定する必要はありません。たとえば、プライベートマスターサーバーの場合を考えます。その場合、ゾーンのスレーブDNSサーバーの管理者のみが認識する権限のあるDNSサーバーが存在します。DNSサーバーは、何らかのメカニズムを介して、問題のゾーンに関する完全かつ正確な知識があると判断した場合、そのゾーンに対して権限を持ちます。たとえば、通常は権限のあるDNSサーバーは、SOAレコードで有効期限として定義された制限時間内に構成されたマスターサーバーに到達できない場合、権限がなくなる可能性があります。
信頼できる回答のみが適切なクエリ応答と見なされる必要があります。それ以外はすべて、委任または何らかのエラーです。権限のないサーバーへの委任は「ラメ」委任と呼ばれ、リゾルバーが1ステップ戻って他の名前付きDNSサーバーを試す必要があることを意味します。委任に権限のある到達可能なネームサーバーが存在しない場合、名前解決は失敗します（そうでない場合、通常よりも遅くなります）。
権限のないデータはキャッシュしないでくださいので、これはすべて重要です。権限のないサーバーには全体像がないため、どうしてそうなるのでしょうか？そのため、権限のあるサーバーは、「権限のあるユーザーは誰で、何のために」という質問に答えることができなければなりません。これは、ゾーン内NSレコードによって提供される情報です。
主に単一のゾーン内の複数のホスト名ラベルを中心に（特に動的IP範囲が大きい場合などの逆DNSゾーンを中心に）、またはネームサーバーリストが親ゾーンと問題のゾーン（これはほとんどの場合エラーですが、意図的に行うこともできます）。
これがどのように機能するかはdig、+norec（再帰を要求しないでください）および@サーバー指定子機能を使用してもう少し詳しく見ることができます。以下は、実際のDNSサーバーの解決方法の説明です。unix.stackexchange.com例で開始するためのAレコードのクエリa.root-servers.net：
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
flagsセクションごとのカウントと同様によく見てください。qrQuery Responseでaaあり、Authoritative Answerです。comサーバーに委任されるだけであることに注意してください。その委任を手動で追跡します（実際には、再帰リゾルバーは追加セクションのIPアドレスが提供されている場合はそれを使用します。委任応答でIPが提供されていない場合は、名前付きネームサーバーの1つの別の名前解決を開始しますが、その部分をスキップして、例の簡潔さのためにオペレーティングシステムの通常のリゾルバにフォールバックします）。
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
これがstackexchange.com（とりわけ）に委任されていることがわかりns1.serverfault.comますが、まだ正式な回答が得られていません。再び委任に従います。
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
ビンゴ！aaフラグが設定されていて、見つけたいと思ったとおりにIPアドレスが含まれているため、答えが返ってきました。余談ですが、少なくともこの投稿を書いている時点では、委任先とリストされた権限のネームサーバーのリストが異なり、両者が同一である必要はないことを示しています。上記で例示したのは、基本的にリゾルバーによって実行される作業です。ただし、実際のリゾルバーは途中で応答をキャッシュするため、毎回ルートサーバーにアクセスする必要はありません。
上記の例からわかるように、委任レコードとグルーレコードは、ゾーン自体の権限レコードとアドレスレコードとは異なる目的を果たします。
キャッシュ、名前解決サーバーは、一般的に、キャッシュポイズニングから保護するために、返されたデータに対していくつかの健全性チェックも行います。たとえばcom、親ゾーンによってに委任先として既に名前が付けられているソース以外のソースから、権限のあるサーバーに名前を付ける回答のキャッシュを拒否する場合がありますcom。詳細はサーバーに依存しますが、インターネット上のランダムなネームサーバーがその「管轄権」の下に公式にない委任記録を上書きできるようにするという納屋の扉を開かずに、可能な限りキャッシュすることを目的としています。