ネームサーバ【name server】

広告

広告

ネームサーバとは

最終更新
2006-01-17T20:15:00+09:00
この記事のURI参照
http://www.7key.jp/nw/technology/protocol/dns_server.html#what

ドメインおよびそのデータに関する情報を保持するサーバプログラムをネームサーバ又はDNSサーバと呼びます。主にドメイン名IPアドレスに変換する役割を果たします。ネームサーバはドメイン名からIPアドレスの変換を行う正引きや、IPアドレスからドメイン名の変換を行う逆引きをするために参照されるDNSゾーンファイルと言う対照表を持ち、DNSゾーンファイルをもとに外部からの問合せに答えます。ちなみにこのDNSゾーンファイルはリソースレコードの集合から成り立っています。

ここでゾーンとは、各ドメインで管理されるDNS情報の単位を指します。DNS情報はネームサーバが管理しますので、ゾーンはネームサーバが管理するドメイン名スペース内の範囲ともいえるでしょう。各ネームサーバが持つゾーンには重なり合う部分が無く、自分の管理するドメインからサブドメインを作成した場合は、そのサブドメインのネームサーバにゾーンに関する全ての責任を与えます。このことによってドメイン名スペースは、責任の譲渡によってゾーンに分割され、ネームサーバによって分散管理されていることとなります。

また、それぞれのネームサーバは、責任を譲渡されたドメインを自由に管理することができ、この状態を「オーソリティAUTHORITY)を持っている」と表現します。管理者がサブドメインを別の管理者に譲渡すると、オーソリティは譲渡された管理者が持つこととなります。オーソリティの及ぶ範囲とゾーンは同じで、オーソリティはゾーンの完全な情報を持ちます。つまりオーソリティとは、ドメインの特定のエリアに関する情報を全て持つネームサーバが持つ権威(authority)ということになります。

ネームサーバの役割

最終更新
2006-01-16T23:31:00+09:00
この記事のURI参照
http://www.7key.jp/nw/technology/protocol/dns_server.html#part_r

ネームサーバと一口に言っても、実は様々な役割を果たしています。以下に主なネームサーバの役割を紹介します。

コンテンツサーバ【Contents Server】

フルサービスリゾルバからの反復問い合わせに対し、自身が管理しているゾーンに対する問合せにだけ応答を行います。名前解決ができなくても他のネームサーバへの問合せは行わず、管理外の問合せに対しては「知らない」と応答を返します。反復問い合わせを行いません。ルートネームサーバや、インターネットで公開してるネームサーバがこれにあたります。

フルサービスリゾルバ【Full-Service Resolver】

スタブリゾルバからの再帰問い合わせに対し、他のネームサーバへ反復問い合わせを行うことによってIPアドレスを調べ、スタブリゾルバに返信する機能を持ちます。プロバイダのネームサーバや、LAN内のネームサーバがこれにあてはまります。教えてもらったリソースレコードをキャッシュして、問い合わせの効率化を行うことから、キャッシュサーバとも呼ばれます。

スタブリゾルバ【Stub Resolver】

クライアント側にあり、フルサービスリゾルバに再帰問い合わせを行うリゾルバです。単にリゾルバと言った場合これを指します。

スレーブサーバ【Slave Server】

自分で再帰問い合わせを行わず、フォワーダへ問い合わせをするサーバです。スレーブサーバはフォワーダとして外部ネームサーバを指定します。スタブリゾルバから再帰問合せを受けた際、自分が持つ情報で名前を解決できるのであればリゾルバに応答をします。できなければ、そのままフォワーダに問合せを転送します。また、スレーブサーバは頻繁に使われるドメイン名をキャッシュする機能も持ちます。

フォワーダ【Forwarder】

スレーブサーバの問い合わせに対して、他ネームサーバへ問い合わせを行うサーバです。スレーブサーバからの問合せを受け取ったフォワーダ反復問合せによりIPアドレスを取得し、スレーブサーバに返します。スレーブサーバは受け取ったIPアドレスをスタブリゾルバに返す流れとなります。

