Возможны ли поддомены для IP адресов, например, www.127.0.0.1 или 8.8.8.8.8 в IPv4 только хотя-бы для HTTP-запросов?

Обновил вопрос. С ICANN по этому поводу можно договориться.

Хотя зачем тут вообще ICANN? Ведь браузер может обрабатывать введённый домен как угодно. Тем более если такой домен изначально невозможен, то ICANN на него претендовать не должно.
Просто отправлять с 8.8.8.8.8 на 8.8.8.8, а в HOST прописывать весь адрес

Вадим Егоров: На уровне IP-пакетов нет вообще никаких доменов. Есть только четыре байта для адреса получателя и четыре для адреса отправителя. Каким образом отправитель узнал этот адрес - по имени домена через DNS, знал заранее или просто задал наугад - абсолютно безразлично.

Rsa97: На мой взгляд вы пока заслужили лайк =) До решения далеко

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

Rsa97: А если у меня например серый IP адрес? Весь вопрос только вокруг этого и крутится - недостача IPv4 адресов.

Вадим Егоров: Для этого есть NAT и port-mapping. Достаточно получить один внешний белый IP.

Rsa97:

Для HTTP-сервера вам и так никто не мешает зарегистрировать любое количество доменов, направить их на свой IP и уже на своём сервере определять, что за домен прописан в HTTP-запросе.

Вот и я об этом. Почему бы провайдеру не поставить сервер, маршрутизирующий запросы на своих клиентов за NAT'ом в зависимости от субдомена?

Rsa97: О том, возможно ли это уже речи не идёт. Теперь - почему это не делают.

Вадим Егоров: Зачем это провайдеру? И что делать с остальными протоколами? Оборудование провайдера маршрутизирует IP-пакеты, в них просто нет места для чего-либо, кроме четырёх байт адреса.
Поверх IP идёт следующий уровень - ICMP, TCP, UDP, GRE и т.д. Уже поверх TCP организуются HTTP, SMTP, FTP и огромное количество других протоколов.

Вадим Егоров: Да, ещё, провайдер не видит, что находится за NAT, и вообще, NAT это или одиночный компьютер.

Rsa97: Да, кстати, порты тоже ведь можно резервировать - этот ваш port-mapping, если я правильно понял. Но для каждого клиента всего один порт и если к серверу не будет обращаться обычный клиент со своим браузером, вполне неплохое решение. Но один случайный порт на клиента - маловато, если больше надо - используй проксирование трафика. Если нужен лёгкий доступ для клиента - опять-же проксирование. Проксирование HTTP(S) вполне можно реализовать бесплатно с помощью пхпшного шареда. Клиент -> Шаред -> Порт провайдера -> Ты. Но что с другими протоколами?

Rsa97: Я про провайдера предоставляющего интернет - провайдер то имеет доступ к своему NAT и может поставить сервер с одним IP, проксирующий или маршртизирующий трафик к нужному клиенту по нужному запросу. Это конечно не полноценное решение, но хоть что-то.

Rsa97: Это реализовать ведь - пару минут. Похоже провайдеры не заинтересованы в таких решениях, так же как и во внедрении IPv6 - оно и ясно, хотят навариться на сдаче в аренду IP. Даже кажется новость о заканчивающихся IP надумана ради удорожания их.

Вадим Егоров: Да не может такого провайдер сделать. По какому признаку он должен определять, что это HTTP пакет? По портам? Так у меня на 80 порту может что угодно сидеть. По содержимому пакета? Так ему маршрутизаторы придётся на пару порядков производительнее покупать, а за чей счёт? А если это HTTPs, то в нём в открытом виде вообще ничего нет, домен не узнать, только IP получателя. А расшифровать HTTPs может только получатель.
Если вы про хостинг-провайдеров, то у них, как правило, проблем нет. На один IP можно повесить любое количество сайтов, различая их уже на уровне сервера. Для этого смешивать IP-адрес с доменами не нужно.

Rsa97: Вы что-то тупите. На 80м порту маршрутизатора провайдера обычно стоит HTTP сервер отдающий пустую страницу. Я про тот IP адрес, который вам покажет i2p.ru, но по которому вы перейдёте и он не даст доступ к вашему серверу. То есть самый обычный NAT, ну как такое можно не понять. Я даже не знаю как объяснить.
Почему бы вместо этой пустой страницы не отправлять пользователся к соответствующему серверу за натом в зависимости от HOST в HTTP-запросе?

