Как использовать DNS/ имена хостов или другие способы разрешения определенного IP: порт

Это канонический вопрос о разрешении DNS/ имен хостов на IP / порты

Пример 1

Я использую веб-сервер на порту 80, а другой - на порту 87. Я хотел бы использовать DNS, чтобы www.example.com перешел на порт 87. Как я могу сделать это, используя только DNS?

Пример 2

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

Пример 3

Поддерживают ли некоторые протоколы приложений определенную осведомленность об имени хоста и позволяют ли предпринимать специальные действия на основе этой информации? Есть ли другие вопросы о сбое сервера, которые охватывают некоторые из них?

Commandeering: Первоначально этот вопрос задавался о запуске IIS и Apache на одном и том же сервере, но те же концепции можно применять к любому серверному программному обеспечению, получающему соединения от клиентов. В приведенных ниже ответах описаны технические проблемы и способы использования поддержки DNS и протоколов приложений для назначения номера порта для подключения клиента.

8 ответов

Вы не можете использовать DNS, чтобы указать на порт (если клиент не поддерживает записи SRV, большинство не делает).

Сайты и протоколы с заголовками хоста

Для этого вам нужно будет установить какой-нибудь интерфейсный метод. Обычно вы используете интерфейсный веб-сервер или специальное прокси-сервер для переадресации соединения с порта 80 на порт!80 на основе имени сервера, запрашиваемого в заголовке. Некоторые брандмауэры также могут пересылать сообщения на основе заголовка узла.

SRV Records

Некоторые клиенты поддерживают поиск записей 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.

При этом есть несколько "обходных путей".

  • Просто используйте http://www.domain.com:87/ - это подключится к порту 87 (apache) на вашем сервере.
  • Вы можете настроить перенаправление, чтобы http://www.domain.com/apache переадресовывал (или прокси-сервер, если вы хотите, чтобы он появился) на www.domain.com:87.
  • Вы можете настроить "VirtualHost" так, чтобы www.domain2.com по-прежнему находился на 80-м порту, доступном для www.domain.com. Вы не можете настроить это без изменения IIS.

Сэм прав, DNS не зависит от портов. Перенаправление портов любого рода происходит службой, работающей на этом порту. Поэтому вам нужно что-то сделать с IIS, чтобы это произошло, если у вас нет другого выбора, кроме как оставить это на порте 80.

Я также обошел вашу ситуацию с помощью mod_proxy на Apache, не уверенный, есть ли способ сделать это с IIS.

Технически вы можете использовать записи 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-records.

Дело в том, что SRV не включен в протокол http как необходимость, поэтому каждый браузер, который его реализует, разрешает URL-адреса по-другому, чем браузеры, которые этого не делают.

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

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

Большинство веб-серверов, например (Apache, IIS и т. Д.), Позволяют размещать два домена на одном и том же IP-адресе, используя тот факт, что веб-запросы содержат поле заголовка узла, которое идентифицирует домен в самом запросе.

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

Чтобы использовать любую (TBT) службу на нестандартном порту и не записывать порт в URI, каждый может использовать записи SRV, определенные в RFC 2782.

_http._tcp.www.example.com. IN      SRV 0    5      87   www.example.com.

Все остальные http-хосты в зоне по-прежнему будут обслуживаться по умолчанию через порт 80

DNS не имеет возможности перенаправить на определенный порт, все, что заботит DNS - это разрешение IP-адреса имени и наоборот.

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

Самый простой способ - использовать обратный прокси-сервер и установить его в качестве веб-прокси. Вы можете настроить 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.

Хотя приведенные выше упоминания ясно показывают, что записи DNS не зависят от порта (за исключением записей SRV, которые не включены в большинство клиентов); есть возможность: использовать сервисы переадресации URL, предлагаемые большинством DNS-провайдеров (например, easyDNS)

Это позволит вам упростить для пользователя:

поэтому из вашего примера http://www.example.com переходит на порт 87, с помощью этой службы вы можете настроить http://www.example.com для доступа к http://www.example.com:87 (в основном пользователь, у которого есть только домен, сможет попасть на ваш сайт); вы также можете использовать это для вызова обычного разрешения протокола http на https://www.example.com:87 или даже для указания на некоторые подстраницы как https://www.example.com:87/dologin

Решение IPV6 для @kaperd кажется идеальным, но, хотя я смог правильно настроить сервер, мне не удалось открыть цель в Chrome... может быть, нужно немного подергать, и я не потратил достаточно времени.

Другие вопросы по тегам