Перейти к содержимому
Калькуляторы

А посоветуйте DNS-сервер на FreeBSD

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Или пофиг?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PowerDNS?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понятно.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Осваиваю 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. Как мне его настроить, чтобы они работали вместе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Есть 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 у меня определены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

# 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 неавторитетный?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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