Вадим Егоров: ip.ru мне показывает мой внешний белый адрес, выданный провайдером. Соответственно, если я на своём маршрутизаторе настрою переадресацию 80 порта на свой HTTP-сервер, настроенный соответствующим образом, то смогу обращаться к своему сайту хоть по имени, хоть по IP.

Вадим Егоров: Вот есть провайдер 1. адрес маршрутизатора 1.1.1.1. Серая подсеть 192.168.1.0/24
Есть второй провайдер. адрес маршрутизатора 2.2.2.2. Серая подсеть 192.168.1.0/24.

Теперь вопрос. Куда пойдёт трафик через ваш выдуманный домен www.192.168.1.1 ?

Rsa97: Это конечно хорошо, что у вас белый, но я про остальных.

Rsa97: "белый адрес" - не у всех так. Писали же про серые адреса.

fshp: в примере www.192.168.1.1 должен направлять как раз на локальный 192.168.1.1 в твоей подсети, а в заголовке HOST будет "www.192.168.1.1".
Смысл этой задачи как раз не в этом. Смысл в том, что бы:
24.1.1.1.1 прямо направлял той серой подсети 192.168.1.0/24 маршрутизатора 1.1.1.1 при запросе с любого другого маршрутизатора, в том числе и с 2.2.2.2

fshp: но было бы намного легче реализовать это, привязав к адресу 1.1.1.1 настоящий домен. Если маршрутизатор может анализировать трафик и узнавать субдомен, благодаря которому пришёл трафик, можно направлять 24.moylubimiyprovider.ru на 192.168.1.1/24 этого провайдера из любой точки мира.

Вадим Егоров: А если за этим маршрутизатором ещё подсеть будет 10.10.10.0/24 например? 24.1.1.1.1 куда указывать должен?

fshp: тогда на каждом должно быть ПО, маршрутизирующее по домену и тогда будет 24.10.10.10.10.24.192.168.0.1.1.1.1.1 направлять куда надо, но это ужасно. Это ведь один провайдер, внутри которого вложены подсети, он там свои внутренние подсети пусть сам в базу добавляет и каждому клиенту свой номер даёт, а уже по номеру будет глобальный доступ. То есть у меня ID 18327 - пусть во внутреннем DNS будет

18327.1.1.1.1 = 24.10.10.10.10.24.192.168.0.1.1.1.1.1

Вадим Егоров: вообщем то, что вы предлагаете возможно реализовать. Но придется менять все оборудование на планете. Тут на ipv6 не могут перейти уже 20 лет. А он универсальный, в отличии от вашего предложения.

fshp: Так я предлагаю своё решение потому что для него как-раз менять ничего не нужно. В любом маршрутизаторе стоит полноценная ОСь или есть возможность поставить и в ней что угодно делайте, хоть HTTP заголовки проверяйте, хоть что ещё.

Вадим Егоров: Это вам так кажется. Попробуйте, например, написать свою ось для маршрутизаторов Cisco. А заодно новый стек протоколов для Windows, маршрутизаторы и на нём бывают.

Вадим Егоров:
>стоит полноценная ОСь или есть возможность поставить и в ней что угодно делайте, хоть HTTP заголовки проверяйте, хоть что ещё.
категорически нет. Мало того, что подавляющая часть трафика на производительных специализированных маршрутизаторах выполняется специализированными ПЛИСами с микроядром, о которых информацию имеет только производитель, так еще и значительная часть трафика вообще маршрутизируется на L3-коммутаторах аппаратно, где что-то добавить/поправить представляет из себя проблему даже для разработчиков устройства.

Mystray: У провайдера есть как-минимум один маршрутизатор, имеющий белый IP. Так же у провайдера уже внедрена возможность прикреплять белый IP любому клиенту за провайдерским NAT'ом, то есть доступ к любому клиенту реализовать можно. Тогда можно маршрутизировать весь входящий трафик с белого маршрутизатора на отдельный сервер, сервер будет направлять HTTP-соединения своим клиентам таким-же образом как направляет по белым их адресам (вероятно, придётся прикрепить к каждому абоненту внутренний адрес, доступный любому другому клиенту в пределах этого маршрутизатора, что обычно уже реализовано у нормальных провайдеров) в зависимости от HTTP-заголовка HOST, а клиенты уже купившие белые адреса будут получать свой трафик напрямую, без этого сервера. Чем плох вариант? К тому-же не обязательно делать что-то вроде 18290.1.1.1.1, так-как браузеры не поддерживают такие запросы, достаточно 18290.moiprovider.ru и всё будет ок. Кстати это можно реализовать вообще без участия провайдера.
Например я поставлю себе сервер с белым адресом в сети своего провайдера. На сервере настрою маршрутизацию запросов в зависимости от поддоменов. Прикреплю домен к серверу. Отлично - теперь 10.10.10.10.subnet.moidomain.net направляет куда надо. Вообще достаточно по одному такому клиенту на каждого провайдера для полноценного внедрения.
Пойду реализовывать. Вполне неплохо ведь?

