Jump to content
Калькуляторы

Авторитетные ответы для Unbound

Я как-то задавал подобный вопрос с год назад, но на форуме решить его не удалось. Задавал вопрос и в майл-листах, там тоже без ответа. Тогда это было несущественно, но теперь возникла необходимость в авторитетных ответах.

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

В мане написано, что для local-zone для данных, указанных в local-data, дается авторитетный ответ. Это у меня работает, но такое меня не устраивает, поскольку приходится всю зону прописывать.

В мане также сказано, что для более сложных случаев можно использовать stub-zone, где тоже дается авторитетный ответ. Но как я только не пробовал, ответ не авторитетный.

Не подскажите, как добиться авторитетного ответа?

Share this post


Link to post
Share on other sites

не ну как бы анбаунд вообще ниразу не авторитарный

а так, только локал-дата, единственный случай когда он дает авторитарный ответ

 

и да, даже не поленился открыл ман по анбаунду

 Stub Zone Options
  	There may be multiple stub-zone: clauses. Each with a name: and zero or
  	more hostnames or IP addresses.  For the stub zone this list  of  name-
  	servers  is used. Class IN is assumed.  The servers should be authority
  	servers, not  recursors;  unbound  performs  the  recursive  processing
  	itself for stub zones.

  	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
  	There may be multiple stub-zone: clauses. Each with a name: and zero or
  	more hostnames or IP addresses.  For the stub zone this list  of  name-
  	servers  is used. Class IN is assumed.  The servers should be authority
  	servers, not  recursors;  unbound  performs  the  recursive  processing
  	itself for stub zones.

  	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.

  	This  setup  allows DNSSEC signed zones to be served by that authorita-
  	tive server, in which case a trusted key entry with the public key  can
  	be  put in config, so that unbound can validate the data and set the AD
  	bit on replies for the private zone (authoritative servers do  not  set
  	the AD bit).  This setup makes unbound capable of answering queries for
  	the private zone, and can even set the AD bit ('authentic'), but the AA
       ('authoritative') bit is not set on these replies.

 

but the AA ('authoritative') bit is not set on these replies.

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

Я имею ввиду это:

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.

А мне как раз и нужны more complicated authoritative data.

Share this post


Link to post
Share on other sites

Полдня гуглил.

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

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

Share this post


Link to post
Share on other sites

Я уже писал ранее.

NSD у меня есть.

У меня на одном сервере работают NSD (на порту 5353) и Unbound (на порту 53); для Unbound добавлены stub-зоны с переадресацией на @5353.

Также на файрволе настроена переадресация с порта 5353 на порт 53 для обращений из внешних сетей.

То есть снаружи DNS-запросы попадают на авторитетный NSD (с запрещенной рекурсией), а изнутри клиентские DNS-запросы попадают на Unbound.

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

И до недавних пор все были счастливы. Но недавно завелся абонент по выделенной линии (ЮЛ) со своим почтовым сервером, у которого антиспам требует авторитетных ответов.

Share this post


Link to post
Share on other sites

ну так пусть свой нс подымают, и получают авторитарные ответы

или пустите в обход заворота прямиком на нсд

Share this post


Link to post
Share on other sites

А зечем Вам обязательно ресолвер для клиентов и NS на 1 IP ? IP адресов настолько мало ? оставьте тут только unbound, а nsd повесьте рядом на 53 порт и не мучте их :)

 

для NSов запоминающихся IP иметь вовсе не обязательно. они нужны 1 раз при регистрации домена.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this