1. dnscache

D. J. Bernstein [Translated into Japanese by MAENO Toshinori]
Internet publication
djbdns

2. dnscacheプログラム

dnscacheはローカルに DNS 情報をキャッシュするものです。 web ブラウザや メイル転送エイジェント(MTA)などのローカルクライアントから 再帰型 DNS 問合せを受け付けます。 リモートの DNS サーバからの返事を収集します。 時間を節約するために返事を保存します。

このページはリファレンスページです。 解説は workstations, home computers, external caches, BIND からの移行 などの説明を見てください。

3. 構成(Configuration)

dnscache は通常 dnscache-conf プログラムを使って設定します。

dnscache は $ROOT環境変数で指定されたディレクトリにchrootして、 $UID と $GID 環境変数で指定された uid と gid として実行されます。

$IP の port 53 に向けて接続されてくる UDP パケットと TCP 接続を受け付けます。

$IPSENDの高位ポートからパケットを送り出します。

128 バイトまでのseedを標準入力から読み込み、 そのseedを dns_random_initに渡します。

ルートサーバのドット10進表記IPアドレスが一行にひとつ ずつ書かれているファイルservers/@を読み込みます。

さらに、他ドメイン用のサーバの IP アドレスがあるかどうか、 servers ディレクトリを調べます。 例えば、servers/moon.af.milというファイルにアドレス表があったら、 anything.moon.af.mil という形のものはそこのアドレスに問合せます。 anything.moon.af.milについては これら以外の他のサーバ(ルートサーバを含む)からのレコードはキャッシュしません。

1.03 版以降の機能: 環境変数 $FORWARDONLY が設定されていると、 servers/@ にはルートサーバではなく、 他のキャッシュの IP アドレスの一覧があるものとして扱います。 問い合わせはクライアントが問合せを送るように これらのキャッシュに転送されます。 NS レコードに従って連鎖をたどっていくことはしません。

4. メモリの使用

200までのUDP問合せと20のTCP接続が同時に扱えるように、 256KB を越えない固定領域のテーブルを使います。 その他、各問合せに対して通常は数バイトですが、 ときにはもうすこしのメモリを動的に確保します。 問合せ処理にメモリが足りなくなったら、その問合せを捨てます。

UDPで送られてくる問い合わせ列用に 128KBのバッファを予約します。 1.03 版以降では、すでに 200 のUDP 問い合わせを処理して いる最中に新しい UDP 問い合わせを受けとると、 一番古い問い合わせを捨てます。 すでに 20 のTCP 接続を処理している最中に新しい接続要求があると、 一番古い接続を捨てます。

$CACHESIZE環境変数で制御される固定領域のキャッシュを使います。

    A セット. 22 バイト と アドレス毎に4 バイト と 所有者名の長さ。
    NS セット、 PTR セット、 CNAME セット. 22 バイト と 所有者名と 全データ名の長さ。
    MX セット. 22 バイト と MX毎に 2 バイトと全データ名の長さ。
    その他のレコードセット. 22 バイト と レコード毎に 2 バイトと 全データ文字列と所有者名の長さ。
    存在しないドメイン または サーバフェイル 22 バイト と 所有者名の長さ。 

8192 バイトを越えるセットはキャッシュされません。

dnscacheはキャッシュに空きスペースが無くなっても終了しません。

5. 名前の解決とキャッシュについての方針

dnscacheはきちんと作られたルートネームサーバの一覧表に依存しています。 これとは逆に BIND はネームサーバを並べた hint file から出発して、 これらのネームサーバにルートネームサーバの場所を問合せます。

当該サーバの管轄区域外のレコードは保存しません; (当然、渡しません。)

例えば、foo.domのレコードは ルートサーバ、dom サーバ、そしてfoo.dom サーバ からしか受け取りません。

dnscacheは返事の additional セクションからグルーを取り出すために キャッシュをバイパスしたりしません。 特に、サーバの管轄範囲外のグルー、 TTL 0 のグルー、その他のキャッシングポリシーに反するグルー などの情報は使いません。

レコードはたかだか1週間しか保存されません。 2147483647 より大きな TTLは 0 と見なされます。

SOA レコードは保存されません。 ただし、SOA の TTL は ゼロレコード返答と存在しないドメインに対する キャッシュ時間(最大でも1時間)を決めるために使います。 DNS クライアントへの返答 dnscacheの返答は一般に BINDの返答よりずっと小さいものです。 応答にはオーソリティレコード (ソースネームサーバのNS レコードと否定返答のSOA レコード) や 付加レコード( NS、MX レコードに関連する A レコード) は含めません。 UDP についての長さ制限のために切りつめられた answer セクションはまったくなかったものとして扱われます。

dnscacheはローカルユーザが他のローカルユーザを覗かせないよう努めます; 非再帰問合せと逆問合せには答えません; ゾーン転送要求も無視します。 環境変数 $HIDETTL が設定されているとき、返答のTTL を 0にして返します。 1.03 より前の版では常に 返答のTTL を 0にして返します。

RFC 1035 によれば、AA ビットは specifies that the responding name server is an authority for the domain name in question section. 「返答したネームサーバは問合せセクション中のドメインのオーソリティであることを 示す」とあります。

対照的に、BINDはしばしば肯定返答に対し そのドメイン名に対するオーソリティでないにもかかわらず、 AAをセットします。

6. 重複した IP アドレス

サーバーが dnscache にIP アドレスを重複して返してくると、 dnscache はその重複した IP アドレス をそのまま クライアントに渡します。 このサーバの振舞いは RFC 2181, section 5.5 に反しています。 しかし、重複 IP アドレスは負荷分散のために有用なので、 重複があっても dnscache はわざわざ取り除くことはしません。

広く存在しているBIND サーバの不良 (BIND 9.1 では修正されている)は 意図することなく重複 IP アドレス を作りだす。

     % dnsq a ns-ext.vix.com ns-ext.vix.com
     1 ns-ext.vix.com:
     117 bytes, 1+1+2+2 records, response, authoritative, noerror
     query: 1 ns-ext.vix.com
     answer: ns-ext.vix.com 3600 A 204.152.184.64
     authority: vix.com 3600 NS ns-ext.vix.com
     authority: vix.com 3600 NS ns1.gnac.com
     additional: ns-ext.vix.com 3600 A 204.152.184.64
     additional: ns1.gnac.com 130768 A 209.182.195.77

dnscacheが重複した IP アドレスを返す 一番の理由がこの BIND の不良です。

7. 特定の名前

dnscacheは内部的にlocalhostを処理します。 127.0.0.1 という A レコードがあったものとします。

内部的に1.0.0.127.in-addr.arpaを処理します。 localhost という PTR レコードがあったものとします。

ドットつき 10進表記のドメイン名を内部処理します。


2002-10-30 訳:前野年紀

8. history

dnscache はすべての in bailiwick なレコードをキャッシュします。
    port, transaction ID をあてられれば毒盛は簡単です。 


CategoryDns CategoryWatch CategoryTemplate

MoinQ: djbdns/dnscache/説明 (last edited 2021-06-03 03:14:49 by ToshinoriMaeno)