Dns записи: DNS записи – NS, CNAME, TXT, A, AAAA

DNS записи для почтовых серверов / Хабр

Представьте, что вы в реальной жизни получили конверт, где в поле “Отправитель” написано имя вашего старого друга. Можете ли вы, не открыв и не прочитав письма, точно сказать – это конверт от вашего старого друга или какого-то злоумышленника?

Именно эта задача стоит перед почтовыми серверами — просто взглянув на конверт определить, не врёт ли поле отправитель. Для этого почтовый сервер обращается к тому механизму, который в интернете служит для подтверждения владения доменом – DNS серверу.

Видео

Previous Про порты и шифрование в почтовых серверах

Сразу оговорюсь, что под полем «отправитель» я подразумеваю не поле «from» в самом сообщении, а адрес сервера отправителя.

Почтовый сервер очень зависим от DNS. Единственный случай, когда почтовому серверу не нужен DNS сервер – когда это локальный почтовый сервер, который не отправляет и не получает письма от других серверов.

Теперь, давайте определимся со всеми необходимыми DNS записями для почтовых серверов. Начнём с “А” записи, которая преобразует имя в IP адрес. Кстати, А – от слова адрес. Частые примеры имён для почтовых серверов – mx.example.org, mail.example.org, smtp.example.org. Несколько А записей с одним именем и разными IP адресами позволят балансировать трафик на разные почтовые сервера при условии настройки round robin DNS.

MX запись – от слова мейл эксчейнджер – нужна, чтобы другие почтовые сервера могли узнать, на какой адрес следует отправлять почту по указанному домену получателя. Если вы планируете использовать субдомены, допустим, [email protected], то и для субдомена понадобится отдельная MX запись. Также, вы можете указывать несколько MX записей для одного домена, указывающие на разные адреса и выбирая приоритет. Скажем, вы хотите, чтобы по умолчанию вся почта отправлялась на сервер mx1.example.org, тогда даёте ему приоритет ближе к нулю. Чем менее приоритетнее сервер, тем большее число вы ему назначаете. Максимальное значение – 65535, но обычно приоритеты выставляют 10, 20, 30 и т.п. Приоритеты могут совпадать, тогда либо DNS балансирует эти записи, если так настроено на DNS сервере, либо отправитель будет использовать первый доступный сервер.

PTR запись – обратная DNS запись, которая преобразует IP адрес в имя. Основная задача данной записи для почтового сервера – отсеять большую часть спама. Эта запись позволяет определить имя хоста, с которого приходит почта. При получении почты, почтовый сервер делает два запроса – на получение имени по IP адресу и на получение IP адреса по имени отправителя. Если результаты совпадают – значит сервер отправитель тот, за кого себя выдаёт. В отличии от остальных записей, такую запись можно создать только в случае владения или аренды IP адреса.

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

SPF – запись, которая разрешает определённым адресам отправлять сообщение с указанного домена, и говорит, что делать если сообщение пришло с другого адреса. Допустим, вы, как отправитель, заявляете, что разрешаете отправлять почту из домена example.org только адресу mail.example.org. А если сообщение придёт не с этого адреса, но в поле отправитель указан домен example.org, то смело отклонять это сообщение как недоверенное. По идее, сервера получатели должны проверить вашу SPF запись и действовать согласно тому, что вы выставили, но получатель может игнорировать ваши “наставления” по своему желанию. SPF запись нужна для защиты от спуфинга – атак, когда злоумышленник притворяется одним из пользователей отправителя.

### Примеры настройки SPF записей

# C этого домена не принимать почту
v=spf1 -all

# С этого домена принимать почту только с адресов, указанных в MX записях
v=spf1 mx -all

# С этого домена принимать почту с адреса mail.example.org, с остальных маркировать сообщения как подозрительные
v=spf1 a:mail.example.org ~all

При настройке SPF записи вы указываете версию SPF, а она пока одна – первая. Дальше указываете адреса, которым разрешаете отправлять сообщения с данного домена. В качестве адресов может быть просто запись “mx” – то есть те сервера, которые у вас указаны в MX записях. Также можно прописать дополнительные адреса с помощью опций a – по A записи, по ipv4 и ipv6 адресам и т.п. После разрешенных адресов указывается опция all для всего того, что не подошло под ваше правило. Вы можете советовать получателю разрешить все сообщения с любых адресов по вашему домену, запретить, пометить как несоответствующее, но пропустить, либо на усмотрение получателя. Полный синтаксис и все опции SPF я дам в виде ссылки в конце.
И хотя SPF указывает на адреса, кому разрешено отправлять сообщения, есть вероятность подмены сообщения кем-то посередине. Для предотвращения таких атак есть другая DNS запись.

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

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

DMARC – запись, которая позволяет выставить политики в зависимости от проверок SPF и DKIM. Эти политики, опять же, нужны получателю, чтобы знать, как поступать с вашими письмами.

### Примеры настройки DMARC записей

# Отклонять все несоответствующие сообщения и посылать отчёт на адрес администратору
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

# Посылать в спам 50% сообщений, которые не соответствуют политикам, остальное доставлять, и также посылать отчёт
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]

# Пропускать все сообщения и отправлять отчёт администратору
v=DMARC1; p=none; rua=mailto:[email protected]

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

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

Забыл упомянуть. В сети есть пара важных инструментов для проверки ваших настроек.

Один из самых удобных инструментов — mail-tester. Всё просто:

1. Заходите на сайт, копируете почтовый адрес, который выдал вам сервис.

2. Отправляете на этот адрес со своего домена с любого ящика сообщение. Желательно, чтобы сообщение не было пустым, а содержало какой-никакой текст.

3. Возвращаетесь на сайт, нажимаете «Затем проверьте оценку».

4. Проверяете результат. Портал проверит все возможные настройки, как DNS — те же SPF, DKIM и DMARC записи, так и покажет, попал ли ваш сервер в черные списки и т.п. Также он выдаст рекомендацию, если у вас есть ошибки в настройках.

5. Если были ошибки — исправляете а затем опять отправляете сообщение и снова проверяете результат. Если проблемы были связаны с DNS записями, убедитесь, что ваши изменения в DNS применились(к примеру, той же командой dig), прежде чем пробовать заново.

НО! Сервис даёт вам всего 3 бесплатные попытки в день, поэтому, желательно, исправить все ошибки, а затем заново проверять.

Еще один инструмент — mxtoolbox. Тут, в основном, проверка на наличие DNS записей и попадание в спам листы. Также на этот портале можно найти множество различных инструментов для проверки и нет такого ограничения, как в mail-tester. Хотя среди инструментов и есть проверка на наличие DKIM ключа, но без сообщения с вашего домена mxtoolbox не сможет подтвердить правильность настройки почтового сервера для работы с DKIM.

Если вы настроили DKIM и хотите убедиться в правильности, можете отправить сообщение на тот же gmail аккаунт, а затем открыть сообщение в исходном виде и попытаться найти строку DKIM=pass. Либо воспользоваться готовым сервисом — dkimvalidator. Принцип работы такой же, как у mail-tester — отправляете сообщение на сгенерированный адрес и смотрите результат.

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

Полезные ссылки:
Что такое SPF
Загадки и мифы SPF
What Is DKIM?
HowTo: DMARC

Введение в DNS-записи | Вебмастеру

Система доменных имен (DNS) — это адресная книга интернета. DNS направляет трафик на сайт почту, сопоставляя доменные имена с IP-адресами. В этом руководстве рассматриваются основные концепции DNS и DNS- записей.

Общая группа доменов указывается справа. В приведенных ниже примерах домен верхнего уровня или TLD — это .com.

example.com
mail.hello.example.com

Каждое значение слева от TLD отделяется точкой, и называются поддоменами. hello и mail соответственно являются поддоменами второго и третьего уровня. Субдомены используются для идентификации определенных компьютеров или служб.

Выбор и указание сервера DNS является неотъемлемой частью владения доменом. Иначе клиентские устройства не будут знать, где найти информацию о DNS.

Серверы имен размещают информацию о домене DNS в текстовом файле, который называется файлом зоны. Они также известны как записи Start of Authority (SOA). Вы можете разместить свою информацию DNS на серверах имен в одном из нескольких мест:

