Устранение распространенных ошибок конфигурации DNS

DNS (система доменных имен) может быть незнакома большинству людей, использующих Интернет, но это настоящая невидимая сила, управляющая Интернетом, без которой все бы видели только числа и IP-адреса. Все значение доменных имен существует сегодня только благодаря DNS.

Введение

Самый простой способ объяснить DNS в одном предложении - это сопоставление доменного имени с IP-адресом. Я не уверен, сколько людей знает, что когда кто-то вводит доменное имя в IE/Firefox, браузер отправляет DNS-запрос, запрашивая IP-адрес у резолвера провайдера ISP (поставщика интернет-услуг), и резолвер обращается к корневым серверам, а затем систематически получает IP-адрес за считанные миллисекунды.

Понимание DNS и его работы - одна из самых сложных тем в компьютерной инженерии, и даже самые опытные сетевые администраторы сталкиваются с трудностями, когда дело доходит до написания файлов зон DNS.

Прежде чем я продолжу с этой статьей, следующие моменты являются САМОЙ ВАЖНОЙ информацией, которую вы должны помнить, иначе вы не поймете ничего.

Важные моменты для запоминания

Запись A всегда должна содержать IP-адрес (сопоставление хоста с IP)

Когда вы указываете запись A, она должна содержать IP-адрес с правой стороны. Запись A так важна в DNS, без нее значение сопоставления имен хостов с IP было бы абсурдным. Так что запомните это!

CNAME (псевдоним) должен содержать имена хостов. Здесь нет IP.
Записи NS и MX должны содержать имена хостов. IP не допускаются.
Используйте ТОЧКУ в конце, когда вы указываете доменное имя в файле зоны DNS. Эта ТОЧКА так важна, и если вы забудете ее, вам будут сниться кошмары с вашей конфигурацией DNS.

Например

example.com. IN NS ns1.example.com.

Почему ТОЧКА? Просто потому, что она указывает на начало запроса с корневых серверов (обозначенных точкой)

Записи MX (для почтовых серверов) должны содержать имена хостов, а не IP.

Общие термины DNS и их значения

(i) Записи Glue

Записи Glue - это записи A, которые связаны с записями NS, чтобы предоставить “информацию о начальной загрузке” для имен серверов записей NS. (см. RFC 1912, раздел 2.3)

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 11.33.55.77
ns2 IN A 22.44.66.88

В приведенном выше примере мы сопоставляем каждую запись NS с IP-адресом (запись A), таким образом связывая именованные серверы с IP (то есть “склеивая” их).

(ii) Делегирование LAME Nameserver

Сервер имен, который дает неавторитетный ответ, обычно называется ‘LAME’. Каждый домен должен иметь как минимум 2 сервера имен, и если я спрошу каждый из них, и если у них есть информация о зоне домена, я получу авторитетный ответ. Если нет, это “плохая делегация”. Смотрите RFC 1912, раздел 2.8.

Пример плохой делегации:

domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net

ns1.domain.com настроен на наличие информации о зоне домена, но ns2.exserver.net не был настроен должным образом и не имеет никакой информации о домене. Таким образом, ns1 ответит авторитетно, тогда как ns2 не ответит, что будет “плохим” до тех пор, пока он не будет правильно настроен.

Чтобы получить более глубокое понимание, давайте используем инструмент dig для example.com.

Сначала мы находим серверы имен example.com:

 dig example.com NS

;; СЕКЦИЯ ОТВЕТА:
example.com. 158240 IN NS a.iana-servers.net.
example.com. 158240 IN NS b.iana-servers.net.

Поскольку мы получили 2 сервера имен, мы спрашиваем каждый из них, дают ли они авторитетный ответ. Если это авторитетный ответ, флаг ‘aa’ в заголовке будет установлен в полученном ответе (‘aa’ - это авторитетный ответ).

dig @b.iana-servers.net example.com NS
dig @a.iana-servers.net example.com NS

;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; СЕКЦИЯ ВОПРОСА:
;example.com. IN NS

;; СЕКЦИЯ ОТВЕТА:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Посмотрите на флаги.

flags: qr aa rd

Поскольку ‘aa’ установлен в ответе, оба сервера имен example.com предоставляют авторитетный ответ. Если это плохая делегация, вы не получите авторитетного ответа.

ОСТОРОЖНО:

Вы не должны использовать CNAME (псевдоним) вместе с записями NS, и это часто сбивает с толку большинство резолверов, вызывая циклы и часто приводя к “плохой” делегации.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net

Так что никогда не используйте CNAME вместе с записями NS.

(iii) Скрытые серверы имен

Скрытые серверы имен (или скрытые серверы имен) - это несовпадающие/конфликтующие серверы имен, которые существуют на корневом уровне против серверов имен в домене.

Чтобы проиллюстрировать это, когда я спрашиваю родительские серверы о вашем домене для записей NS на корневом уровне, я получаю

