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文字というか長さが０。
  • ツリー空間のパス。
  • 大文字小文字は区別しないけど、前方互換性のために区別しとくかも。
  • ユーザがタイプしてドメインを記述するとき、'.' ドットで区切る。
  • ローカルドメイン上だと、所属するドメインを省略することができる。
  • ドメイン名は最大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 - ネームサービス

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

  • クラス分割？

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

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

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

ネームサーバの内部

動作モード

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

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

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

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なら、ステップ２に戻ってキャッシュする
      3. 答えがCNAMEだったら、SNAMEをCNAMEで書き換えてステップ１に戻る
      4. サーバー故障とか以上なら、ステップ３に戻る
    • いつ終わる？妥当な答えがもらえるか、SLISTがからになるまで。

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

6. A SCENARIO - 筋書き

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