• Регистратор домена;
• Ваш собственный DNS-сервер;
• Сторонний DNS-хостинг.

Записи DNS сопоставляют доменные имена с IP-адресами. Затем DNS-записи автоматически объединяются в файл зоны, что позволяет подключенным устройствам искать правильный IP-адрес домена. Если вы решите использовать серверы имен Linode, диспетчер DNS поможет создать файл зоны. Он содержит следующие записи:

; example.com [448369]
$TTL 86400
@  IN  SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400
@       NS  ns1.linode.com.
@       NS  ns2.linode.com.
@       NS  ns3.linode.com.
@       NS  ns4.linode.com.
@       NS  ns5.linode.com.
@           MX  10  mail.example.com.
@           A   12.34.56.78
mail        A   12.34.56.78
www         A   12.34.56.78

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

Доменное имя должно быть переведено на IP-адрес. DNS сопоставляет понятные пользователю доменные имена (example.com) с IP-адресами (192.0.2.8). Это происходит в специальном текстовом файле, называемом файлом зоны. В нем перечислены домены и соответствующие им IP-адреса. Файл зоны похож на телефонную книгу, в которой имена совпадают с адресами улиц.

Вот как работает процесс поиска DNS:

1. Вы вводите доменное имя, например com,в адресную строку браузера.
2. Компьютер подключен к интернету через провайдера (ISP). DNS-преобразователь интернет-провайдера запрашивает у корневого сервера имен соответствующий сервер имен TLD.
3. Корневой DNS-сервер отвечает IP-адресом для сервера имен .com.
4. DNS-распознаватель провайдера использует IP-адрес, полученный от корневого сервера имен.
5. Сервер имен .comотвечает IP-адресом сервера имен com.
6. DNS-распознаватель ISP считывает файл зоны с сервера имен домена.
7. Файл зоны показывает, какой IP-адрес соответствует домену.
8. Теперь, когда у провайдера есть IP-адрес для com, он возвращает его браузеру, который затем обращается к серверу сайта.

Описанный выше сценарий выполняется, если у провайдера нет информации о запрашиваемом домене. На самом деле провайдеры кэшируют данные о DNS после того, как получили ее в первый раз. Это ускоряет поиск и снижает нагрузку на DNS-серверы.

Но кэширование может стать проблемой, если вы недавно внесли изменения в информацию о DNS. Для ее решения измените значение времени жизни файла зоны (TTL), чтобы обновление DNS происходило быстрее.

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

example.com     A       12.34.56.78

hello.example.com       A       12.34.56.78

Вы можете указать разные субдомены на разных IP-адресах. Если нужно указать каждый субдомен example.com на IP, то можете использовать для субдомена звездочку (*):

*.example.com   A       12.34.56.78

Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:

Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:

Запись AXFR используется для репликации DNS. Хотя существуют более современные способы.

Записи AXFR не используются в обычных файлах зон. Чаще всего они применяются на подчиненном DNS-сервере для репликации файла зоны с главного DNS-сервера.

DNS Certification Authority Authorization (CAA) использует DNS, чтобы владелец домена мог указать, каким центрам сертификации разрешено выдавать сертификаты для этого домена.

Запись CNAME (запись канонического имени) соответствует домену или поддомену. При записи CNAME используются разрешения DNS целевого домена в качестве разрешения псевдонима. Например:

alias.com       CNAME   example.com.
example.com     A       12.34.56.78

При запросе alias.com начальный поиск DNS найдет запись CNAME с целью example.com. Будет запущен новый поиск DNS example.com, который найдет IP-адрес 12.34.56.78. Посетители alias.com будут направлены к IP-адресу 12.34.56.78.

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

Записи MX не могут ссылаться на имена хостов, определенные CNAME. Целевой домен для записи CNAME также должен иметь нормальное разрешение A-записи.

Примечание

CNAME-запись может быть эффективным способом перенаправления трафика от одного домена к другому, сохраняя тот же URL-адрес. Но она не работает так же, как редирект URL-адресов. CNAME-запись направляет трафик для определенного домена на IP-адрес целевого домена. Как только пользователь достигнет этого IP-адреса, конфигурация сервера будет определять способ обработки домена. Если этот домен не настроен, сервер отобразит веб-страницу по умолчанию. Она может быть веб-страницей целевого домена в записи CNAME, в зависимости от того, как настроен сервер.

Запись DKIM она же запись DomainKeys Identified Mail отображает открытый ключ для аутентификации сообщений, которые подписаны с помощью протокола DKIM. Это расширяет возможности проверки подлинности электронной почты. Типичная запись DKIM выглядит следующим образом:

selector1._domainkey.example.com        TXT     k=rsa;p=J8eTBu224i086iK

DKIM-записи представлены в виде текстовых записей. Запись должна быть создана для субдомена, который имеет уникальный селектор для этого ключа, затем указывается точка (.) и _domainkey.example.com. Тип -TXT, значение включает в себя тип ключа, за которым следует фактический ключ.

Запись MX устанавливает адресат доставки почты для домена или субдомена. Типичная MX-запись выглядит следующим образом:

example.com         MX      10  mail.example.com.
mail.example.com    A           12.34.56.78

Приведенные выше записи направляют почту для example.com на сервер mail.example.com. В идеале MX-запись должна указывать на домен, который также является именем хоста его сервера. Если вы используете стороннюю почтовую службу, такую ​​как Google Apps, то следует применять предоставленные ими MX-записи.

Приоритет является еще одним компонентом MX-записей. Это число, записанное между типом записи и целевым сервером. В примере, приведенном выше, использован приоритет 10.

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

example.com         MX      10  mail_1.example.com
example.com         MX      20  mail_2.example.com
example.com         MX      30  mail_3.example.com

Если mail_1.example.com не работает, электронная почта будет доставлена на mail_2.example.com. Если mail_2.example.com также не работает, почта будет доставлена на mail_3.example.com.

NS-записи устанавливают серверы имен для домена. Они задаются для домена у регистратора и в файле зоны. Типичные записи сервера имен выглядят следующим образом:

example.com     NS      ns1.linode.com.
example.com     NS      ns2.linode.com.
example.com     NS      ns3.linode.com.
example.com     NS      ns4.linode.com.
example.com     NS      ns5.linode.com.

Серверы имен, которые вы назначаете у своего регистратора, содержат файл зоны для домена.

Также можно настроить различные серверы имен для любого из поддоменов. Они задаются в файле зоны вашего основного домена:

mail.example.com    NS      ns1.nameserver.com
mail.example.com    NS      ns2.nameserver.com

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

Запись PTR или запись указателя сопоставляет IP-адрес с доменом или поддоменом, позволяя функционировать обратным DNS-запросам. Она работает противоположно записи A, в том смысле, что позволяет искать домен, связанный с конкретным IP-адресом, а не наоборот.

Записи PTR обычно устанавливаются на хостинге. Они не являются частью файла зоны домена.

Для добавления записи PTR необходимо создать действительную запись A или AAAA, которая указывает IP-адрес для нужного домена.

Примечание

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

Запись SOA обозначает файл зоны с именем хоста, на котором он был создан. Далее в нем указывается контактный адрес электронной почты администратора домена. Типичная запись SOA:

@ IN  SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400

Примечание

Адрес электронной почты администратора пишется с точкой (.) вместо символа @.

Вот что означают эти цифры:

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

Сервер имен, упомянутый в записи SOA, считается основным для динамического DNS. На нем изменения файла зоны производятся до того, как они распространяются на другие серверы имен.

Запись Sender Policy Framework (SPF) содержит список почтовых серверов, назначенных для домена или субдомена. Это помогает подтвердить легитимность почтового сервера и снижает вероятность подделки заголовков писем. Спамеры часто пытаются сделать это, чтобы обойти фильтры.

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

example.com   TXT     "v=spf1 a ~all"

В SPF-записи необходимо перечислить почтовые серверы, с которых вы отправляете почту, а затем исключить остальные. Ваша SPF- запись будет содержать домен или поддомен, тип (TXT или SPF, если ваш сервер имен поддерживает его) и текст (который начинается с «v = spf1» и содержит настройки SPF- записи).

С помощью этой SPF-записи принимающий сервер проверит и IP-адрес отправляющего сервера, и IP-адрес example.com.

Примечание

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

