Dlaczego Heroku ostrzega przed „nagimi” nazwami domen?

Natknąłem się na tę stronę w dokumentach Heroku ...

Domeny nagie, zwane również domenami nagimi lub wierzchołkowymi, są konfigurowane w DNS za pośrednictwem rekordów A i mają poważne konsekwencje dla dostępności, gdy są używane w środowiskach o wysokiej dostępności, takich jak ogromne lokalne centra danych, usługi infrastruktury chmurowej i platformy, takie jak Heroku.

Aby zapewnić maksymalną skalowalność i odporność, aplikacje powinny unikać nagich domen i zamiast tego polegać wyłącznie na nazwach hostów opartych na subdomenach.

Czy ktoś tu mówi Enterprise? O jakich „implikacjach dotyczących dostępności” ostrzegają?

(Zauważam, że http://stackoverflow.com nie działa bez problemu, więc ewidentnie istnieją realne alternatywne filozofie w tym temacie).

— Agvorth
źródło

Biegnę www.yes-www.org i pochwalam to pytanie.

— Michael Hampton

Istnieje również inna obawa: zasoby statyczne nie mogą być obsługiwane bez dołączonych plików cookie (nie można dodawać plików cookie TYLKO dla domeny głównej; pliki cookie muszą być dla subdomeny lub dla .domain.com(symbol wieloznaczny, używany, jeśli domena główna)). Możesz obejść ten problem, obsługując zasoby z innej domeny (SE używa sstatic.net ), aby uniknąć ohydnej subdomeny www.

— Tom Marthenal,

@MichaelHampton, dlaczego nie możemy zostawiać komentarzy na www.yes-www.org? Dlaczego nie wspominasz ALIAS(lub ANAMEzapisujesz) na swojej stronie?

— Augustin Riedinger

To pytanie ma 6 lat i dotyczy głównie ograniczeń oprogramowania. Jakieś aktualizacje?

— Michael Cole

Odpowiedzi:

Mówią o tym, że kiedy używasz, CNAMEaby wskazać ich usługi (jest to możliwe tylko w subdomenie, a nie w katalogu głównym strefy - nie może współistnieć z rekordami SOAi NSwymaganymi w katalogu głównym twojej strefy), mogą wprowadzić zmiany we własnych rekordach DNS, aby obejść jakiś problem z dostępnością.

W przypadku katalogu głównego strefy należy użyć Arekordu, aby wskazać określony adres IP usługi. Jeśli mają problem z routingiem lub odmową usługi w odniesieniu do tego konkretnego adresu, nie są w stanie zaktualizować rekordu strefy, A aby wskazywał na inny adres IP w locie; mogą jednak aktualizować własne, a to CNAMEpozwala im to zrobić.

Nie dotyczy to Stack Exchange, ponieważ nie korzystają z platformy strony trzeciej; oni będą tymi, w odpowiedzi na problem dostępności, więc czy jest to CNAMEalbo Anie robi różnicy do nich.

— Shane Madden
źródło

Co z ALIAS(lub ANAME) rekordami?

— Augustin Riedinger

@AugustinRiedinger Nie są to w rzeczywistości typy rekordów DNS - są to konfiguracje, w których niektórzy dostawcy DNS zajmą się abstrakcją dynamicznego sprawdzania bieżącego Arekordu celu, a następnie odsyłania go w odpowiedzi na zapytanie o tę nazwę. Są one zasadniczo zaprojektowane, aby rozwiązać dokładnie ten problem, więc zdecydowanie nadają się do użycia w tym przypadku.

— Shane Madden

Więc jeśli ich użyjemy, ostrzeżenie o skalowalności z heroku nie będzie już prawdziwe, prawda? Czy może jest jakaś wada techniczna ich używania?

— Augustin Riedinger

@AugustinRiedinger Correct. Wadą techniczną jest trudność implementacji, ponieważ „standardowy” serwer DNS nie może tego dokonać bez dostosowania. Tak długo, jak implementacja twojego dostawcy jest stabilna, powinna być tak samo dobra jak CNAMEkonfiguracja w subdomenie.

— Shane Madden

Jako dodatek do odpowiedzi @ ShaneMadden, jednym z obejść jest to, że platforma innej firmy również zarządza twoją strefą DNS. Na przykład, jeśli używasz AWS Elastic równoważenia obciążenia usługi, oraz ich Route 53 usługę DNS, można wiarygodnie wskazać szczyt strefy na przykład ELB, stosując swoje własne rekordy alias , który pozwala im aktualizować strefy DNS w odpowiedzi na kwestie dostępności.

Jest to jednak argument przeciwko koncepcji no-www , ponieważ www.example.commoże mieć CNAMErekord.

— mgorven
źródło