DNS сервер
 

Ребят, прошу, пожалуйста, консультации.

В общем, пользуясь инструкциями настраивал DNS сервер на debian 8.6

1. Настраивал кэшируюший - работает.

2. Настроил зону обратного просмотра:


Работает:
3.По той же инструкции настраивал и зону прямого просмотра:


Какая-то фигня:
** server can't find ns.debian: SERVFAIL

Что может быть не так?

P.S.
Догадка:
Может быть потому что ns.debian - это не домен, а всего лишь имя компьютера линукс поэтому он и выдает такое сообщение?

@ указывает на директиву $ORIGIN, но ее не видно в вашей зоне.
пример куска зоны реального авторитетного ns (с измененным именем зоны):
табуляция вместо имени записи означает, что наследуется имя предыдущей записи.
Таким образом имя записи SOA (@) указывает на $ORIGIN, табуляция в NS записи со значением "ns1.myzone.ru." указывает на то, что имя этой записи наследуется у @, табуляция в NS записи со значением "ns2.myzone.ru." указывает на то, что имя этой записи наследуется от предыдущей NS записи.

P.S. ну а реверс зона работает потому что вы указали имя зоны в качестве имени soa rr. Вообще штука в том, что $ORIGIN указывать не обязательно, точнее директива синтезируется из имени зоны, указанного в named.conf, но @ наследует имя из $ORIGIN только тогда, когда она указана явно, а не синтезирована. Если в моем примере не было бы $ORIGIN, и я указал бы не fqdn имя в качестве имени rr (не fqdn с точки зрения синтаксиса файла зоны это имя, которое не оканчивается точкой), например "vasya", то это имя было бы дополнено синтезированной строкой "myzone.ru.", просто потому, что эта строка указана в качестве имени зоны в named.conf. Но вот "@" в таком случае я бы использовать не мог, т.е. имя зоны в SOA нужно было бы указывать явно.

Короче, указывать $ORIGIN это хорошая практика, и если у вас нет адекватных причин не делать этого, то указывайте $ORIGIN всегда.

а это вполне нормальная ситуация, RR с именем зоны просто является записью на вершине зоны, это может быть и A запись:
вот например 3 RR с именем зоны, в том числе A.

P.S. CNAME не может быть записью на вершине зоны.

А ведь нет.
Эксперимента ради оставил зону SOA как она есть, а
остальное изменил:
100.168.192.in-addr.arpa. IN NS ns.0debian.
4 IN PTR ns.0debian.
И выдача на запрос IP
ns.0debian.
:)

При таком конфиге:
root@ns:~# nslookup ns.debian
Server: 192.168.100.4
Address: 192.168.100.4#53

** server can't find ns.debian: NXDOMAIN

И пинг ns.debian отсутствует.

Я когда настраивал DNS на WinServer, то пинговал и доменное имя и ip.

не совсем понял сути эксперимента. я сказал, что эта зона работает корректно, в отличие от прямой зоны, потому, что в качестве имени SOA RR было корректно указано имя зоны, т.е. "100.168.192.in-addr.arpa.", а в прямой вы имя не указали, а указали "@", но, как я писал выше, @ наследует имя зоны только из явно указанного $ORIGIN. Попробуйте в реверс зоне без явно заданной $ORIGIN указать в качестве имени SOA не "100.168.192.in-addr.arpa.", а "@" и посмотрите что будет.

fqdn закрываются точкой, в вашей $ORIGIN точки нет:

А ларчик-то просто открывался.

Ресурсная запись для прямой зоны ns.debian остается как есть:
А вот в файле /etc/bind/named.conf.local
зону-то я не правильно определил:
zone "ns ns.debian" {
type master;
file "/etc/bind/db.ns.debian";
};

Итого:
Но все равно, спасибо за советы.
Тем более, узнал. что есть такая директиву $ORIGIN.
:)

Ну, я не предполагал, что зона в named.conf определена не верно.
Как бы там ни было, странно, что символ @ без явно указанной $ORIGIN работает, вся документация говорит о том, что @ не может ссылаться на синтезированную $ORIGIN, хотя я и не пробовал, т.к. всегда использовал эту директиву.

Для чистоты эксперимента, я бы попробовал добавить еще одну зону в bind, скажем "lala.local", создал бы еще один файл зоны, ну и в SOA и NS указал бы ns.debian в качестве авторитетного сервера, при этом использовал бы @ без $ORIGIN.