Рекомендуем посетить ресурс openspf.org, чтобы узнать, как работают SPF- записи и как создать запись, которая подходит для вашей настройки.

Запись SRV сопоставляет конкретную службу, работающую на домене или поддомене, с целевым доменом. Это позволяет направлять трафик, предназначенный для определенных служб, на другой сервер. Типичная запись SRV:

_service._protocol.example.com  SRV     10      0       5060    service.example.com

Описание элементов, которые используются в SRV-записи:

• Служба: названию службы должно предшествовать подчеркивание ( _ ) и точка ( . ). Служба может быть чем-то вроде _xmpp.
• Протокол: имя протокола должно начинаться с подчеркивания ( _ ) и заканчиваться точкой ( . ). Протокол может быть чем-то вроде _tcp.
• Домен: имя домена, который будет получать исходный трафик для службы.
• Приоритет: первое число (10 в приведенном выше примере) позволяет установить приоритет для целевого сервера. Можно установить цели с разными приоритетами, что позволит иметь резервный сервер (или серверы) для этой службы. Меньшие числа имеют более высокий приоритет.
• Вес: Если две записи имеют одинаковый приоритет, вместо него учитывается вес.
• Порт: порт TCP или UDP, на котором работает служба.
• Цель: целевой домен или поддомен. Он должен иметь запись A или AAAA, которая разрешается в IP-адресе.

Примером использования SRV-записей является настройка федеративной VoIP .

Запись TXT (текстовая запись) предоставляет информацию о домене другим интернет-ресурсам. Одно из распространенных применений TXT-записи — создание SPF- записи на серверах имен, которые изначально не поддерживают SPF. Другой вариант использования — создание записи DKIM для почты.

Данная публикация представляет собой перевод статьи «DNS Records: An Introduction» , подготовленной дружной командой проекта Интернет-технологии.ру

телеграм канал. Подпишись, будет полезно!

Как проверить DNS-запись домена: инструкция

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

Я расскажу, какими способами можно проверить каждый тип DNS-записи.

Типы DNS-записей

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

1. A – адресная запись, которая отвечает за привязку доменного имени к определенному IP-адресу по протоколу IPv4.
2. AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
3. CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
4. DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
5. MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
6. NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
7. PTR – действует обратно записям A и AAAA, то есть показывает соответствие IP-адреса и доменного имени. Многие почтовые серверы во время фильтрации писем проверяют ее наличие.
8. SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
9. SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
10. SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
11. TXT – содержит общую вспомогательную информацию о домене, используется для указания SPF-записей, подтверждения прав собственности, обеспечения безопасности электронной почты и так далее. 

Способы проверки DNS-записей домена

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

Есть множество способов, позволяющих проверить DNS-записи. Можно воспользоваться как специальными командами в системе, так и онлайн-сервисами.

Встроенные в систему службы

• nslookup. Действует на ОС Windows и Linux. С помощью этой утилиты можно точно узнать информацию об IP-адресе, а еще о настройке всех ресурсных записей. Утилита запускается через «Командную строку» в Windows и «Терминал» в Linux. Вводить команду нужно одинаково в обоих случаях и примерно вот так:

nslookup -type=тип_записи site.com

• host. Эта утилита используется в ОС Linux. Она есть в стандартном пакете командной строки «Терминал». С ее помощью можно проверить все виды запросов к DNS-серверу. Вводится команда вот таким образом:

host site.com

Можно перед доменным именем добавить опцию -t и указать тип записи для получения более подробного поиска. Выглядеть это будет примерно вот так:

host -t A site.com

host -t MX site.com

Проверка DNS-записей с помощью сторонних сервисов

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

• 2whois.ru – известный сайт, с помощью которого можно узнать DNS-записи самого разного типа. Просто нужно указать домен в соответствующей строке и начать проверку.

• dns.nettools.ru – очень удобный сервис, в котором можно получить информацию не только о ресурсных записях, но и возможности выполнения рекурсивных запросов, а также проверки сервера на возможность выгрузки данных.

• functions-online.com – здесь тоже очень удобно проверять настройки DNS-записей самых различных типов. Сервис дает полную информацию, а еще предоставляет PHP документацию на разных языках.

•  mail-tester.com – сервис поможет определить, попадет ли письмо, отправленное с вашего сервера, в «Спам». Еще здесь можно определить ошибки в ссылках и проверить качество форматирования писем.

• xseo.in/dns – на данном ресурсе есть раздел для проверки самых разных DNS записей. 

• digwebinterface.com – навороченный онлайн-сервис с очень простым исполнением. С первого взгляда может показаться сложным, но на самом деле справиться с ним может даже новичок.

Заключение

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

типы записей, как их добавить и проверить

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

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

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

Типы DNS-записей

Существуют следующие типы записей:

• SOA-запись (Start of authority)
  SOA-запись DNS определяет авторитетную информацию о доменном имени и зоне в целом.
• A-запись (Address)
  Связывает IP с доменным именем. По сути, любая система с подключением http должна иметь свою A-запись, чтобы по доменному имени определялся привязанный к нему IP-адрес.
• NS-запись (Name Server)
  Определяет сервер, который отвечает за выбранную вами зону. У каждого домена должна быть хотя бы одна NS-запись, хотя на самом деле их может быть несколько — вплоть до отдельной записи для любого указанного поддомена.
• CNAME-запись (Name Alias)
  Позволяет создавать отсылки к ранее созданным A-записям и PTR-записям. Чаще всего используется для того, чтобы тот же сайт был доступен под разными доменными именами, например, при создании «зеркал».
• MX-запись (Mail Server)
  DNS MX-запись сообщает различным почтовым программам о том, где находится нужный почтовый сервер. Без нее предназначенная для указанного домена почта не будет отправлена на IP-адрес из A-записи.
• TXT-запись (Text)
  Применяется для добавления комментария к выбранному домену. Иначе, чем как добавить TXT-запись в DNS (при его изменении), вы не сможете привязать текст произвольного содержания к домену.
• PTR-запись (Reverse Address)
  Связывает домен хоста с его IP в обратной зоне DNS, поэтому должен быть прописан для каждого хоста отдельно. Зачастую эта запись создается автоматически, но проверка никогда не помешает. При этом сама же обратная зона DNS допускает использование только трех типов записи — PTR, NS и CNAME.

Другие, редкоиспользуемые типы записей

• LOC-запись (Location)
  Подобный тип записи востребован среди крупных компаний и организаций, так как применяется для определения месторасположения хоста с указанием широты и долготы.
• SRV-запись (Service Address)
  Используется для ассоциации домена и названия сервиса с указанием протокола на хосте. Проще говоря, с ее помощью определяется размещение сервиса на хосте.
• HINFO-запись (Host Information)
  Позволяет получить данные об архитектуре и используемой ОС хоста, так как для хранения данных подобного вида используется именно такая запись.
• WKS-запись (Well Known Service)
  Данный тип записи связывает с определенной зоной имя хостинга, номер порта и протокол сервиса. Зачастую используется на хостах, используемых в качестве почтовых серверов.
• RP-запись (Responsible Person)
  Этот тип позволяет получить данные отдельного человека или организации, ответственных за конкретно взятое доменное имя. По этой записи можно узнать e-mail ответственного лица.
• KEY-запись (Public Key)
  Используется довольно редко — для ассоциации ключа для некоторых хостингов и используется в IETF-протоколе DNS для минимизации риска атак с подменой самого DNS.

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

Как проверить DNS-записи домена?

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

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

Если же при использовании сервиса от RigWEB у вас возникли вопросы — задайте их нашей техподдержке, и вы получите ответ в течение 30 минут! Пользуйтесь профессиональным хостингом и удобными инструментами для создания и развития своих веб-проектов, ведь мы всегда готовы их вам предоставить!

Подробное руководство по настройке TTL для записей DNS / Блог компании Varonis Systems / Хабр

Система DNS — это фундаментальный технологический продукт. Обработка практически всех сетевых запросов верхнего уровня и поисковых запросов в Интернете, пересылка интернет-трафика и электронной почты, а также многие другие операции становятся возможными благодаря установке определенных соответствий при поиске DNS (преобразованию таких имен, как some.domain.org, в IP-адреса или имена других доменов).

