【DNSの機能（SOAレコード）について】
このHPはDNSの機能（SOAレコード）についてまとめたものです。
1-1 SOAレコード
SOAレコードは、ゾーンファイルの中で用いられるレコード。SOAレコードでは、
そのゾーンファイルが管理するゾーンの情報を持っている。
また、そのドメインを管理しているプライマリDNSサーバの指定や、ゾーン管理者の
メールアドレス、スレーブDNSサーバに対するゾーン転送の設定などを行う。
下図で、SOAレコードの例を示す。
①：ゾーン名。ここで指定したゾーンの権限を持つことを宣言する。
②：このゾーンのプライマリDNSサーバーを指定する。この例では、このゾーンに対するプライマリDNSサーバ名が「ns1.example.co.jp.」であることを示している。
③：ゾーン管理者のメールアドレスを指定する。ただし、ゾーンファイルの中では、「@(アットマーク）」は特殊な
用途で用いられるので、メールアドレスの「@(アットマーク）」を「.(ドット）」に置き換えて指定する。
「ccnamaster@example.co.jp.」の場合は「ccnamaster.example.co.jp.」と指定する。
④：ゾーンファイルの「シリアル値」を表す。シリアル値はプライマリDNSサーバから、スレーブDNSへのゾーン転送が行われるかどうかを決定する設定情報。このシリアル値が大きいほど、新しいゾーンファイルであるとみなされる。
⑤：「リフレッシュ値（更新時間）」を表す。スレーブDNSサーバーは、マスターDNSサーバに対して、定期的にゾーンファイルが更新されているか確認する。
このスレーブDNSサーバからプライマリDNSサーバへ、問い合わせの間隔を定義するのが「リフレッシュ値（更新時間）。
セカンダリDNSサーバは、前回の確認からここで設定された時間が経過すると、「DNS NOTIFY」による通知を受けていなくても、ゾーンデータの更新がないかを確認する。
ここの例では、リフレッシュ値は1D（1日、86400秒）と設定されているので、1日ごとにスレーブDNSサーバは、プライマリDNSサーバへ問い合わせを行う。
⑥：「リトライ値」を表す。スレーブDNSサーバは定期的にゾーンファイルが更新されているかどうかを確認する。しかし、実際にはスレーブDNSサーバとプライマリDNSサーバ間の回線障害等で問い合わせに失敗することも出てくる。この様な場合に、再度確認の試行を行うまでの時間を指定するのが、「リトライ値」。
ここの例では、リトライ値は30M（30分、1800秒）と設定されているので、問い合わせに失敗した場合は、30分ごとに再度問い合わせを行う。
⑦：「有効期限(expire)」を表す。スレーブDNSサーバからプライマリDNSサーバへのゾーン転送の問い合わせに失敗をしたら、問い合わせに成功するまで、「リトライ値」の間隔で問い合わせを繰り返すが、問い合わせが成功しなまま、失敗が続いた場合、この「有効期限（expire）」を迎えると、スレーブDNSサーバは、このゾーンを破棄する。
ここの例では、「有効期限（expire）は、「1W（1週間）」と設定されているので、問い合わせに成功しないまま1週間を経過すると、スレーブDNSサーバはこのゾーンを破棄する。
⑧：「ネガティブキャッシュのTTL値」を表す。「ネガティブキャッシュ」とは、問い合わせたレコードが存在しなかった場合、「問い合わせたレコードは存在しない」という情報を情報をキャッシュする機能の事。
例えば、「ccna1.example.jp.」というホストの情報がゾーンファイルで、全く定義されていないときに、「ccna1.example.jp.」の問い合わせをリゾルバのDNSサーバーが行った場合には、ゾーンを管理するDNSサーバは、その様なホストは存在しないと返答し、リゾルバのDSNサーバは、この「ccna1.example.jp.」は存在しないという情報をキャッシュする。
キャッシュサーバは他の情報と同じように、この「存在しない」という情報を、指定された時間保持している。
このHPはDNSの機能（SOAレコード）についてまとめたものです。
1-1 SOAレコード
SOAレコードは、ゾーンファイルの中で用いられるレコード。SOAレコードでは、
そのゾーンファイルが管理するゾーンの情報を持っている。
また、そのドメインを管理しているプライマリDNSサーバの指定や、ゾーン管理者の
メールアドレス、スレーブDNSサーバに対するゾーン転送の設定などを行う。
下図で、SOAレコードの例を示す。
①：ゾーン名。ここで指定したゾーンの権限を持つことを宣言する。
②：このゾーンのプライマリDNSサーバーを指定する。この例では、このゾーンに対するプライマリDNSサーバ名が「ns1.example.co.jp.」であることを示している。
③：ゾーン管理者のメールアドレスを指定する。ただし、ゾーンファイルの中では、「@(アットマーク）」は特殊な
用途で用いられるので、メールアドレスの「@(アットマーク）」を「.(ドット）」に置き換えて指定する。
「ccnamaster@example.co.jp.」の場合は「ccnamaster.example.co.jp.」と指定する。
④：ゾーンファイルの「シリアル値」を表す。シリアル値はプライマリDNSサーバから、スレーブDNSへのゾーン転送が行われるかどうかを決定する設定情報。このシリアル値が大きいほど、新しいゾーンファイルであるとみなされる。
⑤：「リフレッシュ値（更新時間）」を表す。スレーブDNSサーバーは、マスターDNSサーバに対して、定期的にゾーンファイルが更新されているか確認する。
このスレーブDNSサーバからプライマリDNSサーバへ、問い合わせの間隔を定義するのが「リフレッシュ値（更新時間）。
セカンダリDNSサーバは、前回の確認からここで設定された時間が経過すると、「DNS NOTIFY」による通知を受けていなくても、ゾーンデータの更新がないかを確認する。
ここの例では、リフレッシュ値は1D（1日、86400秒）と設定されているので、1日ごとにスレーブDNSサーバは、プライマリDNSサーバへ問い合わせを行う。
⑥：「リトライ値」を表す。スレーブDNSサーバは定期的にゾーンファイルが更新されているかどうかを確認する。しかし、実際にはスレーブDNSサーバとプライマリDNSサーバ間の回線障害等で問い合わせに失敗することも出てくる。この様な場合に、再度確認の試行を行うまでの時間を指定するのが、「リトライ値」。
ここの例では、リトライ値は30M（30分、1800秒）と設定されているので、問い合わせに失敗した場合は、30分ごとに再度問い合わせを行う。
⑦：「有効期限(expire)」を表す。スレーブDNSサーバからプライマリDNSサーバへのゾーン転送の問い合わせに失敗をしたら、問い合わせに成功するまで、「リトライ値」の間隔で問い合わせを繰り返すが、問い合わせが成功しなまま、失敗が続いた場合、この「有効期限（expire）」を迎えると、スレーブDNSサーバは、このゾーンを破棄する。
ここの例では、「有効期限（expire）は、「1W（1週間）」と設定されているので、問い合わせに成功しないまま1週間を経過すると、スレーブDNSサーバはこのゾーンを破棄する。
⑧：「ネガティブキャッシュのTTL値」を表す。「ネガティブキャッシュ」とは、問い合わせたレコードが存在しなかった場合、「問い合わせたレコードは存在しない」という情報を情報をキャッシュする機能の事。
例えば、「ccna1.example.jp.」というホストの情報がゾーンファイルで、全く定義されていないときに、「ccna1.example.jp.」の問い合わせをリゾルバのDNSサーバーが行った場合には、ゾーンを管理するDNSサーバは、その様なホストは存在しないと返答し、リゾルバのDSNサーバは、この「ccna1.example.jp.」は存在しないという情報をキャッシュする。
キャッシュサーバは他の情報と同じように、この「存在しない」という情報を、指定された時間保持している。
