DNSの仕組みについてまとめてみた

15785 ワード
bind dns dns テキストリンク

はじめに

DNSについて調べてみました

参考

「DNSをはじめよう」

まとめ

  • DNSの種類
    • 権威サーバー(DNSコンテンツサーバー)
    • DNSキャッシュサーバー(フルリゾルバ)
  • whois
    • Whois検索はレジストリが提供しているサービス
  • ゾーン = ドメイン (ゾーンファイルは権威サーバーに存在)
    • 権威サーバーで管理するドメインの個数分、ゾーンファイルが存在(拡張子=.zone.trans)
    • 逆引きもある場合は逆引きファイルも存在
    • セカンダリの拡張子
    • 逆引き(拡張子=.rev.trans) ゼーン(拡張子=.zone.trans)
  • キャッシュ(DNS浸透に時間がかかるとはこのこと)
    • DNSキャッシュサーバーが名前解決に成功した場合、権威サーバーのゾーンファイルのTTL時間分、キャッシュサーバーにAレコードの情報がキャッシュされる
  • ネガティブキャッシュとは
    • DNSキャッシュサーバーが名前解決に失敗した場合(権威サーバーに対象のリソースレコードがない場合)に対象(ゾーン)ドメインのSOAレコードのMiNIMUMのTTL時間だけリソースレコード値が無いことがキャッシュされる
    • SOAレコード自身ののTTLとSOAレコードのMiNIMUMの小さいほうが選択される

@   IN   SOA   NS1.DO-REG.JP.    root.FSV.JP.(
                                 1001251650 ; Serial
                                 10800      ; Refresh 3 hour
                                 3600       ; Retry 1 hour
                                 3600000    ; Expire 1000 hours
                                 3600       ; Minium 1 hours
                                )
  • DNS浸透とは
    • DNSキャッシューサーバーは一度検索すると権威サーバーのリソースレコードで指定されたTTL時間だけ内部にキャッシュを保存して2度目からの検索はルートDNSに検索に行かずにキャッシュを参照すること
    • よって権威サーバーDNSのAレコードを変更しても、以前の内容をDNSキャッシュサーバーが以前のAレコードのTTL時間だけキャッシュするのでAレコードを変更したとしても反映に時間がキャッシュ時間だけかかること。DNSキャッシュサーバーのキャッシュをクリアして新しくDNS検索するようにさせることもできる

クエリの種類

DNSサーバーのクエリーには2種類あります。

  • クライアントからキャッシュDNSサーバーへのクエリー(再帰的クエリ)
    • 送信相手に再帰的な動作を要求するため、再帰的クエリ
    • クエリー中にRDビット = 1がセットされている
  • キャッシュDNSサーバーから権威DNSサーバーへのクエリー(非再帰的クエリ、反復クエリ)
    • クエリー中にRDビットがセットされていない

登場人物

  • レジストリ(登録管理組織)=卸元
    • レジストラに卸すだけ
    • TLDを管理
    • comとかjpとか

販売 ↓ ↑ ユーザーが登録したドメインをレジストラのNSで解決しますよ、という情報の登録お願い

  • レジストラ(登録事業者)=お名前comなど
    • ドメイン名をリセラに卸す
    • レジストラはレジストリが管理するデータベースに自由にアクセスできるよう、レジストリと契約を交わしているらしい
    • 一般消費者にドメインを販売(サービス面や価格面で競争が働く仕組み)
    • 登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する機関です
    • 登録したドメインは自分たちのNSで解決できますよーという情報をレジストリに登録してもらって、名前解決をたどれるようにする　(委任情報の登録)

　　↓

  • リセラ(再販事業者)　ムームードメインなど

    • 一般消費者にドメインを販売

  • ICANN

    • ドメインの登録作業やIPアドレスを管理する役割を担う非営利団体。レジストラになるためには「ICANN」に認定を受けなければならず、「ICANN」の定める規則やポリシーを遵守することが求められる。

私たちユーザーがドメインを取得しようと思ったら、必ずレジストラを介してレジストリ(卸元)に申請
レジストラはレジストリが管理するデータベースに自由にアクセスできるよう、レジストリと契約を交わしてい

ドメインを買うときのポイント

  • ドメインの品質自体はどこで買おうが問題ない
  • 各会社でオプションが異なる。更新のしやすさとか、更新料の安さなど

レジストリとTLD(トップレベルドメイン)

google.comのcomやexample.jpのjpをTLDと呼ぶ

一意性を保つために一つのTLD**に一つのレジストリによって管理

レジストリのVeriSign Global Registry Servicesはcomだけでなく netやnameなど複数のTLDを任されています

