DNSサーバを作る場合にはマスター、スレーブを作ることは必須になっています。
マスターのゾーン転送でエラーが出たので備忘録としてTipsをご紹介。
目次
スレーブからマスターへゾーン転送要求を行う
|
1 2 3 4 5 6 |
[root@SG-DNS-Slave slaves]# dig @xxx.xxx.xxx.xxx example.net axfr ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> @xxx.xxx.xxx.xxx example.net axfr ; (1 server found) ;; global options: +cmd ; Transfer failed. |
|
1 |
; Transfer failed. |
マスターのログを確認します。
|
1 2 3 4 5 6 7 8 9 |
[root@SG-DNS-Master ~]# tail -f /var/log/messages Aug 1 08:43:36 SG-DNS-Master named[41106]: client 10.15.0.61#60973: received notify for zone 'ccc.bbb.aaa.in-addr.arpa' Aug 1 08:43:40 SG-DNS-Master named[41106]: client 10.15.0.61#39609: zone transfer 'example.net/AXFR/IN' denied Aug 1 08:45:09 SG-DNS-Master named[41106]: client 10.15.0.61#51290: zone transfer 'example.net/AXFR/IN' denied Aug 1 08:45:17 SG-DNS-Master named[41106]: client 10.15.0.61#45920: received notify for zone 'ccc.bbb.aaa.in-addr.arpa' Aug 1 08:45:18 SG-DNS-Master named[41106]: client 10.15.0.61#40606: zone transfer 'example.net/AXFR/IN' denied Aug 1 08:45:33 SG-DNS-Master named[41106]: client 10.15.0.61#34692: zone transfer 'example.net/AXFR/IN' denied Aug 1 08:45:42 SG-DNS-Master named[41106]: client 10.15.0.61#33853: zone transfer 'example.net/AXFR/IN' denied |
|
1 |
zone transfer 'example.net/AXFR/IN' denied |
ゾーン転送要求が拒否されています。
|
1 |
client 10.15.0.61# |
マスタはスレーブを10.15.0.61と認識してログに出していますね。
マスター設定ファイル編集
マスターが認識しているスレーブのIPをallow-transferディレクティブに追加します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
# vi /etc/named.conf // 管理するゾーンの設定 zone "example.net" { type master; file "master/catchallmail.net.zone"; //転送先スレーブの指定 allow-transfer { 10.15.0.61; ←追加 10.15.0.7; スレーブグローバルIP; }; notify yes; also-notify { 10.15.0.61; ←追加 10.15.0.7; スレーブグローバルIP; }; }; zone "ccc.bbb.aaa.in-addr.arpa" { type master; file "master/ccc.bbb.aaa.in-addr.arpa.zone"; //転送先スレーブの指定 allow-transfer { 10.15.0.61; ←追加 10.15.0.7; スレーブグローバルIP; }; notify yes; also-notify { 10.15.0.61; ←追加 10.15.0.7; スレーブグローバルIP; }; }; |
構文エラー確認
|
1 |
# named-checkconf /etc/named.conf |
再起動で反映させます。
|
1 |
# service named restart |
digでスレーブからマスターへゾーン転送要求を行います。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
[root@SG-DNS-Slave slaves]# dig @xxx.xxx.xxx.xxx example.net axfr ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> @xxx.xxx.xxx.xxx example.net. axfr ; (1 server found) ;; global options: +cmd example.net. 200 IN SOA ns1.example.net. root.example.net. 2014100812 200 200 200 200 example.net. 200 IN TXT "v=spf1 ip4:xxx.xxx.xxx.xxx ~all" example.net. 200 IN NS ns1.catchallmail.net. example.net. 200 IN NS ns2.catchallmail.net. example.net. 200 IN MX 10 mail1.catchallmail.net. example.net. 200 IN A xxx.xxx.xxx.xxx mail1.example.net. 200 IN A xxx.xxx.xxx.xxx ns1.example.net. 200 IN A xxx.xxx.xxx.xxx ns2.example.net. 200 IN A yyy.yyy.yyy.yyy www.example.net. 200 IN A xxx.xxx.xxx.xxx example.net. 200 IN SOA ns1.example.net. root.example.net. 2014100812 200 200 200 200 ;; Query time: 0 msec ;; SERVER: 210.140.84.68#53(210.140.84.68) ;; WHEN: Tue Aug 1 09:03:05 2017 ;; XFR size: 11 records (messages 1, bytes 295) |
ゾーンが転送されました。
スレーブからゾーン転送ファイルを確認する。
|
1 2 3 4 5 6 |
[root@SG-DNS-Slave slaves]# ls -laht /var/named/slaves 合計 16K -rw-r--r-- 1 named named 452 8月 1 09:22 2017 ccc.bbb.aaa.in-addr.arpa.zone -rw-r--r-- 1 named named 596 8月 1 09:20 2017 example.net.zone drwxrwxr-x 6 named named 4.0K 8月 1 08:59 2017 .. drwxr-x--- 2 named named 4.0K 8月 1 08:59 2017 . |
転送されています。
他のサーバからゾーン転送要求を行います。
|
1 2 3 4 5 6 |
[hoge@another-server ~]$ dig @xxx.xxx.xxx.xxx example.net axfr ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> @xxx.xxx.xxx.xxx example.net axfr ; (1 server found) ;; global options: +cmd ; Transfer failed. |
拒否されました。ちゃんと設定が行われていることが確認できています。
あなたのDNSサーバ ちゃんと管理出来ていますか？
BINDは緊急対応レベルの脆弱性が多く、アップデートをその都度行わないといけません。まともに管理するのは凄く大変。それにDNSサーバはマスター・スレーブで２台も必要になってきますし、維持コストもかかります。
TSIG, ゾーン転送の脆弱性回避術
脆弱性がよくあるBINDのゾーン転送機能を使わないように設定し、ゾーンファイルをrsyncとCronでスレーブに転送し、定期的に同期させるという方法で回避できます。
DNSサーバアウトソースのすすめ
- 特にDNSを自前で管理する理由がない
→ドメイン管理レジストラのDNSサービスを利用する。 - メールフィルタで逆引きは必要だ
→逆引きが可能なクラウドサービスを使う。
そのようにすると管理が楽だし、コストも自前でDNSサーバを維持するよりずっと安く効率的。それにドメイン業者やクラウド側にはDNSの専門家がいるので安心ですよ。基本的にお客様の要望がなければ、DNSは外部に持つようにして、お客様の運用コストを減らしています。
上記はインターネット公開用のDNSサーバの話で、社内LAN用のDNSならば必要になります。
お疲れ様です。
