1. Qiita
  2. 投稿
  3. dns

俺のDNS - 脱・初心者のためのメモ

  • 9
    いいね
  • 0
    コメント

DNSを運用している人、これからBINDを使ってみたい人にとって必須といって良い情報をまとめておく。
「何となく理解している(つもり)」という不安な状態から「DNSの動きをわかっている」という安心できる状態になるのをゴールとする。

DNSとは

大きくわけて以下の3つの役割を行う

  • フルサービスリゾルバ(キャッシュサーバ)
    • 名前解決などの問い合わせに対して返答する機能
  • コンテンツサーバ
    • ドメイン名とIPアドレスのひも付けを行う
  • 分散型データベースをまとめる機能

設定によって停止させておく機能もある。

権限の委譲

スクリーンショット 2016-08-18 13.22.16.png

DNSのネットワーク的なつながりは、上記のツリー構造になっている。

  • /サーバ(ルートサーバ)は世界に13台ある(2016年現在)
  • /サーバはjpドメインの権限を持つサーバの情報を「知って」いる
    • つまり/サーバは、jpドメインの権限を管理するサーバ情報を委譲されている
  • jpサーバはco.jpドメインの権限を持つサーバの情報を「知って」いる
    • つまりjpサーバは、co.jpドメインの権限を管理するサーバ情報を委譲されている

フルサービスリゾルバ

/サーバから順にjp、co.jp、example.co.jpと名前解決していく処理を行うサービス。
一度名前解決した情報はキャッシュするため、2回め以降は素早く返答することが可能。
調べた内容を保存(キャッシュ)するため、キャッシュサーバ、キャッシュDNSなどとも呼ばれる。

スタブリゾルバ

フルサービスリゾルバに対して、スタブリゾルバというものがある。

スタブリゾルバとは、フルサービスリゾルバに対して問い合わせを「する側」のリゾルバである。
つまり、ブラウザがURLをリクエストした際、PC側のスタブリゾルバが外部のフルサービスリゾルバへ問い合わせを行い、フルサービスリゾルバが各種/サーバやjpサーバなどへ問い合わせ代行を行う。

  • Linuxでは/etc/resulv.confがスタブリゾルバの設定ファイル
    • どのフルサービスリゾルバへ問い合わせるか記述する
  • Windowsではインターネット プロトコル バージョン4(TCP/IPv4)のプロパティがスタブリゾルバの設定になる
    • 指定するDNSがフルサービスリゾルバ
    • ルータ側でフルサービスリゾルバのIPアドレスを指定していれば指定しなくてもOK
  • Macではシステム環境設定ネットワークにある任意のアダプタから詳細情報を開き、DNSカテゴリのDNSサーバ内で確認することができる
  • GoogleのDNSがハイスピードらしく、フルサービスリゾルバとしてスタブリゾルバ側に設定してる人も多い(らしい)
    • プライマリ:8.8.8.8
    • セカンダリ:8.8.4.4

名前解決の仕組み

Untitled.png

  1. PCのブラウザからURL(www.example.co.jp)を打ち込む
    • スタブリゾルバがフルサービルリゾルバへ問い合わせを代理依頼
  2. フルサービスリゾルバがこのURLのドメインを知っているか知らないかを判断する
    • キャッシュがあるかないかのチェックをする
      • 知っていれば名前解決として完了
  3. /サーバに、jpサーバの権限を持つDNSサーバを問い合わせる
    • /サーバはjpサーバの委譲を受けているので必ずリゾルバへ返答できる
    • /サーバの情報(hint)は各PCに最初から入ってる(caファイルなど)
  4. jpサーバに、co.jpサーバの権限を持つDNSサーバを問い合わせる
    • jpサーバはco.jpサーバの委譲を受けているので必ずリゾルバへ返答できる
  5. co.jpサーバに、example.co.jpサーバの権限を持つDNSサーバを問い合わせる
    • co.jpサーバはexample.co.jpサーバの委譲を受けているので必ずリゾルバへ返答できる
  6. 名前解決ができたらリゾルバは情報を保存(キャッシュ)する
    • 次回同じドメインの問い合わせが来たらキャッシュを利用して直ぐにPCへIPアドレスを返す
  7. PCはIPアドレレスを取得できたのでIPアドレスで直接目的のサーバへアクセスする

上記のように、「最初にIPアドレスを知る」ための名前解決をDNSで行い、次に「取得したIPアドレスをつかって目的のサーバに到達」する、という2種類を「インターネットアクセス」と呼ぶ(名前解決の範囲は、上記番号と図で言うと1〜6まで)。

この方式を、再帰的問い合わせ と呼ぶ。
セキュリティ的に再起問い合わせを禁止してるDNSもある(自社のドメインだけ管理してたりする独自DNS。いわゆるコンテンツDNSサーバ。通常そういったDNSはそこで止まってしまうのでフルサービスリゾルバとして設定してはいけない)。

  • Linuxでは/var/named/named.ca がhintファイル