Мы решили написать о времени жизни (Time To Live, TTL) данных, поскольку большинству системных администраторов не приходится каждый день работать с конфигурациями DNS и значительная часть информации об этом параметре — это полузабытые байки, передаваемые системными администраторами из поколения в поколение.

Задав соответствующий вопрос в Twitter, мы выяснили, что некоторые системные администраторы даже не могут расшифровать аббревиатуру TTL (хотя такие, к счастью, в меньшинстве).

Отгадайте загадку! Что означает аббревиатура TTL, когда речь идет о системе DNS?

18:43 26 окт. 2016 г.

4 % Граница терминальной передачи

85 % Время жизни

8 % Телеметрическая транспортная линия

3 % Список доверенных технологий

26 голосов • Окончательный результат

Ретвит 1 Отметка «Нравится» 1

Чтобы внести ясность, мы рассмотрим следующие темы.

1. Общие сведения о системе DNS и параметре TTL

2. Устранение проблем с TTL в записях DNS

3. Рекомендации по управлению изменениями в записях DNS

4. Инструменты DNS

5. Дальнейшие действия

1. ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ DNS

Что такое запись DNS?

Запись сервера доменных имен (Domain Name Server, DNS) содержит два важных параметра:

адресацию (установку соответствия) запросов для той или иной записи;

время актуальности записи при кэшировании — именно это значение получило зловещее название «время жизни» (TTL).

Зачем кэшируются записи DNS?

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

Что такое TTL?

Время жизни (TTL) представляет собой продолжительность кэширования записи *каждым звеном* цепочки установки соответствий DNS. Это значение измеряется в секундах (важность этого будет объяснена ниже).

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

Каково стандартное значение TTL для записей DNS?

Значение TTL всегда выражается в секундах. Большинство служб настройки конфигурации DNS содержат готовый список значений для записей.

300 секунд = 5 минут = «Очень короткое»

3600 секунд = 1 час = «Короткое»

86 400 секунд = 24 часа = «Длинное»

604 800 секунд = 7 дней = «Абсолютный максимум»

Как осуществляется поиск DNS?

Когда вы вводите в браузере какой-либо URL-адрес, создается целая серия поисков.

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

1. Кэширована ли нужная запись?

2. Если да, действительно ли ее значение TTL?

Если на какой-либо из этих вопросов получен ответ «Нет», запрос перемещается на следующее звено цепочки.

Почему в основе системы DNS лежат сетевые подключения, а не устройства?

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

Рассмотрим ситуацию на примере обычного ноутбука. Я, как правило, работаю на ноутбуке дома. Несмотря на то что я уже несколько недель никуда его не брал, за это время на устройстве устанавливались следующие подключения:

• к основной домашней сети Wi-Fi/кабельной сети;

• к мобильному телефону при недоступности кабельной сети;

• оба варианта выше, но с подключением через VPN.

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

Такое часто случается в корпоративных сетях, где имя домена Active Directory совпадает с адресом веб-сайта компании. На внешнем сервере DNS (уровень поставщика Интернета) хранится запись DNS, направляющая адрес www.example.com к верному IP-адресу/CNAME веб-сервера, но на внутреннем сервере DNS, используемом службой Active Directory, записи не дублируются.

Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через VPN.

2. УСТРАНЕНИЕ ПРОБЛЕМ С TTL В ЗАПИСЯХ DNS

Сколько времени требуется на обновление записи DNS?

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

Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).

Но если бы все было так просто.

Каковы затраты на поиск DNS?

Когда речь заходит о «затратах» на поиск DNS, обычно имеются в виду не денежные, а временные затраты. В зависимости от численности интернет-гремлинов в глобальной сети на выполнение запроса DNS обычно уходит 100–200 миллисекунд.

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

Упрощенная схема расчета затрат на поиск DNS

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

С кэшированием

(30 файлов изображений x 50 мс на загрузку каждого файла) + (100 мс на выполнение одного поиска DNS с последующим кэшированием) = 1600 мс

Без кэширования

(30 файлов изображений x 50 мс на загрузку каждого файла) + (30 x 100 мс на каждый поиск DNS) = 3000 мс

Почему мои записи DNS не обновляются?

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

• Веб-браузеры самостоятельно кэшируют записи DNS и хранят их в течение некоторого времени без учета TTL, что якобы повышает скорость их работы. Например, современные версии Internet Explorer по умолчанию кэшируют записи DNS на 30 минут (до версии IE 4 это время составляло 24 часа) и игнорируют более низкие значения TTL.

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

• Сложные внутренние сети с большим числом сервером DNS, чем предполагалось, обновляются дольше по очевидным причинам.

Именно поэтому во многих службах можно встретить следующее заявление: «Полное распространение изменений в записях DNS может занять несколько дней, поэтому планируйте свои действия соответствующим образом».

Можно ли как-нибудь принудить клиент удаленно обновить запись DNS?

Этот вопрос обычно задается в следующем контексте: «После обновления записей DNS клиент не может получить доступ к некоторым сайтам. Как выполнить обновление принудительно?»

К сожалению, единственный ответ на этот вопрос: «Никак». В системе DNS нет команды, позволяющей принудительно выполнить раннее обновление данных для клиентов более низкого уровня.

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

Лучше всего изменить значения TTL в своих записях заблаговременно.

3. РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ В ЗАПИСЯХ DNS

Какие значения TTL лучше: маленькие или большие?

Разработчики уже давно ведут священную войну по поводу того, как нужно оформлять отступы в коде: с помощью знаков табуляции или пробелов. Я выяснил, что сетевые администраторы испытывают примерно те же чувства, когда дело касается длительности TTL.

Обычно это мнение подкрепляется их собственным опытом по отражению предыдущих сетевых атак и устранению проблем с конфигурацией сети.

Атака DDOS, способная на 12 часов остановить работу корневых серверов DNS или аналогичных серверов поставщика Интернета, меньше скажется на сайтах с очень высоким значением TTL. В таких случаях клиенты будут работать даже при выключении или перегрузке сервера DNS.

Однако, если при переключении узлов Интернета или электронной почты вы случайно сделаете ошибку, 12 часов без какой-либо возможности устранить ее — это последнее, что вам будет нужно. Именно поэтому некоторые администраторы считают, что время жизни не должно превышать 1 минуты.

Лично я стараюсь указывать для записей DNS малое значение TTL (меньше 1 часа/3600 секунд).

Как узнать, когда клиент запросит обновленную запись DNS?

Определить, когда все клиенты обновят данные, очень сложно.

Время жизни — это *не* срок годности. Не стоит сравнивать значение TTL в записи DNS с рекомендуемой датой употребления, указанной, например, на несвежем хлебе: это не определенное время, при наступлении которого запись станет недействительной и потребует замены.

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

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

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

1. За несколько дней до переключения укажите для параметра TTL записи DNS низкое значение, например 300 секунд.

2. Установите для записи дату переключения.

3. Через несколько дней после переключения задайте более высокое значение TTL.

Как лучше всего добавлять новые записи DNS?

Добавить новую запись проще, чем изменить существующую.

1. Добавьте запись с низким значением TTL.

2. Проверьте, все ли работает, и увеличьте значение TTL.

Какое значение TTL наиболее распространено?

Мнения относительно *правильного* значения TTL настолько расходятся, что мы предприняли попытку определить его на основе статистики. Список из 500 самых важных веб-сайтов по версии Moz показался нам отличным срезом Интернета. Кроме того, на этом ресурсе был доступен готовый файл CSV с перечнем сайтов, вошедших в итоговый список.

Я написал небольшой сценарий для выполнения итерации по списку и поиска текущего значения TTL для основной записи в каждом домене. Как и в любом проекте по анализу данных, эти данные будут сильно варьироваться в зависимости от постановки вопроса. Пример не всеобъемлющий, в нем представлены текущие (кэшированные) результаты и т. д. и т. п. Невзирая на все эти оговорки, полученные результаты все же имеют определенную ценность.

Анализ значений TTL для 500 важнейших интернет-доменов по версии Moz

Вы можете просмотреть или изменить этот сценарий либо загрузить его и выполнить анализ самостоятельно: gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b

Посмотреть список и загрузить его в формате CSV можно по адресу moz.com/top500

Минимальное значение TTL: 1

Максимальное значение TTL: 129 540

