Почему браузеры не используют записи SRV? [закрыто]

Это похоже на минимальный объем работы, и это значительно упростит реализацию надежных веб-сайтов на стороне сервера. Кроме того, записи SRV были на протяжении многих лет ...

Есть что-то, чего я здесь не хватает?

Редактировать: @DJ Pon3 - то, о чем я говорю, это:

один сайт обслуживается из двух центров обработки данных без необходимости в BGP, но все еще работает, если любой центр обработки данных отключен. (Также может быть достигнуто короткими DNS TTL.)
несколько серверов httpS на разных портах на одном IP-адресе.

domain-name-system srv-record fadedbee
источник

Мне не ясно, с какой именно проблемой, ты думаешь, это решит. До сих пор было вполне возможно создавать надежные веб-сервисы без srv-записей.

Роб Мойр

Я думаю (и, может быть, только потому, что я простак), что это решило бы проблему запуска веб-сайта на альтернативном порте без необходимости знать пользователю, на каком порту работает сайт, и вводить номер порта в поле. URL.

Joeqwerty

Стыдно не так ли ?

JdeBP

точная копия stackoverflow.com/questions/9063378/…

Alnitak

@ chrisdew, почему вы задали один и тот же вопрос на обоих сайтах?

Alnitak

Ответы:

Почему браузеры не используют записи SRV?

Поскольку записи SRV не существовали, когда http был когда-то создан, и потому что http не считается службой.

Записи SRV существуют уже много лет ...

Хахаха. Вы помните время, когда начал работать HTTP? Когда были написаны первые браузеры? Это было давным-давно.

SRV являются первыми в RFC 2782. HTTP идет к RFC 1945 за 1.0. Угадай, кто был первым

TomTom
источник

HTTP 1.1 был 2616, поэтому тоже пропустил. Нужна ли нам HTTP 1.2 с поддержкой SRV?

Увядшая пчела

Нет, потому что задавать вопросы - это не нужно;)

TomTom

-1 за довольно глупый аргумент, что относительный возраст ограничивает совместимость. Мир действительно делает имеет возможность сделать два отдельных изобретения работают вместе , когда они существуют, и сделал только что много раз на протяжении всей истории. Он даже сделал это дважды для SRVзаписей ресурсов и HTTP.

JdeBP

@JdeBP ты хорошо знаешь, что если бы это было так просто, это было бы сделано к настоящему времени. Проблема заключается в том, что сайты переходят на механизм HTTP + SRV, не предоставляя бесчисленные миллионы пользователей, которые будут зависать в старых браузерах.

Alnitak

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

Альнитак

SRV записи предлагают три вещи:

Несколько имен хостов - можно обойтись без
Альтернативные порты - плохая идея - см. Ниже
Исправление для проблемы CNAME в зоне апекса

Re: альтернативные порты - записи SRV могут использоваться как способ запуска веб-серверов на альтернативных портах без необходимости рекламировать этот факт в URL. Это плохо . Корпоративные политики брандмауэра очень часто запрещают доступ к «необычным» портам, и поощрение идеи использования альтернативных портов будет плохим для доступности сайта.

Единственное ощутимое преимущество, которое я вижу, касается # 3 - оно позволит example.comперенаправить на него, webhost.example.netне требуя CNAME(что не разрешено в вершине зоны) или Aзаписи (что плохо для обслуживания зоны).

Альнитак
источник

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

JdeBP

@JdeBP IMNSHO Данные балансировки нагрузки и резервные данные не принадлежат DNS - это хорошо относится к сферам «глупых хитростей DNS (TM)». Они оба относятся к уровню IP-маршрутизации - это единственное место, где вы можете обеспечить плавное переключение между службами.

Альнитак

На самом деле, альтернативные порты - хорошая идея, потому что протоколы не должны быть привязаны к портам. Представьте себе мир, в котором почтовое отделение всегда должно было находиться на втором этаже здания, разве это не бессмысленно? Для этого у нас есть адресные книги (DNS)! Что действительно плохо, так это определение исходящих правил брандмауэра на основе порта. Это просто бессмысленно, потому что злоумышленники всегда могут использовать неблокированные порты. Кроме того, представьте себе мир, в котором было бы отказано проходить на второй этаж в каждом здании, просто потому, что это может быть почтовое отделение. Забавно, не правда ли? ;)

FlashFan

@FlashFan, к сожалению, корпорации по-прежнему хотят блокировать выход в Интернет , предполагая, что все веб-сайты находятся на порте 80 или 443.

Alnitak

Да, я знаю. Вот почему было бы полезно включить записи SRV, потому что это заставит корпорации прекратить совершать эти бессмысленные, дурные практики. Независимо от того, сколько исходящих портов вы блокируете, пока открыт один порт, вы можете делать все, что захотите, потому что вы можете делать все, что угодно для каждого порта. Тот факт, что вы даже не можете знать, действительно ли то, что проходит через соединение TLS через порт 443, является HTTP, лишь подчеркивает это.

FlashFan