Разное

Ns запись dns: DNS записи – NS, CNAME, TXT, A, AAAA

25.05.2018

Содержание

Давайте уже разберемся в DNS / Хабр


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

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


Что такое DNS

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

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


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

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

petekeen.net, который хостится на машине web01.bugsplat.info. Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).

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

$ dig web01.bugsplat.info

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

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

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

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

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

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

Тут говорится, что у хоста 

web01.bugsplat.info. есть один адрес A192.241.250.244. Число 300 это TTL, или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet. Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA’s DNS Parameters.

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

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

В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (

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

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

Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес 

web01.bugsplat.info?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig‘у, если бы информация не был закэширована:

$ dig +trace web01.bugsplat.info

; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info
;; global options: +cmd
.           137375  IN  NS  l.root-servers.net.
.           137375  IN  NS  m.root-servers.net.
.           137375  IN  NS  a.root-servers.net.
.           137375  IN  NS  b.root-servers.net.
.           137375  IN  NS  c.root-servers.net.
.           137375  IN  NS  d.root-servers.net.
.           137375  IN  NS  e.root-servers.net.
.           137375  IN  NS  f.root-servers.net.
.           137375  IN  NS  g.root-servers.net.
.           137375  IN  NS  h.root-servers.net.
.           137375  IN  NS  i.root-servers.net.
.           137375  IN  NS  j.root-servers.net.
.           137375  IN  NS  k.root-servers.net.
;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms

info.           172800  IN  NS  c0.info.afilias-nst.info.
info.           172800  IN  NS  a2.info.afilias-nst.info.
info.           172800  IN  NS  d0.info.afilias-nst.org.
info.           172800  IN  NS  b2.info.afilias-nst.org.
info.           172800  IN  NS  b0.info.afilias-nst.org.
info.           172800  IN  NS  a0.info.afilias-nst.info.
;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms

bugsplat.info.      86400   IN  NS  ns-1356.awsdns-41.org.
bugsplat.info.      86400   IN  NS  ns-212.awsdns-26.com.
bugsplat.info.      86400   IN  NS  ns-1580.awsdns-05.co.uk.
bugsplat.info.      86400   IN  NS  ns-911.awsdns-49.net.
;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms

web01.bugsplat.info.    300 IN  A   192.241.250.244
bugsplat.info.      172800  IN  NS  ns-1356.awsdns-41.org.
bugsplat.info.      172800  IN  NS  ns-1580.awsdns-05.co.uk.
bugsplat.info.      172800  IN  NS  ns-212.awsdns-26.com.
bugsplat.info.      172800  IN  NS  ns-911.awsdns-49.net.
;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms

Информация выводится в иерархической последовательности. Помните как 

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

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

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

NS-записи для вас.

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

$ dig -x 192.5.5.241

; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;241.5.5.192.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
241.5.5.192.in-addr.arpa. 3261  IN  PTR f.root-servers.net.

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

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

web01.bugsplat.info.. И, наконец, получает ответ!

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


Другие типы

Есть еще несколько типов, о которых стоит знать. Первый это 

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

$ dig petekeen.net mx

; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;petekeen.net.          IN  MX

;; ANSWER SECTION:
petekeen.net.       86400   IN  MX  60 web01.bugsplat.info.

;; Query time: 272 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:33:43 2013
;; MSG SIZE  rcvd: 93

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

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

$ dig www.petekeen.net

; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.petekeen.net.      IN  A

;; ANSWER SECTION:
www.petekeen.net.   86400   IN  CNAME   web01.bugsplat.info.
web01.bugsplat.info.    300 IN  A   192.241.250.244

;; Query time: 63 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:36:58 2013
;; MSG SIZE  rcvd: 86

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


Что не так с CNAME

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

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

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


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

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

$ dig www.petekeen.net @8.8.8.8

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


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

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


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

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

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

$ dig iskettlemanstillopen.com
;; QUESTION SECTION:
;iskettlemanstillopen.com.  IN  A

;; ANSWER SECTION:
iskettlemanstillopen.com. 500   IN  A   192.64.119.118

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

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

CNAME для Heroku или Github

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

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

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


Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info. Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

$ dig randomapp.web01.bugsplat.info

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

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

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:


Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

Что такое DNS-записи домена? Типы ресурсных записей 🌐

Содержание

Система доменных имен (Domain Name System) или просто DNS — важнейшая часть механизма Всемирной сети. Именно она позволяет сопоставить доменные имена веб-ресурсов с IP-адресами физических устройств, на которых они расположены.

Эту распределенную базу данных можно назвать аналогом «телефонного справочника» всего Интернета. «Телефонные номера» в ней — это IP-адреса, а «ФИО абонентов» — соответствующие им доменные имена.

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

Об основных типах DNS-записей и их назначении расскажем в данной статье.

Из чего состоит DNS-запись

В состав DNS-записи входят следующие поля:

  • Name / Hostname (Имя, хост, домен — имеет несколько названий). Определяет домен, к которому относится (привязана) данная ресурсная запись.
  • Type (Тип). Указывает на тип (назначение) данной ресурсной записи. Наиболее распространенные типы DNS-записей — A, AAAA, MX, CNAME и TXT.
  • Class (Класс). Здесь указывается тип рабочей сети. Теоретически, система может работать во всех ее типах. Но, TCP/IP сети — самые распространенные. Поэтому, поле редко используется.
  • TTL (Time To Live) — время жизни (хранения) DNS-записи.
  • RDATA (Resource Data) — значение данного поля ресурсной записи зависит от ее конкретного типа.
  • Priority (Приоритет) — задает приоритет (очередность) обработки конкретной DNS-записи.
  • Protocol (Протокол)— указывает на протокол, используемый TCP, UDP, TLS.
  • Service Name (Имя сервиса) — его можно посмотреть в файле /etc/services. Например: pop3, telnet.
  • Weight (Вес) — задает вес хоста. Обработка запросов распределяется по весу хоста.
  • Address (Адрес) — IP-адрес, который автоматически конвертируется в in-addr.arpa формат.

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

Распространенные типы записей

Типы DNS-записей зависят от их функционального назначения.

Что такое DNS записи - Распространенные типы

A-запись (Address record)

Address record указывает на конкретный IP-адрес домена. Без нее сайт работать не будет. По этой записи система определяет к какому серверу обращаться за получением информации, когда пользователь вводит название сайта в адресную строку веб-браузера.

Пример
HostnameТип записиЗначение записи
eternalhost.net.A194.61.0.6

AAAA-запись (Address record to IPv6)

AAAA запись DNS — аналог предыдущей А-записи. В значении указывается внешний IP-адрес в формате IPv6.

Пример
HostnameТип записиЗначение записи
eternalhost.net.AAAA212:14:2127:1:211:4eef:fe10:b17

CNAME-запись (Canonical name)

CNAME («каноническое имя») указывает на расположение хостов на одном сервере. С ее помощью, можно прописать несколько доменов и поддоменов в рамках одного сервера.

Каноническое имя позволяет создать наследование, при котором поддомен получает свойства всех ресурсных записей одного домена (кроме NS), через псевдоним (алиас).

Перед ее заполнением, надо прописать A-запись. После, можно создавать псевдонимы (их количество не ограничено).

Пример
HostnameТип записиЗначение записи
www.eternalhost.netCNAMEeternalhost.net.

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

MX-запись (Mail exchanger)

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

Пример
HostnameТип записиЗначение записи
eternalhost.net.MXmx1.eternalhost.net.

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

Пример
Host nameТип записиЗначение записи
eternalhost.net.A194.61.0.6

Например, для привязки почты для домена на серверы Яндекс почты, надо указать следующие записи:

HostnameТип записиЗначениеПриоритетTTL
eternalhost.net.MXmx.yandex.net.1021600

Привязка почты для домена к Google, Mail.ru и другим почтовым сервисам осуществляется по такому же принципу.

NS-запись (Name Server)

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

Пример
HostnameТип записиЗначение записи
eternalhost.net.NSns1.eternalhost.net.

TXT-запись (Text String)

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

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

Пример
HostnameТип записиЗначение записи
eternalhost.net.TXTЛюбая текстовая запись без кавычек.

SOA-запись (Start of Authority)

Указывает местоположение сервера с эталонной информацией о домене. Запись создается автоматически в самом начале и не может быть отредактирована или удалена.

Пример
HostnameТип записиSerial number TTLRefreshRetryExpireMinimum TTL
Контактный адрес администратора файловой зоныSOA18121911233600720054060480086400

SRV-запись (Service record)

Указывает расположение серверов (имя хоста, № порта) для определенных сервисов. Выполняет ассоциативную роль. Например, через него можно задать:

IMAP-сервер для eternalhost.net находится по адресу mail.eternalhost.net. При этом, eternalhost.net — веб-сервер.

Пример
Host nameService NameProtocolPriorityWeight
eternalhost.net._xmpp-server_tcp1000

PTR-запись (Reverse DNS)

Обратная запись DNS служит для связывания отдельного IP-адреса с доменным именем. В основном, запись используется для отправки почты с домена. Если PTR-запись совпадет с именем почтового сервера из параметра HELO (EHLO), повысится шанс миновать спам-фильтры почтовых серверов на стороне получателя письма.

Пример
Host nameТип записиAddress
mail.eternalhost.net.PTR194.61.06.in-addr.arpa

DNAME-запись (Domain Name)

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

CAA-запись (Certification Authority Authorization)

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

HINFO-запись (Host Information)

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

WKS-запись (Well Known Service)

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

RP-запись (Responsible person)

Здесь прописаны реквизиты ответственных за домен. Указать можно как одного человека, так группу людей. Поле «Text Record Name» хранит Ф.И.О. ответственного работника, а поле «E-mail Address» — его электронную почту.

LOC-запись (Location information)

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

Где редактируются DNS-записи

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

Например, в ISPmanager это делается в разделе «Доменные имена». Для редактирования нужно войти в панель управления, выделить курсором нужный домен и нажать кнопку «Записи» в верхнем меню.

Что такое DNS записи - как редактировать

В открывшемся списке можно добавить или отредактировать DNS-запись при помощи функциональных кнопок «Создать» и «Изменить».

Что такое DNS записи - как редактировать

Редактировать DNS-запись — Технологии Яндекса

Обязательные
domainСтрока

Имя домена.

record_idЧисло

Идентификатор DNS-записи.

Необязательные
subdomainСтрока

Имя поддомена. Например, «domain.com» — имя поддомена домена «com», а «my.domain.com» — имя поддомена домена «domain.com».

Значение по умолчанию — «@» (корень домена).

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

ttlЧисло

Время жизни DNS-записи в секундах.

Для SOA-записи это время, на которое кешируется значение DNS-записи промежуточными DNS-серверами. Это же время будет использоваться по умолчанию для всех остальных новых записей зоны. Допустимые значения — от 900 и до 1209600. Рекомендуемое значение — 21600.

refreshЧисло

Частота проверки в секундах вторичными DNS-серверами DNS-записи для этой зоны. Допустимые значения — от 900 и до 86400. Рекомендуемое значение — 10800.

Параметр нужно передать, если редактируется SOA-запись.

retryЧисло

Время в секундах между повторными попытками вторичных DNS-серверов получить записи зоны. Повторные запросы отправляются, если основной сервер не отвечает. Допустимые значения — от 90 и до 3600. Рекомендуемое значение — 900.

Параметр нужно передать, если редактируется SOA-запись.

expireЧисло

Время в секундах, по истечении которого вторичные DNS-серверы считают записи зоны несуществующими, если основной сервер не отвечает. Допустимые значения — от 90 и до 3600. Рекомендуемое значение — 900.

Параметр нужно передать, если редактируется SOA-запись.

neg_cacheЧисло

Время в секундах, в течение которого будет кешироваться отрицательный ответ (ERROR = NXDOMAIN) от DNS-сервера. Допустимые значения — от 90 и до 86400. Рекомендуемое значение — 10800.

Параметр нужно передать, если редактируется SOA-запись.

admin_mailСтрока

Email-адрес администратора домена.

Параметр обязателен только для SOA-записи.

contentСтрока

Содержимое DNS-записи.

Для записи типа:
  • A — адрес в формате IPv4 (например, «194.84.46.241»).

  • AAAA — адрес в формате IPv6 (например, «2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d»).

  • CNAME, MX или NS — полностью определенное имя домена (FQDN).
  • TXT — текст TXT-записи (например, «v=spf1 redirect=_spf.yandex.ru»).

priorityЧисло

Приоритет DNS-записи (чем меньше значение, тем выше приоритет).

Параметр обязателен только для SRV или MX-записи.

Значение по умолчанию — 10.

portСтрока

TCP или UDP-порт хоста, на котором размещен сервис. Сервисом может быть, например, джаббер.

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

weightЧисло

Вес SRV-записи относительно других SRV-записей для того же домена, с тем же приоритетом.

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

targetСтрока

Каноническое имя хоста, предоставляющего сервис.

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

Введение в 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 записи домена, 🍀 параметры домена

AЭтот тип записи привязывает конкретное доменное имя на определенный, точный IP-адрес.
AAAAЗапись AAAA ставит в соответствие доменному имени адрес IPv6. Например имя example.ru может указывать на IPv6-адрес 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d. У каждого хоста может быть несколько IPv6-адресов, т.е. возможно установить несколько AAAA-записей.
NSЗапись NS указывает имена серверов на которых размещена информация для данного домена (сервера имен).
TXTЗапись NS указывает имена серверов на которых размещена информация для данного домена (сервера имен).
MXЗапись MX предназначена для того, чтобы указывать имя почтового сервера, который принимает почту для данного домена.
SOAДанная запись и ее значение фактически не влияют на работу домена (как А-записи или PTR), SOA содержит административную информацию.
CNAMEЗапись CNAME позволяет поставить в соответствие одному имени хоста другое. Если для домена www.example.ru установлена запись CNAME на домен example.ru, то запрос пришедший на имя домена www.example.ru будет перенаправлен на example.ru.
PTRЗапись нужна для того чтобы было возможно ассоциировать IP адрес с доменным именем. PTR запись всегда добавляется на стороне владельца IP адреса, как правило — это компании, владеющие блоками адресов и предоставляющие эти адреса в аренду.
HINFOТип записи используемый для хранения информации об архитектуре и операционной системе некоторого хоста. Например, вам может понадобится создать запись для сервера test.example.ru, что он(сервер) есть x86 PC под FreeBSD. Однако, это очень редко применяется, так как такая информация может быть использована злоумышленниками при подготовке атак.
CAAС помощью данной DNS записи владелец домена мог указывать удостоверяющий центр, имеющий право выпускать SSL/TLS-сертификаты для указанного домена.
SRVЗапись SRV определяет положение, порт и параметры работы серверов отвечающих за работу определенных служб, например SIP или XMPP (Jabber).
NAPTRNAPTR записи чаще всего используются для приложений интернет-телефонии, например, при отображении серверов и адресов пользователей в протоколе установления сеанса (SIP).

Управление DNS, работа с NS и А записями на примерах

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

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

  • Запись A (запись адреса) — указывает IP адрес хостинга, где находится наш сайт.
  • Запись MX (адрес посты) — определяет IP адрес постового сервера для домена, как правило, совпадает с записью A.
  • Запись NS (name server) — указывает на DNS-сервер для конкретного домена.

Рассмотрим данные нюансы на примере работы с регистратором доменов Webnames. Для любого домена у нас есть 2 варианта задания соответствия между доменом и хостингом:

1. Указание записей A и MX, которые будут содержать IP хостинга с нашим сайтом:

При этом данное соответствие будет «храниться» в NS записях регистратора  (webnames). Поэтому при создании хостинг аккаунтов вы можете использовать NS регистратора — в данном случае это ns1.nameself.com и ns2.nameself.com. При этом во вкладке DNS сервера в вашей учетной записи найдете:

2. В том же разделе меню управление DNS для домена вы также можете указать NS сервера хостера, например:

Теперь, по сути, вся ответственность по заданию соответствия между IP адресом и вашим доменом лежит на компании, которая эти DNS предоставляет. В данном случае это хостинг CoolVDS. Там, кстати, можно прикупить выделенный сервер в США, что хорошо подойдет по MFA сайты.  Для того чтобы там «подключить» домен нужно обратиться в тех.поддежку на почту [email protected]: в теме письма пишите «домен для ваш_сервер.coolvds.com», где в тексте указываете домен, ip и опять имя сервера, например:

mydomain.com:193.333.555.777:ваше_имя.coolvds.com

Может слегка запутано, но только в первый раз. Другие хостинги могут при покупке хостинга спрашивать какие DNS использовать. Например, так делается в Hostpro, и если вы выберете использовать их DNS, тогда просто для своего домена нужно будет указать их NS сервера — master.hostsila.com и slave.hostsila.net без всяких A и MX записей.

Точно также 2 варианта, о которых я сказал выше есть у большинства нормальных регистраторов доменов. Еще один пример — Getnic.name. Здесь вы можете воспользоваться услугой бесплатного управления DNS или указать сторонние NS сервера.

Для этого выбираете домен и заходите в его учетную запись — здесь можете указать существующие NS другого хостера либо кликнуть по ссылке «управление DNS». Во втором случае сможете задать A, MX и все необходимые записи для домена и использовать бесплатные NS от getnic.name.

Создание собственных NS записей

Для некоторых своих проектов я покупал виртуальные сервера у Hostpro — расположение в Украине, поддержка адекватная и очень дружелюбная. После приобретения вам выдают 2 IP адреса — основной и дополнительный, а также просьбу зарегистрировать NS вида ns1.mydomain.ru и ns2.mydomain.ru.

Для webnames заходим опять же в раздел «Управление зоной» для своего домена, где добавляем нужные записи типа NS:

Для украинского регистратора iname.ua делается аналогичным образом: добавляете запись типа NS и указываете выданные IP.

Теперь для новых зарегистрированных доменов, сайты которых располагаются на вашем сервере сможете указывать не только A запись со ссылкой на IP, а и просто определять через свои NS — ns1.mydomain.ru и ns2.mydomain.ru. Кстати, напоследок ссылка на статью про то как можно не ждать обновления DNS — редактируем файл hosts после чего сможете приступать к работе над своим проектом пока глобальные DNS еще не обновились (дело нескольких часов).

Вот такой получился небольшой ликбез по управлению DNS, созданию NS, A, MX записей для доменов. Возможно, вы работаете с теми же регистраторами и хостингами, тогда данная статья должна быть полезной подсказкой, если какие-то вопросы возникают (особенно новичкам). Хотя, в принципе, конечно, всегда можно обратиться в тех.поддержку как регистратора домена, так и там где вы покупаете хостинг — в хороших, уважающих себя и клиентов, компаниях должны помочь, с другими лучше дела не иметь.

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

Типы ресурсных записей DNS / Вопросы и ответы на DNAR.RU Основные типы ресурсных записей (Resource Records)
NS-записи

Назначение:
Определяют DNS-сервера, которые являются авторитативными для данной зоны.

Формат:
Хост NS Значение

Примеры:
Если домен test.ru делегирован с DNS-серверами ns1.r01.ru и ns2.r01.ru, то на них должны присутствовать следующие NS-записи:

test.ru. NS ns1.r01.ru.
test.ru. NS ns2.r01.ru.

Если домен делегирован с DNS-серверами, принадлежащими той же зоне (допустим, test.ru делегирован с ns1.test.ru. 192.168.0.1 и ns2.test.ru. 192.168.0.2), то NS-записи необходимо дополнить A-записями (так называемые glue-records):

test.ru. NS ns1.test.ru.
test.ru. NS ns2.test.ru.
ns1.test.ru. A 192.168.0.1
ns2.test.ru. A 192.168.0.2


A-записи

Назначение:
Задают преобразование имени хоста в IP-адрес.

Формат:
Хост A Значение

Пример:
Преобразованию имени test.ru в IP-адрес 192.168.0.1 соответствуюет следующая A-запись:

test.ru. A 192.168.0.1


MX-записи

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

При наличии нескольких MX-записей сначала происходит попытка доставить почту на ретранслятор с наименьшим приоритетом.

Формат:
Хост MX Приоритет Значение

Пример:
Идентификацировать mail.test.ru как почтовый ретранслятор для test.ru с приоритетом 10 можно следующей записью:

test.ru. MX 10 mail.test.ru.


CNAME-записи

Назначение:
CNAME-запись определяет отображение псевдонима в каноническое имя узла.

Формат:
Хост CNAME Значение

Пример:
Прописать bbb.test.ru как псевдоним aaa.test.ru можно следующей записью:

bbb.test.ru. CNAME aaa.test.ru.


SRV-записи

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

Приоритет SRV-записи работает аналогично приоритету MX-записи: чем меньше приоритет, тем более желательно использование связанной цели.

Веса SRV-записей позволяют администраторам зоны распределять нагрузку между целями. Клиент должен опрашивать цели одного приоритета в пропорции к их весам.

Порт SRV-записи определяет порт, по которому работает искомая служба.

Формат:
Хост SRV Приоритет Вес Порт Значение

Пример:
Предположим, мы хотим по запросу FTP-клиента для досупа по FTP к test.ru направлять клиент сначала на ftp1.test.ru. через 21 порт, а затем на ftp2.test.ru. через 21 порт, если ftp1.test.ru. недоступен. Это можно сделать следующими записями:

_ftp._tcp.test.ru. SRV 1 0 21 ftp1.test.ru.
_ftp._tcp.test.ru. SRV 2 0 21 ftp2.test.ru.


TXT-записи

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

Формат:
Хост TXT Текст

Пример:
Прописать в DNS информацию о месторасположении сервера mail.test.ru:

mail.test.ru. TXT «Location this machine: Moscow»


AAAA-записи

Назначение:
Задает преобразование имени хоста в IPV6-адрес.

Формат:
Хост AAAA Значение

Пример:
Преобразованию имени test.ru в адрес 222:10:2521:1:210:4bff:fe10:d24 соответствуюет следующая AAAA-запись:

test.ru. AAAA 222:10:2521:1:210:4bff:fe10:d24 Задать вопрос

Быстрый старт: создание зоны DNS и запись — портал Azure — Azure DNS
  • 3 минуты, чтобы прочитать

В этой статье

Вы можете настроить Azure DNS для разрешения имен хостов в вашем публичном домене.Например, если вы приобрели доменное имя contoso.xyz у регистратора доменных имен, вы можете настроить Azure DNS для размещения домена contoso.xyz и разрешить www.contoso.xyz по IP-адресу ваш веб-сервер или веб-приложение.

В этом кратком руководстве вы создадите тестовый домен, а затем создадите запись адреса для разрешения www на IP-адрес 10.10.10.10 .

Важное значение

Все имена и IP-адреса в этом кратком обзоре являются примерами, которые не представляют реальные сценарии.

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

Для всех шагов портала войдите на портал Azure.

Создать зону DNS

Зона DNS содержит записи DNS для домена. Чтобы начать размещение своего домена в Azure DNS, создайте зону DNS для этого доменного имени.

Для создания зоны DNS:

  1. В левом верхнем углу выберите Создайте ресурс , затем Сеть , а затем DNS-зона .

  2. На странице Создать зону DNS введите или выберите следующие значения:

    • Имя : введите contoso.xyz для этого примера быстрого запуска. Имя зоны DNS может быть любым значением, которое еще не настроено на DNS-серверах Azure. Реальной ценностью будет домен, который вы купили у регистратора доменных имен.
    • Группа ресурсов : выберите Создайте новый , введите MyResourceGroup и выберите OK .Имя группы ресурсов должно быть уникальным в подписке Azure.
  3. Выберите Создать .

Создание зоны может занять несколько минут.

Создать запись DNS

Вы создаете записи DNS или записи для своего домена в зоне DNS. Создайте новую запись адреса или запись «A», чтобы преобразовать имя хоста в адрес IPv4.

Для создания записи «А»:

  1. На портале Azure в разделе Все ресурсы откройте консоль .DNS-зона xyz в группе ресурсов MyResourceGroup . Вы можете ввести contoso.xyz в поле Фильтр по имени , чтобы найти его проще.

  2. В верхней части страницы DNS-зона выберите + Набор записей .

  3. На странице Добавить набор записей введите или выберите следующие значения:

    • Наименование : Тип www . Имя записи — это имя хоста, которое вы хотите преобразовать в указанный IP-адрес.
    • Тип : выберите A . Записи «А» являются наиболее распространенными, но существуют другие типы записей для почтовых серверов («MX»), адресов IP v6 («AAAA») и т. Д.
    • TTL : тип 1 . Время жизни запроса DNS указывает, как долго DNS-серверы и клиенты могут кэшировать ответ.
    • TTL блок : выбор часов . Это единица времени для значения TTL .
    • IP-адрес : для этого примера быстрого запуска введите 10.10.10.10 . Это значение является IP-адресом, к которому разрешается имя записи. В реальном случае вы должны ввести публичный IP-адрес для вашего веб-сервера.

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

Проверьте разрешение имени

Теперь, когда у вас есть тестовая DNS-зона с тестовой записью «A», вы можете проверить разрешение имен с помощью инструмента под названием nslookup .

Для проверки разрешения имен DNS:

  1. На портале Azure в разделе Все ресурсы откройте зону DNS contoso.xyz в группе ресурсов MyResourceGroup . Вы можете ввести contoso.xyz в поле Фильтр по имени , чтобы найти его проще.

  2. Скопируйте одно из имен серверов имен из списка серверов имен на странице Обзор .

  3. Откройте командную строку и выполните следующую команду:

      nslookup www.contoso.xyz <имя сервера имен>
      

    Например:

      nslookup www.contoso.xyz ns1-08.azure-dns.com.
      

    Вы должны увидеть что-то вроде следующего экрана:

Имя хоста www.contoso.xyz преобразуется в 10.10.10.10 , как вы его настроили. Этот результат подтверждает, что разрешение имен работает правильно.

Очистить ресурсы

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

Следующие шаги

,

DNS для служб и модулей

Редактировать эту страницу

На этой странице представлен обзор поддержки DNS Kubernetes.

Введение

Kubernetes DNS планирует Pod и службу DNS в кластере и настраивает kubelets, чтобы сказать отдельным контейнерам использовать IP-адрес службы DNS для разрешить DNS-имена

Какие вещи получают DNS-имена?

Каждая служба, определенная в кластере (включая сам DNS-сервер) назначил имя DNS. По умолчанию список DNS-поиска клиента Pod будет включите собственное пространство имен Pod и домен кластера по умолчанию.Это лучше иллюстрируется примером:

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

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

Сервисы

A / AAAA-записей

«Нормальным» (не без заголовка) Сервисам присваивается DNS-запись A или AAAA, в зависимости от семейства IP услуги, для имени формы my-svc.my-namespace.svc.cluster-domain.example . Это разрешает к кластеру IP службы.

«Безголовые» (без IP-адреса кластера) Службам также назначается запись DNS A или AAAA, в зависимости от семейства IP услуги, для имени формы my-svc.my-namespace.svc.cluster-domain.example . В отличие от нормального Сервисы, это разрешает набор IP-адресов модулей, выбранных Сервисом. Ожидается, что клиенты будут использовать набор или использовать стандартный циклический перебор выбор из набора.

SRV-записей

SRV-записей создаются для именованных портов, которые являются частью обычных или безголовых Сервисы. Для каждого именованного порта запись SRV будет иметь вид _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example .Для обычной службы это разрешает номер порта и имя домена: my-svc.my-namespace.svc.cluster-domain.example . Для безголовой службы это разрешает несколько ответов, по одному для каждого модуля который поддерживает службу и содержит номер порта и доменное имя модуля формы автоматически сгенерированные-name.my-svc.my-namespace.svc.cluster-domain.example .

модулей

записей A / AAAA

Все модули, созданные с помощью Deployment или DaemonSet, имеют следующие Доступное разрешение DNS:

pod-ip-адрес.развертывание-name.my-namespace.svc.cluster-domain.example.

Поля имени хоста и субдомена

В настоящее время при создании модуля его именем хоста является значение метаданных . Имя модуля .

Спецификация Pod имеет необязательное поле hostname , которое можно использовать для указания Имя хоста Pod. Если указано, он имеет приоритет над именем модуля имя хоста модуля. Например, данный модуль с именем хоста установлен в « my-host », Pod будет иметь имя хоста, равное « my-host ».

Спецификация Pod также имеет дополнительное поле поддомен , которое можно использовать для указания его поддомен. Например, модуль с именем хоста , установленным на « foo », и поддомен значение « bar », в пространстве имен « my-namespace », будет иметь полную квалификацию доменное имя (FQDN) « foo.bar.my-namespace.svc.cluster-domain.example «.

Пример:

  apiVersion: v1
вид: Сервис
метаданные:
  имя: субдомен по умолчанию
спецификация:
  селектор:
    имя: busybox
  clusterIP: нет
  порты:
  - name: foo # На самом деле порт не нужен.порт: 1234
    targetPort: 1234
---
apiVersion: v1
вид: Pod
метаданные:
  имя: busybox1
  метки:
    имя: busybox
спецификация:
  имя хоста: busybox-1
  поддомен: default-поддомен
  контейнеры:
  - изображение: busybox: 1.28
    команда:
      - спать
      - "3600"
    имя: busybox
---
apiVersion: v1
вид: Pod
метаданные:
  имя: busybox2
  метки:
    имя: busybox
спецификация:
  имя хоста: busybox-2
  поддомен: default-поддомен
  контейнеры:
  - изображение: busybox: 1.28
    команда:
      - спать
      - "3600"
    имя: busybox
  

Если существует служба без заголовка в том же пространстве имен, что и модуль то же имя, что и субдомен, DNS-сервер кластера также возвращает A или AAAA запись для полного имени хоста Pod.Например, если для Pod задано имя хоста « busybox-1 «, а для субдомена — « default-subdomain » и автономная служба с именем « default-subdomain » в в том же пространстве имен модуль будет видеть свое собственное полное доменное имя как « busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example «. DNS служит Запись A или AAAA под этим именем, указывающая на IP-адрес модуля. Обе капсулы « busybox1 » и « busybox2 » может иметь свои отличные записи A или AAAA.

Объект Endpoints может указать имя хоста для любых адресов конечных точек, вместе с его IP.

Примечание: Поскольку записи A или AAAA не создаются для имен блоков, имя хоста требуется для блоков A или AAAA запись будет создана. Модуль без имени хоста , но с субдоменом создаст только Запись A или AAAA для службы без наушников ( default-subdomain.my-namespace.svc.cluster-domain.example ), указывая на IP-адрес модуля.Кроме того, Pod должен быть готов, чтобы иметь запись, если publishNotReadyAddresses = True не установлен на Сервисе.

Политика DNS модуля

Политики DNS можно устанавливать отдельно для каждого модуля. В настоящее время Kubernetes поддерживает следующие специфичные для pod политики DNS. Эти политики указаны в dnsPolicy поле Под Спец.

  • « по умолчанию »: Pod наследует конфигурацию разрешения имен от узла что бегут стручки.Смотрите связанные обсуждения Больше подробностей.
  • « ClusterFirst »: любой DNS-запрос, который не соответствует настроенному кластеру суффикс домена, такой как « www.kubernetes.io », пересылается в восходящий поток Сервер имен, унаследованный от узла. Администраторы кластера могут иметь дополнительные Стаб-домен и вышестоящие DNS-серверы настроены. Смотрите связанные обсуждения для получения подробной информации о том, как DNS-запросы обрабатываются в этих случаях.
  • « ClusterFirstWithHostNet »: для модулей, работающих с hostNetwork, вам следует явно установите свою политику DNS « ClusterFirstWithHostNet ».
  • « Нет «: позволяет модулю игнорировать настройки DNS из Kubernetes Окружающая среда. Все настройки DNS должны быть предоставлены с использованием dnsConfig поле в Pod Spec. Смотрите подраздел по настройке DNS Pod ниже.

Примечание: «По умолчанию» не является политикой DNS по умолчанию. Если днсПолицы нет если указано явно, то используется «ClusterFirst».

В приведенном ниже примере показан модуль с установленной для него политикой DNS « ClusterFirstWithHostNet », потому что для нее hostNetwork настроен на истинных .

  apiVersion: v1
вид: Pod
метаданные:
  имя: busybox
  пространство имен: по умолчанию
спецификация:
  контейнеры:
  - изображение: busybox: 1.28
    команда:
      - спать
      - "3600"
    imagePullPolicy: IfNotPresent
    имя: busybox
  restartPolicy: всегда
  hostNetwork: правда
  dnsPolicy: ClusterFirstWithHostNet
  

DNS Config модуля Pod

DNS Config модуля Pod позволяет пользователям лучше контролировать настройки DNS для модуля Pod.

Поле dnsConfig является необязательным и может работать с любыми настройками dnsPolicy .Однако, если для модуля dnsPolicy установлено значение « Нет », поле dnsConfig имеет быть уточненным.

Ниже приведены свойства, которые пользователь может указать в поле dnsConfig :

  • серверов имен : список IP-адресов, которые будут использоваться в качестве DNS-серверов для Порт назначения Можно указать не более 3 IP-адресов. Когда Стручок днсПолиция имеет значение « Нет «, список должен содержать хотя бы один IP-адрес, в противном случае это свойство не является обязательным.Перечисленные серверы будут объединены с базовыми серверами имен, сгенерированными из указанная политика DNS с удаленными дублирующими адресами.
  • поисков : список DNS-доменов поиска для поиска имени хоста в модуле Pod. Это свойство не является обязательным. Если указано, предоставленный список будет объединен в базу поиска доменных имен, сгенерированных из выбранной политики DNS. Повторяющиеся доменные имена удаляются. Kubernetes позволяет использовать не более 6 поисковых доменов.
  • опций : необязательный список объектов, где каждый объект может иметь имя свойство (обязательно) и значение свойство (необязательно).Содержание в этом свойство будет объединено с параметрами, созданными из указанной политики DNS. Повторяющиеся записи удаляются.

Ниже приведен пример модуля с пользовательскими настройками DNS:

service / network / custom-dns.yaml
  apiVersion: v1
вид: Pod
метаданные:
  пространство имен: по умолчанию
  имя: днс-пример
спецификация:
  контейнеры:
    - название: тест
      изображение: nginx
  dnsPolicy: "Нет"
  dnsConfig:
    неймсерверы:
      - 12.3.4
    поиск:
      - ns1.svc.cluster-domain.example
      - my.dns.search.suffix
    параметры:
      - имя: ndots
        значение: «2»
      - имя: edns0
  

Когда вышеуказанный модуль создан, контейнер test получает следующее содержимое в файле /etc/resolv.conf :

  nameserver 1.2.3.4
поиск ns1.svc.cluster-domain.example my.dns.search.suffix
Варианты ndots: 2 edns0
  

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

  kubectl exec -it dns-example - cat / etc / resolv.конф
  

Вывод похож на это:

  nameserver fd00: 79: 30 :: a
поиск default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
Варианты ndots: 5
  

Доступность функции

Доступность конфигурации Pod DNS и политики DNS « Нет » показана ниже.

k8s версия Поддержка функций
1.14 Стабильный
1.10 Beta (по умолчанию включено)
1,9 Альфа

Что дальше

Руководство по администрированию конфигурации DNS

.
лучших бесплатных и общедоступных DNS-серверов в 2020 году

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

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

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

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

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

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

Получите бесплатный брандмауэр DNS на всю жизнь с Keepsolid VPN Unlimited — всего $ 160 на 5 устройств на всю жизнь

В настоящее время

Keepsolid предлагает бесплатных защит DNS Firewall при покупке подписки VPN Unlimited.Это решение сетевой безопасности, которое перехватывает разрешение DNS для известных вредоносных веб-сайтов и защищает ваши устройства от заражения вредоносным ПО. При единовременной оплате всего 32 долл. США за устройство (при тарифном плане на 5 устройств) вы получаете 256-битное шифрование AES военного уровня, неограниченный трафик и скорость соединения на всю жизнь. Используйте эксклюзивный код VPNUNLIMITED20. Посмотреть предложение

Почему платный DNS лучше, чем бесплатный

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

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

Лучшие бесплатные, платные и бизнес-альтернативные серверы доменных имен

  1. OpenDNS
  2. Cloudflare
  3. Google Public DNS
  4. Comodo Secure DNS
  5. Quad9
  6. Verisign DNS

(Кредит изображения: OpenDNS)

1. OpenDNS

Первичные, вторичные DNS-серверы: 208.67.222.222 и 208.67.220.220

Оператор-ветеран

Фишинговые сайты по умолчанию заблокированы

Дополнительная веб-фильтрация

Основанная в 2005 году и в настоящее время принадлежащая Cisco, OpenDNS является одним из крупнейших имен в общедоступной DNS.

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

Коммерческие планы позволяют просматривать историю вашей интернет-активности за последний год и дополнительно блокировать вашу систему, предоставляя доступ только к определенным веб-сайтам.Они не будут обязательными для обычного пользователя, но если вам интересно, они могут быть вашими примерно за 20 долларов (14,30 фунтов) в год.

Если вы опытный специалист по обмену DNS, вы можете сразу же начать, перенастроив ваше устройство для использования серверов имен OpenDNS.

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

(Кредит изображения: Cloudflare)

2. Cloudflare

Первичные, вторичные DNS-серверы: 1.1.1.1 и 1.0.0.1

Впечатляющая производительность

Строгие уровни конфиденциальности

Форум сообщества поддержки

Самый известный благодаря своей сети доставки контента с самым высоким рейтингом, Cloudflare расширил свой диапазон, включив в него новую общедоступную службу DNS — броскую 1.1.1.1.

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

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

На веб-сайте 1.1.1.1 есть некоторые рекомендации по настройке с простыми учебными пособиями по Windows, Mac, Android, iOS, Linux и маршрутизаторам.Они очень общие — например, вы получаете один набор инструкций для всех версий Windows — но есть некоторые плюсы (IPv6, а также детали IPv4), и вы должны быть в состоянии это выяснить. Кроме того, мобильные пользователи могут использовать WARP, который защищает весь интернет-трафик телефона.

Продукт не предлагает блокировку рекламы и не пытается отслеживать, что вы можете получить, а что нет. Единственное предостережение в том, что Cloudflare ввел фильтрацию контента для вредоносных программ и блокировку контента для взрослых, с их 1.1.1.2 / 1.0.0.2 и 1.1.1.3/1.0.0.3 соответственно, но это вариант, который пользователь может выбрать, а не навязывать его.

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

(Изображение предоставлено: Google Public DNS)

3. Google Public DNS

Первичные, вторичные DNS-серверы: 8.8.8.8 и 8.8.4.4

Надежность в области конфиденциальности

Похвальная прозрачность

Предназначено для опытных пользователей

Google держит свои пальцы в большинстве веб-пирогов, и DNS не является исключением: это бесплатный Public DNS — простая и эффективная замена для серверов имен вашего собственного интернет-провайдера.

Конфиденциальность не может полностью соответствовать обещаниям Cloudflare «мы ничего не храним», но это неплохо. Служба регистрирует полную информацию об IP-адресе запрашивающего устройства в течение примерно 24-48 часов для устранения неполадок и диагностики. «Постоянные» журналы сбрасывают любую личную информацию и сокращают сведения о местоположении до уровня города, и все, кроме небольшой случайной выборки, удаляются через две недели.

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

Сайт поддержки Google предлагает только самые базовые рекомендации, ориентированные на опытных пользователей, предупреждая, что «только пользователи, которые умеют настраивать параметры операционной системы, [должны] вносить эти изменения». Если вы не уверены, что делаете, проверьте учебные материалы от такого поставщика, как OpenDNS, не забывая заменить его серверы имен на Google: 8.8.8.8 и 8.8.4.4.

(Изображение предоставлено Comodo)

4. Comodo Secure DNS

Первичные, вторичные DNS-серверы: 8.26.56.26 и 8.20.247.20

Фокус на безопасность

Интеллектуальная обработка паркованных доменов

Производительность может быть не такой высокой

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

Как и следовало ожидать, Comodo Secure DNS уделяет большое внимание безопасности.Он не только блокирует фишинговые сайты, но и предупреждает, если вы пытаетесь посетить сайты с вредоносными, шпионскими программами и даже припаркованными доменами, которые могут перегружать вас рекламой (всплывающие окна, всплывающие окна и т. Д.). Кроме того, вы можете попробовать сервис Comodo Dome Shield, который добавляет дополнительные функции к Comodo Secure DNS.

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

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

Тем не менее, Comodo все еще может быть интересным, если вы ищете дополнительный уровень веб-фильтрации, и на веб-сайте поддержки есть несколько коротких, но полезных инструкций по настройке службы на ПК с Windows, Mac, маршрутизаторах и Chromebook.

(Кредит изображения: Quad9)

5. Quad9

Первичные, вторичные DNS-серверы: 9.9.9.9 и 149.112.112.112

Уровни быстрой производительности

Блокирует вредоносные домены

Ограниченная помощь в настройке

Quad9 is молодая служба DNS, которая с августа 2016 года предоставляет быструю и бесплатную службу DNS.

Компания продвигает свою способность блокировать вредоносные домены, собирая сведения из различных государственных и частных источников.«Неясно, что это за источники, но на веб-сайте говорится, что Quad9 по состоянию на декабрь 2018 года использовал 18+« поставщиков информации об угрозах ».

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

О производительности Quad9 не спорят. DNSPerf в настоящее время оценивает его в семи из десяти по среднему времени запросов по всему миру, отставая от Cloudflare и OpenDNS, но без особых усилий опережая таких соперников, как Comodo.

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

Руководство по установке немного ограничено и содержит учебные пособия только для последних версий Windows и macOS. Тем не менее, они хорошо представлены, и нетрудно понять, что вам нужно делать.

(Изображение предоставлено Verisign)

6. Verisign DNS

Первичные, вторичные DNS-серверы: 64.6.64.6 и 64.6.65.6

Довольно стабильный

Надежная безопасность

Не самая быстрая служба

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

Служба Verisign DNS бесплатна, и компания выделяет три функции, которые они считают наиболее важными, а именно стабильность, безопасность и конфиденциальность. Служба определенно предоставляет на этот счет, особенно для безопасности и стабильности.Что касается конфиденциальности, хотя вы никогда не можете быть на 100% уверены в том, что касается требований компании, проблем не было, и компания заверяет вас, что ваши общедоступные данные DNS не будут проданы третьим лицам.

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

На их веб-сайте вы можете найти учебные пособия по настройке общедоступного DNS.Учебники доступны для Windows 7 и 10, Mac, Linux и мобильных устройств. Также есть руководство по настройке параметров DNS-сервера на вашем маршрутизаторе.

В целом, Verisign предлагает хорошую альтернативу некоторым другим DNS-провайдерам, плюс это бесплатно, так что стоит проверить.

Есть дополнительные вопросы о DNS? Вот некоторые общие вопросы вместе с нашими ответами.

Что такое DNS?

Система доменных имен (DNS) — это телефонная книга для Интернета, структура, которая переводит доменные имена, например, Facebook.com или twitter.com, на IP-адреса, необходимые устройствам для загрузки этих интернет-ресурсов.

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

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

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

. Почему DNS может иметь значение для меня?

DNS-серверы могут сильно различаться по скорости, особенно в областях, которые не всегда имеют наилучшее покрытие интернета (Африка, Южная Америка, Океания). Чтобы привести пример одного дня, когда мы тестировали, DNSPerf.com сообщил, что Cloudflare достигнут среднее время запроса для Океании составляет 4,43 мс, в то время как Яндекс оставался на уровне 350,24 мс. Это потенциально больше трети секунды дополнительного времени ожидания, прежде чем ваш браузер сможет получить доступ к любому новому веб-сайту.

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

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

Как мне найти самый быстрый сервис DNS?

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

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

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

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

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

Как я могу переключать DNS-серверы?

Шаги, необходимые для изменения службы DNS, зависят от вашего оборудования и, возможно, от версии операционной системы.

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

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

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

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

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

Как найти текущие DNS-серверы?

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

Самый простой способ сделать это — посетить DNSLeakTest.com и нажать кнопку «Стандартный тест». В течение нескольких секунд веб-сайт обычно отображает IP-адреса вашего DNS-сервера, имена хостов и иногда (при необходимости) имя вашего интернет-провайдера.

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

В Windows вы можете начать, введя IPCONFIG / ALL в окне командной строки. Найдите свой сетевой адаптер, и вы должны увидеть его DNS-серверы, указанные в списке.

Если существует один IP-адрес DNS, который указывает на ваш маршрутизатор — 192.168.x.x — это означает, что маршрутизатор обрабатывает все запросы DNS. Введите этот IP-адрес в браузер, войдите в маршрутизатор, если необходимо, и ваши DNS-серверы должны быть указаны в настройках.

Как проверить службу DNS?

Если ваш браузер сообщает вам «IP-адрес сервера не найден», даже если вы уверены, что он работает и доступен, это может быть связано с проблемой вашего DNS.Но вы, возможно, не захотите пойти на смену службы DNS, чтобы выяснить это.

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

Запустите cmd.exe, чтобы открыть окно командной строки, затем введите:

nslookup website.com

Затем нажмите Enter (замените website.com адресом любого веб-сайта, к которому вы пытаетесь обратиться).

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

Затем скажите инструменту использовать другую службу DNS, введя команду, например:

nslookup website.com 8.8.8.8

Адрес 8.8.8.8 использует Google DNS — замените его любой службой DNS, которая вам нравится, например как 1.1.1.1 для Cloudflare.

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

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

Сводка лучших предложений сегодняшнего дня

,

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *