付録2　DNSサーバー（BIND9）

名前解決とは

人は www.t3.metro-cit.internal のような名前のほうが覚えやすく、コンピュータはIPアドレスでしか通信できません。その間を取り持つのが名前解決です。名前からIPアドレスを調べることを正引き、IPアドレスから名前を調べることを逆引きと呼びます。

名前解決の方法には、大きく2つあります。

hostsファイル

その機械の中にあるファイルに、名前とIPアドレスの組を書いておく。OSは、多くの場合DNSに問い合わせる前にまずこのファイルを見る。書いた内容はその1台にしか効かない

DNS

ネットワーク上のDNSサーバーに問い合わせる。名前の管理は世界中で分担されていて、答えはしばらくの間キャッシュ（記憶）される

DNSの階層

ドメイン名は、右から左へ、大きな範囲から小さな範囲へと並んでいます。www.example.com なら、いちばん右（見えないが、最後に「.」がある）が全体の根元（ルート）、次が com、次が example、最後が www です。名前の管理はこの階層に沿って分担されていて、それぞれの階層を担当するDNSサーバーが、次の階層の担当者を知っています。

ルートサーバー

階層のいちばん上。各トップレベルドメイン（com、jp など）の担当者を知っている

権威DNSサーバー

あるまとまり（ゾーン）について正式な答えを持つサーバー。付録2で作るBIND9はこれ

フルサービスリゾルバ

利用者の代わりに階層をたどり、答えを記憶しておくサーバー。この実験のネットワークでは 192.168.100.1 がその役割

課題2では、www.metro-cit.ac.jp という、もう1段階深い名前について、この流れを説明することが求められています。階層のどこで担当のサーバーが分かれているか（ゾーンの区切り）は、ドメインごとに決まっていて、いくつかの階層を1つのサーバーがまとめて担当していることもあります。実際の流れは、Ubuntuで次のコマンドを実行すると観察できます（学内のネットワークの設定によっては、外部に直接問い合わせられず使えないことがあります）。

dig +trace www.metro-cit.ac.jp

表示の中の IN NS の行が「次は誰に聞けばよいか」、最後の IN A の行が答えです。考察のヒント考察のヒント課題2では、答えが記憶（キャッシュ）されている場合とされていない場合で、問い合わせの流れが変わる点にも触れます。dig +trace が使えれば、実際の問い合わせの順番をエビデンスとして示せます。

hostsファイルとDNSの関係

1日目のhostsファイルとDNSは、どちらも「名前 → IPアドレス」を答えますが、仕組みが違います。hostsファイルは各機械の中の手書きのメモで、書いた機械だけに効きます。DNSはネットワーク越しに問い合わせる共有の電話帳で、サーバーの設定を1か所変えれば、そのサーバーに問い合わせるすべての機械に効きます。付録2の手順4が「1日目で設定した hosts を前提に」としているのは、両方の結果を見比べられるようにするためと考えられます。課題4は、この違いから利点と制約を考えるものです。考察のヒント考察のヒント名前とIPアドレスの対応を変えたいとき、hostsなら全部の機械を、DNSならサーバー1か所を直します。機械が10台、1000台に増えたらどうなるか、サーバーが止まったらどうなるかを考えると、利点と制約が見えてきます。

手順の解説

スクリーンショット（エビデンス）を撮るところ。マウスを乗せると撮るタイミングが表示され、押すとページ下のエビデンス一覧の該当項目へ移動します。考察を書くときに知っておきたいこと。マウスを乗せる（スマホでは押す）とヒントが表示されます。

sudo apt install -y bind9 dnsutils
sudo ufw allow 53/udp

sudo nano /etc/bind/named.conf.local

zone "t3.metro-cit.internal" {
    type master;
    file "/etc/bind/db.t3.metro-cit.internal";
};

sudo cp /etc/bind/db.local /etc/bind/db.t3.metro-cit.internal
sudo nano /etc/bind/db.t3.metro-cit.internal

$TTL    86400
@       IN      SOA     ns.t3.metro-cit.internal. admin.t3.metro-cit.internal. (
                        2026092901  ; Serial
                        3600        ; Refresh
                        900         ; Retry
                        604800      ; Expire
                        86400 )     ; Negative Cache TTL
;
@       IN      NS      ns.t3.metro-cit.internal.
ns      IN      A       192.168.100.xxx
www     IN      A       192.168.100.xxx

sudo named-checkconf
sudo named-checkzone t3.metro-cit.internal /etc/bind/db.t3.metro-cit.internal
sudo systemctl restart bind9
sudo systemctl status bind9

zone t3.metro-cit.internal/IN: loaded serial 2026092901
OK

nslookup www.t3.metro-cit.internal 192.168.100.xxx

サーバー:  UnKnown
Address:  192.168.100.107

名前:    www.t3.metro-cit.internal
Address:  192.168.100.107

結果の読み方（dig）

dig @localhost www.t3.metro-cit.internal
systemctl status bind9

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.t3.metro-cit.internal.     IN      A

;; ANSWER SECTION:
www.t3.metro-cit.internal. 86400 IN     A       192.168.100.107

;; SERVER: 127.0.0.1#53(localhost) (UDP)

@localhost

問い合わせ先。自分自身のBIND9に聞いている

status: NOERROR

正常に答えが返った。NXDOMAIN なら「そんな名前はない」

flags: … aa …

aa は authoritative answer（正式な担当者からの答え）

ANSWER SECTION

答えの本体。名前・TTL（秒）・種類（A）・IPアドレス

この画面がエビデンス1です。1エビデンス1の撮影ポイント撮影ポイント　エビデンス1BIND9を再起動したあと、Ubuntuで dig @localhost www.t3.metro-cit.internal を実行した直後。status: NOERROR と ANSWER SECTION の行が1画面に入るように撮る。エビデンス一覧の項目へ移動 ↓

エビデンス（スクリーンショット3点）

• 1. dig @localhost www.t3.metro-cit.internal で、名前解決の結果が表示される画面↑ 「結果の読み方」の節で撮る
• 2. systemctl status bind9 で、DNSサービスが動いていることが分かる画面↑ 手順3で撮る
• 3. Windowsから nslookup www.t3.metro-cit.internal 192.168.100.xxx を実行し、名前解決できる画面↑ 手順4で撮る

課題を考えるための材料