Что такое NS-сервер и как он работает. Проверка DNS-записей домена - что это и зачем нужно Просмотр записей dns

Перевод

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System . Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .

Базовые штуки

Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).

Давайте взглянем на маппинг между именем и адресом:

$ dig web01.bugsplat.info

Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

;; QUESTION SECTION: ;web01.bugsplat.info. IN A

dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:

;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244

Оставшаяся часть ответа описывает сам ответ:

;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56

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

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

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:

$ dig +trace web01.bugsplat.info ; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms

Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.

Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.

Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.

В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!

$ dig -x 192.5.5.241 ; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.

Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае - f.root-servers.net .

Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» - прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

Другие типы

Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:

$ dig petekeen.net mx ; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93

Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

$ dig www.petekeen.net ; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86

Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.

Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .

Запросы к другим серверам

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

$ dig www.petekeen.net @8.8.8.8

Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:

Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:

$ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118

Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:

$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/

CNAME для Heroku или Github

Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.

$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns Добавить метки

Всем привет! Сегодня поговорим о том, как проверить DNS-сервера на предмет блокировки провайдером либо домашним роутером. Ведь если помните, то в мы уже поднимали эту тему.

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

Но согласитесь, что запоминать такую простыню цифр не очень удобно. Вот поэтому и были введены DNS-сервера, которые позволяют обращаться к ресурсам при помощи доменного имени, которое состоит из латинских букв.

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

Зная это, мы с легкостью можем обойти такие ограничения, указав в настройках сетевой карты компьютера альтернативные сервера, где сопоставление доменных имен с IP-адресами происходит уже по другому сценарию:

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

И в ней ввести вот такую строчку:

Как уже упоминалось в начале публикации, в прошлой статье мы таким методом обходили ограничение на установку на телевизоры Samsung. Так вот, в том случае для проверки нужно было ввести команду такого вида:

И если ответ будет таким, как показано на скриншоте выше, то блокировки нет. Если же вы увидите что-то похожее на это:

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

А мы закругляемся, поскольку тема о том, как проверить DNS-сервера на предмет блокировки исчерпана. Если остались вопросы, прошу в комментарии. А напоследок, предлагаю посмотреть познавательное видео про человеческий сон.

Как это работает система DNS?

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

DNS-сервер обращается к одному из корневых NS-серверов интернета, ip-адреса которых жестко заданы и известны и в ответ Корневой сервер отдает DNS-серверу список ip-адресов серверов, на которых расположена зона.COM Выглядит этот список примерно так:

A.gtld-servers.net. 160060 IN A 192.5.6.30 a.gtld-servers.net. 160060 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 160060 IN A 192.33.14.30 b.gtld-servers.net. 160060 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 160060 IN A 192.26.92.30 d.gtld-servers.net. 160060 IN A 192.31.80.30 e.gtld-servers.net. 160060 IN A 192.12.94.30 f.gtld-servers.net. 160060 IN A 192.35.51.30 g.gtld-servers.net. 160060 IN A 192.42.93.30 h.gtld-servers.net. 160060 IN A 192.54.112.30 i.gtld-servers.net. 160060 IN A 192.43.172.30 j.gtld-servers.net. 160060 IN A 192.48.79.30 k.gtld-servers.net. 160060 IN A 192.52.178.30 l.gtld-servers.net. 160060 IN A 192.41.162.30 m.gtld-servers.net. 160060 IN A 192.55.83.30

DNS-сервер обращается к одному из NS-серверов зоны.COM (Допустим, a.gtld-servers.net - 192.5.6.30) и запрашивает список NS-серверов для домена MYDOMAIN.COM. Эти NS-сервера называются NS-серверами, на которые делегирован домен.

Ns1.mydomain.com. 172800 IN A 66.96.142.148 ns2.mydomain.com. 172800 IN A 65.254.254.172 ns3.mydomain.com. 172800 IN A 66.96.142.146 ns4.mydomain.com. 172800 IN A 65.254.254.170

После чего обращается к одному из полученного списка NS-серверов и запрашивает уже информацию относительно домена MYDOMAIN.COM. Пример ответа:

Mydomain.com. 3248 IN MX 0 mail.mydomain.com. mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all" mydomain.com. 2208 IN SOA ns1.mydomain.com. hostmaster.mydomain.com. 1335787408 16384 2048 1048576 2560 mydomain.com. 248 IN A 65.254.242.180 mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; AUTHORITY SECTION: mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 167564 IN A 66.96.142.148 ns2.mydomain.com. 167564 IN A 65.254.254.172 ns3.mydomain.com. 126551 IN A 66.96.142.146 ns4.mydomain.com. 126551 IN A 65.254.254.170