ns0.domain.com
ns2.domain.com
ns3.domain.com

но когда я запрашиваю серверы имен вашего домена для записей NS, они не совпадают и выглядят так:

ns0.domain.com
ns2.domain.com
ns.example-dns.net

Поскольку ns.example-dns.net и ns3.domain.com скрыты, оба являются “скрытыми серверами имен”. Хотя в этом нет ничего плохого, рекомендуется не иметь никаких скрытых серверов имен как на корневом уровне, так и на вашем DNS-сервере.

Вы можете использовать команду dig для поиска записей NS на уровне корневого сервера.

 dig +trace @K.root-servers.net example.com NS

и чтобы спросить один из серверов имен домена.

 dig @ns0.domain.com example.com NS

Ищите любые несовпадения NS между двумя запросами. Если на корневом уровне отсутствует сервер имен, добавьте отсутствующий сервер имен к вашему регистратору доменов. Если сервер имен отсутствует на уровне домена, добавьте сервер имен в файл зоны домена и обновите все ваши вторичные серверы имен.

(iv) Открытый DNS-сервер

Запуск DNS-сервера “открытым” представляет собой большой риск безопасности, поскольку он отвечает на рекурсивные запросы как изнутри, так и снаружи вашей сети. Это означает, что любой может запрашивать ваш сервер для получения IP-адреса, и ваш DNS-сервер ответит им.

Чтобы проиллюстрировать это, у нас есть два сервера имен, работающих на bind для домена example.com.

ns1.example.com
ns2.example.com

Мы спрашиваем ns1.example, чтобы разрешить внешний домен google.com, и если мы получаем IP-адрес (запись A) в секции ответа, это означает, что это “открытый DNS-сервер“.

dig @ns1.example.com google.com  
dig @ns2.example.com google.com

;; глобальные параметры: printcmd
;; Получен ответ:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; СЕКЦИЯ ВОПРОСА:
;google.com. IN A

;; Время запроса: 32 мс

Поскольку нет секции ОТВЕТА или IP-адреса, оба сервера имен не составляют открытый DNS-сервер.

Если вы используете bind8 или более позднюю версию, все, что вам нужно сделать, это установить ‘recursion no’ в параметрах, чтобы отключить ответ DNS-сервера на рекурсивные запросы.

options {
….
recursion no;
}

(v) Передача зон (запрос AXFR)

Передачи зон выполняются вторичными серверами имен для получения последней и обновленной информации о зоне для домена от основного или первичного сервера имен. Передачи зон должны быть доступны только вторичным серверам имен и не должны быть открыты миру, так как это большой риск безопасности и может раскрыть внутренние данные вашей сети злоумышленнику.

Чтобы запросить передачу зоны для example.com, нам нужно сначала спросить основной сервер имен. Смотрите пример ниже с помощью dig.

 dig @ns1.example.com example.com

Если вы видите вывод с полным файлом зоны, вам нужно отключить передачу зоны. В большинстве случаев вы увидите сообщение о сбое соединения или ОТКАЗ, что означает, что передача зоны не разрешена, и это хорошо.

Общие ошибки DNS при написании файла зоны

1. Нет CNAME, указывающего на записи NS

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net —–> Неверно

Размещение CNAME вместе с NS приведет к сбою всех серверов имен и приведет к плохой делегации. Не делайте этого!

Смотрите RFC1912 2.4 и RFC2181 10.3.

2. Избегайте запуска DNS-серверов на IP-адресах в одной подсети (/24) или на одном сервере.

Вся цель DNS заключается в том, чтобы серверы имен были распределены по различным географическим местоположениям, чтобы если один DNS выйдет из строя, другой продолжал работать. Хотя очень распространенной практикой является запуск обоих серверов имен на одном сервере или в одной подсети, это не обеспечит отказоустойчивость. Если сервер выйдет из строя, ваши серверы имен выйдут из строя, и ваш сайт не загрузится.

ns1 IN A 75.33.22.xx —–> одна подсеть /24
ns2 IN A 75.33.22.xx —–> одна подсеть /24

3. Правильный GLUE

Всегда добавляйте glue к вашим записям NS к IP-адресам, используя запись A, в противном случае один из ваших серверов имен выйдет из строя.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 —–> GLUE
ns2 IN A 2.4.6.9 —–> GLUE

Смотрите RFC1912.

4. Нет дублирующихся записей MX

domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com —-> Дубликат

5. Разрешите порт 53 для соединений как UDP, так и TCP

Если вы используете брандмауэр, убедитесь, что вы не блокируете порт 53 для DNS tcp и udp запросов. По умолчанию DNS-запросы используют протокол UDP, в то время как передачи зон и уведомления используют TCP-протокол порта 53.

Порт 53 UDP = DNS-запросы
Порт 53 TCP = Передачи зон

6. CNAME не может сосуществовать с MX-хостами.

Не указывайте CNAME или псевдонимы, указывающие на записи MX.

domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ———-> Неверно

Вместо этого используйте запись A для прямого сопоставления с IP-адресом.

mail IN A 11.33.55.77 —> Верно

Смотрите RFC1912.

7. Записи MX не должны содержать IP-адреса

domain.com. IN 10 MX mail.domain.com. —-> Верно
domain.com. IN 20 MX 11.22.33.44 —–> Неверно

Правильный способ сделать это - склеить хост mx с записью A.

domain.com. IN MX 10 mail.domain.com. —–> Верно
mail IN A 11.33.55.77 ———-> Верно

8. Записи NS не должны содержать IP-адреса

Всегда указывайте серверы имен для вашего домена с записями NS. Это должно быть имя, а не IP-адрес.

domain.com. IN NS dns0.domain.com. —–> Верно
domain.com. IN NS 75.xx.xx.xx ———–> Неверно

ОБРАТНЫЙ DNS ДЛЯ ДОСТАВКИ ПОЧТЫ

Для правильной доставки почты следующие методы борьбы со спамом очень важны, чтобы убедиться, что электронная почта доставляется в папку “Входящие” пользователей. Большинство публичных провайдеров электронной почты, таких как yahoo, hotmail и gmail, используют эти параметры, чтобы пометить электронную почту как спам или нет.

(i) Настройка обратного IP для вашего почтового сервера с PTR в DNS (нужен выделенный IP)
(ii) Настройка SPF-записи в вашем DNS
(iii) Настройка доменных ключей

Я видел во многих случаях, если вы используете план совместного хостинга, большинство электронных писем попадают в папку “Спам/Рассылка” в папке “Входящие” пользователей. Поэтому используйте выделенный сервер.

Настройка обратных IP для IP-адресов почтового сервера

Чтобы настроить обратный IP, сначала вам нужно будет подать запрос вашему хостинг-провайдеру (поскольку они владеют IP-адресом) и попросить их настроить обратный IP для вашего почтового сервера. После этого вам нужно будет добавить строку с использованием PTR в файл зоны вашего домена.

Чтобы протестировать обратный поиск IP:

 host

покажет вывод обратного DNS.

Настройка SPF-записи

SPF-запись настраивается с использованием TXT-записи в вашем файле зоны DNS. Она выглядит так, как показано ниже. Посетите http://openspf.org для получения дополнительной информации о настройке и конфигурации.

domain.com. IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”

Чтобы запросить SPF-запись с помощью dig:

 dig domain.com TXT

Доменные ключи

Она в основном содержит 2 записи (с селектором и без него), размещенные под TXT с использованием подчеркивания вместе с сгенерированным открытым ключом.

‘сel’ - это селектор и может быть именем селектора.

Как настроить DNS-серверы имен для вашего домена с использованием BIND9

Просто перейдите в свою консоль Linux и введите следующие команды.

yum install bind

Создайте новый файл зоны для вашего домена и вставьте пример файла зоны (см. ниже). Вам нужно изменить параметры domain.com, serial и email.

nano /var/named/domain.com.db

Откройте /etc/named.conf и добавьте следующие строки:

zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};

Сохраните изменения в файле и перезапустите bind.

service named restart

Пример файла зоны DNS для BIND

Используйте этот файл для настройки ваших доменов и серверов имен в BIND9:

;=================================================================
;ПРИМЕР ФАЙЛА ЗОНЫ BIND DNS
;для ЛЮБОГО домена (просто измените domain.com на ваш сайт)
;================================================================

; Перед тем как начать, НЕ ЗАБУДЬТЕ ТОЧКУ И УВЕЛИЧЕНИЕ СЕРИЙ

$TTL 14400
$ORIGIN domain.com.

; Запись SOA
; Укажите основной сервер имен ns1.domain.com
; Серийный номер должен увеличиваться при каждом обновлении
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. ( 2009092902 ; Серийный номер в формате ГГГГММДДXX (XX - это увеличение)
10800; секунды обновления
3600; повтор
604800; срок действия
38400; минимум
);
; IP-адрес веб-сайта, указанный в записи A

IN A xx.xx.xx.xx

; Минимум 2 имени сервера DNS

IN NS ns1.domain.com.
IN NS ns2.domain.com.

; Сопоставление всех серверов имен и их соответствующих IP (GLUE)

ns1 IN A xx.xx.xx.xx
ns2 IN A xx.xx.xx.xx

; Укажите любые поддомены и www-запись здесь, используя запись CNAME

www IN CNAME domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.

; Настройка записи MX (почтовый обменник с приоритетом)
domain.com. IN MX 10 mail.domain.com.

; установите запись A для почты
mail IN A xx.xx.xx.xx;====================================

Об авторе

Мистер Балакришнан - интернет-предприниматель и администратор Linux с интересами в программировании на PHP и приложениях Linux. С ним можно связаться на его блоге corpocrat.com или на его странице в Twitter.