Мне передали старую систему привязки на работе, и зоны на главном устройстве не синхронизируются с подчиненным. Я новичок в связывании, и мне действительно нужна помощь. Я хочу, чтобы все изменения, сделанные на МАСТЕРЕ, синхронизировались с ПОДЧИНЕННЫМ.
Серверы могут связываться друг с другом (ping, ssh, полностью открыты между ними). Серверы немного устарели, мне не разрешено обновлять из-за опасений, что что-то сломается.
Ubuntu 12.04.5 LTS BIND 9.8.1-P1
МАСТЕР = ns1..com. SLAVE = ns2..com.
Мы можем использовать bind-серверы, они работают так, как должны, изменения просто не воспроизводятся.
Говорят, что большинство изменений было сделано через графический интерфейс, у меня нет доступа к нему.
Проблемы могли возникнуть во время смены 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
ВЕДУЩИЙ и ВЕДОМЫЙ (конфиг похож, только секрет отличается)
/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 {
};
};
РАБ
/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>;
};
};
Здесь сотни зон, все настроены одинаково.
РАБ
/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";
};
РАБ
/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.
На МАСТЕРЕ системный журнал выглядит так:
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)
Все эти журналы повторяются для разных доменов.
Заголовки 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
мне кажется, что проблема в первую очередь в системе привязки. Это я считаю самым важным для начала.
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-адрес меняется, но передача будет работать уже в этот момент ;-). Удачи !
- редактировать - я добавил забытую точку с запятой частично вместе с ключом. Это может быть ясно с сообщением об ошибке во время загрузки, но чтобы она была завершена .... :-)