[alibek]

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

Для клиентского DNS в первую очередь нужен кеш, рекурсор не столь обязателен.

Я из документации исходил. Там написано, что для зон, описанных как local-zone, Unbound будет давать авторитетный ответ. А если для этих зон данных в local-data недостаточно, тогда нужно эти данные указывать в stub-zone.

Сейчас попробую форвард с корневой убрать, а свои зоны переделать в forward.

[alibek]

Сейчас попробую форвард с корневой убрать, а свои зоны переделать в forward.

То же самое.

 

server:
       private-address: 10.0.0.0/8
       private-domain: "domain.local"
       local-zone: "10.in-addr.arpa."  nodefault
       local-zone: "domain.local."     nodefault
forward-zone:
       name: "domain.local."
       forward-addr: 10.1.128.12@5353
forward-zone:
       name: "10.in-addr.arpa."
       forward-addr: 10.1.128.12@5353

 

> srv-test.domain.local
╤хЁтхЁ:  srv-svc02
Address:  10.1.128.12

Не заслуживающий доверия ответ:
╚ь :     srv-test.domain.local
Address:  10.1.128.9

> 10.1.128.9
╤хЁтхЁ:  srv-svc02
Address:  10.1.128.12

╚ь :     srv-test
Address:  10.1.128.9

[alibek]

Нашет такое обсуждение, тема «serving stub-zones authoritatively».

Я так понял, что авторитетного ответа от Unbound мне не видать? Или с 2008 года все же были изменения, т.к. сейчас в документации говорится другое:

local-zone:

Configure a local zone. The type determines the answer to give if there is no match from local-data. The types are deny, refuse, static, transparent, redirect, nodefault, typetransparent, and are explained below. After that the default settings are listed. Use local-data: to enter data into the local zone. Answers for local zones are authoritative DNS answers. By default the zones are class IN.

If you need more complicated authoritative data, with referrals, wildcards, CNAME/DNAME support, or DNSSEC authoritative service, setup a stub-zone for it as detailed in the stub zone section below.

...

stub-zone:

The stub zone can be used to configure authoritative data to be used by the resolver that cannot be accessed using the public internet servers. This is useful for company-local data or private zones. Setup an authoritative server on a different host (or different port). Enter a config entry for unbound with stub-addr: <ip address of host[@port]>. The unbound resolver can then access the data, without referring to the public internet for it.

[Ivan_83]

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

Тогда там должен быть днс мегафона.

 

Для клиентского DNS в первую очередь нужен кеш, рекурсор не столь обязателен.

Зачем при этом указывать днс сервера левой конторы и сливать туда все клиентские запросы!?

Никто кроме гугла от этого не получает профита.

 

Я из документации исходил. Там написано, что для зон, описанных как local-zone, Unbound будет давать авторитетный ответ.

Увы, я не интересовался как сделать так чтобы в ответах был выставлен флаг AA.

[s.lobanov]

alibek (Вчера, 10:29) писал:

Я из документации исходил. Там написано, что для зон, описанных как local-zone, Unbound будет давать авторитетный ответ.

 

Увы, я не интересовался как сделать так чтобы в ответах был выставлен флаг AA.

 

Но самое главное. alibek, ачем это вообще надо? (выдавать флаг AA клиентам, которые тупо рекурсию от вас хотят)

[alibek]

Я бы хотел, чтобы для своей зоны ответы были авторитетными. В конце концов BIND так делает и в документации Unbound ведь указано, что так можно.

Большинству клиентов не нужно, согласен. Но например два клиента со своим почтовым сервером и проверкой зоны не смогут отправлять почту друг другу.

[s.lobanov]

Но например два клиента со своим почтовым сервером и проверкой зоны не смогут отправлять почту друг другу.

 

Так речь идёт о реальных зонах или о .local и прочем?

[alibek]

У меня они обе зоны держат.

Авторитетность нужна для реальных.

[st_re]

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

 

Зя.. dns/bind-tools

 

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

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

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

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

 

У вас катастрофическая нехватка IP что обязательно вешать на 1 IP и рекурсор (он же только для внутренних клиентов нужен вообще. Снаружи его проще закрыть фаерволом) и держатель зон, призваннй отвечать везде?

[alibek]

dns/bind-tools

А вот тут поискать не догадался. Искал в dnsutl и т.п.

 

У вас катастрофическая нехватка IP

Да нет, это больше удобство использования.

[st_re]

А

 

access-control: 0.0.0.0/0 refuse

 

не помешает дальнейшей жизни mydomain.ru в плане отдаваться наружу? В моем понимании помешает.. Или вся эта бадяга для внутреннего портребления? Я пока не встречал вариантов когда бы кешированый ответ был хуже авторитативного для клиента.

 

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

 

Я бы (в общем я так и делаю) повесил наружу nsd. А внутрь бы клиентам отдавал унбаунд. Форвард или стаб прописывается исключительно, чтобы если каналы наружу помрут смертью храбрых чтобы свои зоны всеравно отдавались. при живых каналах оно как бы и так отдастся нормально. Ну и для локальных доменов, про них снаружи спросить неукого.

[hsvt]

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

 

Зя.. dns/bind-tools

 

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

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

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

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

 

У вас катастрофическая нехватка IP что обязательно вешать на 1 IP и рекурсор (он же только для внутренних клиентов нужен вообще. Снаружи его проще закрыть фаерволом) и держатель зон, призваннй отвечать везде?

 

Всё равно тащит за собой bind

 

===> bind-tools-9.11.1P3 depends on file: /usr/local/sbin/pkg - found

=> bind-9.11.1-P3.tar.gz doesn't seem to exist in /usr/ports/distfiles/.

=> Attempting to fetch http://ftp.isc.org/isc/bind9/9.11.1-P3/bind-9.11.1-P3.tar.gz

bind-9.11.1-P3.tar.gz 12% of 9520 kB 320 kBps 00m20s^

 

Даже если убрать все флаги и опции make config

 

P.S. Хотя не, по факту поставил только то, что нужно)

 

===>  Cleaning for libxml2-2.9.4
===>  Cleaning for idnkit-1.0_6
===>  Cleaning for json-c-0.12.1
===>  Cleaning for autoconf-2.69_1
===>  Cleaning for autoconf-wrapper-20131203
===>  Cleaning for automake-1.15.1
===>  Cleaning for automake-wrapper-20131203
===>  Cleaning for libtool-2.4.6
===>  Cleaning for bind-tools-9.11.1P3

Изменено 1 августа, 2017 пользователем hsvt

[st_re]

ну да, бинд тулзы он собирает из исходников бинда.. откуда они их еще возьмет то ?

[hsvt]

Aug 10 14:04:32 unbound[75308:7] error: read (in tcp s): Permission denied for 10.10.219.13
Aug 10 14:04:32 unbound[75308:7] error: read (in tcp s): Permission denied for 10.10.219.13

 

Что это может быть за ругань? В acces листе разрешен доступ, do tcp включён.

[Ivan_83]

В acces листе разрешен доступ, do tcp включён.

Кажется там больше крутилок было.

[gruber]

А кто-нибудь знает, есть ли аналог директивы $GENERATE где-нибудь кроме BIND ?

 

[alibek]

Кажется нет.

Но в NSD есть $INCLUDE и мне это оказалось даже удобнее.

[gruber]

Ну это не совсем то, а точнее совсем не то :)

include и в BIND тоже есть, только смысл в том чтоб сгенерить одной командой например PTR записи для зоны.

Или я что-то недопонял ?

[alibek]

Я генерирую PTR-записи отдельным скриптом, в простой текстовый файл.

А в основной конфигурации делаю $include этого файла.

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