プライマリネームサーバとセカンダリネームサーバ

最終更新
2006-01-18T20:15:00+09:00
この記事のURI参照
http://www.7key.jp/nw/technology/protocol/dns_server.html#p_s

OSのネームサーバ情報を登録する画面を見たことはあるでしょうか?たいていの場合、プライマリネームサーバセカンダリネームサーバのように2箇所登録するようになっていると思います(セカンダリネームサーバは多くの場合1台以上登録ができると思います)。スタブリゾルバは問合せを行ったネームサーバがプライマリかセカンダリかを区別しませんので、クライアント側にすればどちらがプライマリでどちらがセカンダリという区別はありません。クライアントによって挙動は違いますが、先に問合せる方がプライマリネームサーバ、プライマリに問合せてうまくいかなかった場合はセカンダリネームサーバと、どちらに先に問合せを行うかという1台目、2台目の違いしかありません。

ただ、ネームサーバの役目としてはそれだけではありません。プライマリネームサーバDNSゾーンファイルを自身で(管理者が)保存し、これを元に名前解析を行います。セカンダリネームサーバは、ネットワークを経由してプライマリネームサーバDNSゾーンファイルをコピーし、これを元に名前解決を行います。このDNSゾーンファイルをコピーする機能(動作)のことをゾーン転送と呼びます。つまり、ゾーンファイルを更新する際には、プライマリネームサーバの情報のみを更新してやれば、自動的にセカンダリネームサーバにも更新情報が反映されるというわけです。これは、万が一、1台のネームサーバが停止した場合でも、もう1台のネームサーバによってDNS機能自体が止まってしまうことを防ぐためで、インターネット上でドメインを管理する場合、最低2台のネームサーバを使うことが必須となっています。このような理由から、プライマリネームサーバとセカンダリネームサーバは優先DNSサーバ代替DNSサーバのように呼ばれることもあります。

ゾーン転送【DNS Zone Transfer】の仕組み

まず、セカンダリーネームサーバプライマリネームサーバDNSゾーンファイルが更新されていることを確認すると、ゾーンファイルのダウンロードを行います。ダウンロードデータをもとに自身のゾーンファイルを最新の情報に更新をし、新ゾーンファイルを有効にします。ゾーン転送はセカンダリ側から行われるのが特徴で、TCPが使われます。

ゾーン転送の流れ

SOAのRefresh間隔になったらセカンダリはプライマリにSOAレコードの要求を行います。プライマリはセカンダリへSOAレコードを応答し、セカンダリはDNSゾーンファイルの更新があるかどうかをSOAレコードのSerialで判断をします。もし受け取ったSerialの値が、セカンダリの持つゾーンファイルの中のSOAレコードのSerialよりも大きくなっていれば、ゾーンファイルは更新されたとみなされてゾーン転送を要求します(これらの値が同じだった場合は何もしません)。ゾーン転送の要求では、質問セクションに自分のドメイン名とタイプAXFRが入ります。この要求を受け取ったプライマリは回答セクションにそのゾーンの全てのリソースレコードを入れて応答をします。

SOA RDATAのフォーマット
-フィールド名意味
SOA RDATAMNameネームサーバ名(可変長)
RNameドメインの管理者メールアドレス(可変長)
Serialゾーン情報のシリアル番号(32bit)
Refresh32bitの整数値でゾーン情報が更新されるまでの制限時間(秒)を示す
Retry32bitの整数値でフィールド更新を再試行するまでの時間(秒)を示す
Expire32bitの整数値でゾーンを信頼できる時間(秒)を示す
Minimum32bitの整数値でリソースレコードの最小生存時間(秒)を示す

DNS NOTIFY

