[alibek]

Понравилась мне эта пара больше, чем BIND.

Ранее NSD+Unbound работали на FreeBSD, NSD на порту 5353, Unbound на порту 53.

В файрволе я настроил правила, чтобы все внешние (не из моих сетей) udp/53 перенаправлялись на udp/5353.

В результате DNS-запросы из моих сетей попадали на Unbound и обрабатывались им (рекурсивно, с кешированием), а DNS-запросы извне попадали на NSD и обрабатывались им (только для обслуживаемой зоны, для остальных был отбой).

Получался одновременно авторитетный и кеширующий сервер с одним маленьким недостатком - DNS-ответы в моей сети были неавторитетными.

 

Теперь хочу запустить эту пару на Debian, но с файрволом хитрить не хочу.

Хочу сделать так: NSD запустить на 127.0.0.53:53, а Unbound запустить на 127.0.0.1:53 и остальных интерфейсах. И затем в Unbound прописать stub-зоны с пересылкой на 127.0.0.53:53.

Судя по документации, ответы из stub-зоны должны быть авторитетными.

Но у меня ответов вообще нет, я получаю SERVFAIL от Unbound (а NSD работает и отвечает нормально).

Не подскажите, что не так?

NSD настроен так (версия 4.1.0):

server:
   interface: 127.0.0.53

pattern:
   name: "default"
   provide-xfr: 127.0.0.0/8 NOKEY

zone:
   name: "domain.ru."
   zonefile: "zones/ru.domain"
   include-pattern: "default"

Unbound настроен так (версия 1.4.22):

server:
   interface: 127.0.0.1
   interface: 1.2.3.4

stub-zone:
   name: "domain.ru."
   stub-addr: 127.0.0.53

 

Результат:

# nslookup 10.1.128.9 localhost
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:         localhost
Address:        127.0.0.1#53

** server can't find 9.128.1.10.in-addr.arpa: SERVFAIL

 

Что забыл доделать?

[alibek]

Если для моих доменов указать domain-insecure, то начинает работать.

Но ответы не авторитетны.

# dig @127.0.0.1 test.null

; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> @127.0.0.1 test.null
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29731
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.null.                     IN      A

;; ANSWER SECTION:
test.null.              21432   IN      A       127.0.0.1

;; AUTHORITY SECTION:
null.                   21432   IN      NS      ns.null.

;; ADDITIONAL SECTION:
ns.null.                21432   IN      A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 03 00:14:23 MSK 2017
;; MSG SIZE  rcvd: 87

# dig @127.0.0.53 test.null

; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> @127.0.0.53 test.null
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6463
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.null.                     IN      A

;; ANSWER SECTION:
test.null.              21600   IN      A       127.0.0.1

;; AUTHORITY SECTION:
null.                   21600   IN      NS      ns.null.

;; ADDITIONAL SECTION:
ns.null.                21600   IN      A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Jun 03 00:14:50 MSK 2017
;; MSG SIZE  rcvd: 87

Нужно настраивать DNSSEC на NSD?

[Ivan_83]

А инструкции от создателей нет?

[snvoronkov]

Нужно настраивать DNSSEC на NSD?

Весьма, кстати, вероятно. Крайний раз unbound через старый PIX именно так побеждать пришлось.

[alibek]

В DNSSEC меня смущала необходимость регулярно обновлять anchor.

Видимо придется разобраться.

[alibek]

Кстати, а что специалисты скажут по поводу такого описания зоны?

@   IN SOA    ns.zone.ru. root.zone.ru.  1496494419 4h 1h 2w 1h
      NS     ns.zone.ru.
      NS     ns01.zone.ru.
      NS     ns02.zone.ru.
ns     A      1.2.3.4
ns     A      11.22.33.44
ns01   A      1.2.3.4
ns02   A      11.22.33.44

ns01 и ns02 это независимые сервера (то есть не master/slave, а два master), которые одновременно обновляются скриптом.

Идея в том, чтобы ns-сервером зоны был "облачный" ns.zone.ru, который "распределяется" (по round-robin) между обоими серверами.

Или лучше так не делать?

[alibek]

В DNSSEC меня смущала необходимость регулярно обновлять anchor.

Видимо придется разобраться.

Под anchor я имел ввиду ZSK и KSK.

У нас регистратор RU-CENTER.

И похоже на то, что автоматизации тут не будет, KSK нужно будет вручную указывать в личном кабинете.

К тому же у меня есть приватные зоны, там вообще не понятно, как корневую запись делать.

Чем дальше в лес, тем толще партизаны.

 

Вообщем не буду делать DNSSEC.

Попробую заставить Unbound давать авторитетные ответы для stub-зон.

Или в крайнем случае сделаю как раньше - форвард внешних DNS-запросов на NSD сделаю через iptables.

Или вернусь к BIND.

[snvoronkov]

Или вернусь к BIND.

В 8-м дебьяне bind тухлый. Даже без rrl, ЕМНИП. А руками собирать быстро надоедает (проверено на себе).

