LINUX.ORG.RU

bind не работает forward

 


0

1

Есть 2 сервера. нужно что бы они отвечали за 2 свои зоны а 2 с соседнего - форвардили ему (вариант со слейвом работает но не подходит по ряду причин).

Этот кусок конфига одинаковый для vpn\vps

options {
    allow-recursion { any; };
    allow-query { any; };
    allow-query-cache { any; };
    check-names master ignore;
    additional-from-auth yes;
    additional-from-cache yes;
    dnssec-validation no;
    empty-zones-enable no;
    auth-nxdomain no;};
vpn(2.2.2.2)
zone "10.in-addr.arpa" {
        type master;
        file "db.10";    };
zone "172.in-addr.arpa" {
        type forward;
        forwarders {1.1.1.1;};    };
zone "vpn.domain.com" {
        type master;
        file "vpn.domain.com.zone";    };
zone "vps.domain.com" {
        type forward;
        forwarders {1.1.1.1;};    };
vps(1.1.1.1)
zone "10.in-addr.arpa" {
        type forward;
        forwarders {2.2.2.2;};    };
zone "172.in-addr.arpa" {
        type master;
        file "db.172";    };
zone "vps.domain.com" {
        type master;
        file "vps.domain.com.zone";    };
zone "vpn.domain.com" {
        type forward;
        forwarders {2.2.2.2;};    };

Еще есть зоны «domain.com» (для которой сервера мастер\слейв) и rpz.zone Со «своими» зонами никаких пробелм. Так же нормально резолвятся обратные зоны (те сервер vpn может ответить на запрос о 172.16.74.0/24) Проблема начинается при попытке у сервера 1 запросить зону с сервера 2. Возвращает NXDOMAIN. В логах на сервер все ок (пишет что запрос пришел. НЕ пишет denied), и вообще ни каких ошибок не вижу.

Лог с vps, просим зону vpn:

queries: info: client 192.154.10.10#56562 (vpn.domain.com): query: vpn.domain.com IN A + (1.1.1.1)
queries: info: client 192.154.10.10#34797 (vpn.domain.com): query: vpn.domain.com IN A + (1.1.1.1)
queries: info: client 192.154.10.10#47483 (vpn.domain.com): query: vpn.domain.com IN A + (1.1.1.1)

client: debug 90: client 1.1.1.1#35012: received DSCP 0
client: debug 3: client 1.1.1.1#35012: UDP request
client: debug 5: client 1.1.1.1#35012: using view '_default'
client: debug 3: client 1.1.1.1#35012: query
client: debug 10: client 1.1.1.1#35012 (vpn.domain.com): ns_client_attach: ref = 1
client: debug 3: client 1.1.1.1#35012 (vpn.domain.com): send
client: debug 3: client 1.1.1.1#35012 (vpn.domain.com): sendto
client: debug 3: client 1.1.1.1#35012 (vpn.domain.com): senddone
client: debug 3: client 1.1.1.1#35012 (vpn.domain.com): next
client: debug 10: client 1.1.1.1#35012 (vpn.domain.com): ns_client_detach: ref = 0
client: debug 3: client 1.1.1.1#35012 (vpn.domain.com): endrequest
При этом по tcpdump сервер 1.1.1.1 даже не пытается ничего спросить у 2.2.2.2

Всю башку сломал. Куда копать?



Последнее исправление: DeeZ (всего исправлений: 1)

По логам у вас идёт запрос на A запись из зоны domain.com. Как у вас записаны NS-записи для vpn.domain.com?

mky ★★★★★
()
Ответ на: комментарий от mky

Так я и прошу А-запись. Сейчас заметил что в ответе и в зоне разные серийники. Ощущение что бинд закэшировал ответ и его отдает не смотря на все таймауты и не пытается обновить кэш. Даже после рестарта кэш не сбрасывается.

dig @2.2.2.2 vps.domain.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @2.2.2.2 vps.domain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3406
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;vps.domain.com.                        IN      A

;; AUTHORITY SECTION:
domain.com.             3600    IN      SOA     ns1.domain.com. user.domain.com. 2017090809 900 600 864000 3600

;; Query time: 37 msec
;; SERVER: 2.2.2.2#53(2.2.2.2)
;; WHEN: Fri Sep 08 22:58:03 +05 2017
;; MSG SIZE  rcvd: 84

vpn.domain.com.zone

$TTL 3600       ; 1 hour
@       IN      SOA     ns2.domain.com. user.domain.com. (
                        2017090715
                        900
                        600
                        864000
                        3600 )
                        NS      ns2.domain.com.
                        A       2.2.2.2
ns                      A       2.2.2.2
vps.domain.com.zone
$TTL 3600       ; 1 hour
@       IN      SOA     ns1.domain.com. user.domain.com. (
                        2017090715
                        900
                        600
                        864000
                        3600 )
                        NS      ns1.domain.com.
                        A       1.1.1.1
ns1                     A       1.1.1.1

DeeZ
() автор топика
Ответ на: комментарий от DeeZ

Серийник - это серийник зоны domain.com. Похоже как то не правильно делигировал субдомен.

DeeZ
() автор топика
Ответ на: комментарий от DeeZ

Если проблемы с зоной, лучше начинать с запросов NS записи, чтобы было видно, понимает ли bind, что это отдельная зона.

в ответе и в зоне разные серийники

Дак в ответе, похоже, серийник от зоны domain.com, bind спокойно ищет в этой зоне запись vps и ничего не найдя возвращает NXDOMAIN.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну да. Суть вопроса была в том что бы поддомен не делегировать в форвардить, при условии что для самого домена бинды авторитативны. Пока не разобрался как это сделать.

DeeZ
() автор топика
Ответ на: комментарий от DeeZ

Решение

Убрать «форвард». Те на сервере VPN убрать кусок

zone "vps.domain.com" {type forward; forwarders {1.1.1.1;};};
А на vps убарть zone
"vpn.domain.com" {type forward; forwarders {2.2.2.2;};};

В зону domain.com добавить вместо форварда:

$ORIGIN vps.domain.com.
@       IN              NS      vps.domain.com.

$ORIGIN vpn.domain.com.
@       IN              NS      vps.domain.com.

DeeZ
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.