Домены с установленным соответствием: 485

Среднее арифметическое значение TTL: 6468

Медианное значение TTL: 300

Минимальные значения были получены от доменов, которые очень часто изменяют записи DNS в целях балансировки нагрузки. Максимальные значения соответствовали доменам, которые не обновлялись в течение длительного времени (да-да, python.org, это я про вас).

При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.

4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS

Как проверить значение TTL для записи DNS в Windows?

Для проверки записей DNS в Windows проще всего использовать служебную программу nslookup: technet.microsoft.com/en-us/library/bb490950.aspx.

Пример: C:\>nslookup -type=cname -debug www.varonis.com

Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).

Как проверить значение TTL для записи DNS в Unix/Linux/Mac?

В системе Unix (и ее производных) для устранения проблем с DNS используется команда dig.

Пример: dig www.varonis.com

Значение TTL обведено красным цветом.

Как проверить запись DNS через Интернет?

Иногда бывает так, что вам необходимо проверить запись DNS без компьютера под рукой. Удобная (и бесплатная) версия команды dig доступна в инструментах Google по следующему адресу: toolbox.googleapps.com/apps/dig.

Значение TTL обведено красным цветом.

Как убедиться в распространении TTL для записи DNS?

Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.

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

ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS

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

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

Как проверить DNS записи домена: список инструментов и инструкция | Блог о email маркетинге

Содержание

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

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

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

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

Для начала давайте разберемся, что же такое DNS. Если простыми словами — это переводчик с языка, понятного людям, на язык, понятный компьютерам, и наоборот.

Как это работает. При слове “сайт” вам не задумываясь назовут 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.

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

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

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

Для проверки записей 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. Проведенное вовремя тестирование позволит избежать проблем с почтовыми провайдерами.

При работе с сервисом рекомендуем в первую очередь проверить здоровье вашего домена Domain health. 

Впишите в специальное поле доменное имя ресурса без http:// и www и нажмите на оранжевую кнопку. 

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

Домен здоров, если не будет выявлено проблем, обозначенных красным цветом. Но результат проведенной проверки показал наличие ошибок, которые необходимо устранить — отсутствие записей 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.

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

Как управлять DNS-записями домена?

Если вы успешно прикрепили свой домен к сайту в uKit, то вам становится доступно редактирование DNS-записей в настройках домена. Чтобы попасть в редактирование записей, перейдите в раздел «Домены», откройте вкладку «Прикреплённые домены» и напротив нужного вам домена нажмите на шестерёнку. Перед вами откроется окно с несколькими вкладками, перейдите во вкладку «Редактирование записей» — именно здесь вам будет доступно добавление различных DNS-записей в настройках домена.

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

Каждая из этих записей используются для различных целей, рассмотрим каждую запись отдельно.

MX-записи

MX-запись предназначена для работы электронной почты. По умолчанию записи размещаются следующим образом:

• Name: @ (если вы подключаете почту для текущего домена)
• Preference: 10
• Exchange: Адрес сервера

Примеры записей:

• @ MX 10 mx.yandex.net
• @ MX 10 emx.mail.ru

TXT-записи

TXT-запись содержит в себе какую-либо текстовую запись. Широко применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также для записи SPF и ключа DKIM. По умолчанию записи размещаются следующим образом:

• Name: @ (либо имя поддомена)
• TXT-DATA: Любая текстовая информация

Примеры записей:

• @ TXT v=spf1 redirect=_spf.yandex.net
• mail._domainkey TXT v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCm+3/BtqNb0jb0O3R2t/T3qJedMUQM78Me6wFVuMfuNUWpTIbFkst7QiaF7K4YezusS/UmZjbt5fRgZArbWxMMuy2/Rn/iQEvhDN+BLAbGi0tr3U+rp3lAOKly/cc2Kum2/Y+IE08SKuUq3aHQlkZnMcDY7KYmuHB98Kl8uI/gYQIDAQAB

CNAME-записи

CNAME-запись позволяет присваивать желаемому адресу псевдоним. Этот псевдоним обычно связывает с адресом какую-нибудь функцию (например, чтобы можно было попасть в почту для домена введя mail.mysite.ru), либо просто сокращает его имя. CNAME-запись по умолчанию заполняется следующим образом:

• Name: Имя поддомена
• CNAME: Адрес, на который будет ссылаться указанный поддомен

Примеры записей:

• mail CNAME domain.mail.yandex.net
• mail CNAME biz.mail.ru

A-записи

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

• Name: Имя поддомена
• Address: IP-адрес сервера

Примеры записей:

Примечание:

А-запись для основного домена по умолчанию уже установлена и изменить её не получится.

SRV-записи

SRV-запись — стандарт в DNS, определяющий местоположение, то есть имя хоста и номер порта серверов для определённых служб. Большинство сервисов предоставляют SRV-запись в следующем виде:

• _service._proto.name TTL class SRV priority weight port target

В конструкторе uKit они по умолчанию размещаются следующим образом:

• Name: Название сервиса и протокола
• Priority: Приоритет
• Weight: Вес
• Port: Порт
• Target: Цель

Примеры записей:

• _xmpp-server._tcp SRV 20 0 5269 domain-xmpp.ya.ru
• _autodiscover._tcp SRV 0 0 443 autodiscover.secureserver.net

Совет:

Если вам необходимо указать другие записи, напишите в службу поддержки.

Помогла ли вам статья?

Статья оказалась полезной для 113 человек

DNS-записей — Найдите самый популярный тип DNS-записей

DNSPropagation.net Team
|
19 марта 2018 г.

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

Тип DNS-записей

Существует множество различных типов DNS-записей, наиболее распространенными из которых являются A, NS, MX, TXT, SOA и CNAME, однако есть и другие, которые очень важны для наших повседневных задач в качестве системных администраторов или инженеров DevOps. В этом видео мы покажем вам основные записи DNS

Однако, если вы хотите глубже понять каждого из них, продолжайте читать:

А записи

записи A используются для указания домена или субдомена на определенный IPv4-адрес.Например, если вы укажете mydomain.com на IP 1.1.1.1, то этот домен будет сопоставлен с сервером 1.1.1.1.

Запись A, вероятно, является наиболее часто используемым типом записи DNS в мире . Его основная функция — указать домен или субдомен на определенный IP-адрес. Другими словами, благодаря записям A вы можете получить доступ к веб-сайту в Интернете, и без них мы были бы полностью неспособны делать 99% того, что мы делаем в Интернете в настоящее время.

А почему запись «А»? Буква «A» на самом деле означает «адрес», потому что, как мы уже сказали, такие записи помогают вам (или, скорее, вашему компьютеру) найти правильный сервер при попытке доступа к веб-сайту.Если у вас есть сайт под названием «mydomain.com» и его запись A указывает на 1.1.1.1.1, это означает, что когда кто-то делает запрос на mydomain.com, он будет направлен на сервер, которому назначен IP-адрес 1.1. 1.1.1.

Записи A имеют довольно простой формат, а также очень просты в использовании и настройке. Давайте посмотрим на пример записи A:

 mydomain.com. 14400 IN A 1.1.1.1 

Во-первых, у нас есть наш домен (или субдомен), которым в примере является mydomain.com, но это может быть любой другой домен или даже подобный субдомену.domain2.com и т. д.
Затем у нас есть TTL (время жизни), обычно оно устанавливается равным 14400 и определяет, сколько секунд требуется, чтобы наша запись полностью вступила в силу. Обычно подходит значение TTL 14400, но вы можете использовать более низкий, если хотите, например, 1800 или 3600.

После этого идет класс IN, затем запись типа «A».
И последнее, но не менее важное: у нас есть адрес, то есть IP, на который должна указывать наша запись A. Итак, если вы хотите, чтобы mydomain.com отображался на сервере 1.1.1.1, то здесь необходимо установить значение «1.1.1.1».

Пример, показывающий общую конфигурацию записи DNS в Cloudflare, одном из самых популярных поставщиков DNS

Записи MX

Записи MX очень важны для правильного функционирования систем электронной почты . Название этого типа записи происходит от Mail eXchanger или MX. Если эта запись не установлена ​​должным образом, наша электронная почта может вообще не работать или просто работать непредвиденным образом.

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

