IETF RFC1034(の和訳)を読んだ

日本語訳原文を見ながら、DNSってどうなっているか調べたいと思ったのでメモ。入り方を間違えると病んでしまったり絶望してしまったりするらしいので、注意しながら…。これで大分、作り方をイメージできるようになりました。

1. STATUS OF THIS MEMO

2. INTRODUCTION

歴史とか書いてある。今DNSがどうなっているとかはあんまし関係ない。世界中のリソースをひとつの名前空間上に表現したい。

  • The domain system provides:
    • Standard formats for resource data.
    • Standard methods for querying the database.
    • Standard methods for name servers to refresh local data from foreign name servers.

そうそうこういうのが知りたい。

  • Elements of omain name systems:
    • the DOMAIN NAME SPACE and RESOURCE RECORDS
    • NAME SERVERS
    • RESOLVERS

3. DOMAIN NAME SPACE and RESOURCE RECORDS

  • ラベルは0〜63オクテット。つまり 0〜63*8ビット。
  • ルートドメインはnull文字というか長さが0。
  • ツリー空間のパス。
  • 大文字小文字は区別しないけど、前方互換性のために区別しとくかも。
  • ユーザがタイプしてドメインを記述するとき、'.' ドットで区切る。
  • ローカルドメイン上だと、所属するドメインを省略することができる。
  • ドメイン名は最大255文字。
  • 'IN-ADDR.ARPAドメインは、ネットワークやホスト番号から名前へ翻訳する役割を持つ'
    • 逆引きのこと?
  • ラベル名は文字で始まり、文字か数字で終わり、途中は文字or数字orハイフン。
    • BNFもあるでよ
  • Resouce Records
    • owner
    • type - 16ビットの値で、レコード種類を表す。
A host address
CNAME canonical name of an alias
HINFO CPU and OS used by a host
MX identifies a Mail Exchange for the domain
NS the AUTHORITATIVE Name Server for the domain
PTR a pointer to another part of the domain name space
SOA Start of a zone of Authority
    • class - 16ビットの値で、プロトコルファミリーを識別する - INとCHがある。普通IN
    • TTL - 32 integer seconds
  • RDATA - resource data of a resource record.
    • こんな感じ

ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33

USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52

    • 逆引き用のレコード

52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU

  • Queries - 問合せ
    • メッセージのやり取りはUDPでやり取りされたり。セクションというのがある。
    1. Question - クエリ。
    2. Answer - RRをお答え。
    3. Authority - 名前を知っているauthorityへたらい回し。
    4. Additional - ?
  • Standard queries
    • QNAME, QTYPE(16bit), QCLASS(16bit)をきく。
    • e.g.) QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN
  • Inverse queries (Optional)
    • >すべてのネームサーバーは少なくとも逆問合せメッセージを理解して、「実装していない」エラー回答を返でなければなりません。
    • 普通はIN-ADDR.ARPAを使って逆引きする。

4. NAME SERVERS - ネームサービス

ネームサーバーは、自分が知っているゾーンのリソースのリストを覚えておく。マスタとして管理する。他のゾーンのも持ってたりするみたい。また、ひとつのゾーンというかドメインについて、サーバを二個以上置いといて冗長性を確保する。

  • クラス分割?

ゾーンを記述するデータは4部分から構成される:

  • ゾーン内の全てのノードの正式なデータ
  • ゾーンの最上位ノードを定義するデータ
  • 委任サブゾーンを定義するデータ。
  • サブゾーンのネームサーバアクセスを可能にするデータ。ポインタ的なもの?

サブゾーンと親ゾーンはデータ連携していないといけない。つまり、上から下、下から上へのクライアントの誘導ができないと困る。

ネームサーバの内部

動作モード

  • 再帰モード
  • 非再帰モード

いろいろ面倒くさそうということがわかった。

変更を検出するためにセカンダリはゾーンのSOAのシリアル番号フィールドを確
認します。何か変更があった場合はSOAのシリアル番号は常に増加します。増加
は単純に行われたり、マスターファイルの書き込み日の基づいたりします。目的
はゾーンの2つのコピーのシリアル番号を比較することでどちらが最近か決定を
可能にすることです。

5. RESOLVERS - リゾルバ

  • リゾルバの仕事
    1. ホスト名からホストアドレスへの変換 - Aレコード
    2. ホストアドレスからホスト名への変換 - PTR問い合わせ
    3. 一般的な検索 - リソースの属性なんかを調べてきたり
  • リゾルバが返すもの
    1. 要求に対する一つ以上のレコード
    2. 名前エラー - 名前に対するリソースがない
    3. データなしエラー - 名前に対するリソースはあるがタイプが適切でない
  • Aliases - 別名が自分の中で見つかったらすぐ返してあげよう
  • Temporary failures - 一時的障害と名前なしエラーなどときちんと区別しよう
  • クエリのデータ構造
SNAME 問い合わせドメイン名
STYPE 問い合わせタイプ - QTYPE
SCLASS 問い合わせクラス - QCLASS (IN or CA)
SLIST Name Serverとゾーンを記述する構造体。距離とか妥当さが分かるらしい。
SBELT Name Serverがないとき?ようわからん
CACHE キャッシュ
  • リゾルバのアルゴリズム
    1. 答えがローカル上にあれば返信
    2. 知ってるサーバの全てに適当な順番で訊きに行く
    3. どれかが返答するまで待つ
    4. 返答を分析
      1. 名前エラーならクライアントにエラーを返してデータをキャッシュする
      2. delegationなら、ステップ2に戻ってキャッシュする
      3. 答えがCNAMEだったら、SNAMEをCNAMEで書き換えてステップ1に戻る
      4. サーバー故障とか以上なら、ステップ3に戻る
    • いつ終わる?妥当な答えがもらえるか、SLISTがからになるまで。

とりあえず、5.3.3を読んでおけばわりとDNSシステムの動きがよくわかるかも。正直、1〜4章とかすっ飛ばしてもよかったかも。

6. A SCENARIO - 筋書き

いろんなクエリの例。いきなりフォーマット見てもわからんもね。設計をもうちょっと考えだしたらもっかい読む。