DigiLoog

PC関係の事なら何でもいけるそんな処

[ns-lab BB] 新環境のキャッシュDNS構成

2020年06月05日(金) - 20:36 | カテゴリ: Linux

旧環境ではBINDを用いてキャッシュDNSサーバを運用していた。
デファクトスタンダードとなっているBINDに慣れておかないと職にも影響が出る上、
仕様変更・脆弱性情報も追いかけるには、実際に運用するのが手っ取り早いという理由もある。

昨今ではBIND以外にもキャッシュDNSが増えた上、BIND以外を採用する環境も増えてきた。
技術提供側としてはニーズに対してスキルを出せないのは不勉強と言わざるを得ないので、
今回のサーバ刷新を機に一部サーバはBIND以外を採用してみた。
また、今後はDNSSEC採用環境が増えて行くと思われる為、
再帰問い合わせが可能なキャッシュDNSでDNSSEC検証も有効化してみた。

  • 全体構成

“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で実現出来そうなので必要性が出た時に試そうと思う。





  • 応援中

    『放課後シンデレラ』を応援しています!
    Cabbit 第四弾!「鍵を隠したカゴのトリ-BIRD IN CAGE HIDING THE KEY-」応援中!