Очень распространенным примером нескольких записей MX является конфигурация по умолчанию, запрашиваемая такими службами, как G Suite, которая для правильной работы требует, чтобы пользователь установил несколько разных записей MX. Сейчас конфигурация следующая:

 mydomain.com. 3600 мкс 1 ASPMX.L.GOOGLE.COM
mydomain.com. 3600 MX 5 ALT1.ASPMX.L.GOOGLE.COM
mydomain.com. 3600 мкс 5 ALT2.ASPMX.L.GOOGLE.COM
mydomain.com. 3600 мкс 10 ALT3.ASPMX.L.GOOGLE.COM
mydomain.com. 3600 мкс 10 ALT4.ASPMX.L.GOOGLE.COM 

Как мы видим, в этом примере у нас всего 5 записей MX для домена mydomain.com, каждая из которых указывает на другой сервер. Различия между ними заключаются в приоритете и значении назначения. Во-первых, у нас есть простой домен, например, мы сказали «mydomain.com».Затем у нас есть TTL, в данном случае установленное на 3600 в 5 примерах, затем идет запись MX, приоритет (используется для указания, какой сервер должен получить письмо первым) и имя хоста почтового сервера.

В случае приоритета меньше значит больше, поэтому в этом примере сервер «ASPMX.L.GOOGLE.COM» будет получать электронные письма перед «ALT1.ASPMX.L.GOOGLE.COM», а этот — их. перед ALT3.ASPMX.L.GOOGLE.COM. В случае записей с одинаковым приоритетом любой из них может получить электронное письмо.

Помните, что после настройки записей Google MX для полного распространения DNS потребуется до 4-8 часов.

Записи CNAME

записи CNAME являются одними из наиболее распространенных типов записей DNS. Аббревиатура «CNAME» на самом деле означает каноническое имя, и, как предполагается, , этот вид записи используется для создания псевдонима между двумя разными доменами .

Допустим, у вас есть веб-сайт, на котором вы храните различные типы записанных данных, и вы обычно получаете доступ к нему с помощью mydata.mydomain.com. Что, если вы также хотите иметь к нему доступ, используя другой субдомен, например, что-то вроде myshinydata.mydomain.com? В этом случае вам просто нужно создать запись CNAME, которая будет указывать myshinydata.mydomain.com на mydata.mydomain.com. После установки новой записи CNAME вы сможете просматривать содержимое mydata.mydomain.com через myshinydata.mydomain.com

Чтобы запись CNAME работала, сначала нам понадобится запись A для псевдонима домена. Если мы хотим, например, создать запись CNAME для mydomain.com, который указывает myotherdomain.com, то будут использоваться следующие записи:

 mydomain.com. 14400 IN A 2.2.2.2
myotherdomain.com. 14400 В CNAME mydomain.com. 

Если нет записи A, то запись CNAME ничего не будет отображать при доступе к myotherdomain.com
Как видите, формат записи CNAME довольно прост, мы должны сначала указать наш домен / поддомен с точкой в конец, затем наш TTL, после этого класс IN, затем идет запись CNAME и в последней позиции домен / поддомен, на который мы хотим указать, за которым следует точка (.) в конце.
Точки в конце имени домена очень важны в большинстве систем, потому что, если мы их не используем, DNS примет домен в качестве поддомена, поэтому вместо subdomain.domain.com вы получите subdomain.domain. com.domain.com. Некоторые системы включают точку автоматически, но если вы не уверены в этом, всегда лучше ввести точку самостоятельно.

Записи NS

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

Это пример записи NS:

 mydomain.com. 1800 IN NS ns1.domainprovider.com. 

Давайте разберемся и рассмотрим подробнее:

Во-первых, конечно, у нас есть наш домен, который, как обычно, должен иметь точку в конце, иначе система DNS может перепутать с поддоменом, и это может быть большим беспорядком, поэтому обязательно используйте точку в конце доменного имени.
Позже появится TTL — время, которое потребуется нашей записи для полного распространения на все системы. Системы DNS используют много кэшированных записей, и по истечении срока жизни запись снова проверяется, чтобы убедиться, что она изменилась.
Класс IN — это самый распространенный класс в системах DNS, а затем у нас есть тип записи, в данном случае NS.
В последней части находится значение записи, которым в примере является «ns1.domainprovider.com.», И еще раз обратите внимание на точку в конце. Это та часть, которая сообщает нам, что «domainprovider.com »имеет власть над записями нашего домена.

Мы должны упомянуть, что можно даже настроить записи NS, если, конечно, провайдер позволяет это. Для того, чтобы это работало, нам потребуются две вещи: пара A-записей NS-записей и пара DNS-серверов, созданных в панели управления регистратора. Рассмотрим пример с ns1.mydomain.com и ns2.mydomain.com, в зоне DNS необходимы следующие записи:

 нс1 14400 IN A 1.1.1.1
ns2 14400 IN A 1.1.1,2 

И в панели управления регистратора должны быть созданы те же записи, то есть «ns1» (ns1.mydomain.com), указывающие на 1.1.1.1, и «ns2» (ns2.mydomain.com), указывающие на 1.1.1.2.

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

TXT записей

Записи TXT имеют разные функции, но все они используются для отображения определенных видов информации или данных. Записи TXT используются для управления важными записями, такими как SPF, DKIM, DMARC и другими.

Записи SPF

Запись SPF, также известная как запись структуры политики отправителя, является одной из самых важных записей, касающихся служб электронной почты. Почему это так важно? Поскольку он скажет, какие хосты авторизованы для отправки электронных писем из определенного домена . Если запись SPF не установлена ​​должным образом, есть вероятность, что ваши электронные письма будут отклонены 90% получателей.

Чтобы определить запись SPF, нам нужно использовать запись TXT. На самом деле создать запись SPF довольно просто, давайте сначала рассмотрим пример:

 mydomain.com. 3600 IN TXT "v = spf1 a mx ip4: 1.1.1.1 include: _spf.google.com ~ all" 

Итак, что именно это означает? Как обычно, сначала у нас есть домен, затем TTL, поле класса IN, тип TXT и в последней части данные SPF. В этом примере мы в основном говорим, что серверы, авторизованные для отправки электронных писем с mydomain.com, — это 1.1.1.1 и _spf.google.com (это используется, например, для таких сервисов, как G Suite). Если вы хотите авторизовать другой сервер для отправки электронной почты, просто отредактируйте данные SPF следующим образом:

 "v = spf1 a mx ip4: 1.1.1.1 ip4: 2.2.2.2 включают: _spf.google.com ~ all "

В данном случае сервер 2.2.2.2 авторизован для отправки писем с myshinydomain.com

Очень часто сторонние поставщики почтовых услуг, такие как Zoho, Google и т. Д., Просят пользователя установить включение в запись SPF, что позволит вам использовать их услуги для отправки писем из вашего домена, даже если ваш домен размещен. у другого провайдера.

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

Записи DKIM

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

Записи DKIM были рождены как средство борьбы со спамом. Например, если в спам-сообщении используется поддельное поле «От:», получатель может подумать, что полученное электронное письмо пришло из допустимого источника, и приступить к его открытию. В этом случае у пользователя нет способа узнать, исходит ли электронное письмо из реального источника или нет, и здесь в игру вступает запись DKIM.Благодаря этому сервер-получатель может проверить, исходит ли электронное письмо от реального источника или от поддельного, и, следовательно, отклонить его.

записи DKIM обычно представляют собой запись TXT, состоящую из поддомена, такого как dkimexample._domainkey, TTL, поля класса IN и поля данных, которое обычно представляет собой набор цифр и букв, которые не имеют смысла для обычного глаза, но имеют смысл для почтовых серверов. Давайте посмотрим на пример, чтобы лучше понять:

 dkimexample._domainkey.mydomain.com 3600 IN TXT "к = RSA; р = MNS8HFNinmdf7gsDGDS + MBJNiKMDSOud45X2MgmO8PQHHcGxoim7mI + FhgOiOS5WgBUpZsrMXnWIS + zrR1xLOS0xDf9suh + Tl4tViX15 / ItB7 + x8FGU7Z5XRK6OwwNcCTQ4OHCTk3WjzF5YU / KFx0riP / wsIDAQAB;" 