DNS-сервер отдает вашему компьютеру полученную информацию и он обращается к нужному IP-адресу. Но, как мы видим, здесь достаточно много разнообразной информации. Рассмотрим все подробнее.

Что такое делегирование домена

Делегированием домена называется передача корневым сервером зоны права размещения домена на определенном NS-сервере. Для примера, корневые сервера ДЕЛЕГИРУЮТ зону.COM на серверы, которые будут за нее отвечать, а серверы зоны.COM ДЕЛЕГИРУЮТ домен MYDOMAIN.COM на NS-сервера хостинг-провайдера или на какие-либо другие. Само делегирование означает, что на корневом сервере для домена присутствуют записи IN NS, указывающие на NS-сервер, на котором размещена информация по домену. Обратите внимание, делегирование предполагает наличие ТОЛЬКО записей IN NS и никаких других. Поэтому домену второго уровня нельзя прописать, к примеру, запись CNAME.

Что такое дочерние NS-серверы

Иногда NS-серверы для домена находятся на его поддоменах. В вышеприведенном примере домен MYDOMAIN.COM делегирован на NS-серверы ns1.mydomain.com, ns2.mydomain.com и т.д. Как же это возможно? Ведь чтобы обратиться к этим NS-серверам нужно узнать их ip-адрес. Все просто - корневой сервер зоны.COM при таком варианте требует указания не только доменных имен NS-серверов, но и их ip-адресов. Поэтому DNS-сервер знает, куда обратиться за подробностями. Рассмотрим пример двух доменов - с дочерним NS-сервером и без: NS-запись у домена diphost.ru

;; ANSWER SECTION: diphost.ru. 292 IN NS ns1.bz8.ru.

NS-запись у домена bz8.ru

;; ANSWER SECTION: bz8.ru. 300 IN NS ns1.bz8.ru. ;; ADDITIONAL SECTION: ns1.bz8.ru. 95617 IN A 185.35.220.5 ns1.bz8.ru. 95617 IN AAAA 2a00:e460:2a00:c01d::9:aaaa

Как видите, все просто. Такая настройка у зарубежных регистраторов называется Child NameServers

Какие бывают NS-записи для домена

NS-запись - указывает, на каких NS-серверах находится домен. Эта запись должна повторять значения для домена, находящиеся на корневых серверах зоны. Только в этом случае домен будет ДЕЛЕГИРОВАН.

Mydomain.com. 1448 IN NS ns3.mydomain.com.

A-запись - указывает IPv4 адрес сервера, к которому нужно обратиться по доменному имени. A-записей у домена может быть несколько. В этом случае выбирается случайный.

Mydomain.com. 248 IN A 65.254.242.180

AAAA-запись - указывает на IPv6 адрес сервера. Также, эта запись иногда упоминается как Квадра-А (четыре А)

MX-запись - указывает на ip-адрес или доменное имя сервера, отвечающего за прием почты на этот домен (MX-сервер). В нашем примере, вся почта на любой адрес домена MYDOMAIN.COM будет поступать на сервер mail.mydomain.com.

Mydomain.com. 3248 IN MX 0 mail.mydomain.com.

MX-записей тоже может быть несколько. MX-запись кроме имени сервера также имеет поле "Приоритет". Оно указывает, в каком порядке нужно обращаться к MX-серверам домена. Чем меньше значение приоритета, тем приоритетнее сервер.

TXT-запись - Сюда записывают различную служебную информацию, для которой нет выделенных полей. Можно записать контактные данные администратора, или что угодно. TXT-записи также используются для хранения SPF и DKIM записей, использующихся для защиты от спама.

Mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all"

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

SOA-запись - генерируется автоматически NS-сервером и содержит служебную информацию: адрес электронной почты ответственного за NS-сервер, дату и время последнего обновления домена, предельное время кеширования зоны (TTL) и т.д.

SRV-запись - служит для хранения адресов различных серверов, обслуживающих домен. Обычно они не совпадают с адресом web-сервера, указанного в A-записи и, как и MX-сервер, расположены на других адресах. В эту запись можно добавить адреса JABBER, TeamSpeak серверов и т.д.

Общие правила оформления записей на NS-сервере

