YAMAHA RTXシリーズとRoute53の仕様不一致による動作不具合
にゃん、ぱす…..zzz
いやー、今回コレで3時間はハマりました。
ウェブ上に情報が無いようなので、YAMAHAさんには申し訳ないですがアップします。
RTXシリーズはTTL:0のレコードを無効なレコードとしてリジェクトする。
さて、一部のルータ（具体的にはYAMAHA RTXシリーズ、NEC IXシリーズ）は、IPSecの宛先にFQDNを指定する事が可能です。
今回、Route53でTTL:0のDNSラウンドロビンを構成してRTXのipsec ike remote addressに設定した場合、SAが確立せず、ログも表示されませんでした。
再現環境：RTX810 Rev.11.01.19 (Mon Jul 29 15:27:26 2013)
症状：TTL:0のAレコードを構成した際、ISAKMPが開始されず、debug logにも表示されない。
従来BINDやdjbdns等では、TTLは短くても120秒程度の設定でとどめていました。
これは慣習的にDNSサーバへの負荷を下げるためでもあったのですが、Route53ではHealthCheckによるFailOverなどが構成可能な為、意図的に短いTTLのレコードが構成可能です。
YAMAHAサポートからの回答
（中略）
早速ではございますが、お問い合わせ内容につきましては誠に申し訳ございませんが、弊社ルーター製品ではDNSTTLが0の場合は無効なレコードとして実装しております。何卒ご理解を賜りますようお願い申し上げます。その他ご不明な点などございましたら、お手数ですがご連絡いただければ幸いです。
今後ともヤマハ製品をよろしくお願い申し上げます。
rtproにも探した限りなかったのと、回答に日数がかかったことから、おそらくマイナーな仕様だったようです。
DNSの仕様として
んじゃ、RFCではどっちが正解かというと、RFC2181に記載があります。
Clarifications to the DNS Specification(ＤＮＳ仕様書の解釈)
標準１３のTTLフィールドの定義は、値が何ビットか、符号付か符合なしかど
んな値が設定できるかはっきりしていません。ＴＴＬ値は最小０で最大
２１４７４８３６４７で、符号なしの数とここで明記します。すなわち、
２^３１－１が最大値です。転送する際に３２ビットのＴＴＬ値に対して、
有効桁数３１ビットで符号化され、最上位ビットはゼロになります。
ＤＮＳの実装は最上位ビットが１のＴＴＬ値を０と扱うべきです。
ＤＮＳ実装は受信したＴＴＬ値に自由に上限を決めることが出来、大きな値
は全て最大値と同じと扱うことが出来ます。ＴＴＬはキャッシュに残してお
く義務を示すのではなく、残せる限界を指定します。
つまるところ、00000000 00000000 00000000 00000000ではなく、10000000 00000000 00000000 00000000をTTL:0として扱ってくれ、と書いてある。
ただ、お互いTTL:0を認識している事から、パケットレベルではあっていて、YAMAHA側がRFCに準拠した実装をしていないように感じます。
ここから先はtcpdumpとWireSharkの世界なので、今日はおあづけ。。。（腹減った。）
結論として
TTLを変更したところ、すぐにisakmpが上がったので、リトライはしていたようです。
試しにTTL:1のレコードを作った場合、50%の確立で名前解決に失敗する事になるので、挙動は不安定ですがisakmpは動きました。
最終的に、TTLは10secにしました。これは、Aレコードの制御とOpenSwanの制御により、上手く縮退・再接続の挙動を確認する為に調度良い値だった為です。
また、nslookupコマンドではTTLに関わらず正常に名前解決できていた事から、nslookupとipsecでは別の名前解決の実装がなされていると想像します。
えんいー。