У меня есть сайт с профилями пользователей и следующей структурой адресов:
Мне нужно разрешить пользователям указывать / перенаправлять свои собственные домены на соответствующую страницу на моем сайте, например:
Один внешний домен можно указать только на одну внутреннюю страницу. Пользователи настроят свой DNS вручную, добавив запись CNAME / A. У пользователей будет только домен, без сервера, поэтому они не смогут перенаправить через .htaccess.
Поэтому мне нужно было бы предоставить пользователям запись CNAME / запись A, чтобы они обновили DNS и перенаправили свой домен мне.
Вопрос такой:
Заранее благодарим вас за то, что поделились своим экспертным мнением.
Поэтому мне нужно было бы предоставить пользователям запись CNAME / запись A, чтобы они обновили DNS и перенаправили свой домен мне.
Осторожно: вы, похоже, объединяете концепции DNS с концепциями протокола HTTP (просмотр веб-страниц). Они разные и требуют отдельного рассмотрения.
DNS используется для обеспечения сопоставления доменных имен и IP-адресов (и других записей ресурсов, но здесь это не имеет значения). Другими словами, он определяет сервер, ответственный за www.user1owndomain.com, www.user2owndomain.com, www.mywebsite.com, и все.
В DNS нет концепции протоколов, которые могут подключаться к этому серверу, и, следовательно, данные HTTP, такие как имена путей (/ user1), бессмысленны в смысле DNS. Они даже не передаются DNS-серверу на этапе разрешения адреса. Помните, что доменное имя www.domain.com не означает, что оно может использоваться только для веб-трафика; это единственное соглашение, что на www.domain.com обычно есть компьютер, работающий на другом конце, который прослушивает порт 80 и обслуживает веб-сайт, но он также может обслуживать трафик SSH, почтовый сервер и т. д.
HTTP, протокол обмена данными между браузером и сервером, на который разрешается домен. Если www.mywebsite.com имеет IP 1.2.3.4 в соответствии с DNS, браузер подключается к этому серверу через порт 80 для просмотра веб-страниц.
Если вам нужно выполнить перенаправление веб-трафика, это делается на уровне HTTP, и DNS имеет минимальное влияние на фактическое перенаправление (даже если вы используете псевдоним DNS или запись CNAME; см. Ниже).
Если мой сайт работает на Amazon S3, могу ли я это сделать? (так в оригинале)
Да. Есть два возможных пути:
Используйте экземпляр EC2, на котором вы запускаете веб-сервер (Apache, nginx или аналогичный). Настройте DNS для www.userXowndomain.com для разрешения на IP-адрес этого сервера. Настроить Виртуальные хосты Apache для каждого из пользовательских доменов, указывающих на веб-сервер. Настройте каждый виртуальный хост для перенаправления на нужный URL (www.mywebsite.com/user1) в соответствии с этот вопрос SF.
Чистый эффект: DNS преобразуется в IP, браузер подключается к IP, Apache определяет домен и сопоставляется с виртуальным хостом, конфигурация виртуального хоста отправляет HTTP-перенаправление на правильный URL.
Если вы не хотите запускать полный экземпляр EC2 исключительно для веб-трафика, вы можете использовать для этой цели сегменты S3 в сочетании с маршрутом 53 для направления трафика на каждый домен www.userXowndomain.com в сегмент. Затем сегмент настраивается с перенаправлением на соответствующий URL-адрес.
Примечание: если у вас есть экземпляр EC2 для хостинга www.mywebsite.com, нет причин, по которым его нельзя использовать для перенаправления. Это просто дополнительная конфигурация виртуального хоста Apache, поэтому отдельный экземпляр не требуется.
Если да, то как и есть ли какие-либо ограничения на количество связанных доменов?
Жестких ограничений нет. Могут быть искусственно наложены ограничения из-за конфигурации Apache на количество виртуальных хостов (в основном из-за ведения журнала и количества открытых файловых дескрипторов), но их можно преодолеть с помощью тщательная настройка.
Мягкие ограничения могут вступить в игру, если перенаправления чрезвычайно занят, так что сервер перегружается. Это было бы то, что вы могли бы обнаружить с помощью обычного мониторинга производительности и введения большего количества серверов для балансировки нагрузки (или переноса загруженной работы на выделенные машины). Если вы не бежите очень сайты с высокой посещаемостью, это вряд ли будет проблемой.
Это можно решить с помощью самого S3 или мне нужно использовать Route 53? (так в оригинале)
Как отмечалось выше, не путайте DNS с HTTP. Если у доменов пользователя есть собственная служба DNS, например, предоставляемая регистратором, вы можете использовать ее для настройки записей DNS, указывающих на экземпляр EC2, на котором выполняется перенаправление веб-сервера. Вы также можете делегировать серверы имен домена на маршрут 53. Окончательный ответ, вероятно, зависит от ваших отношений с клиентом: первое решение позволяет клиенту управлять своим собственным DNS (например, для других служб, таких как почта). Последний передает вам контроль над всем пространством имен userXowndomain.com, то есть вы должны настроить ВСЕ аспекты DNS, связанные с этим доменом. Это может включать, помимо прочего, записи MX для доставки почты, любые другие поддомены по желанию клиента, псевдонимы, записи SPF и т. Д.
Является ли сервер Linux / Apache лучшей платформой для этого? Если да, то как его настроить?
Apache, работающий в Linux, был бы одним из способов достижения этого, и, вероятно, это было бы рентабельно. Существует множество других платформ веб-обслуживания, которые также могут выполнять перенаправления HTTP. Конфигурация выполняется в соответствии с соответствующими страницами для каждого веб-сервера, настраивая виртуальные хосты для каждого домена и настраивая перенаправление HTTP для этого домена.
Стандарт HTTP / 1.1 в RFC 2616, определяет несколько типов перенаправления. Вам нужно будет указать тип перенаправления, который веб-сервер должен обслуживать для перенаправления www.userXowndomain.com -> www.mydomain.com/userX. Было бы поучительно изучить RFC, поскольку разные перенаправления подразумевают разное поведение и могут иметь вторичное влияние на такие проблемы, как SEO.
Наиболее распространенные перенаправления определены Коды состояния HTTP 301 и 307, что соответствует «постоянно перемещен на другой URL» и «временно перемещен на другой URL» соответственно. Временно перемещенный URL-адрес, в частности, означает, что исходный URL-адрес (www.userXowndomain.com) все еще должен использоваться для доступа к запрошенному ресурсу в будущем, и пользовательские агенты не должны обновлять свои записи для постоянного использования www.mywebsite.com/ user1 как начальный URL.
Перенаправления с использованием "наборов фреймов" также использовались в прошлом. Это тот случай, когда вы размещаете одну веб-страницу в домене каждого пользователя, который использует тег с одним кадром, указывающим на правильный URL. Такого подхода обычно следует избегать.
Часто возникает путаница в отношении роли DNS и протокола HTTP в просмотре веб-страниц, в частности потому, что DNS предоставляет записи CNAME или «псевдонимы», которые являются псевдонимом возврата DNS одного домена к выходным данным другого.
Псевдоним DNS означает ничего в веб-браузер; псевдоним DNS просто сообщает преобразователю DNS, что на запросы домена X следует отвечать, как если бы это был запрашиваемый домен Y, и, следуя цепочке, в конечном итоге должен быть достигнут IP-адрес, к которому подключается браузер. Затем браузер подключается к этому адресу, все еще полагая, что он обращается к изначально запрошенному домену (например, www.userXowndomain.com).
Вы можете реализовать свои перенаправления, используя CNAME для каждого пользовательского домена, с www.userXowndomain.com, указывающим на домен www.mywebsite.com в DNS. Тем не менее, вам все равно необходимо настроить веб-сервер с виртуальными хостами или чем-то подобным, чтобы соответствовать каждому запросу для www.userXowndomain.com и выполнять перенаправление на www.mywebsite.com/userX. DNS просто сообщает браузеру, как подключиться к веб-серверу; вместо этого он не сообщает браузеру, что такое URL-адрес перенаправления.
Однако эта конфигурация не лишена недостатков. Если вы хотите перенаправить корень зоны (например, http: // userXowndomain.com), есть ограничения за использование CNAME в корне зоны, потому что никакие другие данные не должны сосуществовать в корне зоны согласно RFC (например, запись MX для доставки почты). Это может не быть проблемой, или это может быть препятствием, в зависимости от услуги, которую вы предлагаете своим пользователям.
Я должен отметить, что многие регистраторы доменов предоставляют базовые HTTP-перенаправления 301 или 307 в стандартной комплектации с регистрацией доменного имени, и, следовательно, вы можете избежать значительной сложности, используя их службу, а не создавая свою собственную.