ドメイン名システム (DNS)
インターネットの通信相手は、
IPv4アドレスあるいはIPv6アドレスと呼ばれる
32bitや128bitの数値により識別されます。
この数値は人間が扱うには不便であるため、
インターネットでは名前と数値の対応表を用意し、通信相手を名前で識別できるドメイン名システム (DNS) を採用しています。
通信相手は例えば www.example.com という名前を持ちます。この名前は次のように分解できます。
ホスト名とはコンピュータやサーバの名前です。
また、この例ではドメイン名はexample.comになります。
DNSでは、DNSサーバと呼ばれるサーバに、
ドメイン内の名前とアドレスの対応付け表を持たせておきます。
名前からアドレスを得たい、あるいはアドレスから名前を得たいコンピュータやサーバは、
DNSサーバへの問い合わせを行うことで、名前とアドレスの相互変換を行うことができます。
名前をアドレスに変換することを正引き、アドレスを名前に変換することを逆引きと呼びます。
www.example.comの例では、おおよそ次の流れで名前からアドレスを解決しています。(実際はもう少し複雑な仕組みです)
トップレベルドメイン(一番最後のドメイン名)である.comを管理するDNSサーバに www.example.com のアドレスを問い合わせる。
.com を管理するDNSサーバはサブドメインである example.com のDNSサーバにwww.example.comのアドレスを問い合わせる。
example.com を管理するDNSサーバは.com を管理するDNSサーバにwww.example.com のアドレスを返す。
.com を管理するDNSサーバは問い合わせ元にwww.example.com のアドレスを返す。
独自ドメインの取得
独自ドメインを取得する前に、先に説明したDNSの概略を理解しておくと良いでしょう。
DNSの仕組みを考えると、独自ドメインは次のステップで取得できることになります。
独自ドメインを管理するDNSサーバを用意する。
取得したいドメインの親ドメインに対応したDNSサーバを管理する機関に、そのサブドメインの取得を申請する。
サブドメインのDNSサーバに、名前とアドレスの対応付け表を設定する。
取得したいドメインの親ドメインは、.comや.jpなど「トップレベルレベルドメイン」の方が多いかとおもいます。
このようなDNSサーバを管理する機関へのサブドメイン取得申請は、ドメイン取得代行業者を利用するのが一般的です。
ドメイン取得代行業者の中には、サブドメインの取得に加えてDNSサーバも用意したり、
全世界に公開される管理者の公開情報(Whois情報)として業者自身の情報を代理公開してくれる業者もあります。
ドメイン取得代行業者を利用する前に、どの機能を提供しているのか確認しておくと良いでしょう。
例えば執筆時点である2016年5月現在、
専用サーバやVPS(バーチャル・プライベート・サーバ)の業者である
さくらインターネットは、
DNSサーバを準備し、公開情報の代理公開を行ってくれます。
DNS対応付け表の作成
DNSサーバを自身で用意する場合は、BIND等のソフトウェアを利用してDNSサーバを構築します。
DNSサーバを準備してくれるドメイン取得代行業者を利用しても、
サブドメインのDNSサーバに設定する名前とアドレスの対応付け表だけは自身で作成します。
いずれにしても、名前とアドレスの対応付け表については理解しておく必要があります。
レコードの種類 | 内容 |
SOA | DNSサーバのホスト名、管理者メールアドレス(最初の.は@に置き換える)、ドメイン更新情報 |
A | ホスト名に対応するIPv4アドレス。 |
AAAA | ホスト名に対応するIPv6アドレス。 |
PTR | IPアドレスに対するホスト名。 |
NS | DNSサーバのホスト名。 |
MX | メールサーバの優先度とそのホスト名。 |
CNAME | ホスト名のエイリアス。 |
TXT | 追加のテキスト情報。SPFと呼ばれる迷惑メール対策情報の提供などで使われます。 |
1つのホスト名に対して複数のアドレスを対応づけても問題ありません。その場合は、ホスト名を与えてアドレスを取得すると複数のアドレスが返されます。
CNAMEは原則として、対応表内でエイリアス名をホスト名として参照してはならないという制約があります。できるだけAやAAAAを使ったほうが良いでしょう。
対応付け表の書き方
対応付け表には、次の行(レコード)を繰り返し書いていきます。
レコード名は最後に.があればフルのドメイン名、そうでない場合はドメイン名からの相対的な名前として扱われます。
クラスは通常IN(インターネット)になります。
ゾーンファイルの指定
通常はゾーンごとにファイルを分けて書きます。ファイル名に制約はありません。
その場合、正引き、逆引きのそれぞれについて、SOAレコードを含むゾーンファイルを指定します。
正引きの例は以下です。
zone "example.com" {
type master;
file "/etc/bind/example.com.zone";
}
例えばIPv4の192.168.1.8〜15に対する逆引きの例は以下です。
/29は逆引きでカバーされる範囲が29ビット固定部分と3ビットの自由部分で構成されることを表します。
zone "8/29.1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/8.1.168.192.rev";
}
逆引き指定されたファイルの先頭には$ORIGIN 8/29.1.168.192.in-addr.arpaを加える必要があるようです。
IPv6の場合は、IPv6アドレスの16進数表記を左右反転させてから、
それを1文字ごとに.で区切り、最後にip6.arpaを追加する形でゾーン指定します。
DNSサーバをドメイン取得代行業者が用意する場合、ゾーンファイルを自身で指定することはおそらくありません。
SOAレコード
SOAレコードは次の情報を持ちます。
優先DNSサーバ | DNSサーバのホスト名を記述します。 |
管理者メールアドレス | @を.に置き換えたメールアドレスを記述します。そのため、メールアドレスのユーザ名部分に.を含むことはできません。 |
ドメイン情報のシリアル番号 | 更新のたびに数値が増えるのであれば何でも良いです。4桁、2桁、2桁の年月日(YYYYMMDD)にその日の更新回数を2桁の数値で追加した8桁の番号を使うことが多いようです。 |
リフレッシュ間隔(秒) | バックアップ用のDNSサーバが優先DNSサーバから全データを取得する間隔。 |
リトライ間隔(秒) | バックアップ用のDNSサーバがデータ取得失敗した際にリトライする間隔。 |
有効期限(秒) | バックアップ用のDNSサーバのデータ有効期限。 |
存在しない名前のキャッシュ時間(秒) | 存在しないとされた名前を、問い合わせせずに存在しないとみなしてよい時間。 |
SOAレコードは正引きと逆引きのいずれについても必要です。
SOAレコードは、例えば次のように書きます。@はサブドメイン名自身を指します。
フルのホスト名を記述する場合は最後に.を追加します。
@ IN SOA ns1.example.com. root.example.com. (2016011501 21600 3600 604800 3600)
DNSサーバをドメイン取得代行業者が用意する場合、SOAを自身で書くことはおそらくありません。
Aレコード
AレコードはIPv4の正引きに使われます。ホスト名とIPアドレスとの対応表を書きます。
@ IN A 192.168.1.9
www IN A 192.168.1.10
mail IN A 192.168.1.11
ns1 IN A 192.168.1.12
AAAAレコード
AAAAレコードはIPv6の正引きに使われます。
@ IN AAAA fe80:1111:2222:3333:4444:9
www IN AAAA fe80:1111:2222:3333:4444:10
mail IN AAAA fe80:1111:2222:3333:4444:11
ns1 IN AAAA fe80:1111:2222:3333:4444:12
PTRレコード
PTRレコードはIPv4、IPv6の逆引きに使われます。IPアドレスとホスト名との対応表を書きます。
例えば、IPv4の場合は次のように書きます。
フルのホスト名を記述する場合は最後に.を追加します。
9 IN PTR example.com.
10 IN PTR www.example.com.
11 IN PTR mail.example.com.
12 IN PTR ns1.example.com.
NSレコード
ドメインのDNSサーバのホスト名を指定します。
フルのホスト名を記述する場合は最後に.を追加します。
MXレコード
メールサーバの優先度とそのホスト名を指定します。
優先度の数値が小さいほど優先されます。
@ MX 10 mail
@ MX 20 mail2
フルのホスト名を記述する場合は最後に.を追加します。
@ MX 10 mail.example.com.
@ MX 20 mail2.example.com.
CNAMEレコード
ホスト名の別名を定義します。
可能であればAやAAAAで定義したほうが良いでしょう。
TXTレコード
ホスト名にテキストデータを関連付けます。
DNSはテキストデータの内容をチェックしません。
TXTレコードは、SPFと呼ばれる迷惑メール対策情報の提供などで使われます。
メールサーバは、送信元を偽装した迷惑メールであるか判別するために、
送信元ドメインのTXTレコードにSPF用のデータが含まれるかチェックしています。
例えば以下のTXTレコードは、メールを送信しないドメインであることを宣言しています。
また、以下のTXTレコードは、mail.example.comからのみメールを送信するドメインであることを宣言しています。
v=spf1 a:mail.example.com -all