Я тестирую свою конфигурацию обновления ddns (для ISC DHCP, размещенного на том же сервере) с nsupdate
, и пока передняя зона обновляется правильно:
# nsupdate
> server 127.0.0.1
> key dhcpupdate MYSECRETKEY
> update add test.example.com. 600 IN A 10.2.2.45
> send
# tail -n1 /var/log/named.conf
client 127.0.0.1#12584: view internal: updating zone 'example.com/IN': adding an RR at 'test.example.com' A
обратная зона не:
# nsupdate
> server 127.0.0.1
> key dhcpupdate MYSECRETKEY
> update add 45.2.2.10.in-addr.arpa. 600 IN PTR test.example.com.
> send
response to SOA query was unsuccessful
Затем nsupdate отправляет меня обратно в оболочку, и в журналах нет ошибок (или сообщений любого рода). Я пробовал обновление обратной зоны с конечными точками и без них. У меня такое чувство, что я упускаю что-то базовое, но не могу понять, что именно.
Спасибо за любые указатели. Вот мои файлы конфигурации и другая информация:
# cat /etc/named.conf
acl internals {
127.0.0.0/8;
10.2.2.0/24;
};
logging {
channel named.log {
file "/var/log/named/named.log";
severity dynamic;
};
category default {
named.log;
};
};
options {
listen-on port 53 { any; };
// listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
key dhcpupdate {
algorithm hmac-md5;
secret "MYSECRETKEY";
};
include "/etc/named.root.key";
view "internal" {
match-clients { internals; };
recursion yes;
zone "localhost" IN {
type master;
file "/var/named/db.localhost";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/var/named/db.0.0.127.in-addr.arpa";
allow-update { none; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "example.com" {
type master;
file "/var/named/db.example.com";
allow-update { key dhcpupdate; };
};
zone "2.2.10.in-addr.arpa" IN {
type master;
file "/var/named/db.2.2.10.in-addr.arpa";
allow-update { key dhcpupdate; };
};
};
view "external" {
match-clients { any; };
recursion no;
forwarders { 1.2.3.4; 1.2.3.5; }; // ISP DNS servers
forward first;
};
# cat /var/named/db.example.com
$ORIGIN .
$TTL 600 ; 10 minutes
example.com IN SOA ns1.example.com. root.example.com. (
5 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS ns1.example.com.
A 10.2.2.44
$TTL 3600 ; 1 hour
MX 1 ASPMX.L.GOOGLE.COM.
MX 5 ALT1.ASPMX.L.GOOGLE.COM.
MX 5 ALT2.ASPMX.L.GOOGLE.COM.
MX 10 ASPMX2.GOOGLEMAIL.COM.
MX 10 ASPMX3.GOOGLEMAIL.COM.
$ORIGIN example.com.
$TTL 600 ; 10 minutes
myserver A 10.2.2.5
ns1 A 10.2.2.5
test A 10.2.2.45
www A 123.12.34.32 // externally hosted www server
# cat /var/named/db.2.2.10.in-addr.arpa
;
; BIND data file for example.com
;
$TTL 10m
@ IN SOA ns1.example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
2.2.10.in-addr.arpa. IN NS ns1.example.com.
5 IN PTR myserver.example.com.
РЕДАКТИРОВАТЬ:
Использование команды отладки в nsupdate дает следующее:
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28411
;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;96.2.2.10.in-addr.arpa. IN SOA
;; TSIG PSEUDOSECTION:
dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367446210 300 16 XXXXXXXXX 28411 NOERROR 0
response to SOA query was unsuccessful
РЕДАКТИРОВАТЬ2:
При указании зоны получаю следующее:
> debug
> server 127.0.0.1
> zone 2.2.10.in-addr.arpa
> key dhcpupdate XXXXXXXXXXX
> update add 96.2.2.10.in-addr.arpa. 600 IN PTR scott-lap.example.com.
> send
Sending update to 127.0.0.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 11170
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;2.2.10.in-addr.arpa. IN SOA
;; UPDATE SECTION:
96.2.2.10.in-addr.arpa. 600 IN PTR scott-lap.example.com.
;; TSIG PSEUDOSECTION:
dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367447008 300 16 XXXXXXXXXXXXXX 11170 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: SERVFAIL, id: 11170
;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;2.2.10.in-addr.arpa. IN SOA
;; TSIG PSEUDOSECTION:
dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367447008 300 16 XXXXXXXXXXXXXXXXX 11170 NOERROR 0
РЕДАКТИРОВАТЬ3:
Ага. Я пытаюсь использовать host
чтобы увидеть, разрешает ли он IP-адрес моего DNS-сервера (который указан в файле обратной зоны выше), и это то, что я получаю. Снова нет записей в журнале.
# host -v 10.2.2.5
Trying "10.2.2.10.in-addr.arpa"
Host 10.2.2.10.in-addr.arpa not found: 2(SERVFAIL)
Received 40 bytes from 10.2.2.5#53 in 0 ms
РЕШЕНИЕ:
Понятия не имею, почему, но теперь это работает. Единственное, что я сделал, было rndc querylog
, который явно ничего не может исправить сам по себе, а также следующее:
# chown -R named:named /var/named
# find . -type d -exec chmod 770 {} \;
# find . -type f -exec chmod 660 {} \;
Что самое забавное, я на 99,999% уверен, что разрешения уже установлены правильно (имя владельца / группы, с 660 разрешениями). Я имею в виду, что я проверял права доступа как минимум десяток раз. О, еще что я сделал - удалил db.2.2.10.in-addr.arpa.jnl нулевой длины и перезапустил named, чтобы позволить ему воссоздать его. Он воссоздал его правильно (хотя и с 644 разрешениями), и с этого момента он работал. Я сбит с толку, почему он работает, но я возьму его! Спасибо всем за ваши усилия.
РЕДАКТИРОВАТЬ:
Похоже, что мой файл обратной зоны каким-то образом обновился (я предполагаю через nsupdate). Отправляю сюда на случай, если это поможет. Обратите внимание на разницу с моей первоначально опубликованной зоной 2.2.10.in-addr.arpa в моем исходном вопросе. Мне кажется, что различия достаточно тривиальны, чтобы не повлиять на функциональность, но, конечно, я далеко не эксперт.
$ORIGIN .
$TTL 600 ; 10 minutes
2.2.10.in-addr.arpa IN SOA ns1.example.com. root.example.com. (
4 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS ns1.example.com.
$ORIGIN 2.2.10.in-addr.arpa.
10 PTR a.example.com.
11 PTR b.example.com.
15 PTR c.example.com.
96 PTR d.example.com.
55 PTR 3.example.com.
5 PTR server.example.com.
У меня есть подозрение, что это может быть отсутствие явного zone
заявление в вашем обновлении.
nsupdate
должен угадать, к какой зоне применяется обновление, когда вы его опускаете («на основе остальной части ввода» согласно справочной странице), и я вижу много места для того, чтобы это предположение было неверным, учитывая, сколько квадратов глубиной в этой зоне.
В противном случае дайте -v
вращение, чтобы увидеть, повезет ли вам с TCP.