>> Вы что-то тупите. На 80м порту маршрутизатора провайдера
>> обычно стоит HTTP сервер отдающий пустую страницу.

Вадим Егоров, единственный кто здесь тупит это ты. Вот тебе маршрутизатор: E-320. Подскажи-ка, где у него "стоит HTTP сервер отдающий пустую страницу"? :-)

Интернет совсем не такой каким ты себе его представляешь...

Александр Карабанов: Какой суровый аппарат. Конечно там нету сервера. Но можно сделать - можно направлять весь входящий трафик с этого маршрутизатора на HTTP-сервер внутри сети. Вы мой комментарий выше прочитали?

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

Александр Карабанов: кстати с FTP, VNC и наверное с другими протоколами можно сделать то-же самое - поставить прокси, перенаправляющую трафик в зависимости от поля user при авторизации. То есть u10.20.10.20-root направит на 10.20.10.20 и пользователь root.

Rsa97: Не думаю, если есть услуга "белый IP". Странный пункт. С чего он может быть?

Вадим Егоров: Посчитайте-ка, сколько стоит сервер, который сможет в принципе отмаршрутизировать хотя бы 20 гбит трафика. И увеличьте мощность (как минимум ЦПУ) раза в два, так как перехват соединений, отслеживание их состояний и прочее сопутствующее-- намного более тяжелые операции.
А теперь умножьте цену минимум на два, так как нужен резерв. А теперь добавьте стоимость соответствующих портов на коммутаторах, стоимость выворачивания трафика черезодноместо к этим серверам и т.д. Зачем? Тем более, что это неизбежно приведет к лишним милисекундам задержек, лишней точке возникновения проблем, лишнему куску железа, который нужно обслуживать.
Да и НАТ далеко не у всех есть.

P.S. практически всегда у провайдеров на белые адреса типа 185.64.X.Y смотрит DNS адрес вида y.x.provider.net или host-185-64-X-Y.provider.net (или как у админа фантазии хватит), при чем резольвится в обе стороны. Связано это с наличием у адресов PTR-записей. И не надо никаких L7-routing и прочих извратов.
P.P.S. А вообще любой клиент может взять себе халявный домен с халявным днс-сервером (или планые) и не гемороиться непонятными идеями.

Вадим Егоров: Да так, попадались такие провайдеры.

>> можно направлять весь входящий трафик
>> с этого маршрутизатора на HTTP-сервер внутри сети

Вадим Егоров, но зачем?

Александр Карабанов: Чтобы не покупать IP

И весь сыр бор и этот нелепый срач только из-за того, что ты хочешь HTTP сервер на своём домашнем компе поднять и не платить ни за хостинг ни за IP 200 р. в месяц?

Александр Карабанов: Ага, и ещё поделиться решением чтобы все так могли.

Абсурд. К тому же решение и так уже есть - это IPv6.

Александр Карабанов: Да вы что? Вы бы перечитали все комментарии к ответам. Я уже описал решение, большинство согласилось. Уже всё решено, осталось с вами поболтать :)

Вадим Егоров: Хорошенькое решение. "Я не хочу платить 200 рэ, поэтому пусть провайдер поставит сервер за пару миллионов". Так провайдер потом эту сумму всё равно с пользующихся услугой "HTTP-роутинг" взыщет.

Rsa97: ну это не обязательно провайдер будет ставить сервер. Возможно поставлю я сам для других пользователей. А чего такие суммы? Моя малинка и то справится.

Вадим Егоров: Так вы же хотите, чтобы всё, что провайдеру приходит на 80 порт шло на один сервер. А это могут быть и десятки и сотни тысяч клиентов.

Всё ради малинки?



Да позвони ты уже в техподдержку скажи что прям "вапче" надо пусть они тебе порт пробросят и ты успокоишься уже :-)

PS
Что за провайдер хоть?