Если в записи указано доменное имя, оно должно заканчиваться точкой, иначе к нему будет приклеено имя основного домена. Т.е. если указать запись

Mydomain.com. IN MX 10 mx.mail.ru

то MX-сервер домена будет определяться как mx.mail.ru.mydomain.com. Поэтому правильный вариант записи:

Mydomain.com. IN MX 10 mx.mail.ru.

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

Система DNS-записей домена: суть и предназначение

В упрощенном понимании система DNS сравнима с телефонным справочником. Здесь также доменное имя сайта (номер абонента) связывается с его IP-адресом (именем). А воспользовавшись соответствующими сервисами поиска можно получить много полезной информации о сервере, на котором он размещен. Так:

A – запись, устанавливающая взаимообратное соответствие хоста и IP-адреса (иными словами, что при наборе в поисковой строке доменного имени пользователь должен быть переадресован на определенный IP-адрес).
CNAME – запись, что, как правило, используется для осуществления переадресации с поддомена на другой определенный домен.
MX – учетная запись, позволяющая идентифицировать почтовый шлюз домена, составляющими которой выступают приоритет и адрес узла. Является критичной для правильной работы электронной почты. Для одного сервера таких записей может быть несколько.
NS – адрес узла, указывающий на сервер имен для конкретно заданного домена. Поскольку эта запись предоставляет информацию о том, на каких DNS-серверах хранится информация об указанном домене, ее работа критически важна.
PTR – обратная запись, устанавливающая связь от IP-адреса сервера к его каноническому доменному имени. Активно задействована в процедуре фильтрации почты
SOA – этот показатель содержит информацию о сервере, где хранится изначальная (эталонная) информация по проверяемому домену.
SPF – запись, закрепляющая список серверов, имеющих право заниматься рассылкой почты от имени домена.
SRV – значение, указывающее на серверы для сервисов.
TXT - запись, позволяющая владельцу домена вносить дополнительную, важную (на его взгляд) информацию.

К заполнению этих строк необходимо отнестись с особой внимательностью, ведь малейшая ошибка здесь может приостановить работу ресурса, размещенного на сервере, на длительное время.

Как это работает. При слове “сайт” вам не задумываясь назовут Google.com, Facebook.com и прочие доменные имена. Если спросить у компьютера - получим набор из 10-12 цифр, т.е. IP адрес устройства в сети. Что такое Facebook.com он не знает. Чтобы наладить взаимопонимание между человеком и машиной, создали систему доменных имен - DNS, которая умеет преобразовывать доменные имена в IP адреса.

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

Типы DNS записей домена

Преобразование доменных имен в IP - одна из немногих функций. Кроме этого DNS выполняет и другие. Для их реализации используются типы записей DNS. Перечислим самые распространенные:

Записям, которые определяют IP адрес устройства по доменному имени присвоен тип А (или АААА для IPv6).
Для одного и того же IP адреса можно задавать любое количество доменных имен. В этом случае используется запись типа CNAME , которая определяет псевдоним для доменного имени.
Запись типа MX помогает узнать адрес почтового сервера, куда требуется отправить почту. Для одного домена может существовать несколько MX записей.
TXT - запись, включающая в себя текстовые данные. Используют для передачи информации, например для проверки владельца домена, или для подтверждения безопасности email. Текстовых записей может быть любое количество. Добавляются в настройках домена.

Существуют еще много других типов записей, но используются намного реже.

Какие записи влияют на доставку писем?

Есть специальные TXT записи , наличие которых определяет, попадут письма в инбокс или будут заблокированы еще до появления в почтовых ящиках.

Как вы думаете, кто читает ваши письма прежде чем их доставят получателю? ЦРУ, Моссад или МИ-6? Нет, их прочтут спам-фильтры, которые постоянно совершенствуются и увеличивают количество факторов определения спама. Попадание в базу спам ресурсов (блеклисты) серьезно затруднит жизнь, если вы регулярно совершаете рассылки.

Аутентификация DKIM, SPF, DMARC подтвердит подлинность домена и обеспечит доставку писем в почтовый ящик. Они грудью стоят на страже репутации домена и оберегают от фишинга и спама.

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

SPF - доменная запись, которая содержит информацию о списке серверов отправки и механизмах обработки писем. Эта запись отравляет жизнь спамерам и мошенникам в прохождении антиспам систем. Четко указывает у кого есть право отправлять письма от имени домена, а у кого нет.

