Heroku neden “çıplak” alan adlarına karşı uyarıyor?

Ben karşılaştım bu sayfayı Heroku docs ...

Çıplak veya tepe alan adı da denilen çıplak alanlar, DNS'de A kayıtları aracılığıyla yapılandırılır ve büyük şirket içi veri merkezleri, bulut altyapısı hizmetleri ve Heroku gibi platformlar gibi yüksek kullanılabilir ortamlarda kullanıldığında ciddi kullanılabilirlik etkilerine sahiptir.

Maksimum ölçeklenebilirlik ve esneklik uygulamaları için açık alanlardan kaçınmalı ve bunun yerine yalnızca alt etki alanı tabanlı ana bilgisayar adlarına dayanmalıdır.

Burada kimse Enterprise bilen var mı? Uyardıkları "uygunluk sonuçları" nedir?

(Ben fark http://stackoverflow.com sorun çalışır, bu nedenle besbelli bu konuda uygulanabilir alternatif felsefeleri vardır.)

— Agvorth
kaynak

Www.yes-www.org adresini çalıştırıyorum ve bu soruyu onaylıyorum.

— Michael Hampton

Başka bir endişe de var: statik varlıklar eklenmiş çerezler olmadan sunulamaz (kök etki alanı için SADECE çerez ekleyemezsiniz; çerezler bir alt etki alanı veya için olmalıdır .domain.com(joker, eğer kök etki alanı kullanılıyorsa)). Bu sorunu , çirkin www alt alan adından kaçınmak için farklı bir alandan (SE sstatic.net kullanır ) varlıklarla hizmet vererek çalışabilirsiniz .

— Tom Marthenal

@MichaelHampton, www.yes-www.org hakkında neden yorum yapamıyoruz? Neden sayfanızdan ALIAS(veya ANAMEkayıtlardan) söz etmiyorsunuz?

— Augustin Riedinger

Bu soru 6 yaşında ve çoğunlukla yazılımdaki sınırlamalar hakkında. Herhangi bir güncelleme var mı?

— Michael Cole

Yanıtlar:

Konuştukları şey, CNAMEhizmetlerine işaret etmek için bir kullandığınızda (bu sadece alt etki alanında olabilir, bölge kökü değil - bölgenizin kökünde gerekli olan SOAve NSkayıtları ile birlikte bulunamaz ), Bir çeşit kullanılabilirlik sorunu etrafında çalışmak için kendi DNS kayıtlarında değişiklik yapabilirler.

Bir bölge köküyle, Ahizmet için belirli bir IP adresini göstermek için bir kayıt kullanmanız gerekir . Yönlendirme ile ilgili bir sorunu varsa veya belirli bir adrese karşı bir tür hizmet reddetmesi durumunda, bölgenizdeki A kaydını anında farklı bir IP'ye işaret edecek şekilde güncelleyemezler ; Yine de kendilerini güncelleyebilirler ve bu CNAMEonların yapmalarına izin veren şeydir .

Bu üçüncü taraf platformunu kullanmadıkları için Stack Exchange için geçerli değildir; Bir olsun böylece, kullanılabilirlik sorununa yanıt olanlar olacak CNAMEya da Aonlara hiç fark etmez.

— Shane Madden
kaynak

Peki ya ALIAS(ya da ANAME) kayıtlar?

— Augustin Riedinger

@AugustinRiedinger Bunlar aslında bir DNS kayıt türü değil - belirli DNS sağlayıcılarının A, hedefin geçerli kaydını dinamik olarak kontrol etmenin ve ardından bu adın sorgusuna yanıt olarak geri sunmanın soyutlamasını gerçekleştirecekleri bir yapılandırma . Esasen bu sorunu çözmek için tasarlandılar, bu yüzden bu dava için kesinlikle uygunlar.

— Shane Madden

Yani onları kullanırsak, heroku'dan gelen ölçeklenebilirlik uyarısı artık gerçek değil, değil mi? Veya bunları kullanmanın teknik sakıncaları var mı?

— Augustin Riedinger

@AugustinRiedinger Doğru. Teknik dezavantajı uygulama zorluğudur, çünkü "standart" bir DNS sunucusu bu tür bir şeyi özelleştirme olmadan gerçekleştiremez. Sağlayıcınızın uygulaması kararlı olduğu sürece CNAME, bir alt etki alanındaki kurulum kadar iyi olmalıdır .

— Shane Madden

@ ShaneMadden'in cevabına ek olarak, bir geçici çözüm, üçüncü taraf platformunun DNS bölgenizi de yönetmesidir. Örneğin, AWS'nin Elastik Yük Dengeleyici hizmetini ve onların Route 53 DNS hizmetini kullanıyorsanız, bölge takma alanını, kullanılabilirlik sorunlarına yanıt olarak DNS bölgenizi güncellemelerini sağlayan özel takma ad kayıtlarını kullanarak bir ELB örneğinde güvenilir şekilde yönlendirebilirsiniz .

Ancak bu, no-www kavramına karşı bir argümandır , çünkü www.example.combir CNAMEkaydı olabilir.

— mgorven
kaynak