Мне нужна помощь в настройке DNS-сервера в Debian 9 (Stretch). я следую этот учебник, но я думаю, что я что-то делаю не так ...
В моем случае мы предположим, что у меня есть домен с именем example.com, а IP-адрес моего сервера: 203.0.113.141
Прежде всего, я создал зоны в своем named.conf.local
файл. Теперь этот файл выглядит так:
zone "example.com" IN { // Domain name
type master; // Primary DNS
file "/etc/bind/fwd.example.com.db"; // Forward lookup file
allow-update { none; }; // Since this is the primary DNS, it
}; // should be none.
zone "141.ip-203-0-113.net" IN { // Reverse lookup name, it was given from my server provider
type master; // Primary DNS
file "/etc/bind/rev.example.com.db"; //Reverse lookup file
allow-update { none; }; //Since this is the primary DNS, it should be none.
};
После этого я создал оба файла с таким содержимым:
fwd.example.com.db:
$TTL 604800
@ IN SOA example.com. root.example.com. (
21 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
;Name Server Information
IN NS dns.example.com.
;IP address of Name Server
dns IN A 203.0.113.141
rev.example.com.db:
$TTL 604800
@ IN SOA example.com. root.example.com. (
21 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
;@ IN NS localhost.
;1.0.0 IN PTR localhost.
;Name Server Information
IN NS dns.example.com.
;Reverse lookup for Name Server
141 IN PTR dns
Бег named-checkconf
и named-checkzone
команды после настройки этих файлов дают мне правильный результат без ошибок.
Я также перезапустил bind9
служба. Но когда я пытаюсь проверить DNS с помощью dig
команда, ответ не такой, как ожидалось.
Команда dig example.com
выходы:
; <<>> DiG 9.10.3-P4-Debian <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53052
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; AUTHORITY SECTION:
example.com. 604800 IN SOA example.com. root.example.com. 21 604800 86400 2419200 604800
;; Query time: 0 msec
;; SERVER: 203.0.113.141#53(203.0.113.141)
;; WHEN: Sat Sep 01 09:05:29 EDT 2018
;; MSG SIZE rcvd: 81
Согласно руководству, которому я следовал, я ожидал строку вроде:
;; ANSWER SECTION:
www.example.com. 604800 IN A 203.0.113.141
Но в этом выводе его нет.
Кроме того, когда я проверяю обратный поиск с помощью dig -x 203.0.113.141
, вывод не показывает ничего, связанного с моим доменом example.com:
; <<>> DiG 9.10.3-P4-Debian <<>> -x 203.0.113.141
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42358
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;141.113.0.203.in-addr.arpa. IN PTR
;; ANSWER SECTION:
141.113.0.203.in-addr.arpa. 86400 IN PTR 141.ip-203-0-113.net.
;; AUTHORITY SECTION:
0.203.in-addr.arpa. 66624 IN NS ns10.ovh.ca.
0.203.in-addr.arpa. 66624 IN NS dns10.ovh.ca.
;; Query time: 893 msec
;; SERVER: 54.39.21.141#53(54.39.21.141)
;; WHEN: Sat Sep 01 09:12:51 EDT 2018
;; MSG SIZE rcvd: 132
Опять же, согласно руководству, я ожидал другого ОТВЕТА с моим доменным именем в нем.
Итак, как вы думаете, могла ли быть некорректная конфигурация любого из этих файлов?
Хорошо, поэтому здесь задаются два вопроса.
На то есть две причины. Сначала вы не запрашивали A-запись для «www.example.com»; во-вторых, вы не определили такую запись. В вашем файле прямой зоны вы должны добавить следующую строку,
www IN A 203.0.113.141
а затем запросите эту запись с помощью dig www.example.com
.
Я предполагаю, что вы также хотите, чтобы «example.com» и «www.example.com» указывали на один и тот же веб-сервер, и в этом случае вам также необходимо добавить запись A для самой вершины (домена). Для этого вы должны добавить эту строку:
example.com. IN A 203.0.113.141
У вас уже есть NS и запись SOA для этой вершины, но запись A необходима, если вы также хотите перейти к ней.
Мне нужно отредактировать этот ответ. Полученный вами ответ кажется мне правильным, хотя это не то, что вы ожидали увидеть.
Изменить: я думал о «взломе CNAME», в котором ваш интернет-провайдер создает CNAME, указывающую на субдомен и предоставляющую вам контроль над этим субдоменом. Но поскольку интернет-провайдер предоставляет запись PTR, я бы сначала связался с ним и попросил подробностей о том, как они хотят, чтобы вы настроили запись PTR для этого IP-адреса (если вам вообще разрешено это делать).