Как обойти ограничения CNAME корневого домена?


117

Мы размещаем множество веб-приложений для наших клиентов. Очевидно, что они хотят использовать свои собственные домены для ссылки на эти приложения, обычно они хотят, чтобы любой пользователь либо вводил, http://www.customer1.exampleлибо http://customer1.exampleпереходит в их веб-приложение.

Ситуация, с которой мы сталкиваемся, заключается в том, что нам необходимо иметь возможность изменить IP-адреса в ближайшем будущем. И мы не хотим полагаться на то, что заказчик внесет изменение в свои домены. Поэтому мы подумали, что использование 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

Любые идеи?


Я не понимаю, почему "customer1.com IN CNAME" customer1.mycompanydomain.com недействителен. Я считаю, что это должно сработать. Не могли бы вы объяснить, в чем проблема с этим решением?
sleske

3
Да, прочтите следующий вопрос и ответ. Он недействителен согласно DNS RFC. stackoverflow.com/questions/655235/…
Geo

2
Я не понимаю заголовок вопроса. Где задействован "корень" (.)?
bortzmeyer

2
он имеет в виду корень зоны, а не «корень»
Alnitak

2
Что ж, тогда это не обычный словарь DNS. Разве "апекс" не подходящее слово? Или «на высшем уровне» для программистов на Лиспе? :-)
bortzmeyer

Ответы:


63

Причина, по которой этот вопрос все еще часто возникает, заключается в том, что, как вы упомянули, где-то кто-то, считающийся важным, написал, что RFC заявляет, что доменные имена без поддомена перед ними недействительны. Однако если вы внимательно прочитаете RFC, вы обнаружите, что это не совсем то, о чем говорится. Фактически, RFC 1912 гласит:

Не переусердствуйте с CNAME. Используйте их при переименовании хостов, но планируйте избавиться от них (и проинформируйте своих пользователей).

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

  • НИКНЕЙМЫ в DNSimple
  • ANAME в DNS стало проще
  • ANAME на easyDNS
  • CNAME в CloudFlare

Для каждого провайдера настройка аналогична: укажите в записи ALIAS или ANAME для вашего верхнего домена example.domain.com, как если бы вы использовали запись CNAME. В зависимости от поставщика DNS пустое значение или значение @ Name определяет вершину зоны.

ALIAS или ANAME или @ example.domain.com.

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

Я категорически не согласен с утверждением, что это делают только «админы-любители» или подобными идеями. Это простой вопрос: «Что должны делать имя и его служба?» сделка, а затем адаптировать конфигурацию DNS для удовлетворения этих пожеланий; Если ваши основные услуги - это Интернет и электронная почта, я не вижу ДЕЙСТВИТЕЛЬНОЙ причины, по которой навсегда отказаться от CNAME было бы проблематично. В конце концов, кто предпочтет @ subdomain.domain.org вместо @ domain.org? Кому нужен www, если вы уже настроили сам протокол? Нелогично предполагать, что использование имени корневого домена было бы недопустимым.


1
Этот конкретный ответ был очень полезен для меня, так как я хотел указать домен корневого уровня в CDN. Большинство CDN по необходимости являются полными доменными именами, поскольку они могут разрешаться на разные IP-адреса в разных местах и ​​в разное время. Я использую DNS Made Easy и могу использовать тип записи ANAME.
Rubix

3
Я не мог с этим согласиться. Желание разместить сайт с «голого» доменного имени - обычное и логичное решение. Он использует меньше символов, он выглядит лучше и т. Д. Собственный идентификатор протокола URL-адреса (www) является неотъемлемой частью URL-адреса, если он вообще был необходим (а это было не так).
Эд Бишоп

3
ANAME хороши, или вы можете просто 301, все без www на www. через бесплатную службу перенаправления 301 198.251.86.133
Джейкоб Эванс,

51

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

Обычно ваша корневая запись содержит несколько записей. Скажем, 3 для ваших серверов имен, а затем один для IP-адреса.

Согласно RFC:

Если на узле присутствует запись CNAME RR, других данных не должно быть;

И согласно документу IETF «Общие ошибки работы и конфигурации DNS»:

Это часто делается неопытными администраторами как очевидный способ разрешить вашему доменному имени также быть хостом. Однако DNS-серверы, такие как BIND, увидят CNAME и откажутся добавлять какие-либо другие ресурсы для этого имени. Поскольку никакие другие записи не могут сосуществовать с CNAME, записи NS игнорируются. Поэтому все хосты в домене podunk.xx также игнорируются!

Ссылки:


17
Но ПОЧЕМУ никакая другая запись не может сосуществовать с CNAME? Это просто ограничение, добавленное автором RFC, или для этого есть техническая причина? Если для этого нет технических причин, можно легко придумать RFC-расширение.
Sven

Итак, если это работает для меня (используйте CNAME для корневой записи, другие поддомены для этого домена все еще работают), это означает, что мне просто повезло, и реализация DNS моего провайдера не игнорирует эти дополнительные записи, хотя могла? И это также означает, что мне не нужно бояться каких-либо проблем на стороне клиента, если DNS-сервер обрабатывает это так?
didi_X8 04

Это попытка ответить на другой вопрос, «почему CNAME не разрешены на вершине», тогда как на самом деле вопрос заключается в том, «как преодолеть это ограничение». -1.
rustyx 03