キャッシュ

再帰問い合わせに成功したリゾルバは効率を図るためにその情報をキャッシュするが、キャッシュには生存期間が決められている。

もし生存期間が決められてなければ、目的のサーバが引っ越しなどでIPアドレスが変わっても追従出来ない。そのため、適切な期間を経るとキャッシュが消滅するようになっている。その期間を生存期間(TTL)と呼ぶ。TTLは、Time To Liveの略。

DNSがやり取りするゾーン情報では、以下の様な種類のキャッシュを使用する。
TTLは基本的に「秒」で記述する(ただし日や週で指定することも可能)。
指定できる内容としては以下になる。

  • refresh(更新時間)
    • スレーブの更新タイミングの目安となる秒数
  • retry(再試行時間)
    • 再実行する際にウェイトする秒数
  • expiry(有効期限)
    • マスターがダウンしてる際の生存期間
  • niminum(ネガティブキャッシュ)
    • ネガティブキャッシュの生存期間
    • デフォルトのTTL

ドメイン情報や権限などが書かれ、他のDNSと共有する情報を「ゾーン設定ファイル(ゾーンファイル)」と呼ぶ。
ゾーンファイルは上記TTLとば別に、シリアル番号というものも持つ。いくらゾーンファイルを新しく更新しても、このシリアル番号が低いものは更新されないので注意する必要がある。
シリアル番号は番号であれば何でも良いが、全世界的に主に「年月日」+「連番」を記述するのが定石となってる(2016082501など)。

マスタとスレーブ

1台のDNSに負荷が偏らないようにするため、複数台のDNSサーバで情報を分散しておくのが通例となっている。これならネットワークトラブルなどで1台が破損しても、複数台用意しておけば名前解決が可能。

example.co.jpの権限を持っているDNSサーバ(マスタ)から、example.co.jpの情報をコピーさせ、情報のみを他のDNS(スレーブ)に渡す。
この情報を「ゾーン」とよび、ゾーンをコピーさせるのを「ゾーン転送」と呼ぶ。

  • マスタはスレーブにコピーしない
  • スレーブがマスタからコピーしてくる

ゾーン転送は基本的に一方通行。この一方通行の元がマスタ、一方通行の先がスレーブと覚えても良い。
マスタ、スレーブというのはそういうDNSのアプリケーションがあるわけではなく、そういう設定になっているだけで同じDNSである。

マスタは自分で管理し、スレーブを外部の業者に任せるという方法が通例。そのための無料サービスもある。

マスタをプライマリ(primary)として捉えれば、スレーブは2台目なのでセカンダリ(secondary)になる。セカンダリを複数台持ち、兄弟構成にはできるが、その先は委譲しない(してはいけない)ので、3台目のターシアリ(tertiary)という概念はない。

マスタもスレーブも中身はほぼおなじなので、スレーブがバックアップ用というわけではない。マスタもどこかのスレーブになることもある。

逆引き

使用しているサーバのグローバルIPが220.110.50.25とする。
この場合は以下の様なツリーになる。

arpa
┗ in-addr
 ┗ 220
  ┗ 110
   ┗ 50
    ┗ 25

ツリーの上から見れば、arpa.in-addr.220.110.50.25となるが、実際には以下のように逆から構成されたドメインになる。

25.50.110.220.in-addr.arpa

ドメイン名からIPアドレスを取得するのが正引き。IPアドレスからドメインを問い合わせるのが逆引き。
1つのIPアドレスには複数のドメインを設定することができるので、逆引き問い合わせの場合は複数のドメインがヒットすることがある。

ドメインは購入できるが、IPアドレスは買うものではない(一時的に借りる)ので、基本的にIPアドレスの管理はプロバイダ側に任せる事が多い(つまり自社でDNSを建てる場合、逆引き設定がよくわからなければ、変に設定するより何も設定しないほうが良いということ)。

レコード

DNSが持つ様々なデータをレコードという形で管理する。
ここではあくまで便宜的に ゾーン = ドメイン = FQDNということで説明する。
FQDNとは最後にドットをつけたドメイン名。

DNSにBIND9を使ってる場合、こちらも参照されたし。
俺のDNS - BIND9の覚書

Aレコード

ドメインからIPアドレスを調べる際に参照されるレコード。

www.example.co.jp. 86400 IN A 220.110.50.25

  • FQDNTTLIN AIPアドレス という並び。
  • IN Aはインターネットアドレスと言う意味。
  • 正引きする際に必須のレコード
  • IPv6向けにAAAAレコードがある

CNAMEレコード

別名を付ける場合に指定するレコード。
元になるドメインは必ずAレコードで指定されたものを使う。

