広告
広告
https://www.7key.jp/nw/technology/protocol/dns_server.html#whatドメインおよびそのデータに関する情報を保持するサーバプログラムをネームサーバ又はDNSサーバと呼びます。主にドメイン名をIPアドレスに変換する役割を果たします。ネームサーバはドメイン名からIPアドレスの変換を行う正引きや、IPアドレスからドメイン名の変換を行う逆引きをするために参照されるDNSゾーンファイルと言う対照表を持ち、DNSゾーンファイルをもとに外部からの問合せに答えます。ちなみにこのDNSゾーンファイルはリソースレコードの集合から成り立っています。
ここでゾーンとは、各ドメインで管理されるDNS情報の単位を指します。DNS情報はネームサーバが管理しますので、ゾーンはネームサーバが管理するドメイン名スペース内の範囲ともいえるでしょう。各ネームサーバが持つゾーンには重なり合う部分が無く、自分の管理するドメインからサブドメインを作成した場合は、そのサブドメインのネームサーバにゾーンに関する全ての責任を与えます。このことによってドメイン名スペースは、責任の譲渡によってゾーンに分割され、ネームサーバによって分散管理されていることとなります。
また、それぞれのネームサーバは、責任を譲渡されたドメインを自由に管理することができ、この状態を「オーソリティ（AUTHORITY）を持っている」と表現します。管理者がサブドメインを別の管理者に譲渡すると、オーソリティは譲渡された管理者が持つこととなります。オーソリティの及ぶ範囲とゾーンは同じで、オーソリティはゾーンの完全な情報を持ちます。つまりオーソリティとは、ドメインの特定のエリアに関する情報を全て持つネームサーバが持つ権威（authority）ということになります。
https://www.7key.jp/nw/technology/protocol/dns_server.html#part_rネームサーバと一口に言っても、実は様々な役割を果たしています。以下に主なネームサーバの役割を紹介します。
フルサービスリゾルバからの反復問い合わせに対し、自身が管理しているゾーンに対する問合せにだけ応答を行います。名前解決ができなくても他のネームサーバへの問合せは行わず、管理外の問合せに対しては「知らない」と応答を返します。反復問い合わせを行いません。ルートネームサーバや、インターネットで公開してるネームサーバがこれにあたります。
スタブリゾルバからの再帰問い合わせに対し、他のネームサーバへ反復問い合わせを行うことによってIPアドレスを調べ、スタブリゾルバに返信する機能を持ちます。プロバイダのネームサーバや、LAN内のネームサーバがこれにあてはまります。教えてもらったリソースレコードをキャッシュして、問い合わせの効率化を行うことから、キャッシュサーバとも呼ばれます。
クライアント側にあり、フルサービスリゾルバに再帰問い合わせを行うリゾルバです。単にリゾルバと言った場合これを指します。
自分で再帰問い合わせを行わず、フォワーダへ問い合わせをするサーバです。スレーブサーバはフォワーダとして外部ネームサーバを指定します。スタブリゾルバから再帰問合せを受けた際、自分が持つ情報で名前を解決できるのであればリゾルバに応答をします。できなければ、そのままフォワーダに問合せを転送します。また、スレーブサーバは頻繁に使われるドメイン名をキャッシュする機能も持ちます。
スレーブサーバの問い合わせに対して、他ネームサーバへ問い合わせを行うサーバです。スレーブサーバからの問合せを受け取ったフォワーダは反復問合せによりIPアドレスを取得し、スレーブサーバに返します。スレーブサーバは受け取ったIPアドレスをスタブリゾルバに返す流れとなります。
https://www.7key.jp/nw/technology/protocol/dns_server.html#p_sOSのネームサーバ情報を登録する画面を見たことはあるでしょうか？たいていの場合、プライマリネームサーバとセカンダリネームサーバのように2箇所登録するようになっていると思います（セカンダリネームサーバは多くの場合1台以上登録ができると思います）。スタブリゾルバは問合せを行ったネームサーバがプライマリかセカンダリかを区別しませんので、クライアント側にすればどちらがプライマリでどちらがセカンダリという区別はありません。クライアントによって挙動は違いますが、先に問合せる方がプライマリネームサーバ、プライマリに問合せてうまくいかなかった場合はセカンダリネームサーバと、どちらに先に問合せを行うかという1台目、2台目の違いしかありません。
ただ、ネームサーバの役目としてはそれだけではありません。プライマリネームサーバはDNSゾーンファイルを自身で（管理者が）保存し、これを元に名前解析を行います。セカンダリネームサーバは、ネットワークを経由してプライマリネームサーバのDNSゾーンファイルをコピーし、これを元に名前解決を行います。このDNSゾーンファイルをコピーする機能（動作）のことをゾーン転送と呼びます。つまり、ゾーンファイルを更新する際には、プライマリネームサーバの情報のみを更新してやれば、自動的にセカンダリネームサーバにも更新情報が反映されるというわけです。これは、万が一、1台のネームサーバが停止した場合でも、もう1台のネームサーバによってDNS機能自体が止まってしまうことを防ぐためで、インターネット上でドメインを管理する場合、最低2台のネームサーバを使うことが必須となっています。このような理由から、プライマリネームサーバとセカンダリネームサーバは優先DNSサーバと代替DNSサーバのように呼ばれることもあります。
まず、セカンダリーネームサーバはプライマリネームサーバのDNSゾーンファイルが更新されていることを確認すると、ゾーンファイルのダウンロードを行います。ダウンロードデータをもとに自身のゾーンファイルを最新の情報に更新をし、新ゾーンファイルを有効にします。ゾーン転送はセカンダリ側から行われるのが特徴で、TCPが使われます。
SOAのRefresh間隔になったらセカンダリはプライマリにSOAレコードの要求を行います。プライマリはセカンダリへSOAレコードを応答し、セカンダリはDNSゾーンファイルの更新があるかどうかをSOAレコードのSerialで判断をします。もし受け取ったSerialの値が、セカンダリの持つゾーンファイルの中のSOAレコードのSerialよりも大きくなっていれば、ゾーンファイルは更新されたとみなされてゾーン転送を要求します（これらの値が同じだった場合は何もしません）。ゾーン転送の要求では、質問セクションに自分のドメイン名とタイプAXFRが入ります。この要求を受け取ったプライマリは回答セクションにそのゾーンの全てのリソースレコードを入れて応答をします。
| - | フィールド名 | 意味 |
|---|---|---|
| SOA RDATA | MName | ネームサーバ名（可変長） |
| RName | ドメインの管理者メールアドレス（可変長） | |
| Serial | ゾーン情報のシリアル番号（32bit） | |
| Refresh | 32bitの整数値でゾーン情報が更新されるまでの制限時間（秒）を示す | |
| Retry | 32bitの整数値でフィールド更新を再試行するまでの時間（秒）を示す | |
| Expire | 32bitの整数値でゾーンを信頼できる時間（秒）を示す | |
| Minimum | 32bitの整数値でリソースレコードの最小生存時間（秒）を示す |
DNS NOTIFYはプライマリ側から動作を行うゾーン転送方法です。上記のゾーン転送方法では、セカンダリ側から動作を開始する必要がありました。しかしこれは、プライマリのゾーンファイルが更新されても、セカンダリからゾーン転送要求が行われるまでの間、セカンダリのゾーンファイルは更新されないこととなります。更新頻度によってはSOA中のRefreshで調整をできるでしょうが、ゾーンファイルが頻繁に更新されることが予想される環境では、更新のタイムラグを最小限に抑えられる別の方法が必要となりました。そこで使われるのがDNS NOTIFYです。ただし、DNS NOTIFYはプライマリとセカンダリがそれぞれDNS NOTIFYに対応していなければなりません。
Dynamic DNSのように、頻繁にゾーンファイルが書き換えられることが予想される環境でDNS NOTIFYを使うと、ファイルに数行の更新がなされるたびにファイルの全転送（AXFR）が行われ、プライマリに多大な負荷が発生します。そこで利用されるのが差分ゾーン転送です。差分データ転送ではプライマリが過去のゾーン情報を記憶しており、セカンダリのゾーンファイルとの差分情報のみを転送することにより転送量を大きく減らす事ができるのです。ただし、差分データ転送はプライマリとセカンダリがそれぞれ差分データ転送に対応していなければなりません。
https://www.7key.jp/nw/technology/protocol/dns_server.html#root_nm_svrTCP/IPネットワークには無数のネームサーバが存在し、ドメイン名に対応した階層構造となっています。最上位に位置するネームサーバはルートサーバと呼ばれ、全世界に13台が分散配置されています。
| name | org | city | IP add. |
|---|---|---|---|
| a | VeriSign | Dulles VA | 198.41.0.4 |
| b | ISI | Marina del Rey,CA,US | 192.228.79.201 (2001:478:65::53) |
| c | Cogent | Herndon VA | 192.33.4.12 |
| d | UMD | College Park,MD, US | 128.8.10.90 |
| e | NASA | Mt View, CA, US | 192.203.230.10 |
| f | ISC | Palo Alto, CA, US | 192.5.5.241 (2001:500::1035) |
| g | DISA | Vienna, VA, US | 192.112.36.4 |
| h | ARL | Aberdeen, MD, US | 128.63.2.53 (2001:500:1::803f:235) |
| i | NORDUnet | Stockholm, SE | 192.36.148.17 |
| j | VeriSign | Mt View, CA, US | 192.58.128.30 |
| k | RIPE | London, UK | 193.0.14.129 (2001:7fd::1) |
| l | ICANN | Los Angeles, US | 198.32.64.12 |
| m | WIDE | Tokyo, JP | 202.12.27.33 (2001:dc:3::35) |
https://www.7key.jp/nw/technology/protocol/dns_server.html#supplement広告