alibek Опубликовано 2 июня, 2017 · Жалоба Понравилась мне эта пара больше, чем 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 Что забыл доделать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 июня, 2017 · Жалоба Если для моих доменов указать 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 2 июня, 2017 · Жалоба А инструкции от создателей нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 июня, 2017 · Жалоба Нужно настраивать DNSSEC на NSD? Весьма, кстати, вероятно. Крайний раз unbound через старый PIX именно так побеждать пришлось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 3 июня, 2017 · Жалоба В DNSSEC меня смущала необходимость регулярно обновлять anchor. Видимо придется разобраться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 3 июня, 2017 · Жалоба Кстати, а что специалисты скажут по поводу такого описания зоны? @ 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) между обоими серверами. Или лучше так не делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 3 июня, 2017 · Жалоба В DNSSEC меня смущала необходимость регулярно обновлять anchor. Видимо придется разобраться. Под anchor я имел ввиду ZSK и KSK. У нас регистратор RU-CENTER. И похоже на то, что автоматизации тут не будет, KSK нужно будет вручную указывать в личном кабинете. К тому же у меня есть приватные зоны, там вообще не понятно, как корневую запись делать. Чем дальше в лес, тем толще партизаны. Вообщем не буду делать DNSSEC. Попробую заставить Unbound давать авторитетные ответы для stub-зон. Или в крайнем случае сделаю как раньше - форвард внешних DNS-запросов на NSD сделаю через iptables. Или вернусь к BIND. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 июня, 2017 · Жалоба Или вернусь к BIND. В 8-м дебьяне bind тухлый. Даже без rrl, ЕМНИП. А руками собирать быстро надоедает (проверено на себе). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 июня, 2017 · Жалоба А кто-нибудь пробовал несколько инстансов NSD запускать на Debian 8? Из-за отсутствия view я бы хотел запустить два инстанса, для приватных и публичных зон (на приватном и публичном интерфейсе соответственно). Как это делать теоретически на systemd я знаю — нужно файл описания сервиса переименовать в nsd@.service и выполнить systemctl enable nsd-{private,public} Но сервер рабочий, не хотелось бы неудачных экспериментов. А тестового под Debian 8 пока нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 19 июля, 2017 (изменено) · Жалоба А кто-нибудь пробовал несколько инстансов 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 июля, 2017 · Жалоба А Можете пожалуйста привести конфиги на pf для перенаправления трафика с 53 на 5353 Даже не смешно. Оно гуглится в мануалах минимум с 2008 года, когда я сам только учился этому. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 20 июля, 2017 · Жалоба А Можете пожалуйста привести конфиги на pf для перенаправления трафика с 53 на 5353 Даже не смешно. Оно гуглится в мануалах минимум с 2008 года, когда я сам только учился этому. Это только часть вопроса, я просто хотел услышать как вообще это всё работало у alibek и общее представление и нюансы. Заодно проще было бы с примером сразу, чтобы не гуглить и не вспоминать. Последнее время больше с iptables работал, pf настроил и забыл, потому опять лазить туда надолго не хотелось :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 20 июля, 2017 · Жалоба Все работало хорошо. Но я отказался от 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 21 июля, 2017 · Жалоба Все работало хорошо. Но я отказался от 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 не нужен во внешке, остановился на двух кешах и двух авторитетных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...