レジストリが任されたTLDのドメインをネームサーバーで管理している。
* 信頼できない、新興のレジストリが管理しているドメインを使用する時は注意が必要
- ioなどを使っていた監視サービスがioのNSが落ちたことで使えなくなったことがあった

Whoisとは

  • レジストリのサービス
  • そのドメインを所有している組織や担当者の氏名や連絡先、ドメインの有効期限をwebで見れるようにしたもの
  • レジストラが登録者の情報ではなくて代理でレジストラの情報をwhoisに登録もできる。

DNSの種類

  • ネームサーバー、コンテンツサーバー、権威サーバー
    • ドメイン名とIPアドレスを紐づけた情報を登録
  • フルリゾルバ、DNSキャッシュサーバー、フルサービスリゾルバ
    • クライアントの代わりにドメイン名からIPアドレスを調べてくれる

キャッシュに関して

DNSキャッシューサーバー

「DNSを変更したけど浸透には時間がかかる」
- 調べた結果はリソースレコードに設定されているTTLが切れるまでキャッシュに保存*してくれるのでキャッシュの情報が使われてしまうということ


  example.jp.     3600    IN NS   ns2.example.jp.
  example.jp.     3600    IN MX   10 mx1.example.jp.
  example.jp.     3600    IN A    61.120.151.84
  • Aレコードを変更した場合はAレコードのTTL時間分かかる
  • NSレコードを変更した場合はNSレコードのTTL時間分かかる

省略した場合は$TTL時間になる

ただし一部のDNSキャッシュサーバーは一つ前の親のTTL時間でキャッシュしてしまうらしい

この挙動はフルリゾルバの実装依存になります。体感的には子ネームサーバのTTLに従う実装が多いです。ただ親ネームサーバのTTLに従うフルリゾルバは存在します(例えばOCNが提供するフルリゾルバは親ネームサーバのTTLに従います)。

よって権威サーバーの古いリソースレコードのTTL時間、キャッシュサーバーがキャッシュで応答してしまうので
もしすぐに切り替えたければ、DNSキャッシュサーバーのキャッシュをクリアして新しくDNS検索するようにさせる

ネガティブキャッシュとは

  • 対象のリソースレコードがない場合に対象(ゾーン)ドメインのSOAレコードというのTTL時間だけリソースレコード値が無いことがキャッシュされる

権威サーバー

  • リソースレコード
    • 「ドメイン名とIPアドレスの紐づけ」ひとつひとつのこ
  • 自分で権威サーバーを管理しようと思ったら
    • ドメインを取得した業者に権威サーバーの情報を登録する。その後？業者が上位に登録してくれる？？

DNSゾーン

  • インターネットのドメイン名の管理において、あるDNSサーバ（ネームサーバ）が自ら管理するドメインのこと
    • IPアドレスを返すことに責任をもつ
  • サブドメインなどもIPを返してもいいし、委任してもよい
  • 権威サーバーはゾーン一つに対して、を保持

権威サーバー

bindの場合

設定ファイル

/etc/namd/named.conf

  • ここに管理するゾーン情報のファイルの場所など書いてある
  • ドメイン一つに一つのゾーン情報ファイルがある
  • 逆引きがあれば逆引きのゾーン情報ファイルがある

ゾーンファイル

ドメインに関する情報。SOAやそのドメインのNSやA、MXレコードなど

SOA

ゾーンそのものに関する情報
委任されたゾーンを管理する際に必要な情報を設定

リソースレコードの値


www.example.jp  3600    IN  A   61.120.151.84

左から
ラベル
TTL
クラス
タイプ
リソースデータ

ゾーンファイル

https://do-reg.jp/college/dns_v02_p3.html
https://www.atmarkit.co.jp/fnetwork/dnstips/031.html
https://www.infraexpert.com/study/tcpip23.html


//デフォルトのTTL時間。下記レコードで省略するとこの時間がTTLになる
$TTL 5m

// @はドメイン名の省略記法
// $ORIGN ドメイン　で指定できる
// $ORIGNは修飾指定のないレコードに付加するドメイン名 (起点名) を設定する。
// 明示的にORIGINを指定しない場合、そのゾーンファイルのドメイン名自体が暗に指定される

// メールアドレス
// nsdomain1.jp　= このゾーンをもつプライムDNSサーバー
// root@ne.jp = 管理者のメールアドレス
@       IN      SOA     nsdomain1.jp. root.ne.jp. (
                2018102500      ; serial
                1h              ; refresh
                30m             ; retry
                4w              ; expire
                5m              ; ttl
)

