リゾルバ【Resolver】

広告

広告

リゾルバ

最終更新
2006-01-18T21:56:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/resolver.html#what

リゾルバは、ユーザプログラムがドメイン名からIPアドレスを調べたい場合に、ユーザプログラムに代わってネームサーバからIPアドレスを聞き出すためのソフトウェアを指します。つまり、リゾルバはネームサーバ用のクライアントソフトとして動作します(通常リゾルバというとスタブリゾルバのことを指します)。

  1. まずリゾルバはローカルにキャッシュされたリソースレコードを確認します。
  2. あればユーザプログラムにIPアドレスを返し、無ければプライマリネームサーバに問合せを行います。
  3. プライマリネームサーバからの応答がない場合は1秒後に再度プライマリネームサーバに問合せを行います。
  4. 2秒後、更に応答がなければプライマリネームサーバセカンダリネームサーバに登録されている全てのサーバに問合せを行います。
  5. この中で、最初に応答を返してきたネームサーバを使用することとなります。
  6. 2秒後、更に応答が無ければ、再度知っているネームサーバ全てに問合せを行います。
  7. 4秒後、更に応答が無ければ、再度知っているネームサーバ全てに問合せを行います。
  8. 8秒後(最初の問い合わせから17秒後)、ネームサーバからの応答が1つも返ってこなければ、問合せは失敗とされます。

問合せ方式

最終更新
2006-01-18T21:56:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/resolver.html#rule

再帰問い合わせ

リゾルバからネームサーバへ問合せを行う際に使われる方式です。

  1. リゾルバからネームサーバに問合せを行います。
  2. ネームサーバは、自身が管理するゾーン又はキャッシュに目的のリソースレコードがあればリゾルバIPアドレスを応答します。
  3. 問合わされたドメイン名ネームサーバが知らない場合、ネームサーバ反復問合せを他のネームサーバに対して行います。

反復問い合わせ

ネームサーバは、リゾルバから受け取った問合せに対する回答を自分の管理する範囲で行うことができなければ、他のネームサーバに問合せを行わなければなりません。他のネームサーバに問合せを行う際に使われる方式を反復問合せと言います。

ドメインの説明でふれましたが、ドメイン名は分散管理されています。つまり、「www.7key.co.jp」というドメイン名を担当するネームサーバを「7key.co.jp」ドメイン内のネームサーバに登録し、「7key.co.jp」というドメイン名を担当するネームサーバを「co.jp」ドメイン内のネームサーバに登録し、「co.jp」というドメイン名を担当するネームサーバを「jp」ドメイン内のネームサーバに登録し、「jp」というドメイン名を担当するルートサーバを配置するといったように役割分担がきっちり決められています。

よって、「www.7key.co.jp」というドメイン名IPアドレスを調べる際に、自分の持っている情報でクライアントに返答ができない場合は別のネームサーバからIPアドレスを聞かなければなりません。ネームサーバはまずルートサーバに「jp」を担当しているネームサーバのIPアドレスを聞きます。返答が返ってくれば次に「jp」を担当しているネームサーバに「co.jp」を担当しているネームサーバのIPアドレスを聞きます。返答が返ってくれば次に・・・と目当てのドメイン名のIPアドレスが返ってくるまでネームサーバが担当のネームサーバに聞き、目当てのIPアドレスが分かる仕組みになっています。

DNSメッセージ

最終更新
2006-01-18T22:19:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/resolver.html#message

DNS上での問合せや回答といった情報のやり取りはDNSメッセージが使われます。ほとんどの場合UDPプロトコルで運ばれ、53番ポートが使われます。ゾーン転送の際は信頼性を確保するためにTCPプロトコル(53番ポート)が使われます。メッセージのタイプによっては空になるセクションもありますが、次のようなフォーマットが使われます(括弧内はオクテット数、ヘッダ部分は必須)。

DNSメッセージ
DNSヘッダ問合せID(2)フラグ(2)
質問セクション数(2)回答セクション数(2)
オーソリティセクション数(2)追加情報数(2)
セクション質問セクション(可変長)
回答セクション(可変長)
オーソリティセクション(可変長)
追加セクション(可変長)

問合せID

問合せに対して設定するユニークな番号です。その問合せに対する応答でも同じ値を使うことにより、どの問合せへの応答かを判別するために使います。

フラグ

以下のパラメータを用いて、クライアントサーバ双方に必要な情報を通知し合うために使用します(括弧内はbit数)。

DNSヘッダ:フラグ
コード名前意味
QR(1)問合せ/応答0:問合せ
1:応答
OPcode(4)オペレーションコード0:標準問合せ
1:逆順問合せ
2:サーバステータス問合せ
3:拡張用の予約
4:DNS Notify
5:DNS Update
6-15:拡張用の予約
AA(1)Authoritative Answer0:反復の結果応答
1:回答にオーソリティ有り
TC(1)Trancation0:データサイズ512オクテット以下
1:データサイズ512オクテット以上
RD(1)再帰要望0:反復問合せ
1:再帰問合せ
RA(1)再帰有効0:再帰検索不可能
1:再帰検索可能
-(2)予約全てのbitを0
Rcode(4)戻りコード下表参照