Использование записей DKIM очень важно для правильной аутентификации наших электронных писем. Если вы используете сторонние почтовые службы, такие как G Suite, SendGrid и т. Д., Они, вероятно, попросят вас добавить правильную запись DKIM, если у вас ее нет, и они также предоставят вам свой ключ данных для нее, который, как мы сказали, что их нужно использовать в записи TXT.В некоторых случаях вместо этого провайдер может попросить вас создать конкретную запись CNAME для аутентификации ваших писем.

PTR записей

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

Записи

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

SOA

Записи SOA

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

SOA означает «Начало полномочий», и каждая доменная зона должна иметь один для правильной работы . Что именно делает эта запись? По сути, он отмечает точку, в которой домен делегируется из родительского домена.Поясним это на примере.

Допустим, вы указываете домен myshinydomain.com, используя серверы имен хостинг-провайдера. В зоне DNS домена провайдер хостинга должен установить запись SOA (часто устанавливается автоматически). Это разрешение на использование службы DNS.

Запись SOA обычно выглядит так:

 ns1.hosingprovider.com admin.hostingprovider.com 20180120 86400 7200 604800 300 

И вот значение каждого предмета:

• Во-первых, у нас есть ns1.hosingprovider.com, который в примере является основным сервером имен.
• После этого у нас будет admin.hostingprovider.com, ответственный за службу DNS.
• Далее у нас есть отметка даты, в данном случае это будет 2018 год — январь — день 20. Это помогает отслеживать самые последние изменения в зоне DNS.
• На четвертом месте — количество секунд до обновления зоны DNS.
• Тогда есть количество секунд до повторной попытки обновления в случае сбоя.
• Далее, у нас есть ограничение в секундах до того, как зона DNS перестанет быть авторитетной.
• И последнее, но не менее важное: у нас есть отрицательный TTL, который в основном означает, как долго отрицательный результат должен считаться таким, прежде чем пытаться снова.

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

Записи AAAA

Запись

ALIAS — это особый тип записи DNS, который недоступен ни одному провайдеру, поэтому не удивляйтесь, если у вашего провайдера ее нет. Эта виртуальная запись очень полезна для указания вашего домена на определенное имя хоста .

Допустим, вы хотите указать yourdomain.com на yourapp.shinydomain.com. Для этого типа записи вы не можете использовать запись A (потому что они используют IP-адреса), и вы не можете использовать запись CNAME, поэтому запись ALIAS вступает в игру.С его помощью вы сможете точно указать домен / поддомен на другой домен / поддомен. Для преобразователей это будет выглядеть так, как будто ваш домен просто указывает на тот же IP-адрес указанного домена через запись A.

Этот вид записи, хотя и выглядит простым, на самом деле требует сложной настройки для работы. Его можно настроить, например, с помощью DNS-сервера Erlang, который является программным обеспечением с открытым исходным кодом. Этот тип сервера позволяет администраторам выполнять множество настроек, благодаря которым можно создавать собственные записи, такие как ALIAS.Чтобы записи ALIAS работали должным образом, сервер распознавания также должен указывать записи A / AAAA на соответствующие серверы. Информация, предоставленная сервером распознавателя, используется сервером Erlang, чтобы указать домен / поддомен на правильный адрес при получении запроса. Конечно, все это происходит в мгновение ока, и система на самом деле не так проста в настройке, это лишь поверхность.

Записи CAA

Записи CAA, также известные как записи авторизации центра сертификации, используются для определения центров сертификации, которые могут выдавать сертификат SSL для домена .

Обычно большинству центров сертификации разрешено выпускать сертификаты SSL для большинства доменов, но в некоторых особых случаях возможно разрешить только определенному органу делать это для определенного домена. Используя записи CAA, владелец домена может указать, каким центрам сертификации разрешено выдавать сертификат SSL для домена.

Этот вид записи также работает как уведомление, когда кто-то пытается запросить сертификат SSL через запрещенный центр сертификации.Если запись CAA отсутствует, то любой центр сертификации может выдать сертификат SSL для домена. Если запись CAA существует, то только центры сертификации, перечисленные в записи, могут выдавать сертификат.

Запись CAA может определять политику сертификатов для всего домена или для определенных имен хостов. Записи CAA применяются также для поддоменов, поэтому, если у нас установлен CAA для mydomain.com, он также будет применяться для example.mydomain.com или любого другого поддомена. С помощью записей CAA мы также можем контролировать тип сертификата, который может использоваться, например, должен ли он быть для одного имени или должен быть SSL с подстановочными знаками.

Давайте посмотрим на небольшой пример, в котором указано, что только центр сертификации Let’s Encrypt может выдать сертификат для mydomain.com:

 mydomain.com. CAA 0 issue "letsencrypt.org" 

И если мы хотим разрешить COMODO, мы должны установить две записи, по одной для каждого центра сертификации.

 mydomain.com. CAA 0 проблема "letsencrypt.org"
mydomain.com. CAA 0 issue "comodoca.com" 

Конечно, есть много других примеров, которые мы могли бы использовать, и, как мы уже говорили, есть несколько различных конфигураций, которые мы можем установить, например, чтобы разрешить выдачу только одноименных сертификатов или сертификатов с подстановочными знаками.Если мы хотим, чтобы Let’s Encrypt было разрешено выдавать SSL с подстановочными знаками, запись будет выглядеть так:

 mydomain.com. CAA 0 issueewild "letsencrypt.org"

 

POOL записей

Запись POOL — это особый тип записи, доступный не всем провайдерам. Что делает эта запись? Используя этот вид записи, вы можете создавать записи CNAME для одного и того же поддомена. Это означает, что субдомен может иметь более одной записи CNAME, и каждый запрос к вашему субдомену будет указывать на одну из этих записей CNAME.

Это работает как установка Round Robin DNS, поскольку перенаправляет ваши запросы на разные хосты. Например, вы можете установить одну запись для хоста в Великобритании, а другую — для хоста в США или где-либо еще. В случае, если один из узлов перестает отвечать или работать, вы можете удалить одну из записей POOL и установить другую, но, конечно, некоторые запросы все равно будут перенаправлены на отказавший узел до тех пор, пока кеш DNS не будет очищен, что обычно не происходит. это не займет много времени.

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

Запись URL

Записи URL

— это особый тип записей DNS, которые доступны не всем поставщикам и / или панелям управления. Задача записи URL-адреса — перенаправить имя хоста на указанный URL-адрес , для которого используется инструмент перенаправления.

С помощью такой специальной записи вы можете, например, перенаправить свой домен на URL-адрес другого домена, и вам не придется использовать записи A или CNAME. Обычно эта запись используется для перенаправления посетителей www.yourdomain.com на yourdomain.com, или вы также можете использовать его для перенаправления something.yourdomain.com на anotherdomain.com

В чем секрет этого? На самом деле это довольно просто: записи URL обычно используют перенаправление HTTP 301 — тот же тип перенаправления, который используется веб-серверами, такими как Apache и Nginx, для постоянного указания домена на другой домен.

Как мы уже говорили, записи URL — это особый тип записей, и не все провайдеры будут иметь их в вашем распоряжении. В то время как другие, такие как записи MX, записи A, записи TXT и т. Д., Доступны везде, записи URL — нет.

В случае, если у вашего провайдера нет доступных записей URL, вы можете использовать запись A, чтобы указать ваш домен на сервер, а затем настроить файл .htaccess (или эквивалент веб-сервера), чтобы установить 301 перенаправление.

SRV записей

Используя Service Resource Records (SRV) , вы можете сказать, какие услуги вы хотите предложить для своего домена или субдомена. Записи SRV часто используются для таких протоколов, как XMPP, LDAP и SIP , а также для таких сервисов, как Office 365.

Этот вид записи состоит из следующих элементов: транспортный протокол, символическое имя, номер приоритета, весовой коэффициент, номер порта и цель.

Здесь вы можете увидеть два примера записей SRV:

 _xmpp._tcp.mydomain.com. 3600 IN SRV 5 40 4070 example1.somedomain.com.
_xmpp._tcp.mydomain.com. 3600 IN SRV 5 30 4070 anotherexample.somedomain.com. 

Давайте посмотрим на это подробнее:

_xmpp — это символическое имя, которое мы используем для службы.Имейте в виду, что это символическое имя должно начинаться с подчеркивания (_).
_tcp будет нашим транспортным протоколом. Как и символическое имя, транспортный протокол тоже должен начинаться с подчеркивания.

