[alibek]

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

До сих пор использовал BIND9. Работает хорошо, но все-таки не сильно удобен в использовании, да и тяжеловат.

Почитал тут про Unbound, который и легче, и быстрее, и секурнее. Но это исключительно клиентский DNS, для кеширования и рекурсивных запросов.

Также есть NSD, который тоже легче, быстрее и секурнее, но вот он как раз исключительно авторитетный DNS, не поддерживающий кеширование и рекурсивные запросы.

Получится ли их совместить и если да, то как это лучше сделать?

[Ivan_83]

Они же от одной конторы, там должны быть инструкции как их совмещать.

В крайнем случае в анбоунде прописать форвад на нсд для нужных зон, и запретить рекурсию с инета.

[alibek]

А для клиентов я буду Unbound давать?

Ведь в этом случае ответы клиентам будут неавторитетными.

Или пофиг?

[DVM-Avgoor]

В каком смысле bind9 тяжеловат? Разве что в конфигурировании. Анбаунд нужен на очень нагруженных рекурсорах, и он умеет кэшить так что сожрет всю память. Я бы не стал говорить что он "легче" bind'a в этом смысле.

[sirmax]

PowerDNS?

5 лет назад он был быстрее бинда и djb но с тех пор я не тестил производительность

[alibek]

В конфигурировании тяжеловат.

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

[mlevel]

BIND10

[Ivan_83]

Анбаунд нужен на очень нагруженных рекурсорах, и он умеет кэшить так что сожрет всю память. Я бы не стал говорить что он "легче" bind'a в этом смысле.

Там есть настройки сколько памяти жрать.

Анбоунд приятен не только на нагруженных но и вообще везде.

[alibek]

Наверное NSD+Unbound правильнее и лучше.

Но что-то там не все так просто и хорошо.

Вообщем не буду нарушать традиции, поставлю BIND.

А NSD+Unbound на досуге на виртуалке покручу.

[alibek]

Спрошу еще раз.

Как лучше настраивать сервера?

Я раньше делал master и один-два slave. Но тут некоторые неудобства в том, что конфигурация master и slave различается и сервера (физические) не взаимозаменяемые. То есть если физический сервер с master выйдет из строя, один из slave нужно будет перенастраивать.

А если запустить два BIND, один авторитетный и с рекурсией на localhost (к нему пакеты буду пересылать с помощью файрвола) и второй кеширующий на внешних интерфейсах, у которого в forwarder будет внутренний? Тогда настройки и зоны серверов можно будет бэкапить простым копированием и восстановить сервер много времени не займет.

[alibek]

И еще, пользователям Unbound вопрос.

Во FreeBSD начиная с 10 версии вместо bind идет unbound.

Лучше использовать встроенный или устанавливать с портов?

[DVM-Avgoor]

Конечно с портов, кошерней :)

[s.lobanov]

Конечно с портов, кошерней :)

 

чем? в портах будут мажорные апдейты а в системе только со всей системой?

[DVM-Avgoor]

чем? в портах будут мажорные апдейты а в системе только со всей системой?

 

Порт собирается с libev, а в системе с заглушкой.

[Ivan_83]

openssh, unbound, svn с системой не собираю, ставлю с портов.

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

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

[alibek]

Понятно.

Да, этого достаточно, чтобы на порты перейти.

А какого рода софт лучше использовать системный?

[Ivan_83]

Мужеского :)

[alibek]

Осваиваю NSD.

Есть с ним какие-то непонятные моменты.

 

1.

server:
...
       #chroot: "/data/chroot/dns"
       zonesdir: "/data/chroot/dns/nsd/"
       pidfile: "/data/chroot/dns/nsd/var/nsd.pid"
       logfile: "var/nsd.log"
...

В документации говорится, что zonesdir является базой для всех файлов и каталогов, заданных относительно.

Однако pidfile пришлось прописать полностью — NSD стартовался, но вот завершиться уже не мог.

Это баг? Или я не так документацию понял?

 

2. dig, host, nslookup являются частью BIND и отдельно их поставить из портов нельзя.

У NSD есть свои инструменты диагностики?

 

3. Никак не соображу, как совместить NSD и Unbound.

NSD у меня сейчас запущен, запросы своей зоны обслуживает правильно.

