職場で古いBindシステムを手に入れましたが、マスターのゾーンがスレーブに同期しません。私はバインドの初心者で、本当に助けを使うことができました。マスターで行ったすべての変更をスレーブに同期させたい。
サーバーは相互に到達できます(ping、ssh、中間で完全にオープン)。サーバーは少し古いですが、壊れるのではないかと恐れて更新を許可されていません。
Ubuntu 12.04.5 LTS BIND 9.8.1-P1
MASTER = ns1..com。 SLAVE = ns2..com。
バインドサーバーを使用できます。バインドサーバーは正常に機能し、変更は複製されません。
ほとんどの変更はGUIを通じて行われたと言われていますが、私はこれにアクセスできません。
問題はMASTERサーバーでのIPの変更中に開始された可能性があります。それは少なくとも問題が発見されたときでしたが、誰も確実に知りませんでした。
サービスを再起動し、キャッシュをフラッシュし、サーバーを再起動しました。私は設定をチェックしましたが、私が見ることができるものからそれは正しいはずです。 rndc --retransferを試しましたが、出力がなく、機能しません。
rndcステータス
次の出力を提供します:
version: 9.8.1-P1
CPUs found: 1
worker threads: 1
number of zones: 296
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
MASTERとSLAVE(設定は同じですが、シークレットのみが異なります)
/etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
key rndc-key {
algorithm hmac-md5;
secret "UHSoHPGEh+p5kIdoGzoX0A==";
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
};
主人
/etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain yes;
listen-on-v6 { any; };
recursion no;
multiple-cnames yes;
fetch-glue yes;
check-names master fail;
check-names slave fail;
allow-transfer { localhost; <IP-OF-SLAVE>; };
notify yes;
dump-file "/";
also-notify {
};
};
SLAVE
/etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain yes;
listen-on-v6 { any; };
recursion no;
multiple-cnames yes;
fetch-glue yes;
allow-transfer { <MASTER IP>; };
//allow-transfer { ns1.<our-domain>.com; };
//also-notify {};
};
主人
/etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "domain.nu" {
type master;
file "/var/lib/bind/<DOMAIN>.nu.hosts";
allow-transfer {
<IP-OF-SLAVE>;
};
};
ここには何百ものゾーンがあり、すべて同じように構成されています。
SLAVE
/etc/bind/named.conf.local
zone "domain.nu" {
type slave;
masters {
<IP-MASTER>;
};
file "/var/lib/bind/domain.nu.hosts";
allow-transfer {
<IP-MASTER>;
};
};
主人
/etc/bind/named.conf.default-zones
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
SLAVE
/etc/bind/named.conf.default-zones
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
この構成とは別に、さまざまなゾーンの構成を/var/lib/bind/.hostsに見つけることができます。これらは、マスター上にあるかスレーブ上にあるかによって、少し異なります
主人
/var/lib/bind/.hosts
$ttl 38400
domain.com. IN SOA ns1.<our domain>.com. admin.<our domain>.com.. (
1373899259
7200
3600
604800
38400 )
<domain.com>. IN NS ns1.<our domain>.com.
<domain.com>. IN NS ns2.<our domain>.com.
<domain.com>. IN A <customer ip>
www.<domain.com>. IN A <customer ip>
_autodiscover._tcp.domain.com. IN SRV 0 0 443 autodiscover.<our-domain>.com.
<domain.com>. IN MX 10 <mx-record>.com.
<domain.com>. IN MX 20 <mx-record>.net.
スレーブ
/var/lib/bind/some-domain.com.hosts
$Origin .
$TTL 38400 ; 10 hours 40 minutes
domain.com IN SOA ns1.<our domain>.se. admin.<our domain>.com. (
1373899259 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS ns1.<our domain>.com.
NS ns2.<our domain>.com.
A 212.247.229.60
MX 10 <mx>.com.
MX 20 <mx>.net.
$Origin <DOMAIN.COM>.
_autodiscover._tcp SRV 0 0 443 autodiscover.<our-domain>.com.
www A <customer ip>
編集:
実行時にログを確認しました
rndcリロード
SLAVEでは、syslogはさまざまなゾーンでこれでいっぱいになります。
Jun 19 13:54:22 ns2 named[3558]: zone <domain.com>/IN: Transfer started.
Jun 19 13:54:22 ns2 named[3558]: transfer of '<domain.com>/IN' from <MASTER IP>#53: connected using <OTHER IP, maybe FW?>#41569
Jun 19 13:54:22 ns2 named[3558]: transfer of '<domain.com>/IN' from <MASTER IP>#53: failed while receiving responses: NOTAUTH
Jun 19 13:54:22 ns2 named[3558]: transfer of '<domain.com>/IN' from <MASTER IP>#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
Jun 19 13:53:49 ns2 named[3558]: zone <DOMAIN.COM>/IN: refresh: unexpected rcode (REFUSED) from master <MASTER IP>#53 (source 0.0.0.0#0)
Jun 19 13:53:49 ns2 named[3558]: zone <DOMAIN.COM>/IN: Transfer started.
MASTERでは、syslogは次のようになります。
Jun 19 16:42:36 ns1 named[12833]: client <SLAVE IP>#15012: query (cache) '<domain.com>/SOA/IN' denied
Jun 19 16:42:36 ns1 named[12833]: client <SLAVE IP>#58925: zone transfer '<DOMAIN.COM>/AXFR/IN' denied
Jun 19 16:42:36 ns1 named[12833]: client <SLAVE IP>#56767: bad zone transfer request: '<DOMAIN.COM>/IN': non-authoritative zone (NOTAUTH)
これらのログはすべて異なるドメインで繰り返されます
問題は主にバインドシステムの外にあるように私には思えます。これは、最初に最も重要だと思います。
Jun 19 13:54:22 ns2 named[3558]: transfer of '<domain.com>/IN' from <MASTER IP>#53: connected using <OTHER IP, maybe FW?>#41569
一般に、通信は機能しているように見えますが(スレーブはマスターに接続できます)、どういうわけか直接ではありません(例:一部のNAT)。その結果、マスターは他の許可されたIPからのリクエストを確認し、転送を適切に拒否します。シンプルなゾーン転送(通知は別のトピックである可能性があります)の実用的なソリューションとして、転送にTSIGを利用して、リクエストがスレーブのIP以外からのものであっても、トランザクションSIGnatureによって適切に処理できるため、適切に承認できます。 ..
tSIGキーを生成するために使用できます。
a=$(dnssec-keygen -a HMAC-MD5 -b 512 -n Host transfer); sed "s/\([^ ]*\)\. IN KEY [0-9]* [0-9]* [0-9]* \([^ ]*\) \([^ ]*\)/key \1 {\n algorithm HMAC-MD5;\n secret \2\3;\n};/" ${a}.key; rm ${a}*
または、読みやすくするために他のフォームを使用する場合:
a=$(dnssec-keygen -a HMAC-MD5 -b 512 -n Host transfer)
sed "s/\([^ ]*\)\. IN KEY [0-9]* [0-9]* [0-9]* \([^ ]*\) \([^ ]*\)/key \1 {\n algorithm HMAC-MD5;\n secret \2\3;\n};/" ${a}.key
rm ${a}*
結果は、バインド構成にコピーする準備ができたテキストになります。
key transfer {
algorithm HMAC-MD5;
secret bv2uLjmxx2RA9DGTP697E17//s6xxt9DgjFxYpVv53qvsHdqG3Fy8IXva/OaEaHHHVuquh23mCIIQ2Gf3ojqzw==;
};
この「ブロック」は、マスター構成とスレーブ構成の両方にコピーして、同じものにする必要があります;-)。
次に、マスター側の設定を
allow-transfer {
<IP-OF-SLAVE>;
};
に
allow-transfer {
key transfer;
};
スレーブ側から
masters {
<IP-MASTER>;
};
に
masters {
<IP-MASTER> key transfer;
};
このようにして、スレーブはキーを使用してマスターに連絡し、ソースIPでもトランザクションが変更されるため、適切なTSIGに基づいて許可されます。転送の許可は、リクエストのソースIPではなく、TSIGの「転送」キーに基づいて設定されます。
次のステップは、ソースIPが変更されている理由を調査することですが、転送はその時点ですでに機能しています;-)。幸運を !
-編集-忘れたセミコロンを一部キーに追加しました。ロード中にエラーメッセージが表示されて明確になる場合がありますが、完了する必要があります。..:-)
スレーブとマスターの両方から投稿したSOAヘッダーには、同じシリアル番号が表示されます。
マスタースレーブレプリケーションが「突然動作を停止する」ときの一般的な「初心者」の間違いは、マスターのゾーンファイルに変更を加えても、SOAシリアル番号レコードが更新されないことです。
マスターのSOAシリアル番号レコードをインクリメントしない場合、スレーブは同期していないことを検出できず、ゾーン転送を要求しません。マスターネームサーバー。
変更を有効にするには、ゾーンファイルを変更した後、マスターでバインドする必要があります。例:rnds reload example.com
それでもうまくいかない場合:@wurtelからのコメントには、さらにデバッグするための適切なポインタがいくつかあります。
SOAシリアル文字列1373899259はタイムスタンプのように見えます:
date --date=" 1970-01-01 00:00:00 UTC +1373899259 seconds"
Mon Jul 15 16:40:59 CEST 2013
現在のタイムスタンプを使用する方が間違いなく「より良い」かもしれませんが、少なくとも+1
から1373899260までインクリメントする必要があります。
date +%s
1560943969