公開日:2015/03/13
DNSの仕組みとDNSレコードの設定の続き。
先週、ドメインキングのDNSサーバに障害が発生してしばらくの間ホームページにアクセスできない＆メールの送受信ができなかった。
今は復旧してるけど、これを機にDNSサーバをドメインキングからお名前.comに移行した。
webサーバ、メールサーバはドメインキングのレンタルサーバで稼働させたまま。
今回も勉強しながらDNSレコードを編集したのでメモする。
編集前
お名前.comドメインNavi内DNSレコード設定。
編集前というかドメインキングのDNSゾーンをお名前.comで復元した状態。
test.smartllc.jpのNSレコードはRaspberry PiをMyDNS.jpでDDNS管理するために追加した。
この状態でも問題なく動作することを確認。
CNAMEレコード
CNAMEレコードはドメイン名にエイリアス(別名)を設定するレコード。
例えば、この場合はwww.smartllc.jpはsmartllc.jpの別名(www.smartllc.jpの実体はsmartllc.jp)としている。
このCNAMEレコードを取得したリゾルバはwww.smartllc.jpの実体であるsmartllc.jpのAレコードからIPアドレスを取得する。
つまりCNAMEレコードはひとつのIPアドレスに複数のドメイン名でアクセスすることがある場合にAレコードを1つにまとめることができる。
webサーバとメールサーバとかFTPサーバを兼用するサーバにそれぞれwww、mail、ftpみたいな違うホスト名でアクセスするような場合。
Aレコードを1つにまとめると何が嬉しいのか。
兼用サーバのIPアドレスに変更がある場合に、Aレコード1つ修正するだけでいい。
CNAMEレコードがないとホスト名分あるAレコードを全て修正することになる。
逆にCNAMEレコードがある場合は、そのエイリアスのAレコードは存在できない。
以上によりCNAMEレコードを使うことで同じIPアドレスのAレコードがなくなってスマートにできる。
が、管理者の手間が省けるだけでリゾルバにとってはマイナス要因だったりする。
CNAMEレコードがない場合は直接Aレコードを取得するだけでよかったのが、
CNAMEレコードがあることによってCNAMEレコード→Aレコードと2段階の問い合わせが発生することになる。
DNSゾーンの規模にもよるだろうけど手間じゃなければCNAMEレコードは使わない方がリゾルバの負担が減る。
こっちの方がスマートだ。
というわけで今回はCNAMEレコードは削除してAレコードに置き換える。
MXレコード
MXレコードはメールの配送先を設定するレコード。
メールサーバのドメイン名と優先度を設定する。
メールサーバが複数用意できる場合は複数レコード設定すれば優先度の高い順にアクセスさせることができる。
数字が小さい方が優先度が高いことになる。
今回はメールサーバに変更はないのでこのままでOK。
SPFレコード
SPFレコードはメールの送信元を証明するレコード。
SPFレコードと言いながら、現状はTXTレコードを使って記述することになる。
SMTPでメールを送信する場合、メールの送信元アドレスは自由に設定できる。
受信側がSPFに対応している場合、送信元アドレスが本物かどうか判断するために取得するのがSPFレコード。
｢v=spf1｣はspf1てバージョンで記述してますて意味。
｢+a +mx -all｣は送信元アドレスがAレコードまたはMXレコードに存在する場合は本物です、それ以外は偽物ですて意味。
｢+｣は省略できるので省略してレコードサイズを小さくした方がいいらしい。
｢v=spf1 a:smartllc.jp -all｣なら送信元アドレスがsmartllc.jpのAレコードに存在する場合のみ本物。
｢v=spf1 ip4:153.122.42.167 -all｣なら送信元アドレスが153.122.42.167の場合のみ本物。
｢v=spf1 -all｣なら送信することはないことを意味する。
ただSPFレコードの記述方法もaやmxでドメイン名を書いちゃうとCNAMEレコードと同じように2段階の問い合わせが発生する。
というわけで今回は｢v=spf1 ip4:153.122.42.167 -all｣とIPアドレスで設定する。
TTL
各DNSレコードにあるTTL。
レコードの有効期限。
単位は秒。
TTLの時間だけDNSサーバはそのレコードをキャッシュする。
DNSレコードの切り替え作業がある時は事前にTTLを短く設定しておくことで切り替えにかかる時間を短縮できる。
テスト時や切り替え時は短めに、運用が安定したら長めに設定すればいいと思う。
編集後
こうなった。
ホームページにアクセスできることを確認。
メールの送受信ができることを確認。
FTP接続できることを確認。
SPFはGmailに送信して確認できた。
送信元アドレスを偽装(smartllc.jpアドレスを名乗ってASAHIネットのサーバから送信)したメールヘッダのReceived-SPFが｢fail｣になることを確認。
smartllc.jpから送信した正規のメールヘッダのReceived-SPFが｢pass｣になることを確認。
問題なさそう。
昨日TTLとか気にしないでいきなりDNSサーバを切り替えちゃってメールが受信できない時間があったのが気になるけど仕方ない_(:3 」∠)_
受信側のSPF判定てどうやるんだ( ﾟдﾟ)