На запросы других зон естественно дает отбой.

Допустим я запущу Unbound. Как мне его настроить, чтобы они работали вместе?

[pavel.odintsov]

NSD/Unbound. От PowerDNS рекомендую держаться подальше, как от самого демона, так и от его разработчиков. Защиты по RRL нету, падает без объяснимых причин, тулза по управлению - виснет через раз. Последний стабильный релиз в прошлом веке.

[alibek]

Я их оба уже запустил, NSD на 53 порту, Unbound на 5353.

А как бы их запустить в связке, чтобы оба работали на 53 порту?

[alibek]

Вот здесь, в разделе «Unbound DNS cluster with BIND or NSD master server» приводится пример.

Насколько я понял идею, авторитетный сервер (NSD) вообще недоступен снаружи, ни для клиентов, ни для интернета.

NSD является back-end, Unbound является front-end, и запросы к делегированной зоне Unbound форвардит в NSD.

Но разве в этом случае ответы за запросы, которые даст Unbound, будут авторитетными?

[alibek]

Что-то не выходит каменный цветок.

Есть FreeBSD 10, NSD (авторитетный) и Unbound (кеширующий).

Конфигурация сети следующая:

10.0.0.0/8 — приватная сеть, домен domain.local (или просто domain).

xx.yy.0.0/16 — публичная сеть, домен domain.ru (а также domain1.ru, который должен его полностью дублировать).

