Настройте DNS-сервер в Debian 9
Мне нужна помощь в настройке 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
оказание услуг. Но когда я пытаюсь проверить днс с 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
Опять же, в соответствии с руководством, я ожидал другой РАЗДЕЛ ОТВЕТА с моим доменным именем в нем.
Итак, вы думаете, что это может быть неправильная конфигурация любого из этих файлов?
1 ответ
Хорошо, поэтому здесь задаются два вопроса.
В1: Почему я не вижу запись A для www.example.com?
Для этого есть две причины. Сначала вы не спрашивали о записи "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 необходима, если вы хотите просмотреть ее.
Q2: Почему я не вижу желаемый результат для моей записи PTR?
Мне нужно отредактировать этот ответ. Ответ, который вы получаете, кажется мне правильным, хотя это не то, что вы ожидали увидеть.
Изменить: я думал о "взломе CNAME", в котором ваш провайдер создает CNAME, указывая на поддомен и давая вам контроль над этим поддоменом. Но поскольку интернет-провайдер предоставляет запись PTR, я сначала связался бы с ними и попросил уточнить, как они хотят, чтобы вы настроили запись PTR для этого IP-адреса (если вам даже разрешено это делать).