Записи DNS не могут указывать на порты (за некоторыми исключениями, которые здесь не применяются).

Если у вас есть веб-служба, прослушивающая порт 8080, и вы хотите достичь ее, не указывая этот порт, у вас есть 3 варианта:

• Сделайте так, чтобы он действительно слушал порт 80 (или 443 с https).
• Настройте все, что уже прослушивает порт 80, для пересылки запросов к вашей службе через порт 8080 (обратный прокси).
• Если вы можете жить с перенаправлением, используйте его вместо прокси, но тогда ваши клиенты увидят :8080 часть в своих адресных строках после перенаправления.

Веб-серверы по умолчанию прослушивают TCP-порт 80. Если вы не хотите явно вводить номер порта в URL-адресе, у вас есть несколько вариантов:

• Вы можете перенастроить свой веб-сервер для использования порта 80 вместо порта 8080. Это рекомендуется для веб-серверов, таких как nginx или Apache, но не для веб-серверов, таких как Gunicorn. Этот вариант также не всегда возможен, поскольку этот порт может уже использоваться другим веб-сервером.

  Кроме того, когда ваш сервер находится за шлюзом NAT, он не владеет общедоступным IP-адресом, и комбинация этого общедоступного адреса NAT и порта 80 уже может быть перенаправлена ​​на другой веб-сервер.

• Вы можете установить обратный прокси-сервер перед своим веб-сервером, который принимает трафик на TCP-порт 80 и отправляет его на ваш веб-сервер через TCP-порт 8080. Это также будет работать, если порт 80 уже используется. Просто поместите обратный прокси-сервер перед обоими веб-серверами, чтобы они оба слушали порты, отличные от 80.

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

Простой ответ, связанный с уровнем вопроса

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

1. Клиент отправляет доменное имя (полное или иное) на DNS-сервер
2. DNS-сервер возвращает информацию о домене из своих записей. Обычно запрашиваемая ключевая информация - это либо IP-адрес для связи с Интернетом / электронной почтой в этом домене, либо IP-адрес другого DNS-сервера, который лучше может предоставить эту информацию.

Как только клиент связался с сервером, сервер берет на себя управление, и система DNS выпадает из поля зрения.

Это означает, что системе DNS не нужно предоставлять информацию о портах, и она почти никогда этого не делает. Таким образом, хотя цель вопроса верна и часто выполняется, на самом деле это не система DNS. Вот почему вы не можете решить это :)

Идея состоит в том, что, как только ваш клиент может найти конкретную машину или сервер, который он ищет, он должен прослушивать любые порты, которые он выбирает, и принимать / отклонять / отвечать на любые протоколы на любых настроенных портах.

Например, веб-службы HTTP обычно предоставляются через порт 80. Это означает, что как только клиент знает IP-адрес машины, он может предположить, что отправка сообщения на порт 80 приведет к тому, что это сообщение будет прочитано / получено веб-службой этой машины. Но так быть не должно. Если сервер настроен на прослушивание входящих веб-запросов на порт 9000, любой клиент, имеющий доступ к порту 9000, сможет получить доступ к своей веб-службе. Если сервер находится за прокси / NAT / маршрутизатором, который перенаправляет порт 10000 на порт 9000, а клиент отправляет веб-запрос на порт 10000, сервер получит его на порт 9000 и также ответит.

Перенаправление / отображение на веб-сервере

Вы спросили в комментарии о маппинге перенаправления или переписывании. Это функции, которые может выполнять веб-сервер. По сути, вы можете настроить веб-сервер (или большинство / множество веб-серверов), чтобы управлять тем, как он обрабатывает URL-адрес, полученный в запросе. Таким образом, он может внутренне изменять URL-адрес при получении, чтобы разные URL-адреса обрабатывались одинаково, или исправлять общие опечатки (сопоставление), или он может фактически ответить, чтобы сам клиент попросил второй раз, используя другой, заменяющий, URL-адрес. (перенаправление).