Александр Карабанов: Да у меня и так есть IP. Я людям помочь хочу, заодно стать чуть известнее. Для меня личео проблемы нет.
И малинка у меня просто валяется. Сервер чуть получше.

Rsa97: ну не каждый будет этим пользоваться. кстати, такое делают и большие ребята:
i.imgur.com/rMLT1ub.png - Хетцнер
i.imgur.com/0aNjAVc.png - вк

Вадим Егоров: Это просто автоматически сгенерированные доменные имена. Когда у вас несколько сотен или тысяч IP-адресов, то вручную задавать каждому доменное имя не очень удобно. Никаких дополнительных переадресаций там нет.

Делают что? Вписывают в DNS A запись?

Rsa97: если бы это были белые IP адреса к ним бы обращались напрямую. Или хотите сказать, это подобие xip.io?

Вадим Егоров: А к ним и обращаются напрямую. Кто мне мешает завести в своём DNS для своего адреса 127.0.0.1 A-запись it.is.my.address.127.0.0.1.mydomain.local?

Rsa97: а смысл?

Вадим Егоров: Посмотрите на адрес Хетцнера:
static - адрес из блока статически выделяемых адресов
233.82.9.5 - обратная запись самого адреса
clients - адрес из блока выделяемых клиентам
your-server.de - основной домен
Таким образом, при настройке оборудования уменьшается вероятность ошибки и увеличивается читабельность по сравнению с прямым указанием IP или записью server1.your-server.de

>> если бы это были белые IP адреса

Чем адрес 5.9.82.233 не белый? Вот, например bgp.he.net/net/5.9.0.0/16#_netinfo

Да вы с автором вопроса что-то одинаковое курите :-)

Александр Карабанов: почему одинаковое? Я помню, в домене MS так можно к другому компу обратиться(ну не так, похоже). Вообщем, такое возможно и невозможно, как я писал. Читайте с конца

Вадим Егоров: я вроде все по полочкам разложил: c www возможно(ибо это просто переброс на порт какой-то если не ошибаюсь), а так - нет.

Dark Hole: DNS нет никакой разницы, www у вас прописано, ftp, или вообще xyz. Она обеспечивает преобразование "имя <-&rt; IP".

Rsa97: так с www - история особая. Повторяю, мой роутер может сделать переброс поддомена www, могу скрины дать. Да и перед тем как ругать меня, удосужтесь прочитать все, что я написал. Я это писал.

Dark Hole: omnibox хрома не разрешит вам этого сделать. Он не считает www.192.168.0.1 адресом и предлагает поискать это выражение в гугле.

Вадим Егоров: а я про что? В теории, это возможно, в реальности не используется(как и нестандартные маски)

Dark Hole: Это просто хром странный - не позволяет вполне валидный адрес. Было бы неплохо, если бы 18923.83.38.56.12 направляло на клиента 18923 провайдера, владеющего маршрутизатором 83.38.56.12. А сейчас это можно реализовать только по HTTP и только если на 83.38.56.12 направить домен moylubimiyprovider.ru. Тогда на маршрутизаторе будет ПО, проверяющее HOST заголовок HTTP запроса и по нему направлять запросы на своих клиентов и тогда 18923.moylubimiyprovider.ru будет работать и не нужно покупать/арендовать IP если кроме HTTP не собираетесь ничего открывать.

Rsa97:

DNS нет никакой разницы, www у вас прописано, ftp, или вообще xyz. Она обеспечивает преобразование "имя <-&rt; IP".

Но браузер добавляет заголовок с этим www/ftp/xyz кте.

Дело в том, что DNS работает по другому принципу, главным образом на том, что любое имя должно быть глобально. А IP глубоко похрен, что в другой подсети есть аналогичный комп с таким же IP. Главное - в собственной подсети не было такого же. Вообщем, DNS мыслит глобально, а у IP хата с краю)

Да не совсем. Например 127.0.0.1.xip.io направлен на ваше устройство.

Вадим Егоров: Добавляет, если не нашёл сервера по прямо указанному адресу. Но ни в каких стандартах доменные имена www, ftp и иже с ними не прописаны, просто best practice.

Rsa97: Нет, вы похоже подумали, что я говорю о том что пишешь в браузер 123.com - в DNS такого нет - тогда он пытается ресолвить www.123.com.
Нет, я не об этом. Я о том что пишешь адрес www.123.com - он направляется на IP 81.18.81.18 например, а в HOST заголовке HTTP-запроса записано www.123.com.
Благодаря этому хостер, например, может направлять запросы на разные сервера внутри своей сети в зависимости от этого заголовка, при этом IP один.