Если домен не защищен записью SPF и подписью DKIM , спамерам ничего не помешает рассылать письма от вашего имени. Почтовые сервисы проверяют входящую корреспонденцию на наличие SPF и DKIM записи и отсутствие их расценивается как спам.

Но эти механизмы также имеют недостатки. Чтобы почтовому сервису было проще отличать реальные емейлы от поддельных, помимо SPF и DKIM ввели еще одну степень защиты - DMARC. При работе этих 3 факторов одновременно, вероятность успешной доставки сообщений адресату возрастает во много раз.

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

Инструменты для проверки доменных записей

С настройками записей разобрались. Теперь наши письма просто обязаны попадать исключительно в инбокс, а спам-анализаторы почтовых сервисов снимать шляпу при встрече с нашей рассылкой. Так ли это на самом деле и где взять уверенность, что все сделано правильно.

Для проверки записей DNS и диагностики доменов созданы специальные сервисы:

MXtoolbox - проверка DNS записей, полная диагностика домена и дополнительные инструменты для анализа сайта.
DNSstuff.hostpro.ua - здесь вы получите полную информацию о настройках DNS для вашего домена и узнаете, находится ли он в блеклистах.
Functions-online.com - производит проверку DNS записей.
2ip.ru - проверка DNS записей домена и полный анализ сайта.
Mail-tester.com - тестирует письма на попадание в спам, указывает на ошибки в ссылках, проверяет доменные записи и качество форматирования писем. Просто отправьте письмо на предложенный адрес, затем проверьте оценку.
Pr-cy.ru - проверка DNS записей и состояния сайта.

Они будут полезны в случае, если замечены неполадки. Например, перестала доходить или отправляться почта и др. Подобный сбой обычно происходит после коррекций записей DNS. Поэтому, после внесенных изменений необходимо проводить проверки.

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

Пример проверки DNS записей с помощью MXtoolbox

Мы считаем что, это один из лучших сервисов по диагностике доменов . Его чаще всего используют специалисты техотдела для выявления проблем у клиентов и оказания им помощи.

Mxtoolbox позволяет провести общую диагностику домена, обнаружить его наличие в черных списках, проверить корректность MX записей и других DNS записей, даже протестировать вероятность доставки ваших писем в Inbox. Проведенное вовремя тестирование позволит избежать проблем с почтовыми провайдерами.

В этот момент происходит проверка домена на размещение в блеклистах одновременно с выявлением других проблем. В результате получаем отчет о здоровье домена:

Домен здоров, если не будет выявлено проблем, обозначенных красным цветом. Но результат проведенной проверки показал наличие ошибок, которые необходимо устранить - отсутствие записей SPF и DMARC.
Берем автоматически сгенерированные сервисом Estismail записи и совершаем настройки на хостинге. Дальше, проверяем корректность внесенных изменений.

Заходим на сайт mxtoolbox.com .
Кликаем на оранжевую кнопку со стрелкой. Из выпавшего списка нас интересуют SPF Record Lookup, DKIM Lookup и DMARC Lookup.

Как проверить корректность записи DKIM?

Введите домен в поле проверки в следующем формате - example.com:estismail . Вводить без http:// и www . Вместо example.com вписываете ваш домен, а после двоеточия укажите селектор. Выбираем DKIM Lookup .

В открывшемся окне увидите "успешное" сообщение следующего вида:

Если после проведенной проверки открылась картина с сообщением, что DKIM не найдена, придется обновить DNS записи.

Как проверить SPF запись?

Проверка записи SPF, происходит так же, как и проверка DKIM. Из открывшегося списка выберите SPF Record lookup . В соответствующее поле введите имя домена без http:// и www . Если настройки корректны, увидите такую картину:

В нижней колонке в строке SPF Syntax Check высветится The record is valid .

Самая распространенная ситуация, помимо отсутствия записи SPF, это наличие 2 и более записей SPF. Если допущена подобная ошибка, в открывшемся окне увидите следующее:

В этом случае исправьте запись SPF - просто совместите в одной записи все узлы , с которых отправляете рассылки, как было указано на “правильном” предыдущем рисунке.

Как проверить DMARC запись?

При проведении проверки DMARC записи принцип, как и в первых 2 случаях. Из списка под оранжевой кнопкой выбираете функцию DMARC Lookup и вводите название домена без http:// и www.
Если введены корректные записи, увидите следующую таблицу и сообщение внизу в строке DMARC Syntax Check о том, что The record is valid .

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