У них есть свое применение и, в принципе, они могут справиться с вашим вариантом использования, но они не кажутся вам «правильным» решением по следующим причинам:

1. Я не думаю, что картографирование вообще поможет. Отображение почти полностью внутренне для веб-сервера, оно говорит "лечить этот URL как будто это который URL ". Например, вы можете использовать сопоставление URL-адресов веб-сервера, чтобы пользователь мог запрашивать форум, используя очень старые, старые и текущие URL-адреса (для удобства пользователя), используя"https://example.com/index.php?area-=forum&topic=2", также "https://example.com/forum.php?topic=2" а также "https://forum.example.com?topic=2", и обработайте это только один раз, сопоставив первые два из них с третьим URL-адресом внутри, в качестве первого шага в обработке запроса. Поскольку эта цель влияет на путь запроса, а не на IP-адрес / порт, сопоставление не очень полезно для управление портами, и в вашем случае клиент вообще никогда не запрашивает 8080.
2. Перенаправление будет работать, но может быть не тем, что вам нужно. Перенаправление на веб-сервере зависит от фактического получения запроса веб-сервером (поскольку это внутренние функции веб-сервера). Таким образом, веб-сервер в любом случае должен будет прослушивать порт 80, чтобы получить исходный запрос, чтобы ответить перенаправлением / картой. Было бы также должны прослушивать порт 8080. Функционально, потребуется правило перенаправления, чтобы сообщать любому клиенту, запрашивающему порт 80, чтобы он снова запрашивал его, используя URL-адрес ": 8080", что не похоже на то, что вы хотите сделать. Пользователь также увидит новый URL с «: 8080» в нем, хотя похоже, что вы хотите, чтобы он был «прозрачным» и не отображался.
3. Также перенаправление будет работать только для перенаправления стандартного порта (80 или 443). - вы не можете перенаправить порт 2000 на 8080, скажем, потому что клиент не будет запрашивать 2000 по умолчанию, в первую очередь, поэтому он никогда не попадет на веб-сервер, даже если он будет прослушивать 2000. Это Хотя, возможно, это не проблема для вас.

Однако, если вам нужно «интеллектуальное» перенаправление, при котором только определенные запросы перенаправляются на 8080, это может быть подходящим вариантом, потому что перенаправление может включать логику, определяющую, какие URL-адреса следует перенаправлять, тогда как отображение портов (ниже) будет отображать все.

Как правильно это сделать

Ответ на ваш вопрос: вы хотите, чтобы веб-сервер отвечал на веб-запросы, которые клиент отправляет на порт по умолчанию (80/443), но которые сервер фактически получает на порт 8080.

Это означает, что, как видите, вам нужно что-то среднее между отображает порты между клиентом и сервером. Таким образом, клиент отправляет через порт 80 (порт по умолчанию, используемый веб-браузерами), но на самом деле он получает его через порт 8080 веб-сервером. Конечно, вам придется настроить веб-сервер для прослушивания порта 8080, поскольку это не стандартно, но это просто, и любой веб-сервер должен иметь возможность указывать свои прослушивающие порты.

Самый обычный способ сделать это - внутри маршрутизатора / брандмауэра через сопоставление портов.

Проще говоря, для этого маршрутизатору дается правило, согласно которому все полученное, имеющее IP-адрес назначения и порт назначения = 80, должно передаваться в локальную сеть с изменением порта назначения на 8080. Ни веб-сервер, ни клиент не будут знать об изменении (оно на 100% обрабатывается маршрутизатором), поэтому оно будет на 100% прозрачным для них обоих. У клиента не будет ": 8080" в URL-адресе, и ему не нужно будет ничего перенаправлять, поскольку он запрашивает порт 80, а веб-сервер может игнорировать порт 80 и прослушивать только 8080, поскольку он никогда не получает запросы на порт 80. .

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

Вы не можете.

