Как преодолеть ограничения CNAME в корневом домене.
- Перевод
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System . Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .
Базовые штуки
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).
Давайте взглянем на маппинг между именем и адресом:
$ dig web01.bugsplat.info
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
;; QUESTION SECTION: ;web01.bugsplat.info. IN A
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:
;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244
Оставшаяся часть ответа описывает сам ответ:
;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз , когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:
$ dig +trace web01.bugsplat.info ; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms
Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
$ dig -x 192.5.5.241 ; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.
Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае - f.root-servers.net .
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» - прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
$ dig petekeen.net mx ; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
$ dig www.petekeen.net ; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86
Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
$ dig www.petekeen.net @8.8.8.8
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:
$ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118
Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/
CNAME для Heroku или Github
Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns Добавить метки
DNS (система доменных имен) – это «телефонная книга» Интернета. В качестве номера телефона в ней выступает IP-адрес, а в качестве наименований контактов — домены. В такую книгу можно внести не только «телефонный номер», но и дополнительную информацию о контакте («е-mail», «место работы» и т.п.).
Информация о домене хранится на DNS-серверах. Чтобы внести её в систему DNS, нужно прописать ресурсные записи . С их помощью серверы делятся сведениями о доменах с другими серверами. Пока не прописаны ресурсные записи для домена, его нет в «телефонной книге» Интернета. Следовательно, работа сайта или почты на нём невозможна. Прежде чем приступать к указанию ресурсных записей, нужно делегировать домен, то есть прописать для него DNS-серверы. Вы можете сделать это по инструкции: . Затем переходите к ресурсным записям. Изменения вступят в силу после обновления DNS-серверов (обычно до 24 часов).
Основные ресурсные записи: записи типа A, CNAME, MX, TXT и SPF. Рассмотрим их подробнее.
Запись A
Запись A (address) — одна из ключевых ресурсных записей Интернета. Она нужна для связи домена с IP-адресом сервера. Пока не прописана А-запись, ваш сайт не будет работать.
Когда вы вводите название сайта в адресную строку браузера, именно по А-записи DNS определяет, с какого сервера нужно открывать ваш сайт.
Примеры записи A:
| Имя записи | Тип записи | Значение |
|---|---|---|
| site.ru | A | 123.123.123.123 |
| shop.site.ru | A | 123.123.123.123 |
Прописать А-запись вы можете по инструкции:
Запись CNAME
CNAME (Canonical name) — запись, которая отвечает за привязку поддоменов (например, www.site.ru) к каноническому имени домена (site.ru) или другому домену.
Основная функция CNAME — дублирование ресурсных записей домена (A, MX, TXT) для различных поддоменов.
Примеры записи CNAME:
| Имя записи | Тип записи | Значение |
|---|---|---|
| www.site.ru | CNAME | site.ru |
| webmail.site.ru | CNAME | webmail.hosting.сайт |
Если вы пропишете CNAME для поддомена www.site.ru и укажете значение site.ru, сайт будет открываться с того же IP-адреса, что и site.ru . Если вы пропишете CNAME для mail.site.ru и укажете значение webmail.hosting.сайт , то на mail.hosting.сайт будут распространятся те же ресурсные записи, что для webmail.hosting.сайт.
Использование записи CNAME исключает использование других ресурсных записей для данного поддомена, то есть для поддомена webmail.site.ru или www.site.ru нельзя одновременно добавить и запись A и запись CNAME.
Прописать CNAME-запись вы можете по инструкции:
Запись MX
MX (Mail Exchanger) — запись, отвечающая за сервер, через который будет работать почта. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает», на какой сервер нужно отправлять почту для вашего домена.
Примеры записи MX:
| Имя записи | Тип записи | Приоритет | Значение |
|---|---|---|---|
| site.ru | MX | 10 | mx1.hosting.сайт |
| site.ru | MX | 15 | mx2.hosting.сайт |
где mx1.hosting..
Обычно указывается два почтовых сервера, чтобы в случае недоступности одного из них почта всё же была отправлена на другой. Приоритет записи определяет, на какой сервер нужно отправлять почту в первую очередь. Чем меньше число, тем выше приоритет. Таким образом, для доменного имени site.ru почтовый сервер mx1.hosting..hosting.. Если приоритет одинаковый, сервер выбирается случайным образом.
Прописать MX-запись вы можете по инструкции:
Запись TXT
TXT (Text string) — запись, с помощью которой задаются необходимые текстовые комментарии для домена. Часто применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также как контейнер для записи SPF и ключа DKIM. Можно прописывать неограниченное количество TXT-записей, если они не конфликтуют друг с другом.
Прописать TXT-запись вы можете по инструкции:
Запись SPF
SPF-запись (Sender Policy Framework) содержит информацию о списке серверов, которые имеют право отправлять письма от имени заданного домена. Позволяет избежать несанкционированного использования. Настройка SPF прописывается в TXT-записи для домена.
Пример записи SPF:
| Имя записи | Тип записи | Значение |
|---|---|---|
| site.ru | TXT | v=spf1 include:_spf.hosting..123.123.123 a mx ~all |
где 123.123.123.123 — IP-адрес нужного вам сервера.
В этом примере:
- v=spf1 — определяет версию используемой записи SPF;
- include:_spf.hosting.сайт — включает в запись SPF значение SPF-записи другого домена. То есть для домена будут действовать все значения записи SPF для домена «_spf.hosting.сайт»;
- ip4: 123.123.123.123 — разрешает приём почты с IP-адреса 123.123.123.123;
- a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A-записи домена. Проще говоря, с сервера, где размещён сайт;
- mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
- ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается.
Прописать SPF-запись вы можете по инструкции:
Записи NS, PTR, SOA являются служебными и, как правило, настраиваются автоматически.
Запись NS
NS-запись (Authoritative name server) указывает на DNS-серверы, которые отвечают за хранение остальных ресурсных записей домена. Количество NS записей должно строго соответствовать количеству всех обслуживающих его серверов. Критически важна для работы службы DNS.
Запись PTR
PTR — обратная DNS-запись, которая связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись применяется для фильтрации почты.. Если у вас заказан VPS или Dedicated-сервер, прописать PTR-запись можно по инструкции:
Запись SOA
SOA (Start of Authority) — начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как её проверить, вы можете узнать .
Любой пользователь Интернет имеющий домены на серверах хостинг-провайдеров могут создавать и редактировать свои DNS записи. DNS записи имеют Имя, Тип записи и Адрес. Эти названия в различных панелях могут меняться. Например, может быть так:
Имя/Хост/Псевдоним; Тип записи ; Значение/Ответ/Назначение/Адрес.
Во всех вариантах «Тип записи» остается неизменным.
Имя записи
Имя записи, оно же хост/псевдоним это доменное имя, к которому принадлежит или привязана создаваемая запись.
При создании записи в поле «Имя» доменное имя указывается полностью. Имя субдомена или псевдонима не нужно указывать полностью. Достаточно указать имя третьего уровня: mail, www, ftp. Если вводите полное имя, обязательно поставьте точку в конце. То есть имя mail и mail.example.ru. это одно и то же имя в поле Имя/хост/псевдоним.
DNS записи- типы
Рассмотрим основные типы DNS записей, с которыми предстоит сталкиваться при обслуживании своих доменов.
Тип записи А
Тип записи: А (address record) или (адрес Internet 4) . Этот тип записи привязывает конкретное доменное имя на определенный, точный IP-адрес.
Можно добавить больше одного IP адреса для одного домена (имени хоста). Это нужно если используется firewall. Для этого нужно добавить вторую запись типа A, аналогично первой. Указав только другой IP.
В теории можно для одного IP адреса, указать более одного домена. Но этого делать не нужно, так как система доменных имен (DNS) имеет запись специально предназначенную для создания псевдонимов. Называется эти запись типа CNAME.
Тип записи АААА
Тип записи: AAАA (address record для IPv6) или (адрес Internet 6) . Тоже. Что и тип записи А, но IP адрес имеет внешний вид по протоколу IPv6. Например: IPv6-2a03:4900:0:3::99:155
Тип записи CNAME
CNAME (каноническое имя -canonical name record) . Запись типа CNAME позволяет иметь и использовать на сервере более одного имени домена (хоста).
Сначала создается одна запись типа А, для одного IP адреса. Имя домена в записи типа А, называется каноническим именем. Другие домены называют мнемонические. Мнемонические имена могут быть псевдонимами (произвольными именами) или субдоменами. Здесь пример CNAME записи:
popov.example.ru. CNAME example.ru. (не забываем точки в конце).
Сервер может иметь любое количество псевдонимов. Для каждого псевдонима нужно создать запись типа CNAME.
Еще пример записи CNAME:
hosting-1 IN A 8.8.8.8
www IN CNAME hosting-1
ftp IN CNAME hosting-1
Покупаем второй IP и на второй IP переводим поддомен ftp:
hosting-1 IN A 8.8.8.8
hosting-2 IN A 8.8.8.9
www IN CNAME hosting-a
ftp IN CNAME hosting-b , переносим на второй хостинг FTP –сервер.
Еще пример записи CNAME:
hosting-1 IN A 8.8.8.8
peter IN CNAME hosting-1
oleg IN CNAME hosting-1
Следующими записями CNAME привязываем псевдонимы:
example.com. IN CNAME example.ru.
www.example.com. IN CNAME example.ru.
test.example.com. IN CNAME example.ru.
тем самым мы связываем домены example.com, www.example.com, test.example.com с каноническим доменом example.ru. Точки в конце обязательны.
Еще пример переадресация (редирект) с помощью записи типа CNAME
www.example.ru. IN CNAME example.ru.
Обычно, сервера по умолчанию создают записи CNAME только для поддоменов основного домена и не делают их для других доменов (как на фото).
Тип записи MX
MX (почтовый сервер). Эта запись создает поддомен, который обслуживается внутренним (своим) почтовым сервером.
Например: Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mail. Этой записью вы создаете почтовый поддомен mail.example.ru. Если используется внутренний почтовый сервис сервера, то для поддомена mail.example.ru нужно создать тип записи «А». Имя:mail- A (тип записи)- Адрес: IP сервера.
В качестве почтового сервиса можно использовать сторонние почтовые сервера. Для этого вам нужно привязать свой домен к стороннему почтовому серверу. На нем вам создадут, автоматом, MX запись. Если не создадут, то дадут адрес почтового сервера. После этого вам нужно создать записи типа CNAME и MX на своем сервере.
Записью CNAME переадресуйте почтовый домен mail.example.ru. на адрес почтового домена. А записью типа MX для самого домена example.ru. задайте адрес вашего стороненого почтового ящика. В качестве примера можно использовать почтовый сервер Яндекс.
- Для Яндекс тип записи MX будет такой:
Имя/хост/псевдоним — example.ru; Тип записи -MX (почтовый сервер); Значение/ответ/назначение/Адрес – mx.yandex.ru. Приоритет 10.
- Тип CNAME такой:
Имя/хост/псевдоним – mail; Тип записи –CNAME; Значение/ответ/назначение/Адрес –domain.mail.yandex.ru. Приоритет 10.
На почтовом сервере Яндекс , можно без делегирования домена, подключить его только к почтовому серверу Яндекс, создав там, почтовый ящик.
Кроме Яндекс, с помощью MX записей можно привязать домен к почтовым серверам Google, Mail.ru и другим:
Тип записи NS
Тип записи NS (сервер имён). Это, пожалуй, самый важный тип записи. Он определяет домены (адреса) DNS серверов, обслуживающих этот домен.
Тип записи TXT
TXT (текстовая запись) . Это информационная запись. Она не несет функциональной нагрузки.
Запись типа SOA (Start Of Authority)
Запись типа SOA показывает, где храниться на каком сервере лежит основная информация об этом домене. В записи типа SOA указывается полное, уточненное доменное имя зоны. Уточненное доменное имя должно оканчиваться точкой. В записи SOA может стоять символ @, вместо уточненного имени. В этом случае, доменное имя будет взято из файла конфигурации.
- Произвольный серийный номер версии данных (Serial). При запросе вторичного сервера на обновление данных, он, прежде всего, проверяет серийный номер;
- Периодичность запроса для обновления данных со стороны вторичного (Secondary) сервера (Refresh), в секундах;
- Период повторного запроса вторичного сервера при первичной неудаче (Retry);
- Срок действия (годности) данных (Expire), иначе истечение времени, через которое вторичный сервер перестанет обслуживать запросы, если ему не получиться восстановить связь с первичным сервером, в секундах;
- И последнее, время жизни данных зоны DNS в кэше сервера (TTL), запросившего их, в секундах.
Приведу пример записи SOA, для Microsoft DNS
Как редактировать DNS записи в панели ISPManager
В панели ISPManager DNS записи редактируются на вкладке: Доменные имена→ «Клик» по домену.
Как редактировать DNS записи в панели DirectAdmin
В панели DirectAdmin DNS записи редактируются на вкладке: Управление DNS.
Мы размещаем множество веб-приложений для наших клиентов. Очевидно, что они хотят использовать свои собственные домены для ссылки на эти приложения, обычно они хотят, чтобы любой пользователь, который http://www.customer1.example или http://customer1.example пошел в свое веб-приложение.
Ситуация, с которой мы сталкиваемся, заключается в том, что мы должны иметь возможность менять IP-адреса в ближайшем будущем. И мы не хотим полагаться на то, что клиент вносит изменения в записи A в своих доменах. Поэтому мы подумали, что использование записей CNAME будет работать, но, как мы выяснили, записи CNAME не будут работать для корневого домена.
В принципе:
Customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work
Мы хотим иметь возможность изменить IP-адрес customer1.mycompanydomain.example или запись A и наши клиенты будут следовать этой записи, которую мы контролируем.
в нашем DNS это будет выглядеть так:
Customer1.mycompanydomain.example IN A 192.0.2.1
Есть идеи?
8 ответов
Благодаря сипвизу и мистеру Эвилю. Мы разработали PHP script, который проанализирует URL-адрес, который пользователь вводит и вставляет www в начало. (например, если клиент входит kiragiannis.com , он перенаправляется на www.kiragiannis.com). Поэтому наш клиент указывает свой корень (например, customer1.com на A запись, где находится наш веб-редиректор), а затем www CNAME на реальную запись A , управляемую нами.
Ниже кода в случае, если вы заинтересованы в будущем нас.
Причина, по которой этот вопрос все еще часто возникает, заключается в том, что, как вы упомянули, где-то кто-то считал важным автором, что RFC заявляет, что доменные имена без поддоменов перед ними недопустимы. Однако, если вы внимательно прочитаете RFC, вы поймете, что это не совсем то, что написано. Фактически, RFC 1912 заявляет:
Не переусердствуйте с CNAME. Используйте их при переименовании хостов, но планируйте избавиться от них (и проинформируйте своих пользователей).
Некоторые DNS-хосты предоставляют способ получить CNAME-подобную функциональность на верхушке зоны (уровень корневого домена для "голого" доменного имени), используя пользовательский тип записи. Такие записи включают, например:
- Алиас в DNSimple
- ANAME в DNS Made Easy
- ANAME на easyDNS
- CNAME на CloudFlare
Для каждого провайдера настройка аналогична: укажите запись ALIAS или ANAME для вашего домена apex на example.domain.com, так же, как и в случае записи CNAME. В зависимости от провайдера DNS, пустое значение или значение @Name определяет вершину зоны.
ALIAS или ANAME или @example.domain.com.
Если ваш DNS-провайдер не поддерживает такой тип записи, и вы не можете переключиться на тот, который поддерживает, вам нужно будет использовать перенаправление поддоменов, что не так сложно, в зависимости от протокола или серверного программного обеспечения, которое должно это делать,
Я категорически не согласен с утверждением, что это делают только "любители-админы" или подобные идеи. Это просто "Что нужно сделать имени и его сервису?" разобраться, а затем адаптировать свой DNS-конфигурацию для удовлетворения этих пожеланий; Если вашими основными услугами являются Интернет и электронная почта, я не вижу никаких ДЕЙСТВИТЕЛЬНЫХ причин, по которым удаление CNAME навсегда было бы проблематичным. В конце концов, кто предпочел бы @subdomain.domain.org над @domain.org? Кому нужен "www", если вы уже настроили сам протокол? Нелогично предполагать, что использование корневого доменного имени будет недопустимым.
CNAME - запись корня технически не против RFC, но имеет ограничения, что означает, что это не рекомендуется.
Обычно ваша корневая запись будет содержать несколько записей. Скажем, 3 для ваших серверов имен, а затем один для IP-адреса.
Если CNAME RR присутствует на node, никакие другие данные не должны быть присутствует;
И в документе IETF "Общие ошибки в работе и конфигурации DNS":
Это часто предпринимают неопытные администраторы как очевидные чтобы ваше доменное имя также являлось хостом. Однако DNS серверы, такие как BIND, увидят CNAME и откажутся добавлять любые другие ресурсов для этого имени. Поскольку никакие другие записи не разрешены сосуществуют с CNAME, записи NS игнорируются. Поэтому все хосты в домене podunk.xx также игнорируются!
Я не знаю, как они справляются с этим, или какие отрицательные побочные эффекты могут быть, но я использую Hover.com для размещения некоторых из моих доменов и недавно установил вершину моего домена как CNAME. Их инструмент редактирования DNS вообще не жаловался, и мой домен с радостью разрешается через назначенный CNAME.
Вот что Dig показывает мне для этого домена (фактический домен, запущенный как mydomain.com):
; <<>> DiG 9.8.3-P1 <<>> mydomain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mydomain.com. IN A ;; ANSWER SECTION: mydomain.com. 394 IN CNAME myapp.parseapp.com. myapp.parseapp.com. 300 IN CNAME parseapp.com. parseapp.com. 60 IN A 54.243.93.102
Вы должны указать период в конце внешнего домена, чтобы он не думал, что вы имеете в виду client1.mycompanydomain.com.localdomain;
Итак, просто измените:
Customer1.com IN CNAME customer1.mycompanydomain.com
Customer1.com IN CNAME customer1.mycompanydomain.com.
Sipwiz правильно, единственный способ сделать это правильно - это гибридный подход HTTP и DNS. Мой регистратор является повторным продавцом для Tucows, и они предлагают переадресацию доменов в качестве бесплатной добавленной стоимости.
Если ваш домен - blah.com, они спросят вас, куда вы хотите переадресовать домен, и введите его на www.blah.com. Они назначают запись A их серверу apache и автоматически добавляют blah.com в качестве DNS-хоста. Vhost отвечает с ошибкой HTTP 302, перенаправляя их на правильный URL. Это просто для script/setup и может быть обработано с помощью low-end в противном случае было бы утилизировано.
Выполните следующую команду для примера: curl -v eclecticengineers.com