Por que os navegadores não usam registros SRV? [fechadas]

Parece uma quantidade mínima de trabalho e tornará a implementação do servidor de sites confiáveis muito mais simples. Também os registros SRV existem há anos ...

Há algo que estou perdendo aqui?

Edit: @ DJ Pon3 - o que eu estou falando é:

um site veiculado em dois datacenters sem a necessidade de BGP, mas ainda funcionando se o datacenter ficar offline. (Também pode ser alcançado por TTLs DNS curtos.)
vários servidores httpS em portas diferentes em um endereço IP.

domain-name-system srv-record

— fadedbee
fonte

Não sei ao certo qual problema, exatamente, você acha que isso resolveria. Foi perfeitamente possível criar serviços web confiáveis sem registros srv até o momento.

— precisa saber é o seguinte

Eu acho (e talvez apenas porque sou simplório) que resolveria o problema de executar um site em uma porta alternativa sem que o usuário precisasse saber em que porta o site está sendo executado e digite o número da porta no URL.

— joeqwerty

Vergonhoso, não é ?

— JdeBP

duplicata exata de stackoverflow.com/questions/9063378/…

— Alnitak

@chrisdew Por que você fez exatamente a mesma pergunta nos dois sites?

— Alnitak

Respostas:

Por que os navegadores não usam registros SRV?

Como os registros SRV não existiam quando o HTTP foi fornecido uma vez e porque o HTTP não é considerado um serviço.

Os registros SRV existem há anos ...

Hahaha Você se lembra da hora em que o HTTP começou? Quando os primeiros navegadores foram escritos? Isso foi há muito tempo atrás.

SRV são os primeiros na RFC 2782. HTTP vai para RFC 1945 para 1.0. Adivinhe qual foi o primeiro.

— TomTom
fonte

O HTTP 1.1 era 2616, também perdeu. O HTTP 1.2 com suporte a SRV é necessário?

— Fadedbee

Não, porque não é necessário;)

— TomTom

-1 para o argumento bastante tolo de que idades relativas restringem a interoperabilidade. O mundo realmente faz têm a capacidade de fazer duas invenções separadas trabalhar em conjunto, uma vez que existem, e fez exatamente isso muitas vezes ao longo da história. Até o fez duas vezes para SRVregistros de recursos e HTTP.

— JdeBP

@JdeBP você bem sabe que, se fosse assim tão fácil, já teria sido feito até agora. O problema é fazer a transição de sites para um mecanismo HTTP + SRV sem fornecer uma experiência inferior aos inúmeros milhões de usuários que ficariam presos em navegadores antigos.

— Alnitak

Quer dizer que algumas vezes alguém escreveu um rascunho na Internet? Isso é quase o mesmo - é trivial escrever um e, em seguida, o mundo real atinge você e você descobre que, na verdade, existem muitos casos extremos e outros problemas, o que significa que não funcionará no mundo real e, eventualmente, o rascunho expira e é praticamente esquecido. Inferno, isso já aconteceu com muitos dos meus.

— Alnitak

SRV registros oferecem três coisas:

Vários nomes de host - podem ser feitos sem
Portas alternativas - má ideia - veja abaixo
Uma correção para o problema CNAME no apex da zona

Re: portas alternativas - os registros SRV podem ser usados como uma maneira de executar servidores da Web em portas alternativas sem ter que anunciar esse fato na URL. Isso é uma coisa ruim . As políticas de firewall corporativo geralmente proíbem o acesso a portas "incomuns", e incentivar a idéia de usar portas alternativas seria ruim para a acessibilidade do site.

O único benefício tangível que vejo é para o nº 3 - permitiria example.comser redirecionado webhost.example.netsem exigir um CNAME(que não é permitido em um ápice da zona) ou um Aregistro (que é ruim para a manutenção da zona).

— Alnitak
fonte

-1 por perder o ponto inteiro, apesar de muitas pessoas fazerem isso ao longo dos anos, pois pedem isso e o questionador até faz alusão a ele, que é, obviamente, as informações explícitas de balanceamento de carga e fallback para os clientes.

— JdeBP

Os dados de balanceamento de carga e fallback do @JdeBP IMNSHO não pertencem ao DNS - isso faz parte do domínio "Stupid DNS Tricks (TM)". Ambos pertencem à camada de roteamento IP - esse é o único lugar em que você pode fornecer failover contínuo entre os serviços.

— Alnitak

Na verdade, portas alternativas é uma boa idéia, porque os protocolos não devem ser vinculados às portas. Imagine um mundo em que os correios sempre tenham que estar no segundo andar do prédio, isso não faria sentido? É para isso que temos os catálogos de endereços (DNS)! O que é realmente uma má ideia é definir regras de firewall de saída com base em uma porta. Não faz sentido, porque os invasores sempre podem usar as portas não bloqueadas. Além disso, imagine um mundo onde seria negado o acesso ao segundo andar de cada prédio, apenas porque poderia ser uma agência postal. Engraçado, não é? ;)

— FlashFan 27/10

@FlashFan infelizmente, empresas persistem em querer bloco internet saída assumindo que todos os sites são na porta 80 ou 443.

— Alnitak

Sim eu conheço. É por isso que ativar os registros SRV seria bom, porque força as empresas a parar de praticar essas práticas inúteis e ruins. Não importa quantas portas de saída você bloqueie, desde que haja uma porta aberta, você poderá fazer tudo o que quiser, porque poderá fazer tudo em todas as portas. O fato de você nem saber se o que passa pela conexão TLS na porta 443 é realmente HTTP, apenas sublinha isso.

— FlashFan 28/10