Я имею ввиду, технически это можно сделать. DNS известен тем, что может предоставить доменное имя и получить IP-адрес. Тем не менее, я немного изучил протокол DNS, и действительно DNS технически способен действовать как механизм запроса / ответа для гораздо большего, чем просто доменные имена и IP-адреса. Одним из возможных подходов было бы использование записи ресурса DNS, которая не является типичным типом A или AAAA, такой как запись TXT (которая технически является просто текстом и может использоваться для чего угодно) или, возможно, запись SRV или любая другая выберите более новый тип записи ресурса.

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

Однако, если вы не создаете свой собственный сетевой протокол (например, если вы хотите использовать HTTP), вы, вероятно, столкнетесь с серьезной проблемой, которая заключается в том, что существующее программное обеспечение не будет использовать ваше индивидуальное решение, если вы не используете решения, которые уже установлены. Это будет препятствием. Не техническая невозможность. Социальный барьер: Сможете ли вы убедить всех действовать по-своему?

Теперь, когда я объяснил, почему вы не можете этого сделать, у меня может быть решение для того, что вам нужно. Во-первых, давайте посмотрим, почему у нас вообще есть IP-адреса и порты.

IP-адреса и порты делают разные вещи. Назначение IP-адреса - выполнение целей уровней 2 и 3 модели OSI сетевого взаимодействия. Назначение IP-адреса - определить, на какой компьютер должен идти трафик. Тот факт, что мы можем использовать номер порта для этой цели, если брандмауэры / маршрутизаторы исследуют номера портов для выполнения NAPT (преобразование сетевых адресов на основе портов, также иногда называемое PNAT или просто NAT), является более новым методом, который использует ресурс (информация), но не был частью оригинального дизайна. Если мы на минуту отойдем от этого «злоупотребления» номерами портов и рассмотрим исходный дизайн, возможно, мы сможем найти более простое решение. По замыслу Интернета машины должны быть найдены по IP-адресам.

Смысл «номера порта», используемого TCP и UDP и некоторыми альтернативами, заключается в том, чтобы иметь возможность отслеживать отдельные разговоры. Это помогает наладить связь с запущенными программами. Таким образом, если машина получает трафик через TCP-порт 80, машина будет знать, что сетевой трафик предназначен для использования программой, которая является веб-сервером. Если веб-браузер загружает несколько графиков одновременно, комбинации номеров «порта источника» и номеров «порта назначения» могут отслеживать, какие данные предназначены для какой графики, так что эти одновременные разговоры могут происходить без смешивания данных.

Теперь я предполагаю, что у вас есть доступ к DNS-серверу, и вам кажется, что вы думаете, что администрирование DNS было бы удобнее, если бы иметь возможность немного больше обрабатывать маршрутизацию трафика. Но похоже, что DNS не может помочь вам получить номер порта. Что ты можешь сделать?

Рассмотрим IPv6. IPv6 позволяет вам иметь больше IP-адресов. Кроме того, в отличие от некоторых реализаций IPv4, устройства, использующие IPv6, обычно могут легко поддерживать несколько активных адресов IPv6 одновременно. Итак, если вы хотите иметь три разных сетевых протокола на одном компьютере, вы можете назначить как минимум три разных IPv6-адреса одному и тому же компьютеру. А затем вы можете выполнять любые махинации с маршрутизацией с этими IPv6-адресами.

Затем вы можете использовать тип записи ресурса AAAA, чтобы назначить имя этому IPv6-адресу, который ваша сеть может рассматривать как эффективно выделенное для конкретной службы на конкретном компьютере, который вы хотите.

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

Возможное возражение:
И если вы чувствуете, что застряли с IPv4 и думаете, что IPv6 почему-то не поддерживается, я бы посоветовал вам попытаться решить эту проблему. Эту проблему, вероятно, будет легче исправить (возможно, используя своего рода туннелирование), и, вероятно, она станет более полезным исправлением, как только вы его внедрите.