Ofisimizde tamamen istemcilerin
whatever.lan olarak adlandırıldığı tamamen dahili bir DNS kurulumuna sahip bir yerel alan ağımız var. Ayrıca bir VMware ortamım var ve salt sanal makine ağında, sanal makinelere
whatever.vm adını veriyorum.
Şu anda, sanal makineler için bu ağa yerel alan ağımızdan erişilemiyor, ancak bu sanal makineleri taşımak için bir üretim ağı kuruyoruz LAN'dan erişilebilir. Sonuç olarak, kurduğumuz bu yeni ağdaki konuklara uyguladığımız alan son eki/TLD için bir sözleşmeye karar vermeye çalışıyoruz, ancak
.vm,
.local ve
.lan hepsinin çevremizde mevcut çağrışımları var.
Peki, bu durumda en iyi uygulama nedir? Tamamen dahili bir ağ için güvenli bir yerde TLD'lerin veya alan adlarının bir listesi var mı?
İcat edilmiş bir TLD kullanmayın. ICANN delege edecek olsaydı, başınız büyük belada olurdu. Aynı kukla TLD'yi kullanan başka bir kuruluşla birleşirseniz aynı şey olur. Bu nedenle global olarak benzersiz alan adları tercih edilir.
Standart, RFC 2606 örnekler, belgeler, testler için ad ayırır, ancak genel kullanım için hiçbir şey ve iyi nedenlerle: bugün, orada gerçek ve benzersiz bir alan adı almak çok kolay ve ucuzdur. kukla kullanmak için iyi bir neden değildir.
Yani,
iamthebest.org ve cihazlarınızı adlandırmak için kullanın.
İnternet'te adlarını istemediğiniz dahili makineler için şirketinizin kayıtlı etki alanının bir alt etki alanını kullanın. (O zaman, elbette, yalnızca bu adları dahili DNS sunucularınızda barındırın.) Hayali Sample Corporation için bazı örnekler.
Internet'e bakan sunucular:
Www.example.com
Mail.example.com
Dns1.example.com
İç makineler:
Dc1.corp.example.com
Dns1.corp.example.com
Client1.corp.example.com
Bu alt alanın dahili şirket ağındaki makineleri açıkladığını belirtmek için "corp" kullandım, ancak burada istediğiniz "internal" gibi herhangi bir şeyi kullanabilirsiniz: client1.internal.example.com.
DNS bölgelerinin ve alt alan adlarının ağ numaralandırma düzeninizle hizalanmak zorunda olmadığını da unutmayın. Örneğin şirketim, her biri kendi alt ağına sahip 37 konuma sahip, ancak tüm konumlar aynı (dahili) alan adını kullanıyor. Tersine, yalnızca bir veya birkaç alt ağınız olabilir, ancak makinelerinizi düzenlemenize yardımcı olacak birçok eş dahili etki alanı veya alt etki alanı düzeyi olabilir.
Dahili bir alt alan kullanmanın başka bir avantajı daha vardır: akıllıca arama soneklerini ve FQDN yerine yalnızca ana bilgisayar adlarını kullanarak, geliştirme, KG ve üretimde çalışan yapılandırma dosyaları oluşturabilirsiniz.
Örneğin, yapılandırma dosyanızda her zaman "database = dbserv1" kullanılır.
Geliştirme sunucusunda, arama sonekini "dev.example.com" => kullanılan veritabanı sunucusuna ayarlarsınız: dbserv1.dev.example.com
KG sunucusunda, arama sonekini "qa.example.com" => kullanılan veritabanı sunucusuna ayarlayın: dbserv1.qa.example.com
Ve üretim sunucusunda, arama sonekini "example.com" => kullanılan veritabanı sunucusuna ayarlarsınız: dbserv1.example.com
Bu şekilde, her ortamda aynı ayarları kullanabilirsiniz.
Bu soruya önceki cevaplar yazıldığından, rehberliği biraz değiştiren birkaç RFC vardı. RFC 6761 özel ağlar için özel rehberlik sağlamadan özel kullanım alan adlarını tartışır. RFC 6762 yine de kayıtlı olmayan TLD'lerin kullanılmamasını önermekle birlikte yine de bunun yapılacağı durumlar olduğunu kabul etmektedir. Yaygın olarak kullanılan . Yerel Çok Noktaya Yayın DNS (RFC'nin ana konusu) ile çakıştığından, Ek G. Özel DNS Ad Alanları aşağıdaki TLD'leri önerir:
IANA her iki RFC'yi de tanır gibi görünüyor, ancak (şu anda) Ek G'de listelenen adları içermiyor.
Başka bir deyişle: yapmamalısınız. Ancak yine de yapmaya karar verdiğinizde, yukarıdaki adlardan birini kullanın.
Daha önce de belirtildiği gibi, özel ağınız için kayıtlı olmayan bir TLD kullanmamalısınız. Özellikle şimdi ICANN hemen hemen herkesin yeni TLD kaydetmesine izin veriyor. Daha sonra gerçek bir alan adı kullanmalısınız.
Diğer tarafta RFC 1918 açıktır:
Bu tür adreslere dolaylı referanslar işletme içinde bulunmalıdır. Bu tür referansların öne çıkan örnekleri, DNS Kaynak Kayıtları ve dahili özel adreslere atıfta bulunan diğer bilgilerdir.
Bu nedenle ad sunucunuz, özel kayıtların Internet'e iletilmesini önlemek için görünümleri kullanmalıdır.
Ana bilgisayarların sanal adlandırılmasında fizikselden bir fark gözetmeme eğilimindeyiz - aslında, Ana Bilgisayar yapılandırmasını (yazılımı) fiziksel katmandan soyutlamaya başladık.
Bu yüzden Donanım Öğeleri satın alıyor ve bunların üzerinde Ana Bilgisayar Öğeleri oluşturuyoruz (ve bunu belgelerimizde göstermek için basit bir ilişki kullanıyoruz).
Amaç, bir Ana Bilgisayar olduğunda DNS belirleyici faktör olmamalıdır - makinelerimiz bir alandan diğerine hareket ettiğimiz için - örneğin, düşük performanslı bir web uygulamasının pahalı CPU döngüleri tüketmesine gerek yoktur - sanallaştırın ve isimlendirme şemasını korur, her şey çalışmaya devam eder.