Я установил предварительно настроенную систему с панелью ISPConfig на сервере VPS. Когда я создаю зоны DNS и настраиваю их, сервер какое-то время работает, потом какое-то время таймауты и глобальные DNS (например, 8.8.8.8) теряют записи и домен в недоступном (не удалось найти сервер).
Порты открыты. Пока есть тайм-аут на DNS-сервере (который работает, я проверил), я могу без проблем подключиться к порту 53 через telnet.
ОС: Centos 6, BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4
Когда я запрашиваю сервер с dig ANY dekorate.pl @5.133.13.32 у меня тайм-аут. И через некоторое время нормально заработает.
named-checkconf /var/ named/pri.dekorate.pl
/var/named/pri.dekorate.pl:1: unknown option '$TTL'
/var/named/pri.dekorate.pl:3: unknown option 'serial,'
/var/named/pri.dekorate.pl:4: unknown option 'refresh,'
/var/named/pri.dekorate.pl:5: unknown option 'retry,'
/var/named/pri.dekorate.pl:6: unknown option 'expire,'
/var/named/pri.dekorate.pl:7: unknown option 'minimum,'
/var/named/pri.dekorate.pl:10: unknown option '*'
/var/named/pri.dekorate.pl:20: unexpected token near end of file
Файл конфигурации, созданный ISPConfig.
$TTL 3600
@ IN SOA ns1.dekorate.pl. admin.dekorate.pl. (
2015040604 ; serial, todays date + todays serial #
7200 ; refresh, seconds
540 ; retry, seconds
604800 ; expire, seconds
86400 ) ; minimum, seconds
;
* 86400 A 5.133.13.32
dekorate.pl. 3600 A 5.133.13.32
dekorate.pl. 3600 MX 10 mail.dekorate.pl.
dekorate.pl. 3600 NS ns1.dekorate.pl.
dekorate.pl. 3600 NS ns2.dekorate.pl.
mail 3600 A 5.133.13.32
ns1 86400 A 5.133.13.32
ns2 86400 A 5.133.13.32
www 3600 A 5.133.13.32
Примечание: на панели регистратора доменов я делегировал домен на ns1.dokrate.pl и ns2.dekorate.pl с заполнением IP адреса
ОБНОВИТЬ
В данный момент он снова перестал работать. Я сделал (на своей локальной машине):
nc -u -z -v 5.133.13.32 53
Connection to 5.133.13.32 53 port [udp/domain] succeeded!
и:
dig ANY dekorate.pl @5.133.13.32
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @5.133.13.32
;; global options: printcmd
;; connection timed out; no servers could be reached
и на сервере я сделал:
dig ANY dekorate.pl @localhost
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> ANY dekorate.pl @localhos t
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;dekorate.pl. IN ANY
;; ANSWER SECTION:
dekorate.pl. 3600 IN A 5.133.13.32
dekorate.pl. 3600 IN MX 10 mail.dekorate.pl.
dekorate.pl. 3600 IN NS ns2.dekorate.pl.
dekorate.pl. 3600 IN NS ns1.dekorate.pl.
dekorate.pl. 3600 IN SOA ns1.dekorate.pl. admin.dekorate. pl. 2015040604 7200 540 604800 86400
;; ADDITIONAL SECTION:
mail.dekorate.pl. 3600 IN A 5.133.13.32
ns1.dekorate.pl. 86400 IN A 5.133.13.32
ns2.dekorate.pl. 86400 IN A 5.133.13.32
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 6 17:23:53 2015
;; MSG SIZE rcvd: 192
Когда бы это ни случилось. DNS-серверы Google теряют способность разрешать это.
dig ANY dekorate.pl @8.8.8.8
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @8.8.8.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29463
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;dekorate.pl. IN ANY
;; Query time: 3081 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 6 15:28:47 2015
;; MSG SIZE rcvd: 29
Во-первых, в настоящее время я не могу воспроизвести проблему.
Я не уверен, действительно ли что-либо из этого отвечает на вопрос (я не уверен, что это действительно четкий вопрос), но вот мой взгляд на то, что было представлено:
named-checkzone подходит ли инструмент для тестирование файла зоны (named-checkconf для указанного файла конфигурации).
У вас должно быть более одного сервера имен. Я предполагаю, что у вашего регистратора было правило, которое вы обошли, сделав два NS записи (ns{1,2}.dekorate.pl), но поскольку они обращаются к одному и тому же адресу, вы действительно только что нашли способ обойти их соблюдение политики, вместо того, чтобы принять норму наличия нескольких серверов имен (как можно более разных) для повышения надежности.
DNS в основном использует UDP, а не TCP. Ваш тест с telnet использует TCP, что актуально только для некоторых крайних случаев. (Чтобы на самом деле сделать тест DNS, который соответствует telnet с точки зрения подключения вы могли бы сделать dig +tcp ....)
Попробовав пример запроса, я заметил, что вы, похоже, разрешаете запросы на рекурсию от всех. Это очень плохая идея что практически вызывает злоупотребления.
В общем, вы действительно готовы запускать собственные серверы имен?
Если ваша настоящая цель - что-то еще, возможно, лучше не запускать дополнительную инфраструктуру самостоятельно, если это действительно не необходимо.
Беги к этому я. Запись DNS не обновлялась независимо от количества изменений в ISPconfig. Решение было довольно простым. Если вы ошиблись в настройке зоны, привязка произведет .err файл в папке / etc / bind. Он будет содержать ваши «новые» настройки зоны, но старые настройки останутся до тех пор, пока ошибка останется в вашей конфигурации. В моем случае это было неисправно SRV запись. После его удаления ispconfig / bind использовал правильный файл конфигурации вместо старого.
После некоторого исследования с интернет-провайдером выяснилось, что ответ на эту загадку: нас поймали из-за ограничения UDP-соединения, установленного для IP. Лимит снят и все работает.