Назад | Перейти на главную страницу

Проблема с BIND: nsupdate не может обновить обратную зону

Я тестирую свою конфигурацию обновления 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.