Perché Heroku mette in guardia contro i nomi di dominio "nudi"?

Mi sono imbattuto in questa pagina nei documenti di Heroku ...

I domini nudi, chiamati anche domini bare o apex, sono configurati in DNS tramite record A e hanno gravi implicazioni sulla disponibilità se utilizzati in ambienti ad alta disponibilità come enormi data center on-premise, servizi di infrastruttura cloud e piattaforme come Heroku.

Per la massima scalabilità e resilienza, le applicazioni dovrebbero evitare domini nudi e fare affidamento esclusivamente su nomi host basati su sottodomini.

Qualcuno qui parla Enterprise? Quali sono le "implicazioni sulla disponibilità" che stanno avvertendo?

(Noto che http://stackoverflow.com non ha alcun problema, quindi evidentemente ci sono filosofie alternative praticabili su questo tema.)

— Agvorth
fonte

Corro www.yes-www.org e approvo questa domanda.

— Michael Hampton

C'è anche un'altra preoccupazione: le risorse statiche non possono essere offerte senza i cookie collegati (non è possibile aggiungere SOLO i cookie per il dominio principale; i cookie devono essere per un sottodominio o per .domain.com(carattere jolly, usato se dominio principale)). Puoi aggirare questo problema servendo risorse di un dominio diverso (SE utilizza sstatic.net ) per evitare il subdominio www orribile.

— Tom Marthenal,

@MichaelHampton perché non possiamo lasciare commenti su www.yes-www.org? Perché non menzioni ALIAS(o ANAMEregistri) nella tua pagina?

— Augustin Riedinger,

Questa domanda ha 6 anni e riguarda principalmente le limitazioni nel software. Nessun aggiornamento?

— Michael Cole,

Risposte:

Quello di cui stanno parlando è che quando si utilizza un CNAMEper puntare ai loro servizi (che è possibile solo su sottodominio, non la radice di zona - non può coesistere con le SOAe NSrecord che sono necessari nella directory principale della vostra zona), possono apportare una modifica ai propri record DNS per aggirare una sorta di problema di disponibilità.

Con una radice di zona, è necessario utilizzare un Arecord per puntare a un indirizzo IP specifico per il servizio. Se hanno un problema con il routing o qualche tipo di negazione del servizio rispetto a quell'indirizzo specifico, non sono in grado di aggiornare il A record della propria zona in modo che punti al volo a un IP diverso; possono aggiornare il proprio, però, ed è ciò che CNAMEconsente loro di fare.

Questo non si applica a Stack Exchange perché non utilizzano una piattaforma di terze parti; saranno loro a rispondere a un problema di disponibilità, quindi che si tratti di una CNAMEo una Anon fa differenza per loro.

— Shane Madden
fonte

Che dire dei ALIAS(o ANAME) record?

— Augustin Riedinger,

@AugustinRiedinger Questi non sono in realtà un tipo di record DNS: sono una configurazione in cui alcuni provider DNS gestiranno l'astrazione di controllare dinamicamente il Arecord corrente della destinazione, quindi di servirlo in risposta a una query per quel nome. Sono essenzialmente progettati per risolvere questo esatto problema, quindi sono sicuramente appropriati da usare per questo caso.

— Shane Madden

Quindi, se li usiamo, l'avviso di scalabilità di heroku non rimane più vero, giusto? O c'è qualche svantaggio tecnico nell'usarli?

— Augustin Riedinger,

@AugustinRiedinger Corretto. Lo svantaggio tecnico è nella difficoltà di implementazione, in quanto un server DNS "standard" non può realizzare quel tipo di cose senza personalizzazione. Finché l'implementazione del tuo provider è stabile, dovrebbe essere valida come una CNAMEconfigurazione su un sottodominio.

— Shane Madden

In aggiunta alla risposta di @ ShaneMadden, una soluzione alternativa è che la piattaforma di terze parti gestisca anche la tua zona DNS. Ad esempio, se si utilizza il servizio di bilanciamento del carico elastico di AWS e il relativo servizio DNS Route 53 , è possibile puntare in modo affidabile l'apice di zona su un'istanza ELB utilizzando i propri record di alias personalizzati , che consente loro di aggiornare la zona DNS in risposta a problemi di disponibilità.

Questo è tuttavia un argomento contro il concetto no-www , poiché www.example.compuò avere un CNAMErecord.

— mgorven
fonte