// 左側の空白は@(ドメイン)が入る
// ラベルが同じ値の場合、省略すれば前段と同じ値になる
// ドメインを委譲する場合、移譲するNSレコードのAレコードも記載する必要がある
                IN      NS      nsdomain1.jp.
                IN      NS      nsdomain2.jp.
                IN      NS      nsdomain3.jp.
;
                IN      MX      10      mail
;
//.がついている場合FQDNとして解釈される
//左に.がついていないのでwww.ドメイン　mail.にドメインになる
                IN      A       x.x.x.x
www             IN      A       x.x.x.x
mail            IN      A       x.x.x.x
;

  example.jp.     3600    IN NS   ns1.example.jp.
  example.jp.     3600    IN NS   ns2.example.jp.
  example.jp.     3600    IN MX   10 mx1.example.jp.
  example.jp.     3600    IN A    61.120.151.84
  ;
  ns1.example.jp. 3600    IN A    61.120.151.82
  ns2.example.jp. 3600    IN A    202.11.16.212
  mx1.example.jp. 3600    IN A    61.120.151.83
  www.example.jp. 3600    IN A    61.120.151.84

ORIGN

　※　 明示的にORIGINを指定しない場合、そのゾーンファイルのドメイン名が暗黙に指定される。
　※　 ORIGINと同じドメイン名は @ で記載される。 例 - infraeye.com. ⇒ @

補足

  • 末尾のドット

    • ドメイン名の最後に「.」を付けるとFQDNとして解釈され、「.」を付けずに書くとORIGINの内容が末尾に付くことになります。

  • セミコロン

    • セミコロンはこの文字から行末まではコメント

  • 省略

    • mx mailの末尾に.がないのでmail.ドメイン名になる
    • 左は省略されているので、ドメイン名 @ドメイン名のメールアドレスで名前解決きたとき
    • mail.ドメイン名のホストが使用されるということ。そのmail.ドメイン名のAは下に書かれている

  • TTL 5m

    • 一度問い合わせを行ったDNSサーバーはキャッシュを保存し、再度問い合わせをする必要がなくなる。この時間DNSキャッシュサーバーが保存する

  • @（アットマーク）

    • 自ドメインである を指しています。
    • このゾーンファイルのドメイン名しか記載がない場合@だけでそのドメイン名を明示できる

  • root.メールアドレス.ne.jp.

    • 管理者のメールアドレス
    • 「.（ドット）」でユーザ名とドメインを区切ります。

  • NSレコード

ドメイン移管とは

  • ユーザーとお金の管理などしているドメインの管理会社（レジストラ）について、他の事業者へ乗り換えること

コマンド

構文チェック

コンフィグ

named-checkconf /etc/named.conf

ゾーンファイルの確認

ゾーン名とゾーンファイル名を指定する。

named-checkzone "{domain}" /path/to/{domain}.zone

namedをコントロール

rndc reload

named.conf と ゾーン情報をリロードする。
シリアル番号が増えているゾーン情報のみリロードする。

digコマンド

  • BIND9.9以降のdigコマンドはデフォルトでEDNS0付きの問い合わせを送る
  • 問い合わせの送り先がフルリゾルバか権威サーバーかで名前解決要求を有効、無効にするかを使い分ける必要がある
    • フルリゾルバには名前解決要求有効
    • 権威サーバーには名前解決要求無効

基本

dig ドメイン

権威サーバーを調べる

  • dig NS ドメイン

whois

  • IPアドレスやドメイン名の登録者などに関する情報を、インターネットユーザーが誰でも参照できるサービスです
  • Whois検索はレジストリが提供しているサービス

DNSセキュリティ

  • ゾーン転送の制限
    • スレーブDNSのみに限定
    • allow-transfer{ スレーブIP}

DNSSECとTSIG

zsk鍵とksk鍵
「DNSをはじめよう」

  • トラストアンカーにはルートのksk公開鍵が最初からインストールされている
  • 署名があるのはzsk公開鍵とAなどのリソースレコード
  • DSレコードは下位権威サーバーのksk公開鍵のハッシュ値
  • KSK公開鍵、ZSK公開鍵を信頼していく仕組み

DNSSEC

キャッシュサーバーが権威サーバーで応答してきたDNS応答が正しい改ざん、正当な管理者によって行われたことを保証

公開鍵は上位のゾーンに預けて検証して保証。信頼の連鎖。

マスター・サーバのIPを偽装した「なりすましサーバ」が出現した場合はまったくの無防備になります。

TSIG

　そこで、TSIG（Transaction Signature）を用います。TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします