“ns-lab BB” のネットワークではプロトコル接続テスト用にIPv4/IPv6で完全分離しており、
IPv6からIPv4に接続する技術も確認する為、FortiGate50EでNAT64も動いている。
NAT64の為には、DNS64も動かす必要があるので、IPv6環境専用キャッシュDNSも稼働している。
そんな中、メインとなる仮想サーバ群は北海道の「さくらの専用サーバ」で稼働しており、
“ns-lab BB” のバックボーン用ドメインとレコードの管理もそちらで行っている。
流石にバックボーン情報を平文でインターネットに通す訳にもいかないので、
拠点間VPNでNW接続を行い、各拠点のキャッシュDNSから上位フォワードをする構成にしている。
BIND以外の環境では、BINDっぽい挙動を再現する為にdnsdistを前段に配置している
IPv6環境ではユニキャストアドレスをそのまま使えば良いので、
敢えて宅内ドメインを持たずにインターネットに直で名前解決を行っている。
前述の通りNAT64+DNS64用のBINDが稼働しているので、下記の様な設定をBINDに施し、
AAAAレコードが割り当てられていない場合でも、AAAAレコードを生成応答する様にしている。
acl "client" {
2001:db8:face:1000::/64;
2001:db8:face:2000::/64;
localhost;
};
acl "private" {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
view "internal" {
dns64-server "dns64.example.org.";
dns64-contact "postmaster.example.org.";
match-clients { client; };
match-destinations { client; };
dns64 64:ff9b::/96 {
clients { client; };
mapped { !private; any; };
exclude { 64:ff9b::/96; ::ffff:0000:0000/96; };
suffix ::;
recursive-only yes;
break-dnssec yes;
};
};
|
設定を詰めれば単純化する事も出来るが、再帰接続の許可セグメントを限定している為、
ACLを弄って厳密に制御している。
………
DNSサーバなので前段にロードバランサーを介さなくても冗長化が可能な上、
キャッシュDNSは構成が枯れてきている為、特有の複雑設定は実施していない。
なお、dnsdistを前段に置く事でロードバランス・クエリ分散など高度な事が可能となり、
実際に “ns-lab BB” のインターネット向けの権威DNSで採用している。
今回のDNS刷新で難易度の高かった箇所は、
DNSSEC検証を有効化しているキャッシュDNSでトラストアンカーを読み込む箇所。
手動更新・自動更新など色々試してみたが、設定を細かく作り込むと安定しなかったので、
BINDによる自動制御を最終的に採用する事にした。
刷新後の環境は稼働開始してから半年以上経過しているが、
DNSSEC検証含めキャッシュDNSとして問題無く稼働している。
エンタープライズ環境だと、権威DNSはRoute53などを使って外出しする事が出来るが、
キャッシュDNSは自前で持っていないとどうしようも無い事が多い。
そうなると、BINDなりのOSSを使うか、ADドメコンをキャッシュDNSに指定するか、
アプライアンスを入れる事が大半だと思う。
DoT/DoH等の次世代技術も存在するが新環境での導入は見送った。
というのも、同じサーバで監視用Webサーバも動いておりポート番号も被ってしまうのと、
下手にポート変更する位なら実装しないのも手と判断した。
DoT/DoHについては、dnsdistで実現出来そうなので必要性が出た時に試そうと思う。
« 続きを隠す
