Perché i browser non usano i record SRV? [chiuso]

Sembra una quantità minima di lavoro e renderà molto più semplice l'implementazione sul lato server di siti Web affidabili. Anche i record SRV sono in circolazione da anni ...

C'è qualcosa che mi manca qui?

Modifica: @DJ Pon3 - di cosa sto parlando è:

un sito è servito da due datacenter senza la necessità di BGP, ma funziona ancora se uno dei datacenter non è in linea. (Può essere ottenuto anche con TTL DNS brevi.)
più server httpS su porte diverse su un unico indirizzo IP.

domain-name-system srv-record

— fadedbee
fonte

Non sono chiaro su quale problema, precisamente, pensi che questo possa risolvere. Finora è stato perfettamente possibile creare servizi Web affidabili senza record SRV.

— Rob Moir,

Penso (e forse solo perché sono un semplice) che risolverebbe il problema di eseguire un sito Web su una porta alternativa senza che l'utente debba sapere su quale porta è in esecuzione il sito e dover digitare il numero di porta nella URL.

— joeqwerty,

Peccato vero ?

— JdeBP

duplicato esatto di stackoverflow.com/questions/9063378/…

— Alnitak

@chrisdew perché hai posto la stessa identica domanda su entrambi i siti?

— Alnitak,

Risposte:

Perché i browser non usano i record SRV?

Perché i record SRV non esistevano quando un tempo veniva eseguito http e perché non si suppone che http fosse un servizio.

I record SRV sono in circolazione da anni ...

Hahaha. Ti ricordi l'ora in cui è iniziato HTTP? Quando sono stati scritti i primi browser? Questo è stato molto tempo fa.

Gli SRV sono i primi in RFC 2782. HTTP passa a RFC 1945 per 1.0. Indovina quale fu il primo.

— TomTom
fonte

HTTP 1.1 era 2616, quindi mancava anche questo. HTTP 1.2 con supporto SRV è necessario?

— fadedbee,

No, perché chiedete cosa - non è necessario;)

— TomTom

-1 per l'argomento piuttosto sciocco che le età relative limitano l'interoperabilità. Il mondo è davvero fa avere la capacità di fare due invenzioni separati lavorano insieme una volta che esistono, e ha fatto proprio questo molte volte nel corso della storia. Lo ha persino fatto due volte per i SRVrecord di risorse e HTTP.

— JdeBP

@JdeBP sai bene che se fosse stato così facile sarebbe stato fatto ormai. Il problema è il passaggio di siti a un meccanismo HTTP + SRV senza fornire un'esperienza inferiore agli innumerevoli milioni di utenti che sarebbero bloccati sui vecchi browser.

— Alnitak,

Intendi un paio di volte che qualcuno ha scritto una bozza su Internet? Non è praticamente lo stesso - è banale scriverne uno, e poi il mondo reale ti colpisce e scopri che in realtà ci sono un sacco di casi limite e altri problemi che significa che non funzionerà nel mondo reale, e alla fine la bozza scade e è per lo più dimenticato. Diavolo, mi è già successo un bel po 'dei miei.

— Alnitak,

SRV i record offrono tre cose:

Nomi host multipli - si può fare senza
Porte alternative - cattiva idea - vedi sotto
Una correzione per il problema CNAME all'apice della zona

Ri: porte alternative: i record SRV potrebbero essere utilizzati come modo per eseguire server Web su porte alternative senza dover pubblicizzare tale fatto nell'URL. Questa è una brutta cosa . Le politiche del firewall aziendale in genere vietano l'accesso a porte "insolite" e incoraggiare l'idea di utilizzare porte alternative sarebbe scarsa per l'accessibilità del sito.

L'unico vantaggio tangibile che vedo è per il n. 3: consentirebbe example.comdi essere reindirizzati webhost.example.netsenza richiedere un CNAME(che non è consentito in un apice di zona) o un Arecord (che è un male per la manutenzione di zona).

— Alnitak
fonte

-1 per aver perso l'intero punto, nonostante molte persone lo abbiano fatto nel corso degli anni mentre chiedono questo e l'interrogante addirittura allude ad esso, che è ovviamente il bilanciamento del carico esplicito e le informazioni di fallback per i clienti.

— JdeBP,

I dati di bilanciamento del carico e fallback di @JdeBP IMNSHO non appartengono al DNS - questo rientra nei regni di "Stupid DNS Tricks (TM)". Entrambi appartengono al livello di routing IP: è l'unico posto in cui è possibile fornire un failover continuo tra i servizi.

— Alnitak,

In realtà, porte alternative è una buona idea perché i protocolli non dovrebbero essere associati alle porte. Immagina un mondo in cui l'ufficio postale doveva essere sempre al secondo piano dell'edificio, non sarebbe inutile? Ecco per cosa abbiamo le rubriche (DNS)! Ciò che è veramente una cattiva idea è la definizione di regole firewall in uscita basate su una porta. È inutile perché gli attaccanti potrebbero sempre usare le porte non bloccate. Inoltre, immagina un mondo in cui sarebbe negato di andare al secondo piano in ogni edificio, solo perché potrebbe essere un ufficio postale. Divertente, vero? ;)

— FlashFan

@FlashFan, sfortunatamente, le aziende persistono nel voler bloccare l' uscita di Internet supponendo che tutti i siti web siano sulla porta 80 o 443.

— Alnitak,

Si, lo so. Ecco perché abilitare i record SRV sarebbe positivo, perché costringerebbe le aziende a smettere di fare quelle cattive pratiche inutili. Indipendentemente dal numero di porte in uscita bloccate, purché sia aperta una sola porta, puoi fare tutto ciò che desideri, perché puoi fare tutto anche se ogni porta. Il fatto che non si possa nemmeno sapere se ciò che passa attraverso la connessione TLS sulla porta 443 è davvero HTTP, lo sottolinea solo.

— FlashFan