TCに対する補足

通常リゾルバネームサーバUDP53番と通信を行いますが、DNSメッセージが512オクテットを超えた場合はTCP53番に対してスリーウェイハンドシェイクを行い、TCPプロトコルを使用してDNSを行います。

  1. ネームサーバリゾルバからの要求を受け取りますが、応答データが512オクテットを超えていた場合は先頭512オクテットだけをTC=1で応答します。
  2. TC=1の応答を受け取ったリゾルバはデータが完全では無い事を知り、ネームサーバTCPコネクションをはります。
  3. 後は通常通りTCPプロトコルDNSを行います。
DNSヘッダ:フラグ:Rcode
RCODENameDescriptionReference
0NoErrorエラー無しRFC1035
1FormErrネームサーバが問い合わせを解釈できなかったRFC1035
2ServFail問題が発生し、ネームサーバが問い合わせを処理できなかったRFC1035
3NXDomain指定されたドメイン名が存在しないRFC1035
4NotImp要求された問い合わせタイプをネームサーバは未実装RFC1035
5Refused要求された問い合わせは何らかの理由でネームサーバに拒絶されたRFC1035
6YXDomainName Exists when it should notRFC2136
7YXRRSetRR Set Exists when it should notRFC2136
8NXRRSetRR Set that should exist does notRFC2136
9NotAuthServer Not Authoritative for zoneRFC2136
10NotZoneName not contained in zoneRFC2136
11-15available for assignment
16BADVERSBad OPT VersionRFC2671
16BADSIGTSIG Signature FailureRFC2845
17BADKEYKey not recognizedRFC2845
18BADTIMESignature out of time windowRFC2845
19BADMODEBad TKEY ModeRFC2930
20BADNAMEDuplicate key nameRFC2930
21BADALGAlgorithm not supportedRFC2930
22-3840available for assignment
3841-4095Private Use
4096-65535available for assignment

質問セクション数

問合せるドメイン名の数を入れ、基本的には1が入ります。

回答セクション数、オーソリティセクション数、追加情報数

それぞれ、問合せに対する回答の数、問合せに対する回答の数、問合せに対する回答の数が入ります。

質問セクション

DNSヘッダ:質問セクション
Qname(質問名)[可変長] Qtype(質問タイプ)[2オクテット] Qclass(質問クラス)[2オクテット]

問い合わせの内容に関するパラメータが入り、上記のフォーマットで示します。Qnameには問い合わせ対象のドメイン名ASCIIコードで入れます。ドメイン名はドットで分割し(これをラベルと呼ぶ)、それぞれのラベルは1オクテットのラベル長とそれに続く実際のラベルで構成されます。フィールドの最後には0が区切り文字として配置され、パディングはありません。

0x03www0x047key0x02jp0x00

質問タイプと質問クラスには、問い合わせのタイプを示す値が入れられ、値はリソースレコードのタイプとクラスが使われます。下記例はwww.7key.jpのAレコードを問い合わせる際の質問セクション記述例です。

質問セクション記述例
0x03www0x047key0x02jp0x00
0x00010x0001

回答セクション、オーソリティセクション、追加セクション

それぞれ、質問への回答としてのリソースレコードオーソリティをポイントするリソースレコード、追加情報をもつリソースレコードとなっています。フォーマットは下記の通りですが、Ownerフィールドは質問セクションと同様の記述となります。

リソースレコードのデータ形式
名前長さ意味
Owner可変長そのドメインの名前で最長255オクテット。この文字列はNull文字で終了する。
Type16bitこのレコードに保存されているリソースのタイプ。
Class16bitプロトコルファミリーを示すために使われる。16bitにコード化された値で示され、通常は0x0001の値をとる
TTL32bitリゾルバはこの秒数だけリソースレコードのキャッシュを保持し、その後破棄する。
RDLength16bitRDATAの長さ
RDATA可変長TypeとClassによって変化するデータで、リソースの中身となる部分。

また、DNSではメッセージサイズを小さくするために、重複するドメイン名を省略する機能が用意されています。これをメッセージの圧縮と呼びます。例えば、回答セクションでwww.7key.jpというドメイン名が入り、オーソリティセクションで7key.jpというドメイン名を入れる場合、7key.jp部分が重複となります。これを2度記述することを防ぐために、オーソリティセクションにはDNS圧縮ポインタを置きます。

DNSの圧縮ポインタ
11オフセット(14bit)

最初の2bitは標準ラベルとの混同を避けるためのフラグです。オフセットフィールドはメッセージの先頭を起点に名前の残りのラベルがどこにあるのかを数値で示すこととなっています。

補足知識

最終更新
2006-01-18T21:01:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/resolver.html#supplement

広告

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

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