Feragat: Alınma ama bu gerçekten kötü bir fikir. Bunu kimsenin gerçek hayatta yapmasını önermiyorum.
Ancak sıkılmış bir BT görevlisine bir laboratuvar verirseniz, komik şeyler olacak!
Bu deney için, Server 2012 R2 üzerinde çalışan bir Microsoft DNS sunucusu kullandım. Bir DNS bölgesini Active Directory'de barındırmanın zorlukları nedeniyle, AD ile tümleşik olmayan testing.com adlı yeni bir birincil bölge oluşturdum .
Bu betiği kullanarak:
$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
for ($y = 1; $y -lt 256; $y++)
{
for ($z = 1; $z -lt 256; $z++)
{
Write-Host "1.$x.$y.$z`t( $Count )"
$Count++
dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
}
}
}
testing.testing.com.Tam anlamıyla 1.1.1.1'den 1.1.255.255'e kadar her IPv4 adresini içeren , isim için 65025 ana bilgisayar kaydı oluşturdum.
Daha sonra, 65536 (2 ^ 16 bit) toplam A kaydı hatasız olarak kırabildiğimden emin olmak istedim ve yapabileceğimi düşündüm, muhtemelen 16581375'e (1.1.1.1 - 1.255'e kadar gidebileceğimi farz ediyorum). .255.255,) ama burada oturup bu senaryoyu bütün gece boyunca izlemek istemedim.
Bu nedenle, sunucunuzdaki farklı IP'lerle aynı ad için bir bölgeye ekleyebileceğiniz A kaydı sayısının pratik bir sınırının olmadığını söylemek güvenlidir.
Ama aslında müşterinin bakış açısına göre çalışacak mı?
İşte Wireshark tarafından bakıldığı gibi müşterimden ne alıyorum:
(Resmi tam boyut için yeni bir tarayıcı sekmesinde açın.)
Gördüğünüz gibi, istemcimden nslookup veya ping kullandığımda, otomatik olarak iki sorgu yayınlar - bir UDP ve bir TCP. Bildiğiniz gibi, bir UDP datagramına sığdırabileceğim en fazla 512 bayttır, bu yüzden bir limit aşıldığında (20-30 IP adresi gibi) birinin TCP kullanması gerekir. Ancak TCP ile bile, test.testing.com için yalnızca çok küçük bir A kayıt alt kümesi elde ediyorum. TCP sorgusu başına 1000 kayıt döndürüldü. A kayıtları listesi, ardışık her bir sorguda, tam olarak DNS'nin nasıl çalışacağını bekleyeceğiniz gibi, 1 sırayla döner. Bunların arasında robin turu yapmak milyonlarca sorguyu gerektirecekti.
Bunun, büyük ölçüde ölçeklenebilir, esnek sosyal medya ağınızı oluşturmanıza nasıl yardımcı olacağını anlamıyorum, ancak yine de cevabınız var.
Düzenleme: İzleme yorumunuzda, bunun neden genellikle kötü bir fikir olduğunu düşündüğümü soruyorsunuz.
Diyelim ki ortalama bir internet kullanıcısıyım ve servisinize bağlanmak istiyorum. Web tarayıcımda www.bozho.biz yazarım. Bilgisayarımdaki DNS istemcisi 1000 kayıt geri alıyor. Eh, kötü şans, listedeki ilk 30 kayıt cevap vermiyor çünkü A kayıtları listesi güncel tutulmuyor ya da internetin bir kısmını etkileyen büyük çaplı bir kesinti var. Diyelim ki web tarayıcım IP’ye geçmeden bir sonraki adım denemeden önce IP’de 5 saniyelik bir zaman aşımına sahip. Şimdi burada oturup sitenizin yüklenmesini bekleyen 2 buçuk dakika boyunca dönen bir kum saatine bakıyorum. Bunun için kimsenin zamanı yok. Ve web tarayıcımın ya da hizmetinize erişmek için kullandığım herhangi bir uygulamanın ilk 4 ya da 5 IP adresinden daha fazla çaba göstereceğini bile farz ediyorum. Muhtemelen olmaz.
Otomatik temizleme özelliğini kullanıyorsanız ve A kayıtlarının listesini taze tutma umuduyla DNS bölgesinde doğrulanmamış veya anonim güncellemelere izin veriyorsanız, bunun ne kadar güvensiz olacağını hayal edin! Müşterileri, bölgeyi güncellemek için önceden sizden aldıkları bir müşteri TLS sertifikasına ihtiyaç duydukları bir sistemi tasarlasanız bile, gezegenin herhangi bir yerinden ödün vermeyen bir müşteri botnet başlatacak ve hizmetinizi mahvedecektir. Geleneksel DNS, kalabalığı temin etmeden, olduğu gibi, güvensiz bir şekilde güvensiz.
Geniş bant genişliği kullanımı ve atık. Her DNS sorgusu 32 kilobayt veya daha fazla bant genişliği gerektiriyorsa, bu iyi bir şekilde ölçeklenmeyecektir.
DNS yuvarlak robin düzgün yük dengeleme yerine geçmez. Bir düğümden aşağı inen veya hiçbir şeyin ortasında kullanılamayan hale gelmenin bir yolu yoktur. Kullanıcılarınıza, bağlandıkları düğüm düşerse ipconfig / flushdns yapma talimatı verecek misiniz? Bu tür meseleler zaten GSLB ve Anycast gibi şeyler tarafından çözüldü.
Vb.