Как преодолеть ограничения CNAME в корневом домене?

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

Есть идеи?

Ответ 1

Благодаря сипвизу и мистеру Эвилю. Мы разработали PHP script, который проанализирует 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}");
?>

Ответ 2

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

Ответ 3

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

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

В RFC:

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

И в документе IETF "Общие ошибки в работе и конфигурации DNS":

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

Литература:

Ответ 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

Ответ 5

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

Ответ 6

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

Итак, просто измените:

customer1.com IN CNAME customer1.mycompanydomain.com

Для

customer1.com IN CNAME customer1.mycompanydomain.com.

Ответ 7

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

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

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

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

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

Ответ 8

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

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

Добавьте в правила Apache следующие правила перезаписи (либо внутри виртуального хоста, либо вне его).

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

Или, следующие правила перезаписи, если вы хотите, чтобы URL-адреса от 1 до 1 сопоставлялись с сайтом, отличным от 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.