Вадим Егоров: Я, вообще-то, писал о том, что доменное имя www, HTTP и порт 80 технически никак не связаны. Никто не мешает на сервере с именем www.example.com повесить на 80 порт, например, XMPP-сервер.

Rsa97: Ну никто это и не отрицал. А с чего вы решили что это как-то разъяснит ситуацию?

Вадим Егоров: маршутизартор, проверяющий заголовки? Проще белый адрес попросить

Вадим Егоров: я говорю именно про такие исключения вида 127.0.0.1.xip.io. А вообще, DNS сервер может все, что угодно возвращать - хоть 127.0.0.1, и это будет валидно. Но у провайдера может и не быть DNS сервера и так далее по списку. Поэтому, это не используют

Да, но узнать домен по которому пришёл запрос можно, анализируя трафик, если это HTTP. По заголовку HOST. Не обязательно весь трафик направлять куда надо, но хотя-бы HTTP(S).

это разные уровни оси

DeepDash: Ну и что, пусть маршрутизатор лезет в другой уровень и смотрит какой же там HOST. Чем не устраивает?

DeepDash: Я написал, что для других протоколов это не сработает - перенаправляться будет только HTTP.

DeepDash: Пример - хостинги. У них ведь тонны клиентов, но ведь не выделяют каждому свой IP. А домен выделяют каждому - третьего уровня или если направишь ns то и свой домен. Вот то-же самое хотелось бы увидеть у провайдера.

Вадим Егоров: зачем все это провайдеру?
Ломать OSI-стек, покупать дорогостоящее оборудование, умеющее в DPI, придумывать дикие схемы кривой маршрутизации по L7 ради полутора инвалидов, которым "хочется"? Это не станет массовым, никто не захочет видеть IP вместо нормальных DNS.
В принципе, в _некоторых странах_ провайдеров, по сути, обязали чем-то подобным заниматься (влезать в L7 протокол, парсить SNI из HTTPS и URL из GET/POST) но даже там есть заранее приготовленный четкий список хостов, в направлении которых надо это делать, а не вообще все подряд.

инет-провайдеру в страшном сне не приснится предоставлять услуги локального хостинга. С такой схемой как у вас, введение ip6 и то попроще будет.

Mystray: DeepDash: Что вы такое говорите. Да я сам могу такое реализовать без всяких провайдеров и влезания в стек. Достаточно одного сервера с белым IP внутри сети этого провайдера. На сервер цепляем домен. На сервер ставим HTTP-прокси и настраиваем перенаправление трафика в зависимости от HOST-заголовка. Теперь 10.20.10.20.subnet.moidomain.net направляет на клиента внутри сети провайдера с адресом 10.20.10.20.

DeepDash: Хостинг предоставлять не нужно. Я говорил про схему маршрутизации такую-же как у хостинга.

Вадим Егоров: изначально вы говорили про анализ HOST из HTTP и прочих извратов. Просто IP.DOMAIN.com и так может смотреть сразу на клиентский адрес, более того, на белых адресах скорее всего оно уже так и есть и работает для нормальной работы PTR и связанных почтовых серверов.

Mystray: Про белые адреса речи не идёт. Смысл в том, чтобы как-то жить с нехваткой адресов.
>Просто IP.DOMAIN.com и так может смотреть сразу на клиентский адрес
Надеюсь это не из рода xip.io? В таком случае отлично - это то о чём я говорил, если это помогает получить глобальный доступ к серым адресам. Но приведите примеры, а то непонятно. У нас плохо получается понимать друг друга.

Вадим Егоров: Вот сейчас я понял ,чего вы хотите. HTTP-доступности снаружи на серый адрес?
Это можно решить обычным reverse-proxy типа nginx, который имеет доступ в серую сеть провайдера, и кнопкой в личном кабинете, которая заводит virtual host смотрящий на серый клиентский адрес. Но это уже, практически, пол-хостинга. И на уровень стандарта вряд ли выйдет. Юрлица и так, как правило, требуют белый адрес, а физикам оно особо и не нужно, в крайнем случае опять же купят адрес.
Покупка белого адреса намного проще для всех. По крайней мере пока.
Возможно даже придем к продаже не белых адресов, а белых портов для нуждающихся по дешевке.

Mystray: У вас есть рекомендации как сделать это эффективнее? Ведь много запросов будут перегружать роутинговый сервер.