DNS NOTIFYはプライマリ側から動作を行うゾーン転送方法です。上記のゾーン転送方法では、セカンダリ側から動作を開始する必要がありました。しかしこれは、プライマリのゾーンファイルが更新されても、セカンダリからゾーン転送要求が行われるまでの間、セカンダリのゾーンファイルは更新されないこととなります。更新頻度によってはSOA中のRefreshで調整をできるでしょうが、ゾーンファイルが頻繁に更新されることが予想される環境では、更新のタイムラグを最小限に抑えられる別の方法が必要となりました。そこで使われるのがDNS NOTIFYです。ただし、DNS NOTIFYはプライマリとセカンダリがそれぞれDNS NOTIFYに対応していなければなりません。

  1. プライマリでゾーンファイルが更新された場合、セカンダリへSOAレコードを送信。
  2. セカンダリは通知(Notify)メッセージに含まれているSOAのSerialと自身のSerialを比較。
  3. 受け取ったSerialの方が大きければゾーン転送を要求します。
  4. 以降は通常のゾーン転送手順と同じ。

差分ゾーン転送【Incremental Zone Transfer】

Dynamic DNSのように、頻繁にゾーンファイルが書き換えられることが予想される環境でDNS NOTIFYを使うと、ファイルに数行の更新がなされるたびにファイルの全転送(AXFR)が行われ、プライマリに多大な負荷が発生します。そこで利用されるのが差分ゾーン転送です。差分データ転送ではプライマリが過去のゾーン情報を記憶しており、セカンダリのゾーンファイルとの差分情報のみを転送することにより転送量を大きく減らす事ができるのです。ただし、差分データ転送はプライマリとセカンダリがそれぞれ差分データ転送に対応していなければなりません。

  1. セカンダリがSOAを要求し、それを受け取るまでは通常のゾーン転送手順と同じ。
  2. 受け取ったSOAのSerialが自身のものよりも大きかった場合、ゾーン転送を要求する。その際のフォーマットは標準的なDNS問合せと同じだが、問合せタイプにIXFRが入れられSOAレコードを含んだ形での要求となる。
  3. IXFRを受け取ったプライマリはSOAのSerialを確認し、現在のSerialのゾーン情報との違いを計算して変更及び追加されているリソースレコードのみをセカンダリに転送する。
  4. セカンダリは変更分を受け取り、保持しているゾーン情報を変更する。

ルートネームサーバ

最終更新
2006-01-17T22:01:00+09:00
この記事のURI参照
http://www.7key.jp/nw/technology/protocol/dns_server.html#root_nm_svr

TCP/IPネットワークには無数のネームサーバが存在し、ドメイン名に対応した階層構造となっています。最上位に位置するネームサーバルートサーバと呼ばれ、全世界に13台が分散配置されています。

ルートネームサーバ一覧
nameorgcityIP add.
aVeriSignDulles VA198.41.0.4
bISIMarina del Rey,CA,US192.228.79.201
(2001:478:65::53)
cCogentHerndon VA192.33.4.12
dUMDCollege Park,MD, US128.8.10.90
eNASAMt View, CA, US192.203.230.10
fISCPalo Alto, CA, US192.5.5.241
(2001:500::1035)
gDISAVienna, VA, US192.112.36.4
hARLAberdeen, MD, US128.63.2.53
(2001:500:1::803f:235)
iNORDUnetStockholm, SE192.36.148.17
jVeriSignMt View, CA, US192.58.128.30
kRIPELondon, UK193.0.14.129
(2001:7fd::1)
lICANNLos Angeles, US198.32.64.12
mWIDETokyo, JP202.12.27.33
(2001:dc:3::35)

補足知識

最終更新
2006-01-15T13:44:00+09:00
この記事のURI参照
http://www.7key.jp/nw/technology/protocol/dns_server.html#supplement

広告

当ページ作成にあたり、参考にさせてもらったリソース

Copyright (C) 2003-2006 七鍵 key@do.ai 初版:2004年6月13日 最終更新:2006年01月18日