Насколько я понял идею из документации (https://calomel.org/unbound_dns.html), авторитетный сервер не обслуживает запросы напрямую, их ему форвардит кеширующий.

Сделал такую конфигурацию.

 

Авторитетный сервер NSD:

server:
       ip-address: 10.1.128.12
       port: 5353

zone:
       name: "core.domain.local."
       zonefile: "zones/zone-core"
zone:
       name: "domain.local."
       zonefile: "zones/zone-service"
zone:
       name: "domain."
       zonefile: "zones/zone-service"
zone:
       name: "10.in-addr.arpa."
       zonefile: "zones/reverse-service"

zone:
       name: "domain.ru."
       zonefile: "zones/zone-public"
zone:
       name: "domain1.ru."
       zonefile: "zones/zone-public"
zone:
       name: "users.domain.ru."
       zonefile: "zones/zone-users"
zone:
       name: "in-addr.arpa."
       zonefile: "zones/reverse-public"

Зоны domain.local и domain одинаковы, т.к. использую один файл зон. Аналогично с domain.ru и domain1.ru.

Собственно авторитетный сервер с такими настройками работает правильно.

 

Кеширующий сервер Unbound:

server:
       interface: 10.1.128.12
       interface: xx.yy.124.12
       port: 53
       root-hints: "cache.zone"
       access-control: 0.0.0.0/0 refuse
       access-control: 127.0.0.0/8 allow_snoop
       access-control: 10.1.128.0/24 allow_snoop
       access-control: 10.0.0.0/8 allow
       access-control: xx.yy.0.0/16 allow
       do-not-query-address: 127.0.0.0/8
       do-not-query-address: ::1
       do-not-query-localhost: yes
       #private-address: 10.0.0.0/8
       #private-domain: "domain"
       #private-domain: "domain.local"
       local-zone: "168.192.in-addr.arpa." deny
       local-zone: "16.172.in-addr.arpa." deny
       local-zone: "17.172.in-addr.arpa." deny
       local-zone: "18.172.in-addr.arpa." deny
       local-zone: "19.172.in-addr.arpa." deny
       local-zone: "20.172.in-addr.arpa." deny
       local-zone: "21.172.in-addr.arpa." deny
       local-zone: "22.172.in-addr.arpa." deny
       local-zone: "23.172.in-addr.arpa." deny
       local-zone: "24.172.in-addr.arpa." deny
       local-zone: "25.172.in-addr.arpa." deny
       local-zone: "26.172.in-addr.arpa." deny
       local-zone: "27.172.in-addr.arpa." deny
       local-zone: "28.172.in-addr.arpa." deny
       local-zone: "29.172.in-addr.arpa." deny
       local-zone: "30.172.in-addr.arpa." deny
       local-zone: "31.172.in-addr.arpa." deny
       local-zone: "10.in-addr.arpa." nodefault
       local-zone: "yy.xx.in-addr.arpa." nodefault

stub-zone:
       name: "domain."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353
stub-zone:
       name: "domain.local."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353
stub-zone:
       name: "10.in-addr.arpa."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353

stub-zone:
       name: "domain.ru."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353
stub-zone:
       name: "domain1.ru."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353
stub-zone:
       name: "in-addr.arpa."
       stub-addr: 10.1.128.11@5353
       stub-addr: 10.1.128.12@5353

forward-zone:
       name: "."
       forward-addr: 8.8.8.8
       forward-addr: 8.8.4.4
       forward-addr: 77.88.8.8
       forward-addr: 77.88.8.1

По идее, Unbound должен форвардить запросы для указанных зон, и возвращать результаты.

И он вообщем-то работает.

Но его ответы почему-то не авторитетны.

Нет предположений почему?

В документации сказано «Answers for local zones are authoritative DNS answers».

Так local-zone у меня определены.

[alibek]

Ничего не пойму.

 

 

# dig @10.1.128.12 srv-test.domain.local -x 10.1.128.9

; <<>> DiG 9.9.4-P2 <<>> @10.1.128.12 srv-test.domain.local -x 10.1.128.9
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55916
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;srv-test.domain.local.       IN      A

;; ANSWER SECTION:
srv-test.domain.local. 3571   IN      A       10.1.128.9

;; AUTHORITY SECTION:
domain.local.         3571    IN      NS      ns.domain.local.
domain.local.         3571    IN      NS      ns01.domain.local.
domain.local.         3571    IN      NS      ns02.domain.local.

;; ADDITIONAL SECTION:
ns.domain.local.      3571    IN      A       10.1.128.12
ns01.domain.local.    3571    IN      A       10.1.128.11
ns02.domain.local.    3571    IN      A       10.1.128.12

;; Query time: 2 msec
;; SERVER: 10.1.128.12#53(10.1.128.12)
;; WHEN: Fri Oct 31 18:03:23 MSK 2014
;; MSG SIZE  rcvd: 171

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5627
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;9.128.1.10.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
9.128.1.10.in-addr.arpa. 3571   IN      PTR     srv-test.

;; AUTHORITY SECTION:
10.in-addr.arpa.        3571    IN      NS      ns.domain.local.
10.in-addr.arpa.        3571    IN      NS      ns01.domain.local.
10.in-addr.arpa.        3571    IN      NS      ns02.domain.local.

;; Query time: 1 msec
;; SERVER: 10.1.128.12#53(10.1.128.12)
;; WHEN: Fri Oct 31 18:03:23 MSK 2014
;; MSG SIZE  rcvd: 143


# nslookup srv-test.domain.local 10.1.128.12
Server:         10.1.128.12
Address:        10.1.128.12#53

Non-authoritative answer:
Name:   srv-test.domain.local
Address: 10.1.128.9


# nslookup 10.1.128.9 10.1.128.12
Server:         10.1.128.12
Address:        10.1.128.12#53

Non-authoritative answer:
9.128.1.10.in-addr.arpa name = srv-test.

Authoritative answers can be found from:
10.in-addr.arpa nameserver = ns.domain.local.
10.in-addr.arpa nameserver = ns01.domain.local.
10.in-addr.arpa nameserver = ns02.domain.local.

 

 

Почему на 10.1.128.9 приходит авторитетный ответ, а на srv-test неавторитетный?

[Ivan_83]

forward-zone: name: "." forward-addr: 8.8.8.8 forward-addr: 8.8.4.4 forward-addr: 77.88.8.8 forward-addr: 77.88.8.1

Эпическое порно.

Весь рекурсер нахер не нужен с такой настройкой.

 

В примерах же есть:

# forward-zone:

# name: "example.com"

# forward-addr: 192.0.2.73@5355 # forward to port 5355.

[s.lobanov]

Эпическое порно.

Весь рекурсер нахер не нужен с такой настройкой.

 

Ну почему же... Например Мегафон даёт своим клиентам-операторам услугу фильтрации по реестру РКН через свой DNS, но при этом у них сделано так, чтобы ваши клиенты напрямую не пользовались их DNS-ом, а прописывают у себя в acl dns-сервер клиента-оператора