После этого у нас есть TTL, IN — это обычное поле класса DNS, а затем у нас есть приоритет для нашей записи, в данном случае 5 для них обоих.
Вес нашей первой записи равен 40, а вес второй записи — 30. Такие значения, как приоритет и вес, используются для того, чтобы серверы использовали одну запись вместо другой.Сначала используется мишень с наибольшим весом.

И последнее, но не менее важное: у нас есть номер порта, который равен 4070 в обеих записях, и цели, которые являются двумя типичными примерами. Имейте в виду, что целью всегда должна быть запись с адресом A или AAAA, использование CNAME не сработает.

Как мы видели, система доменных имен (DNS) может использовать информацию, предоставленную записями SRV, для поиска серверов, которые мы используем для определенных услуг.

Следующие службы часто используются вместе с записями SRV: CalDAV / CardDAV, DANE, DNS-SD, Kerberos, LDAP, IMPS, SIP, STUN, XMPP и т. Д.

Артикул:

.

Что такое запись DNS? Разъяснение типов записей DNS

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

Что такое запись DNS?

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

Когда вы посещаете microsoft.com, например, вы отправляете запрос на DNS-сервер, тогда DNS-сервер будет искать тип DNS-записи, которую вы запрашиваете, это может быть A, CNAME, TXT, NS, Запись MX или PTR.

Другой пример, когда вы отправляете электронное письмо, ваш почтовый сервер должен будет знать MX-запись последнего домена, на который вы отправляете. Следуя примеру microsoft.com, давайте посмотрим, какая запись MX для их почтового сервера:

 [webtech @ localhost ~] $ dig MX microsoft.com

; << >> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 << >> MX microsoft.com
;; глобальные параметры: + cmd
;; Получил ответ:
;; - >> HEADER << - код операции: QUERY, статус: NOERROR, id: 62469
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 1, АВТОРИТЕТ: 4, ДОПОЛНИТЕЛЬНО: 9

;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ:
; EDNS: версия: 0, флаги :; UDP: 512
;; РАЗДЕЛ ВОПРОСА:
; microsoft.com. IN MX

;; РАЗДЕЛ ОТВЕТА:
microsoft.com. 3600 В MX 10 microsoft-com.mail.protection.outlook.com.
...
...
... 

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

Типы записей DNS

Существует несколько типов записей DNS, давайте кратко объясним каждую из них:

• A-записи
• AAAA-записи
• CNAME-записи
• NS-записи
• MX-записи
• PTR-записи
• Записи TXT
• Записи A

Записи адреса (A) используются для сопоставления имен хостов с числовыми IP-адресами.Например, nixcp.com имеет запись A, указывающую на IP-адрес XX.XX.XX.XXX.

Другая запись адреса (A) настроена для поддомена www.nixcp.com, указывающая на тот же адрес.

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

Этот тип записей выглядит так:

nixcp.com. 1800 IN A 66.55.147.204

Записи AAAA

Запись AAAA практически такая же, как и запись A, с той лишь разницей, что она используется для адресов ipv6 вместо ipv4.

Записи MX

Записи MX позволяют использовать несколько записей, так же, как в Google Apps используются настройки MX при покупке учетной записи электронной почты, например:

 domain.com. 3,600 мкс 1 ASPMX.L.GOOGLE.COM
domain.com. 3,600 мкс 5 ALT1.ASPMX.L.GOOGLE.COM
domain.com. 3,600 мкс 5 ALT2.ASPMX.L.GOOGLE.COM
domain.com. 3,600 мкс 10 ALT3.ASPMX.L.GOOGLE.COM
domain.com. 3.600 MX 10 ALT4.ASPMX.L.GOOGLE.COM 

MX (почтовый обменник) записи позволяют отправлять и получать сообщения электронной почты.

Записи CNAME

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

Например, у вас есть корневая запись A для вашего основного домена domain.com, указывающая на IP-адрес XX.XX.XX.XX.

Затем вы создаете CNAME для субдомена www.domain.com, этот CNAME будет псевдонимом вашей текущей записи A, и он будет отображать ту же информацию.

NS-записи

NS означает «NameServer», и это тип записей, используемых для определения авторитетных серверов имен для домена, например:

 yourdomain.com NS ns1.yourdns.com.
yourdomain.com NS ns2.yourdns.com. 

PTR-записи

PTR-записи (записи указателей) используются для обратного просмотра. Например, если я хочу преобразовать 192.168.1.110 в www.yourdomain.com, запись будет иметь вид:

 110.1.168.192.in-addr.arpa PTR www.yourdomain.com. 

Этот тип записей также называется rDNS и часто используется, когда у вас есть собственный выделенный IP-адрес в среде общего хостинга или выделенный / vps / облачный сервер.

Запись TXT

Запись TXT используется для размещения текстовой информации, наиболее распространенные записи TXT используются для хранения информации SPF (структура политики отправителя), это способ предотвратить спам и пометить письма от различных поставщиков электронной почты как надежные.Записи TXT выглядят так:

 yoursite.com. 1800 IN TXT "yandex-verify: 5987d3c0a4384" 

Это пример типа записи TXT, используемой Яндексом для своей системы статистики.

Заключение

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

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

.

DNS-записи | Объяснение типов записей ресурсов

.

Найдите записи DNS с помощью нашего простого онлайн-инструмента

Поделиться - это забота!

Инструмент DNS Records позволяет получить записи доменного имени для указанного вами доменного имени.

Использование

Доступны две версии инструмента. Чтобы использовать основной инструмент, введите имя домена в текстовое поле и нажмите «Перейти».

Когда это использовать

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

NsLookup

В дополнение к инструменту DNS Records мы предлагаем более продвинутый инструмент NsLookup, который позволяет вам выбрать DNS-сервер для запроса и тип запрашиваемых записей. Если инструмент DNS Records не указывает на какие-либо проблемы, но проблемы все еще возникают, использование NsLookup для указания на другой сервер может вернуть полезные сведения.

NsLookup также позволяет проверить, предоставляют ли несколько серверов согласованную и актуальную информацию.

Более глубокий взгляд

Система доменных имен работает путем передачи информации с одного сервера на другой.

Авторитетные серверы

Первым сервером, который «получит» информацию, относящуюся к имени домена, является тот, которому принадлежит домен или его хост. Это авторитетный сервер. Затем полномочный сервер распространяет информацию о домене на корневые серверы и другие серверы по всему миру. Этот процесс может занять до пары дней.

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

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

Корневые серверы

Существует тринадцать корневых DNS-серверов. Они хранят достоверную информацию о доменах верхнего уровня с использованием самых популярных расширений, таких как .com , .org и .net .

Они также держат следующие рекорды почти для всех доменов:

• A: IPv4-адрес
• AAAA: IPv6-адрес
• NS: полномочный сервер для зоны домена.

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

Распространение DNS

Скорость распространения зависит главным образом от значения TTL (время жизни) записей. Это определяет, как долго запись DNS будет кэшироваться на локальном сервере (преобразователе). Более низкое значение приведет к более быстрому обновлению резолверов.

Поскольку записи домена меняются нечасто, TTL должен быть достаточно высоким. Типичные значения варьируются от 3600 секунд (1 час) до 86400 секунд (1 день). Может возникнуть дополнительная задержка в предоставлении доступа к записям на официальном сервере.

Интересные штучки

Некоторые факты о доменных именах и системе доменных имен на протяжении многих лет:

• Имена хостов и доменные имена появились очень рано в истории Интернета (ARPANET), потому что «network-tools.com» намного легче запомнить, чем «45.79.14.160».
• Первоначальная идея доменных имен, изложенная в RFC 811, предусматривала создание одного сетевого сервера имен хостов в Интернете с таблицей хостов. Однако это было не очень масштабируемо.
• Система доменных имен (RFC 1034) появилась в 1987 году.Он был разработан для использования нескольких серверов и кеширования. Несмотря на хрупкость, это (в основном) система, которая работает сегодня.
• Иногда люди распространяют ложную информацию через систему DNS. Это делается для запуска таких вещей, как атака отказа в обслуживании на сервере, которая может закрыть большую часть Интернета.

.