Мастер связывания не синхронизируется с подчиненным
Мне передали старую систему Bind на работе, и зоны на главном устройстве не синхронизируются с подчиненным. Я новичок в связывании, и мне действительно нужна помощь. Я хочу, чтобы все изменения, сделанные на МАСТЕРЕ, синхронизировались с ПОДЧИНЕННЫМ.
Серверы могут связываться друг с другом (ping, ssh, полностью открыт между ними). Серверы устарели, мне не разрешено обновлять из-за опасений, что что-то может сломаться.
Ubuntu 12.04.5 LTS BIND 9.8.1-P1
MASTER = ns1..com. SLAVE = ns2..com.
Мы можем использовать серверы связывания, они работают так, как должны, изменения просто не реплицируются.
Большинство изменений, как утверждается, были сделаны через графический интерфейс, я не имеют к этому доступа.
Проблемы могли возникнуть во время смены 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 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; };
};
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[12208 impressionMASTER
/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>;
};
};
MASTER
/etc/bind/ named.conf.default-zones[12212ghtSLAVE
/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 reload
на SLAVE системный журнал заполняется следующим образом для разных зон:
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)
Все эти журналы повторяются для разных доменов
мне кажется, что проблема в основном связана с системой привязки. Я считаю, что самое важное для начала.
19 июня 13:54:22 ns2 с именем [3558]: передача '/ IN' с # 53: подключено с использованием <ДРУГОГО IP , может быть, 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==;
};
Это " block "должен быть скопирован как в главную, так и в подчиненную конфигурацию, чтобы она была известна и одинакова; -).
Затем вы можете изменить конфигурацию на стороне MASTER с
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