mail.example.co.jp. 86400 IN CNAME www.example.co.jp.

  • 別名TTLIN CNAMEFQDNという並び
  • CNAMEをCNAMEレコードで別名に指定することが出来ない
  • 外部からアクセスした場合はAレコードもCNAMEレコードも同じ扱いになる
  • sendmailではAレコードとCNAMEレコードは区別される

NSレコード

ドメインの権限を持つDNSサーバを指定するレコード。

example.co.jp. 86400 IN NS ns1.example.co.jp.

  • FQDNTTLIN NSDNS名という並び
  • 下位にあるドメインの権限を持つDNSサーバ(この場合はns1.example.co.jp)を指定する
  • 再帰問い合わせがあった場合はこのレコードが使用されるので重要
    • example.co.jpというドメインを管理してるサーバはどこですか? → ns1.example.co.jpですよ、となる
    • セカンダリを用意してるならもう一行ns2.example.co.jpなどが指定してあることもある

SOAレコード

SOAというのはStart Of Authorityの略。
どのDNSサーバがどのドメインを管理しているのかを宣言する。

example.co.jp. 86400 IN SOA ns1.example.co.jp. root.example.co.jp. ( resial reflesh retry expiry minimum)

通常、カッコの中身は改行して記述する。

example.co.jp.    86400    IN SOA ns1.example.co.jp.    root.example.co.jp. (
    resial
    reflesh
    retry
    expiry
    minimum
)
  • FQDNTTLIN SOAマスタDNSサーバ管理用メールアドレス、各TTL という並び
    • @記号を使えない(別の意味で使う)のでメールアドレスのローカルパートの後ろは「.」で区切る
  • SOAレコードがいわゆる権限権威という意味になる
    • この場合、example.co.jpは、このSOAが書かれたDNSが権威を持っていることになる

MXレコード

メールエクスチェンジ(Mail e Xchanger)のこと。つまりメールの送受信で使うドメインを設定する。
通常メールサーバはmail.example.co.jpなどと指定するが、このままではfoo@mail.example.co.jpになってしまうので、MXレコードに指定してfoo@example.co.jpとすることが可能。

example.co.jp 86400 IN MX 10 mail.example.co.jp.

  • FQDNTTLIN MX参照値ドメイン、という並び
  • 参照値はいくつかあるレコードのうち優先度を指定する
    • 小さいほど優先的に使われる
      • example.co.jp 86400 IN MX 10 mx1.example.co.jp.
      • example.co.jp 86400 IN MX 20 mx2.example.co.jp.
        • 上記の場合、mx1がダウンしてたら優先的にmx2が使われるし、ダウンしてなかったらmx1が優先的に使われる
      • ラウンドロビン的な使い方ができる
  • 通常、TXTレコード、SPFレコードとともに使用し、セキュリティを高めておく

TXT、SPFレコード

改ざんが容易に出来てしまうメールの仕組み上、本当にそのドメインから送られてきてるよ、という証明が必要になるので、そのために記述することが多い。

example.co.jp 86400 IN TXT "v=spf1 a mx ptr ip4:220.110.50.25 mx:mx1.example.co.jp -all"
example.co.jp 86400 IN SPF "v=spf1 a mx ptr ip4:220.110.50.25 mx:mx1.example.co.jp -all"

適切に使用するためには、メールサーバ側でこのレコードを見る設定にしておく必要がある。

PTRレコード

逆引き用のレコード。Aレコードの逆と認識しておいてOK。

25.50.110.220.in-addr.arpa. 86400 IN PTR www.example.co.jp

  • 逆引きIPTTLIN PTRFQDN、という並び

digコマンド

DNSサーバから様々な情報を取得して表示することができるコマンド。

基本的な使い方

  • dig example.co.jp
    • example.co.jpのA、CNAMEレコードを表示する
  • dig example.co.jp MX
    • example.co.jpのMXレコードを表示する
    • MX部分を変更すれば他のレコードも見れる
  • dig example.co.jp ANY
    • すべてのレコードを取得する
  • dig @ns1.sample.com example.co.jp CNAME
    • dn1.sample.comというDNSサーバへexample.co.jpのCNAMEを問い合わせる
  • dig -x 220.110.50.25
    • IPアドレスからドメイン名を逆引きする
    • dig 25.50.110.220.in-addr.arpa PTRでも同じ

ゾーン転送

レコードタイプをAXFRにすると、@で指定したDNS(マスタを指定する)からゾーン情報を転送してもらえる。
ただしマスタが許可しているスレーブからでしか転送してもらえない(この機能を利用してセキュリティのテストが可能。あえて許可されてないDNSサーバから転送がちゃんと失敗するかのテストができる)。

  • dig @ns1.sample.com example.co.jp AXFR
    • マスタであるns1.sample.comからexample.co.jpの情報を転送(ゾーン転送)をしてもらう