Vraag Waarom waarschuwt Heroku voor "naakte" domeinnamen?


Ik kwam over deze pagina in de Heroku-documentatie ...

Naakte domeinen, ook wel bare- of apex-domeinen genoemd, worden via A-records in DNS geconfigureerd en hebben serieuze implicaties voor de beschikbaarheid bij gebruik in zeer beschikbare omgevingen zoals enorme on-premise datacenters, cloudinfrastructuurservices en platforms zoals Heroku.

Voor maximale schaalbaarheid en veerkracht moeten toepassingen naakte domeinen vermijden en in plaats daarvan alleen vertrouwen op op subdomeinen gebaseerde hostnamen.

Spreekt iemand hier Enterprise? Wat zijn de 'beschikbaarheidseffecten' waarvoor ze waarschuwen?

(Ik merk dat http://stackoverflow.com werkt geen probleem, dus blijkbaar zijn er levensvatbare alternatieve filosofieën over dit onderwerp.)


62
2017-07-16 04:55


oorsprong


ik ren www.yes-www.org en ik keur deze vraag goed. - Michael Hampton♦
Er is nog een andere zorg: statische activa kunnen niet worden geserveerd zonder bijgevoegde cookies (u kunt geen cookies toevoegen JUST voor het hoofddomein; cookies moeten voor een subdomein zijn of voor .domain.com (jokerteken, gebruikt als hoofddomein)). U kunt dit omzeilen door items van een ander domein te gebruiken (SE-gebruik sstatic.net) om het afgrijselijke www-subdomein te vermijden. - Tom Marthenal
@MichaelHampton, waarom kunnen we geen opmerkingen achterlaten op www.yes-www.org? Waarom noem je niet ALIAS (of ANAME records) op uw pagina? - Augustin Riedinger
Deze vraag is 6 jaar oud, en vooral over beperkingen in software. Zijn er updates? - Michael Cole


antwoorden:


Waar ze het over hebben, is dat wanneer je een CNAME om naar hun services te verwijzen (wat alleen mogelijk is op subdomein, niet op de zone-root - het kan niet samengaan met de SOA en NS records die vereist zijn in de hoofdmap van uw zone), kunnen zij een wijziging aanbrengen in hun eigen DNS-records om een ​​soort beschikbaarheidsprobleem te omzeilen.

Met een zone-root moet u een A record om naar een specifiek IP-adres voor de service te verwijzen. Als ze een probleem hebben met routering of een vorm van denial of service tegen dat specifieke adres, kunnen ze deze niet bijwerken jouw zones  A record om onderweg naar een ander IP-adres te wijzen; ze kunnen hun eigen echter updaten, en dat is wat a CNAME staat hen toe om te doen.

Dit is niet van toepassing op Stack Exchange omdat ze het platform van een derde niet gebruiken; zij zullen degenen zijn die reageren op een beschikbaarheidsprobleem, dus of het nu gaat om een CNAME of een A maakt geen verschil voor hen.


56
2017-07-16 04:59



Hoe zit het met ALIAS (of ANAME) records? - Augustin Riedinger
@AugustinRiedinger Dit zijn eigenlijk geen DNS-recordtypen - het is een configuratie waarbij bepaalde DNS-providers de abstractie van het dynamisch controleren van de huidige A het doel vast te leggen en vervolgens weer te geven in antwoord op een vraag voor die naam. Ze zijn in essentie ontworpen om dit exacte probleem op te lossen, dus ze zijn absoluut geschikt om te gebruiken voor deze case. - Shane Madden♦
Dus als we ze gebruiken, blijft de schaalbaarheidwaarschuwing van heroku niet meer kloppen, toch? Of is er een technisch nadeel bij het gebruik ervan? - Augustin Riedinger
@AugustinRiedinger Juist. Het technische nadeel zit hem in de implementatiemoeilijkheid, omdat een "standaard" DNS-server dat soort dingen niet kan bereiken zonder aanpassingen. Zolang de implementatie van uw provider stabiel is, moet deze net zo goed zijn als een CNAME instellen op een subdomein. - Shane Madden♦


Als een aanvulling op het antwoord van @ShaneMadden is een oplossing voor het externe platform om ook uw DNS-zone te beheren. Bijvoorbeeld als u AWS's gebruikt Elastische belastingsbalans service, en hun Route 53 DNS-service, kunt u de zone-top op betrouwbare wijze naar een ELB-instantie verwijzen met behulp van hun aangepaste alias records, waarmee ze uw DNS-zone kunnen bijwerken in reactie op problemen met de beschikbaarheid.

Dit is echter een argument tegen de no-www concept, sinds www.example.com kan een hebben CNAME record.


12
2017-07-16 05:57