DNS сервер

[Student00]

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

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

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

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

;
; BIND reverse data file for 192.168.100.XXX net
;
$TTL 604800
100.168.192.in-addr.arpa. IN SOA ns.debian. root.ns.debian. (
2135 ; Serial
604800 ; Refresh time
86400 ; Retry time
2419200 ; Expire time
604800 ) ; Negative Cache TTL
;
100.168.192.in-addr.arpa. IN NS ns.debian.
4 IN PTR ns.debian.



Работает:
root@ns:~# nslookup 192.168.100.4
Server: 192.168.100.4
Address: 192.168.100.4#53
4.100.168.192.in-addr.arpa name = ns.debian.
root@ns:~#

3.По той же инструкции настраивал и зону прямого просмотра:
;
; BIND data file for ns.debian.
;
$TTL 604800
@ IN SOA ns.debian. root.ns.debian. (
2148 ; Serial
604800 ; Refresh time
86400 ; Retry time
2419200 ; Expire time
604800 ) ; Negative Cache TTL
IN 192.168.100.4
;
@ IN NS ns.debian.
@ IN A 192.168.100.4
@ IN AAAA ::ns.debian


root@ns:~# nslookup ns.debian
Server: 192.168.100.4
Address: 192.168.100.4#53
** server can't find ns.debian: SERVFAIL
root@ns:~#
Какая-то фигня:
** server can't find ns.debian: SERVFAIL

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

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

[nokogerra]

@ указывает на директиву $ORIGIN, но ее не видно в вашей зоне.
пример куска зоны реального авторитетного ns (с измененным именем зоны):

$ORIGIN myzone.ru.
$TTL 1h
@ IN SOA ns2.myzone.ru. support.myzone.ru. (
2015042701
2h
30m
3d
15m
)
IN NS ns1.myzone.ru.
IN NS ns2.myzone.ru.



табуляция вместо имени записи означает, что наследуется имя предыдущей записи.
Таким образом имя записи 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 всегда.

[nokogerra]

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

PS C:\Users\kagerro> nslookup -type=soa oszone.net
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
oszone.net
primary name server = ns1.nameself.com
responsible mail addr = support.regtime.net
serial = 1471158665
refresh = 10800 (3 hours)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 10800 (3 hours)

oszone.net nameserver = ns1.nameself.com
oszone.net nameserver = ns2.nameself.com
ns1.nameself.com internet address = 81.176.95.18
ns1.nameself.com internet address = 87.242.73.100
ns1.nameself.com AAAA IPv6 address = 2001:1bb0:e000:15::7
ns2.nameself.com internet address = 77.221.159.237
ns2.nameself.com internet address = 88.212.207.45
ns2.nameself.com AAAA IPv6 address = 2a00:15f8:c001:3::209
PS C:\Users\kagerro> nslookup -type=a oszone.net
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
╚ь*: oszone.net
Address: 89.108.118.149

PS C:\Users\kagerro> nslookup -type=mx oszone.net
╤хЁтхЁ: google-public-dns-a.google.com
Address: 8.8.8.8

Не заслуживающий доверия ответ:
oszone.net MX preference = 0, mail exchanger = mail.oszone.net

oszone.net nameserver = ns2.nameself.com
oszone.net nameserver = ns1.nameself.com
ns1.nameself.com internet address = 87.242.73.100
ns1.nameself.com internet address = 81.176.95.18
ns1.nameself.com AAAA IPv6 address = 2001:1bb0:e000:15::7
ns2.nameself.com internet address = 77.221.159.237
ns2.nameself.com internet address = 88.212.207.45
ns2.nameself.com AAAA IPv6 address = 2a00:15f8:c001:3::209

вот например 3 RR с именем зоны, в том числе A.

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

[Student00]

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

табуляция вместо имени записи означает, что наследуется имя предыдущей записи.
Таким образом имя записи 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 всегда. »

При таком конфиге:
;
; BIND data file for local loopback interface
;
$ORIGIN ns.debian
$TTL 604800
@ IN SOA ns.debian. root.ns.debian. (
1323 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN A 192.168.100.4
;
@ IN NS ns.debian.
@ IN A 192.168.100.4
@ IN AAAA ::1
ns.debian IN A 192.168.100.4

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.

[nokogerra]

А ведь нет.
Эксперимента ради оставил зону SOA как она есть, а
остальное изменил:
100.168.192.in-addr.arpa. IN NS ns.0debian.
4 IN PTR ns.0debian.
И выдача на запрос IP
ns.0debian. »
не совсем понял сути эксперимента. я сказал, что эта зона работает корректно, в отличие от прямой зоны, потому, что в качестве имени SOA RR было корректно указано имя зоны, т.е. "100.168.192.in-addr.arpa.", а в прямой вы имя не указали, а указали "@", но, как я писал выше, @ наследует имя зоны только из явно указанного $ORIGIN. Попробуйте в реверс зоне без явно заданной $ORIGIN указать в качестве имени SOA не "100.168.192.in-addr.arpa.", а "@" и посмотрите что будет.

** server can't find ns.debian: NXDOMAIN
И пинг ns.debian отсутствует. »
fqdn закрываются точкой, в вашей $ORIGIN точки нет:
$ORIGIN ns.debian »

[Student00]

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

Ресурсная запись для прямой зоны ns.debian остается как есть:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.debian. root.ns.debian. (
1323 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN A 192.168.100.4
;
@ IN NS ns.debian.
@ IN A 192.168.100.4
@ IN AAAA ::1



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

Итого:
root@ns:~# nslookup ns.debian
Server: 192.168.100.4
Address: 192.168.100.4#53

Name: ns.debian
Address: 192.168.100.4

root@ns:~# ping ns.debian
PING ns.debian (192.168.100.4) 56(84) bytes of data.
64 bytes from ns.debian (192.168.100.4): icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from ns.debian (192.168.100.4): icmp_seq=2 ttl=64 time=0.094 ms
^C
--- ns.debian ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.094/0.102/0.111/0.013 ms
root@ns:~#


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

[nokogerra]

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

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