Ubuntu
綁定主伺服器不同步到從伺服器
我在工作中得到了一個舊的綁定係統，主伺服器上的區域不同步到從伺服器。我是綁定的菜鳥，真的可以使用幫助。我希望在 MASTER 上所做的所有更改都同步到 SLAVE。
伺服器可以相互訪問（ping、ssh、在兩者之間完全打開）。伺服器有點舊，我不允許更新，因為擔心可能會損壞。
Ubuntu 12.04.5 LTS BIND 9.8.1-P1
大師 = ns1..com。奴隸 = ns2..com。
我們可以使用綁定伺服器，它們可以正常工作，只是不會複製更改。
據說大部分更改都是通過 gui 進行的，我無權訪問。
這些問題可能是在 MASTER 伺服器上更改 ip 時開始的，至少在那時發現了問題，但沒有人確切知道。
已重新啟動服務，刷新記憶體，重新啟動伺服器。我檢查了配置，但據我所知，它應該是正確的。嘗試了 rndc –retransfer ，但它沒有輸出並且不起作用。
rndc status
給出以下輸出：
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 runningMASTER 和 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; }; };MASTER
/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 { }; };從/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 {}; };MASTER
/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>; }; };這裡有數百個區域，所有區域都配置相同。
從/etc/bind/named.conf.local
zone "domain.nu" { type slave; masters { <IP-MASTER>; }; file "/var/lib/bind/domain.nu.hosts"; allow-transfer { <IP-MASTER>; }; };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"; };從/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 中找到不同區域的配置它們看起來有點不同，具體取決於它們是在 MASTER 上還是在 SLAVE 上
主
/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>編輯：
我檢查了日誌，當我在 SLAVE 上執行
rndc reload
時，系統日誌會為不同的區域填充此內容：
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 上，系統日誌如下所示：
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）。結果是 master 看到來自其他 IP 的請求，然後正確地拒絕了傳輸。作為簡單區域傳輸的工作解決方案（通知可能是其他主題），我會看到使用 TSIG 進行傳輸，因此即使請求來自從屬 IP 以外的其他 IP，它也可以被正確處理，因為它可以被 Transaction 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==; };這個“塊”必須複製到主配置和從配置才能知道並且相同;-)。
然後你可以在 MASTER 端更改配置
allow-transfer { <IP-OF-SLAVE>; };到
allow-transfer { key transfer; };在從屬側
masters { <IP-MASTER>; };到
masters { <IP-MASTER> key transfer; };這樣，slave 將使用密鑰與 master 聯繫，甚至源 IP 也會根據適當的 TSIG 更改交易。傳輸的允許不是基於請求的源 IP，而是基於 TSIG 的“傳輸”密鑰。
下一步將/可能是調查為什麼源 IP 正在發生變化，但此時轉移已經開始工作了 ;-)。祝你好運 ！
– 編輯 – 我在密鑰中添加了部分忘記的分號。載入期間的錯誤消息可能很清楚，但要完成…. :-)