Хорошо, у меня проблема, что мой обратный поиск не работает на моем dns bind9
#nslookup 172.16.0.179
Server: 127.0.1.1
Address: 127.0.1.1#53
** server can't find 179.0.16.172.in-addr.arpa: NXDOMAIN
Вот моя обратная зона:
# nano /var/lib/bind/mosek.intranet.rev.zone
$ORIGIN .
$TTL 604800 ; 1 week
172.16.0.in-addr.arpa IN SOA braintree.mosek.intranet. admin.mosek.com. (
79 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS braintree.mosek.intranet.
$ORIGIN 0.16.172.172.16.0.in-addr.arpa.
$TTL 3600 ; 1 hour
179 PTR harbinger.mosek.intranet.
Запись PTR - это что-то автоматически сгенерированное bind9
и вот мой /etc/bind/ named.conf.local
//
// Do any local configuration here
//
include "/etc/bind/rndc.key";
zone "mosek.intranet" {
type master;
file "/var/lib/bind/mosek.intranet.zone";
allow-update {key rndc-key; };
};
zone "172.16.0.in-addr.arpa"{
type master;
file "/var/lib/bind/mosek.intranet.rev.zone";
allow-update {key rndc-key; };
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
как я вижу, все выглядит нормально. что могло вызвать проблему?
У меня все заработало, вот рабочая конфигурация:
# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//
include "/etc/bind/rndc.key";
zone "mosek.intranet" {
type master;
file "/var/lib/bind/mosek.intranet.zone";
allow-update {key rndc-key; };
};
zone "0.16.172.in-addr.arpa"{
type master;
file "/var/lib/bind/mosek.intranet.rev.zone";
allow-update {key rndc-key; };
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
.
# cat /var/lib/bind/mosek.intranet.rev.zone
$ORIGIN .
$TTL 604800 ; 1 week
0.16.172.in-addr.arpa IN SOA braintree.mosek.intranet. admin.mosek.com. (
79 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS braintree.mosek.intranet. $
$ORIGIN 0.16.172.in-addr.arpa.
$TTL 604800 ; 1 week
179 PTR harbinger.mosek.intranet.
При указании записей PTR с помощью in-addr.arpa
domain, наименее значимая часть сетевого IP-адреса должна стоять перед остальными частями, то есть в обратном порядке по сравнению с обычным способом указания IP-адресов в десятичной системе с точками.
Из Статья в Википедии об обратном поиске DNS
Обратный поиск в DNS для адресов IPv4 использует обратную запись IN-ADDR в специальном домене in-addr.arpa. В этом домене IPv4-адрес представлен в виде объединенной последовательности из четырех десятичных чисел, разделенных точками, к которой добавляется суффикс домена второго уровня .in-addr.arpa. Четыре десятичных числа получаются путем разделения 32-битного адреса IPv4 на четыре 8-битных части и преобразования каждой 8-битной части в десятичное число. Затем эти десятичные числа объединяются в следующем порядке: сначала младшая 8-битная часть (крайняя слева), самая значимая 8-битная часть последняя (крайняя правая). Важно отметить, что это порядок, обратный обычному десятичному соглашению, разделенному точками, для записи адресов IPv4 в текстовой форме.
В твоем случае, 172.16.0.in-addr.arpa
следует переписать на все ваши файлы конфигурации BIND как 0.16.172.in-addr.arpa
. Например, вот как должен выглядеть файл зоны:
$ORIGIN .
$TTL 604800 ; 1 week
0.16.172.in-addr.arpa IN SOA braintree.mosek.intranet. admin.mosek.com. (
79 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS braintree.mosek.intranet.
$ORIGIN 0.16.172.in-addr.arpa
$TTL 3600 ; 1 hour
179 PTR harbinger.mosek.intranet