なかなか難しいDNS。特にメールとDNSが被ったとき、難易度は指数関数的に増加する。
そしてこれだけハマるというのは仕事が炎上自分が成長したということ。まことにありがたいこと。DNSでハマったポイントを備忘、アンチパターンとしてここに刻む（お焚き上げの意味もこめて）。
MXレコードにCNAMEレコードを記載してはならない
RFCをちゃんと読んでいればこんなこと起きないだろう、というツッコミはさておき（でも現実に起きたからさ・・・！）。
このように、realserver.contoso.jpはAレコードとして、「10.1.1.1」のIPを登録している。そして、server.contoso.jpはCNAMEレコードとして、realserver.contoso.jpのAレコードを別名指定している。ここまではよくあるDNSレコードのCNAME構成だ。
問題は次。
このCNAMEレコードserver.contoso.jpを、MXレコードmail.contoso.jpに指定してはならない。
10.3. MXレコード・NSレコード
NSリソースレコードやMXリソースレコードの値として使用されるドメイン名は、
別名であってはならない。仕様でこの点が明記されているだけではなく、これらの
レコードのどちらかで別名を使用すると、期待通りに動作しない可能性や、
このアプローチをとることにした意図を満たさない可能性がある。これらの
ドメイン名は、一つ以上のアドレスレコードを保持しなければならない。現在、
アドレスを保持するレコードはAレコードだが、将来アドレス情報を保持する
別のレコードタイプも容認されるかもしれない。 また、別のRRも保持できる
ようになるかもしれないが、それがCNAME RRであってはならない。
こういうポカミスには気をつけたいところ。
先人たちも同じ経験をしている。歴史は繰り返す、映画テネットのように予定された未来を知りつつ、その道を僕らはまた歩く。テネットの場合、未来を知っていてあえてその道を歩いていたが、僕の場合・・・。
CNAMEでバーチャルメールサーバ
小ネタRoute 53 のホストゾーンに CNAME レコードと重複するドメイン名で MX レコードを登録しようとしたらきちんと怒られた
RFCに記載の当該箇所。
現在、アドレスを保持するレコードはAレコードだが、将来アドレス情報を保持する別のレコードタイプも容認されるかもしれない
将来がいつなのかは定かではないが、RFC未定義と言われるAliasレコードをCNAMEの代わりに使うことで、別名指定することはできた（RFC未定義で、違反もなにもないため）。MXにCNAMEではなく、Aliasレコードを使うことは実際DNSの世界で問題がないのかなど、RFCの顛末をウォッチする必要がある。
なりすまし防止のSPFレコード（TXTレコード）
SPFとは何ぞやについては、カゴヤさんのサイトが詳細に記載してくれている。
カゴヤさんのサイトから一部引用。
SPFの動き方
特徴として、以下。
※自ドメイン：自身がメールを送信する側とした場合
・相手ドメインのメールサーバにメールが受信されたときに、相手ドメインのメールサーバは、自ドメインのDNSサーバにSPFレコードを問合せ
・自ドメインのDNSは、相手ドメインのメールサーバにSPFレコードを返す
・相手ドメインのメールサーバは、SPF問い合わせ結果のIP、受信メールの送信元IPを照合し、同一であるかを判定する
⇒異なればなりすまし、同一であれば正常な送信者と判断する仕組み。
判定したときの挙動
SPF（Sender Policy Framework）: 迷惑メール対策委員会
こちらも迷惑メール対策委員会様に詳しく記載されているが、肝はここ。
たとえばSPFレコードに記載した内容が、どういう意味をもつのか？という部分。
example.jp. IN TXT "v=spf1 ip4:172.16.0.1 ip4:172.16.0.2 ip4:172.16.0.3 -all"
このようなSPF(TXT)レコードがあったとして、v=spf1でSPFバージョン1を使うことを宣言し、ip4に書かれたIPアドレス(172.X)であればSPF認証を合格させると記載してある。
-allについては、allがそれ以外すべてのIPやDNSレコードだった場合を意味しており、ハイフンの挙動はFail（すべて拒否する）という意味合いである。
このSPFレコードの場合、ハイフンallなので、ip4のIPアドレスが照合されなければ、受信者にはメールを受信させない、という超厳格なものとなっている。
これをチルダ（~）に変えると、softfailとして扱う。
example.jp. IN TXT "v=spf1 ip4:172.16.0.1 ip4:172.16.0.2 ip4:172.16.0.3 ~all"
つまりこのチルダの場合、IPの照合が違っても受信者のメールボックスにはメールが届く。信頼はできないけどね、という意味となる。たまに受信メールにある「このアドレスは信頼されない」みたいな警告表示が出るが、あれがsoftfail、つまり受信自体は許すということだと思っている。
SPFの書き方
example.jp. IN TXT "v=spf1 ip4:172.16.0.1 ip4:172.16.0.2 ip4:172.16.0.3 ~all"
上記のとおりだが、SPFレコードというものはなく、TXTレコードの中にSPFを書く。
ここがポイント。なんでこんな仕様になっているのか、本当に謎である。
そしてここもポイントだが、必ず1行にして書くということ。
例えば、先ほどのSPFレコードに許可したいMXのIPを追加する場合、このレコード1行に継ぎ足しする必要がある。
example.jp. IN TXT "v=spf1 ip4:172.16.0.1 ip4:172.16.0.2 ip4:172.16.0.3 ip4:172.16.0.4 ~all"
くれぐれも、以下のように行を分けて書いてはいけない。1ドメイン（以下例だとexample.jp）に対して必ず1行で書くこと。
example.jp. IN TXT "v=spf1 ip4:172.16.0.1 ip4:172.16.0.2 ip4:172.16.0.3 ~all"
example.jp. IN TXT "v=spf1 ip4:172.16.0.4 ~all"
なんでこんな仕様になっているのか、本当に(ry
他にもいくつかハマったことがあったので、気が向いたら書く。
余談
R&B歌手ザウィークエンドさんの新アルバム「Dawn FM」を聞いた。これが素晴らしかった。
一般的なR&B歌手はいかにモテているかを歌うことが多い。だが、ザウィークエンドさんの場合、オラオラしたイカつい雰囲気が加味される。歌詞はイカついのにスイートな歌声という、R&B歌手の新境地を開拓。
前アルバムよりダークなところは減ったが、今回もなかなか渋い感じ。そして映画マスクのジムキャリーがなぜかナレーションを務めています。
The Weeknd - Is There Someone Else? (Official Music Video)
⇒「他に誰かいんの？（他の男が・・・）」という題名で、MVも少し狂気な感じ。
The Weeknd - Out of Time (Official Video)
⇒日本の歌手、亜蘭知子の曲をリメイクしています。MVにイカゲームの女優とジムキャリーも出演。前アルバムのMVには水原希子が出ていたり、極東アジアが好きなご様子。