Pourquoi les navigateurs n'utilisent-ils pas les enregistrements SRV? [fermé]

Cela semble être une quantité de travail minimale et cela rendra la mise en œuvre côté serveur de sites Web fiables beaucoup plus simple. Les enregistrements SRV existent également depuis des années ...

Y a-t-il quelque chose qui me manque ici?

Edit: @DJ Pon3 - ce dont je parle, c'est:

un site servi à partir de deux centres de données sans avoir besoin de BGP, mais fonctionnant toujours si l'un des centres de données se déconnecte. (Peut également être atteint par de courts TTL DNS.)
plusieurs serveurs httpS sur différents ports sur une seule adresse IP.

domain-name-system srv-record fadedbee
la source

Je ne sais pas exactement quel problème, précisément, vous pensez que cela résoudrait. Jusqu'à présent, il a été parfaitement possible de créer des services Web fiables sans enregistrements srv.

Rob Moir

Je pense (et peut-être seulement parce que je suis un simplet) que cela résoudrait le problème de l'exécution d'un site Web sur un autre port sans que l'utilisateur n'ait besoin de savoir sur quel port le site s'exécute et d'avoir à taper le numéro de port dans le URL.

joeqwerty

Honteux n'est-ce pas ?

JdeBP

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

Alnitak

@chrisdew pourquoi avez-vous posé exactement la même question sur les deux sites?

Alnitak

Réponses:

Pourquoi les navigateurs n'utilisent-ils pas les enregistrements SRV?

Parce que les enregistrements SRV n'existaient pas lorsque http a été une fois activé et parce que http n'est pas supposé être un service.

Les enregistrements SRV existent depuis des années ...

Hahaha. Vous souvenez-vous du moment où HTTP a commencé? Lorsque les premiers navigateurs ont été écrits? C'était il y a très longtemps.

SRV est le premier dans RFC 2782. HTTP passe à RFC 1945 pour 1.0. Devinez qui était le premier.

TomTom
la source

HTTP 1.1 était 2616, il l'a donc également manqué. HTTP 1.2 avec prise en charge SRV est-il nécessaire?

fadedbee

Non, car quess quoi - ce n'est pas nécessaire;)

TomTom

-1 pour l'argument plutôt stupide selon lequel les âges relatifs limitent l'interopérabilité. Le monde a vraiment fait avoir la capacité de faire deux inventions distinctes travaillent ensemble une fois qu'ils existent, et a fait juste que de nombreuses fois à travers l' histoire. Il l'a même fait deux fois pour SRVles enregistrements de ressources et HTTP.

JdeBP

@JdeBP vous savez bien que si cela avait été aussi simple, cela aurait été fait maintenant. Le problème est la transition des sites vers un mécanisme HTTP + SRV sans fournir une expérience inférieure aux innombrables millions d'utilisateurs qui seraient bloqués sur les anciens navigateurs.

Alnitak

Vous voulez dire quelques fois que quelqu'un a écrit un brouillon sur Internet? Ce n'est pas la même chose - il est trivial d'en écrire un, puis le monde réel vous frappe et vous constatez qu'il y a en fait beaucoup de cas marginaux et d'autres problèmes qui signifient que cela ne fonctionnera pas dans le monde réel, et finalement le projet expire et est surtout oublié. Bon sang, je l'ai déjà fait à plusieurs d'entre eux.

Alnitak

SRV les enregistrements offrent trois choses:

Plusieurs noms d'hôtes - peut être fait sans
Ports alternatifs - mauvaise idée - voir ci-dessous
Un correctif pour le problème CNAME at apex de zone

Re: ports alternatifs - Les enregistrements SRV peuvent être utilisés comme un moyen d'exécuter des serveurs Web sur des ports alternatifs sans avoir à annoncer ce fait dans l'URL. C'est une mauvaise chose . Les politiques de pare-feu d'entreprise interdisent très souvent l'accès aux ports "inhabituels", et encourager l'idée d'utiliser des ports alternatifs serait médiocre pour l'accessibilité du site.

Le seul avantage tangible que je vois est pour # 3 - il permettrait example.comd'être redirigé vers webhost.example.netsans nécessiter un CNAME(ce qui n'est pas autorisé dans un sommet de zone) ou un Aenregistrement (ce qui est mauvais pour la maintenance de la zone).

Alnitak
la source

-1 pour avoir raté tout ce point, malgré le fait que de nombreuses personnes l'ont fait au fil des ans comme elles le demandent et le questionneur y a même fait allusion, ce qui est bien sûr les informations explicites sur l'équilibrage de la charge et le repli pour les clients.

JdeBP

L'équilibrage de charge et les données de secours de @JdeBP IMNSHO n'appartiennent pas au DNS - c'est bien dans les domaines de "Stupid DNS Tricks (TM)". Ils appartiennent tous deux à la couche de routage IP - c'est le seul endroit où vous pouvez fournir un basculement transparent entre les services.

Alnitak

En fait, les ports alternatifs sont une bonne idée car les protocoles ne doivent pas être liés aux ports. Imaginez un monde où le bureau de poste devait toujours être au deuxième étage de l'immeuble, cela ne serait-il pas inutile? C'est pour cela que nous avons des carnets d'adresses (DNS)! Ce qui est vraiment une mauvaise idée, c'est de définir des règles de pare-feu sortantes basées sur un port. C'est tout simplement inutile car les attaquants pourraient toujours utiliser les ports non bloqués. De plus, imaginez un monde où il serait interdit d'aller au deuxième étage de chaque bâtiment, simplement parce qu'il pourrait s'agir d'un bureau de poste. C'est drôle, non? ;)

FlashFan

@FlashFan malheureusement, les entreprises persistent à vouloir bloquer la sortie d' Internet en supposant que tous les sites Web sont sur le port 80 ou 443.

Alnitak

Oui je sais. C'est pourquoi l'activation des enregistrements SRV serait une bonne chose, car elle obligerait les entreprises à cesser de faire ces mauvaises pratiques inutiles. Peu importe le nombre de ports sortants que vous bloquez, tant qu'il y a un port ouvert, vous pouvez faire tout ce que vous voulez, car vous pouvez tout faire à travers chaque port. Le fait que vous ne puissiez même pas savoir si ce qui passe par la connexion TLS sur le port 443 est vraiment HTTP, ne fait que le souligner.

FlashFan