Это Канонический вопрос о разрешении DNS / имен хостов в IP-адреса / порты
У меня один веб-сервер работает на порту 80, а другой - на порту 87. Я хотел бы использовать DNS, чтобы www.example.com перешел на порт 87. Как я могу сделать это, используя только DNS?
Я запускаю службу на своем сервере через нестандартный порт. Как я могу заставить клиентов автоматически подключаться к этому нестандартному порту? Могу ли я использовать DNS? Есть ли поддержка конкретных приложений, где DNS может указывать IP и порт?
Поддерживают ли некоторые прикладные протоколы информацию об имени хоста и позволяют ли предпринимать особые действия на основе этой информации? Есть ли другие вопросы по сбоям сервера, которые касаются некоторых из них?
Commandeering: Первоначально этот вопрос касался запуска IIS и Apache на одном сервере, но те же концепции могут быть применены к любому серверному программному обеспечению, получающему соединения от клиентов. В приведенных ниже ответах описываются технические проблемы и решения, связанные с использованием DNS и поддержки протоколов приложений для назначения номера порта для подключения клиента.
Вы не можете использовать DNS для указания порта (если клиент не поддерживает записи SRV, большинство из них не поддерживает).
Для этого вам нужно будет применить какой-нибудь интерфейсный метод. Обычно вы используете интерфейсный веб-сервер или специализированное программное обеспечение прокси для перенаправления соединения с порта 80 на порт! 80 на основе имени сервера, запрашиваемого в заголовке. Некоторые брандмауэры также могут пересылать данные на основе заголовка хоста.
Некоторые клиенты поддерживают поиск записей SRV, которые указывают имя хоста и номер порта сервера для указанной службы (т.е. пользователь указывает «example.com», клиент ищет запись SRV и получает «server101.example.com» на порту «255». "; затем подключается к этому). Некоторые клиенты также реализуют это там, где это не требуется (мой последний смартфон будет искать записи SRV, например, при настройке новой учетной записи электронной почты).
К сожалению, поддержка SRV-записей встречается редко. Только несколько известных протоколов требуют его поддержки (Jabber / XMPP, Kerberos, LDAP, SIP), и не каждый клиент поддерживает его, даже если это требуется.
Когда вы печатаете http://www.domain.com в вашем браузере подразумевается, что порт HTTP находится на 80. Следовательно, нет прямого способа указать www.domain.com на порт 87, если у вас уже есть служба, работающая на этом порту в IIS.
При этом есть несколько "обходных путей".
Сэм прав, DNS не зависит от портов. Любое перенаправление порта происходит службой, работающей на этом порту. Поэтому вам нужно будет что-то сделать с IIS, чтобы это произошло, если у вас нет другого выбора, кроме как оставить его на порту 80.
Я также обошел вашу ситуацию, используя mod_proxy на Apache, не уверен, есть ли способ сделать это с помощью IIS.
Боюсь, что доменные имена могут быть связаны только с IP-адресом, а не с портом.
Большинство веб-серверов, например (Apache, IIS и т. Д.) Позволяют размещать два домена на одном IP-адресе, используя тот факт, что веб-запросы содержат поле заголовка хоста, которое идентифицирует домен в самом запросе.
Если вы скажете, какой веб-сервер вы используете, я уверен, что люди могут указать вам соответствующую документацию, чтобы настроить ваш сервер так, как вы хотите.
Технически вы можете использовать Записи SRV на DNS-серверах, как определено в RFC 2782 чтобы сообщить браузерам, какие серверы обрабатывают http и на каких портах для (под) домена:
_http._tcp.www.example.com. IN SRV 0 5 80 www.example.com.
_http._tcp.www2.example.com. IN SRV 0 5 87 www.example.com.
Это хорошо работает для многих протоколов / служб, особенно там, где использование записей SRV уже определено в спецификации протокола.
Однако как это "зал позора", большинство веб-браузеров / клиентов не поддерживают это (для HTTP). Также см. почему-браузеры-не-использовать-SRV-записи.
Дело в том, что SRV не включен в протокол http как обязательный, поэтому каждый браузер, который его реализует, разрешает URL-адреса иначе, чем браузеры, которые этого не делают.
Таким образом, вы должны использовать это только в качестве дополнительной балансировки нагрузки, когда не имеет значения, какой сервер выбран с точки зрения контента. «Необязательный», потому что он не сможет сбалансировать большую часть нагрузки, если это будет реализовано только несколькими клиентами.
DNS не имеет возможности перенаправления на определенный порт, все, что заботит DNS, - это разрешение IP-адреса имени, и наоборот.
Некоторые службы, такие как поставщики DNS с динамическим IP, например NO-IP предоставить услугу, которая может помочь вам сделать что-то подобное, чтобы обойти блокировку IP-адресов в домашних службах DNS.
Чтобы использовать любой (TBT) на нестандартном порте и не записывать порт в URI, все может использовать записи SRV, определенные в RFC 2782.
_http._tcp.www.example.com. IN SRV 0 5 87 www.example.com.
Все остальные http-хосты в зоне по-прежнему будут обслуживаться через порт 80 по умолчанию.
Самый простой способ - использовать обратный прокси-сервер и установить его в качестве веб-прокси. Вы можете настроить nginx или apache для этого. Раньше у меня была в основном та же проблема, и я создал инструмент для простой настройки такой конфигурации. Ergo: https://github.com/cristianoliveira/ergo
Я использовал это, и в основном работает как шарм :)
Один из подходов к развертыванию двух веб-серверов на одном хосте состоит в том, чтобы оба они прослушивали порт 80 на двух разных адресах IPv6. IPv6 официально указывает, что вы можете назначить два адреса интерфейсу, и есть достаточно адресов IPv6, которые вы можете сделать, не исчерпывая адресов.
Это на будущее, и каждый из ваших двух доменов может иметь записи AAAA, указывающие на разные IP-адреса, поэтому домены будут находиться на разных веб-серверах.
Если у вас также есть один IPv4-адрес, вы можете использовать порт 80 на IPv4-адресе для запуска обратного прокси. Таким образом клиенты, использующие только IPv4, могут получить доступ к обоим вашим веб-серверам. Подход с обратным прокси-сервером работает даже в том случае, если некоторые веб-серверы находятся на том же хосте, что и обратный прокси-сервер, а некоторые веб-серверы находятся на других хостах.
В такой настройке example.org мог иметь адреса 192.0.2.1 и 2001:db8::1 пока example.net имеет адреса 192.0.2.1 и 2001:db8::2.
Мне не известны технические детали, но я решил эту проблему, создав дистрибутив CloudFront, указывающий на указанный порт HTTP.
Затем в Route 53 я указал на раздачу CloudFront.