Soru Özel ağ için üst düzey alan / alan soneki mi?


Ofisimizde, tamamen dahili DNS kurulumuna sahip bir yerel alan ağımız var. whatever.lan. Ayrıca bir VMware ortamım var ve sanal makine ağında sanal makineleri adlandırıyorum. whatever.vm.

Şu anda, sanal makineler için bu ağ yerel alan ağımızdan erişilemiyor, ancak bu sanal makineleri şu amaçlarla taşımak için bir üretim ağı kuruyoruz. irade LAN'dan ulaşılabilir. Sonuç olarak, kurduğumuz bu yeni ağda misafirlerimize uygulayacağımız alan sonek / TLD için bir sözleşmeye oturmaya çalışıyoruz, ancak iyi bir sonuç elde edemeyiz. .vm, .local ve .lan tüm çevremizde mevcut çağrışımlar var.

Peki, bu durumda en iyi uygulama nedir? Tamamen dahili bir ağ için güvenli olan bir yerde TLD'ler veya alan adları listesi var mı?


104
2018-06-01 21:47


Menşei


Kullanmayın. Özellikle herhangi bir Apple müşteriniz varsa. - RainyRat
.test bu sebeple ayrılmıştır: secure.wikimedia.org/wikipedia/en/wiki/.test - CWSpear
@CWSpear Bu gerçek değil neden  .test saklıdır, bunun için kullanmak için güvenli bir alan yapar Ölçek internete bağlanmayacak ağlar. - voretaq7
@Otto en iyi uygulamaları, bir "gerçek" alan adı (bir ICANN tarafından tanınan TLD altında) aldığınızı ve yerel öğeleriniz için bir alt alan oluşturduğunuzu belirtebilir (ör. mydomain.comtemsilci internal.mydomain.com dahili bir NS'ye ve bölünmüş ufuk DNS'yi (BIND'deki "görünümler") düzgün bir şekilde yapılandırın, böylece dahili isimleri / adresleri internete sızdırmazsınız. TLD / psödo-TLD kadar hoş değil, fakat kontrolünüz altında olduğu için kırılmaya daha az eğilimlidir. - voretaq7
ancak: Kamuya açık üretim hizmetleri için kullandığınız gerçek bir alan adı kullanmayın. Arasında izin verilen çeşitli etkileşimler var www.example.com ve *.internal.example.com bunlar arasında izin verilmez www.example.com ve *.example.netözellikle de siteler arası çerez ayarı. İç ve dış hizmetlerin aynı alanda çalıştırılması, bir kamu hizmetinden taviz verilmesinin iç hizmetlere bir miktar giriş yapması riskini artırır ve bunun tersine, güvenli olmayan bir iç hizmetin harici bir hizmetin içsel kötüye kullanılmasını provoke edebileceği riskini arttırır. - bobince


Cevaplar:


İcat edilmiş bir TLD kullanmayın. ICANN onu devredecek olsaydı, büyük bir belada olurdu. Aynı şey, aynı kukla TLD'yi kullanan başka bir organizasyonla birleşirse. Bu yüzden küresel olarak benzersiz alan adları tercih edilir.

Standart, RFC 2606 örnekler, belgeler, testler, ancak genel kullanım için hiçbir şey, ve iyi nedenlerle ayırır: bugün, gerçek ve benzersiz bir alan adı almak için çok kolay ve ucuzdur, bu da bir kukla kullanmak için iyi bir neden yoktur.

Satın al iamthebest.org ve cihazlarınızı adlandırmak için kullanın.


86
2018-06-02 07:39



Tamamen güvenli olmak için, her şeyi şirketimin alan adının local.company.org, vm.company.org gibi bir alt alanına koyardım. - drybjed
Bunu + 1'le. Muhtemelen şirketinizin bir alanı var. Sadece bundan bir alt alan oluşturun. LAN'ınızın dışında görünür / çözülebilir olmak zorunda değildir. - Dan Carley
Eh, çok iyi avukatlar ile bile, bir ticari marka çağırarak ".lan" veya ".local" iddiasında sorun yaşayacaksınız. Ve "sadece içseldir" argümanı aşırı derecede zayıftır: örgütler birleşir, ortak kuruluşlarla sanal özel ağlar kurar ve "özel" isimlerin sızması gibi hatalar yaparlar. - bortzmeyer
Bununla ilgili tek sığırım, bir alanı gerçekten "satın alamıyor" olmanızdır: sadece bir kiralayabilirsiniz. Bazı bozolar bir fatura ödemeyi unutuyor (ve bu birkaç yüksek profilli vakada gerçekleşti) ve konfigürasyonunuzun çekirdek bir kısmı rastgele bir gecekonduya gider. Yani şirketinizin alan adını kullanıyorsunuz? Yürütücüler yeniden markalaşmaya veya satın alınmaya karar verir ve eski bir adla sıkışmışsınız demektir. .local yeterince iyi çalışıyordu, ama şimdi belli bir şirket tarafından güzel oynamayı reddedecek şekilde önlendi. Gerçekten böyle bir şey görmek isterdim. Ya da bu amaç için resmi olarak ayrılmış. Ama o zamana kadar bu en iyi seçenek. - Joel Coel
@Joel Coel ile katılıyorum, bir kiracınız ve başka bir şey değil. İki ayrılmış TLD ismi olmalı İç kullanım için Kamusal ağlarda geçersiz sayılmalı ve kamu ağları tarafından erişilebilir olmamalıdır. Bir isim iç ev kullanımı için, ikinci isim iç iş kullanımı için olurdu. Her ikisi de aynı şekilde "özel TLD'ler" olarak kabul edilir ve aynı şekilde yönlendirilemeyen "özel alt ağlar" a sahip oluruz (192.168.x.x ve ilk). Bu, ev kullanıcılarının .local ve mDNS'ye zorlanmanın yanı sıra bir şeyler yapmasına da olanak tanır. Küçük işletmeler için, hiçbir etki alanı olmayan NAT'ın arkasında bir dahili LAN çalıştıran Ditto. - Avery Payne


İnternette bulunmasını istemediğiniz dahili makineler için şirketinizin kayıtlı alan adının bir alt alan adını kullanın. (O zaman, tabii ki, bu isimleri sadece iç DNS sunucularınızda barındırır.) Burada hayali Örnek Kurum için bazı örnekler verilmiştir.

İnternet bağlantılı 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 kurumsal ağdaki makineleri tanımladığını göstermek için "corp" kullandım, ancak burada "internal": client1.internal.example.com gibi istediğiniz herhangi bir şeyi kullanabilirsiniz.

Ayrıca, DNS bölgelerinin ve alt alan adlarının ağ numaralandırma düzeninizle hizalanması gerekmediğini unutmayın. Örneğin, şirketim, her birinin kendi alt ağına sahip 37 konumu vardır, ancak tüm konumlar aynı (dahili) alan adını kullanır. Tersine, yalnızca bir veya birkaç alt ağınız olabilir, ancak makinelerinizi düzenlemenize yardımcı olacak çok sayıda dahili alan veya alt alan adları olabilir.


47
2018-06-02 13:03





Dahili bir alt alan kullanmanın bir başka avantajı da vardır: akıllıca arama soneklerini ve FQDN yerine yalnızca ana makine adlarını kullanarak geliştirme, Kalite Güvence ve üretimde çalışan yapılandırma dosyaları oluşturabilirsiniz.

Örneğin, yapılandırma dosyanızda her zaman "database = dbserv1" kullanırsınız.

Geliştirme sunucusunda, arama sonekini "dev.example.com" olarak ayarlarsınız. => kullanılan veritabanı sunucusu: dbserv1.dev.example.com

KG sunucusunda, arama sonekini "qa.example.com" olarak ayarlarsınız. => kullanılan veritabanı sunucusu: dbserv1.qa.example.com

Ve üretim sunucusunda, arama sonekini "example.com" olarak ayarladınız => kullanılan veritabanı sunucusu: dbserv1.example.com

Bu şekilde, her ortamda aynı ayarları kullanabilirsiniz.


30
2018-06-04 12:00



Bu harika. - Chris Magnuson
Birisi kendi iş istasyonunu üretim arama son eki ile bir sorunu sınamaya ve daha sonra bir grup üretim kaydını yanlışlıkla güncelleştirmeye kadar. - Joel Coel
Bu oldukça ham, SRV kayıtları ayrıştırmak için çok basit ve aynı db sunucusu birkaç bölgeye hizmet verecek şekilde herhangi bir bölge içine yerleştirilebilir. Bu durumda, bir miktar kod, config dosyalarınızdaki değeri dolduracaktır. Ve veritabanının adını SRV anahtarı ve ana bilgisayar adına işaret eden tablonun değeri olarak kullanabilirsiniz. Asla arama eklerine güvenmem. Ayrıca, TXT kayıtları ile oldukça yaratıcı olabilir ve aes-256 şifreli (daha sonra base64 kodlu) değerlerle, yani sırlarsa bunları doldurabilirsiniz. TXT kayıtlarını her türlü şey için kullanabilirsiniz. - figtrap
bak, ama istediğim example.com, example.dev ve example.stg. Son 2 sadece özel bir ağda, sıfır yapılandırma erişimi için yerel bir DNS sunucusu kurabilir miyim? Hala tüm siteler için benzer bir yapılandırma kullanarak, sadece tld'e kadar olan değişiklikleri taşıyoruz. Bir hosts dosyası ile .dev için kolay, ancak sıfır yapılandırma ... - DigitalDesignDj


Daha önce söylendiği gibi, özel ağınız için kayıtsız bir TLD kullanmamalısınız. Özellikle şu anda 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 temiz:

Bu adreslere dolaylı referanslar   içinde yer almalıdır   kurumsal. Bunun öne çıkan örnekleri   referanslar DNS Kaynak Kayıtlarıdır   ve diğer bilgileri   iç özel adresler.   Bu nedenle ad sunucunuz, özel kayıtların internette iletilmesini önlemek için görünümleri de kullanmalıdır.


11
2018-06-02 12:41





Fiziksel ev sahiplerinin sanal isimlendirmesindeki hiçbir farkı düşünmüyoruz - aslında, fiziksel katmandan ana bilgisayar konfigürasyonunu (yazılım) soyutlamaya aldık.

Bu yüzden, Donanım Öğeleri satın alıyoruz ve bunların üzerine Ana Öğeler oluşturuyoruz (ve belgelerimizde bunu göstermek için basit bir ilişki kullanıyoruz).

Amaç, bir ana bilgisayar mevcut olduğunda, DNS'nin belirleyici faktör olmamalı - makinelerin bir alandan diğerine geçmesi gibi - örneğin düşük performanslı bir web sunucusunun pahalı CPU döngüleri tüketmesine gerek kalmaması - sanallaştırması ve adlandırma şemasını korur, her şey çalışmaya devam eder.


9
2018-06-01 21:52





Bu soruya verilen önceki cevaplar yazıldığından, rehberliği bir şekilde değiştiren birkaç RFC olmuştur. RFC 6761 Özel ağlar için özel rehberlik sağlamadan özel kullanım alan adlarını tartışır. RFC 6762 yine de kayıt dışı TLD'leri kullanmamanızı tavsiye eder, ancak yine de yapılması gereken durumlar olduğunu kabul eder. Yaygın olarak kullanılan beri .yerel Multicast DNS ile çakışmalar (RFC'nin ana konusu), Ek G. Özel DNS Ad Alanları aşağıdaki TLD'leri önerir:

  • intranet
  • özel
  • corp
  • ev
  • lan

IANA görünür RFC'leri tanımak ancak (halihazırda) Ek G'de listelenen isimleri içermemektedir.

Başka bir deyişle: bunu yapmamalısınız. Ama yine de yapmaya karar verdiğinizde, yukarıdaki isimlerden birini kullanın.


3
2017-10-30 07:00





Bunun size yardımcı olacağından emin değilim, ama AWS hesabımın iç DNS'si için kullanıyorum .aws tld olarak ve gayet iyi çalışıyor gibi görünüyor.

Bazı TLD'ler olduğunu biliyorum, sadece kullanmamaya dikkat etmelisiniz, ama bunlardan başka, çok katı olduğunu düşünmüyorum.

Kimlik doğrulama kaynağını TLD olarak kullanacakları birkaç büyük şirkette çalıştım, yani MS / Windows sunucusu olsaydı, Active Directory'yi auth kaynağı olarak kullanırdı, .adve bazı diğerleri olurdu .ldap (Neden aynı kaynağı kullanmıyorlardı? Yoksa aynı dizin hizmetini kopyalayan sunucular değil? Bilmiyorum, oraya vardığımda böyle oldu)

İyi şanslar


-4
2018-02-29 14:28



Amazon şimdi kayıtlı .aws TLD olarak, sonuçta problemleri görmeye başlayabilirsiniz: nic.aws - Mark McKinstry
Bilgi için, .aws son zamanlarda "25 Mart 2016" => kayıtlı newgtlds.icann.org/en/program-status/delegated-strings - Bruno Adelé
Sahte bir TLD kullanmayı düşünmemekle birlikte, bir anlaşmanın büyük bir kısmı, en azından tüm sistemin kapatılıp kapatılmadığı ve internet ile iletişim kurmak için bir proxy kullandığı halde, ".aws" AWS içinde DEĞİL! Artık AWS ile iletişim kuramayacağınız çok fazla tahmin edilemez senaryo var. - figtrap