CNAME 'создание корневой записи технически не противоречит RFC, вам нужно будет объяснить, почему это не противоречит разделу 3.6.2 RFC1034: Если CNAME RR присутствует на узле, никакие другие данные присутствовать не должны; это гарантирует, что данные для канонического имени и его псевдонимов не могут отличаться. , Конечно, «корень» (то есть апекс именно в этом контексте) уже NSи SOAзаписи и , следовательно , не может иметь CNAMEзаписи.
Патрик Мевзек 02

4

Я не знаю, как им это сходит с рук или какие у них могут быть отрицательные побочные эффекты, но я использую 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

Обфускация, если она действительно необходима (DNS является общедоступной ...), должна использовать руководство RFC2606. И RFC5737 или 3849 для IP-адресов
Патрик Мевзек 02

3

Моя компания делает то же самое для ряда клиентов, где мы размещаем для них веб-сайт, хотя в нашем случае это xyz.company.com, а не www.company.com. Мы заставляем их установить запись A на xyz.company.com, чтобы указать на IP-адрес, который мы им выделяем.

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

  • Используйте балансировщик нагрузки NAT или IP и дайте своим клиентам принадлежащий ему IP-адрес. Если IP-адрес веб-сервера необходимо изменить, вы можете обновить NAT или балансировщик нагрузки,

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

  • Попросите ваших клиентов установить свою запись A для одного основного веб-сервера и использовать перенаправление HTTP для веб-запросов каждого клиента.


3

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

Если ваш домен blah.com, они спросят вас, куда вы хотите переадресовать домен, и вы наберете www.blah.com. Они назначают запись A своему серверу apache и автоматически добавляют blah.com в качестве виртуального хоста DNS. Vhost отвечает ошибкой HTTP 302, перенаправляя их на правильный URL. Это просто скрипт / настройка, и с ним может справиться младший уровень, иначе оборудование было бы утилизировано.

В качестве примера выполните следующую команду: curl -v eclecticengineers.com


3

Вы должны поставить точку в конце внешнего домена, чтобы он не думал, что вы имеете в виду customer1.mycompanydomain.com.localdomain;

Так что просто измените:

customer1.com IN CNAME customer1.mycompanydomain.com

к

customer1.com IN CNAME customer1.mycompanydomain.com.

Для меня (BIND 9.8.2), если записи предназначены для домена customer1.com, это работает ... но интерпретируется как указание CNAMe для поддомена customer1.com.customer1.com. Если я добавлю точку к первому элементу, запись будет интерпретироваться правильно, но больше не будет работать. Я не вижу здесь решения.
Юсси Хирви

-2

Я вижу, что readytocloud.com размещен на Apache 2.2.

Существует гораздо более простой и эффективный способ перенаправить сайт без www на сайт с www в Apache.

Добавьте следующие правила перезаписи в конфиги Apache (внутри виртуального хоста или снаружи. Не имеет значения):

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]

Или следующие правила перезаписи, если вы хотите, чтобы URL-адреса с сайта без www на сайт с www отображались один к одному:

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]

Обратите внимание: для этого необходимо загрузить модуль mod_rewrite. К счастью, readytocloud.com работает на платформе CentOS, которая по умолчанию загружает mod_rewrite.

У нас есть клиентский сервер под управлением Apache 2.2 с немногим менее 3000 доменов и почти 4000 перенаправлений, однако нагрузка на сервер колеблется в районе 0,10–0,20.


Вопрос был про DNS. Не про веб-сервер Apache.
SamTzu

-7

Спасибо sipwiz и MrEvil. Мы разработали PHP-скрипт, который анализирует вводимый пользователем URL и вставляет его wwwв начало. (например, если клиент заходит на kiragiannis.com , он перенаправляет на www.kiragiannis.com ). Итак, наш клиент указывает свой корень (например, customer1.comдля Aзаписи, где находится наш веб-перенаправитель), а затем www CNAMEна реальную Aзапись, управляемую нами.

Ниже код на случай, если вы заинтересованы в будущем нас.

<?php
$url = strtolower($_SERVER["HTTP_HOST"]);

if(strpos($url, "//") !== false) { // remove http://
  $url = substr($url, strpos($url, "//") + 2);
}

$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
  $urlPagePath = substr($url, strpos($url, "/"));
  $url = substr($url, 0, strpos($url,"/"));
}


$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));


if(strpos($url, ".") !== false) { // get rid of subdomain(s)
  $url = substr($url, strrpos($url, ".") + 1);
}


$url = "http://www." . $url . $urlLast . $urlPagePath;

header( "Location:{$url}");
?>

10
Это на самом деле не отвечает на вопрос, который более 69 тысяч человек пришли в эту ветку в поисках. Вопрос больше о DNS и не имеет ничего общего с PHP.
Мэтт Кларк,

1
Вопрос был про DNS. Не о кодировании PHP.
SamTzu

HTTP_HOST - это имя хоста, как следует из его названия, а не URL-адрес. Следовательно, не будет ни http://удаления, ни /( $urlPagePathвсегда будет пустым). См. Httpd.apache.org/docs/2.4/expr.html . Из-за того, что код пытается избавиться от поддомена, он также не будет работать для таких вещей, как www.example.co.ukwhere, co.ukкоторое следует рассматривать в целом. Он также не поддерживает HTTPS. И, наконец, использование PHP просто перенаправления HTTP, когда любой веб-сервер может сделать это в конфигурации, слишком сложно. Короче говоря, это определенно не должно быть подтвержденным ответом на этот вопрос.
Патрик Мевзек 02

Если это правило должно применяться ко всем хостам, то это должно быть сделано как конфигурация apache
Святослав Маринов
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.