Help us understand the problem. What is going on with this article?

DNSサーバーの設定についてわかったこと

More than 1 year has passed since last update.

最近、会社のドメインで障害を起こし(-_-;)、その解決によってわかったことを書き留めます。
ドメインやDNSの設定って、クライアント側は情報が豊富なものの、サーバー側は意外に情報が少なく、体系的に理解するのが難しかったです。

やりたかったこと

とあるWebサービスの使用に際して、ドメイン所有権の確認が必要で、DNSサーバーにレコードを追加する必要がありました。しかし、追加しても所有権の確認ができず、試行錯誤しつつ、障害を引き起こしました。

構成

会社のサーバーは、ドメインと別々の会社で運用しています。
これが別の場合、少し話がややこしくなることを、先のWebサービスのコールセンターの人から聞きました。
A社のレンタルサーバーと、B社で管理するドメインを組み合わせて使います。

B社のドメイン管理サイトにDNSの設定があり、レコードが並んでいます。
- ルートドメインのWebアクセスは、B社のDNSで解決する(NSレコード)
- wwwサブドメインのWebアクセスは、A社のDNSに移譲(NSレコード)
- www以外のサブドメインのWebアクセスは、A社のサーバーに向ける(CNAMEレコード)
- ルートドメインのメールサーバーは、B社指定のサーバーに向ける(MXレコード)
- ドメイン所有権の確認用レコード(TXTレコード)

A社のサーバー管理サイトから、ドメインとゾーンの一覧を見ることができます。しかし、DNSサーバーの設定は必要最低限で、追加することはできません(A社管理のドメイン以外では、DNSの設定不可)。
- ルートドメインのWebアクセスは、A社でレンタル中のサーバーに向ける(Aレコード)
- ルートドメインのメールサーバーは、A社でレンタル中のサーバーに向ける(MXレコード)
- ルートドメインのFTPサーバーは、A社でレンタル中のサーバーに向ける(Aレコード)

今回も、B社の管理サイトからDNSレコードを追加しましたが、いくら待ってもドメイン所有権が確認できません。

そこで、DNSサーバーの設定を見直すことにしました。

ポイント

上記で、A社とB社のDNSサーバー設定で、競合するレコードがありました。
- ルートドメインのWebアクセス(A社:特に設定なし B社:B社のレンタルサーバーに向ける)
- ルートドメインのメールサーバー(A社:A社のサーバーに向ける B社:B社のレンタルサーバーに向ける)

この状態で、どちらが優先的に処理されるのか?という事について、これまで知りませんでした。
その鍵は、SOAレコードにあるようです。

SOAレコードは、Start Of Authorityレコードの略で、『このドメインに対して、最も権威のあるDNSサーバーは私です』という意味のレコードのようです。
SOAレコード保持サーバーのDNSレコードは『権威のある名前解決』、それ以外のサーバーが主張するDNSレコードは、『権威のない名前解決』と分けられます。

今回は、A社のドメイン管理画面で、『DNSサーバーを、A社のサーバーで設定する』という操作を行いました。

これにより、SOAを持つサーバーは、A社のDNSサーバーとなったわけです。

不具合発生

変更してみたところ、会社のWebサイトに接続できなくなり、メールも送受信できなくなりました。

これまでB社のDNSサーバーが権威者だったのだと思います。
それをA社のサーバーにSOAを付与したので、B社のDNSサーバーにしかなかったレコードが上書きされ、名前解決できなくなったようです。

解決のポイント

解決法はシンプルでした。
1. ひとまず、DNSの権威者をB社に戻す
2. B社のDNSサーバーにのみ設定されていたレコードを、A社のDNSサーバーにコピーする
3. A社のDNSサーバーをテストする
4. 本番のDNSサーバーを、B社→A社に再変更

1. ひとまず、DNSの権威者をB社に戻す

A社のドメイン管理画面上で、B社のDNSサーバーを権威者に変更する操作を行いました。

2. B社のDNSサーバーにのみ設定されていたレコードを、A社のDNSサーバーにコピーする

画面をふたつ開いて、コピーしました。
レコードが重複した場合には、意味を考えて削除→上書きで対応しました。

3. A社のDNSサーバーをテストする

今回大活躍のnslookupコマンドを使いました。
引数にDNSサーバーを設定すると、サーバー単体で名前解決のテストができるので、本番切り替えの前にステージングのようなことができます。
ただし、NSレコードで移譲する部分は再現されず、エラーが表示されます。

4. 本番のDNSサーバーを、B社→A社に再変更

テストしてみて問題なさそうだったので、DNSの権威者をA社に再変更しました。

しかし、再びメールの送受信に不具合が出ました。
MXレコードの設定がよく分かっておらず、メールサーバーの名前解決ができなくなっていました。
MXレコードを再びコピーしたところ、ほどなくメール送受信が再開しました。

まとめ

不具合を出してしまい、残念でしたが、おかげでDNSの基本や設定方法を学ぶことができました。

今回最大の気付きは、『SOAレコードで、権威者としてのDNSサーバーを指定するのが非常に大事』だということでした。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away