[alibek]

А кто-нибудь пробовал несколько инстансов NSD запускать на Debian 8?

Из-за отсутствия view я бы хотел запустить два инстанса, для приватных и публичных зон (на приватном и публичном интерфейсе соответственно).

Как это делать теоретически на systemd я знаю — нужно файл описания сервиса переименовать в nsd@.service и выполнить systemctl enable nsd-{private,public}

Но сервер рабочий, не хотелось бы неудачных экспериментов. А тестового под Debian 8 пока нет.

[hsvt]

А кто-нибудь пробовал несколько инстансов NSD запускать на Debian 8?

Из-за отсутствия view я бы хотел запустить два инстанса, для приватных и публичных зон (на приватном и публичном интерфейсе соответственно).

Как это делать теоретически на systemd я знаю — нужно файл описания сервиса переименовать в nsd@.service и выполнить systemctl enable nsd-{private,public}

Но сервер рабочий, не хотелось бы неудачных экспериментов. А тестового под Debian 8 пока нет.

 

Подниму тему.

 

А Можете пожалуйста привести конфиги на pf для перенаправления трафика с 53 на 5353 и конфиг unbound с тюнингом именно под FreeBSD + какая версия была бзди? Буду благодарен.

 

Сейчас хочу поднять второй рекурсивный dns кеш сервер на свежей FreeBSD 11.1 RC3, первый настроен на Debian, ключевые параметры на обработку большого количества запросов будут различаться, я думаю.

 

Пробовал поднимать на CentOS7, там совсем древняя версия и многих крутилок нет.

 

А если у клиента зона обслуживается у нас и он отправляет запрос на 53 порт - он ни как не получит авторитативный ответ? Я вот пока в раздумьях как лучше сделать, совместить unbound+bind или разделить их и сделать ns0_unbound ns1_unbound ns2_bind_master ns3_bind_slave...

Изменено 19 июля, 2017 пользователем hsvt

[Ivan_83]

А Можете пожалуйста привести конфиги на pf для перенаправления трафика с 53 на 5353

Даже не смешно. Оно гуглится в мануалах минимум с 2008 года, когда я сам только учился этому.

[hsvt]

А Можете пожалуйста привести конфиги на pf для перенаправления трафика с 53 на 5353

Даже не смешно. Оно гуглится в мануалах минимум с 2008 года, когда я сам только учился этому.

 

Это только часть вопроса, я просто хотел услышать как вообще это всё работало у alibek и общее представление и нюансы. Заодно проще было бы с примером сразу, чтобы не гуглить и не вспоминать.

Последнее время больше с iptables работал, pf настроил и забыл, потому опять лазить туда надолго не хотелось :)

[alibek]

Все работало хорошо.

Но я отказался от FreeBSD по некоторым причинам, старого конфига pf не сохранилось.

Но там ничего сложного не было - определить макрос со своими подсетями и для src не из этих подсетей делать перенаправление.

Сейчас NSD+Unbound у меня работают на Debian, схема работы чуть изменилась:

 

NSD работает на 127.0.0.53:53

Unbound работает на 127.0.0.1:53 и на внешних интерфейсах

В iptables настраиваю перенаправление внешних DNS-запросов на 127.0.0.53:53, примерно так:

iptables -t nat -A PREROUTING -i $IF_EXT -p tcp -m set ! --match-set EXT src -m set --match-set FWD-DNS dst,dst -j DNAT --to-destination 127.0.0.53:53
iptables -t nat -A PREROUTING -i $IF_EXT -p udp -m set ! --match-set EXT src -m set --match-set FWD-DNS dst,dst -j DNAT --to-destination 127.0.0.53:53

Проще в реализации и кеширующий DNS работает при отключенном iptables.

[hsvt]

Все работало хорошо.

Но я отказался от FreeBSD по некоторым причинам, старого конфига pf не сохранилось.

Но там ничего сложного не было - определить макрос со своими подсетями и для src не из этих подсетей делать перенаправление.

Сейчас NSD+Unbound у меня работают на Debian, схема работы чуть изменилась:

 

NSD работает на 127.0.0.53:53

Unbound работает на 127.0.0.1:53 и на внешних интерфейсах

В iptables настраиваю перенаправление внешних DNS-запросов на 127.0.0.53:53, примерно так:

iptables -t nat -A PREROUTING -i $IF_EXT -p tcp -m set ! --match-set EXT src -m set --match-set FWD-DNS dst,dst -j DNAT --to-destination 127.0.0.53:53
iptables -t nat -A PREROUTING -i $IF_EXT -p udp -m set ! --match-set EXT src -m set --match-set FWD-DNS dst,dst -j DNAT --to-destination 127.0.0.53:53

Проще в реализации и кеширующий DNS работает при отключенном iptables.

 

Благодарю, для себя решил, что мне unbound не нужен во внешке, остановился на двух кешах и двух авторитетных.