Özel ağ için üst düzey etki alanı / etki alanı eki?

115

Büromuzda, tamamen müşterilerin adını verdiği tamamen dahili bir DNS kurulumuna sahip yerel bir alan ağımız var whatever.lan. Ayrıca bir VMware ortamım var ve yalnızca sanal makineden oluşan ağda, sanal makineleri adlandırıyorum whatever.vm.

Şu anda, sanal makineler için bu ağ yerel alan ağı erişilebilir değil, ama biz hangi için bu sanal makineleri geçirmek için bir üretim ağ kuruyoruz olacak LAN ulaşılabilmelidir. Sonuç olarak, biz biz kuruyoruz bu yeni ağ üzerindeki misafirler için geçerli etki alanı soneki / TLD için kongre yerleşmeye çalışıyoruz fakat biz iyi bir ile gelip olamaz, göz önüne alındığında .vm, .localve .lanhepsinin çevremizde varolan çağrışımları var.

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

— Otto
kaynak

2

Yerel kullanmayın. Özellikle de Apple müşterileriniz varsa.

— RainyRat

2

.test bu nedenle bir kenara ayarlanır: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear Bu , internete bağlanmayacak test ağları için güvenli bir etki alanı haline getirmesine rağmen , gerçek neden .test saklı değildir.

— voretaq7

10

@ En iyi uygulamalar, "gerçek" bir alan adı (ICANN tarafından tanınan bir TLD'nin altında) edinmenizi ve yerel öğeleriniz için bunun bir alt etki alanını oluşturmanızı gerektirir (örneğin, kayıt mydomain.com, internal.mydomain.comdahili bir NS'ye delege edin ve bölünmüş ufuk DNS (düzgün bir şekilde yapılandırın) BIND'de "görünümler") yani dahili isimleri / adresleri internete sızdırmazsınız, bir TLD / sözde-TLD kadar güzel değildir, ancak kontrolünüz altında olduğu gibi kırılmaya daha az eğilimlidir

— voretaq7

9

Bununla birlikte : halka açık üretim hizmetleri için zaten kullandığınız gerçek alan adını kullanmayın. Arasında ve en önemlisi, siteler arası çerez ayarı arasında izin verilen www.example.comve izin verilmeyen çeşitli etkileşimler vardır . Aynı alanda iç ve dış hizmetleri çalıştırmak, bir kamu hizmetinden ödün vermenin iç hizmetlere bir miktar giriş yapması riskini artırır ve bunun aksine güvensiz bir iç hizmetin dış hizmetin iç suiistimalini tetikleyebileceği riskini artırır. *.internal.example.comwww.example.com*.example.net

— bobince

94

Bulunan bir TLD kullanmayın. Eğer ICANN bunu devredecek olsaydı, başınız büyük belaya girerdi. Aynı kukla TLD'yi kullanan başka bir kuruluşla birleşirseniz aynı şey. Bu nedenle global olarak benzersiz alan adları tercih edilir.

Standart, RFC 2606 , örnekler, belgeler, testler, ancak genel kullanım için hiçbir şey içermeyen ve iyi nedenlerden dolayı adlarını saklar : bugün, kullanmak için iyi bir neden olmadığından, gerçek ve benzersiz bir alan adı elde etmek çok kolay ve ucuzdur. kukla bir.

Satın almak iamthebest.orgve cihazlarınızı adlandırmak için kullanın.

— bortzmeyer
kaynak

53

Tamamen güvende olmak için her şeyi, local.company.org, vm.company.org, vb. Gibi şirketimin alan adının bir alt alanına koyardım.

— drybjed

4

Bunu + 1'leyin. Muhtemelen şirketinizde zaten bir etki alanı var. Sadece bundan bir alt etki alanı oluşturun. Yerel ağınızın dışında görünür / çözülebilir olması gerekmez.

— Dan Carley

3

Eh, çok iyi avukatlarla bile, bir ticari markayı arayarak ".lan" veya ".local" iddialarında sorun yaşayabilirsiniz. Ve "sadece dahilidir" argümanı son derece zayıf: örgütler birleşiyor, ortak özel kuruluşlarla sanal özel ağlar kuruyorlar ve basitçe "özel" isimlerin sızdırdığı şekilde hatalar yapıyorlar.

— bortzmeyer

8

Bununla ilgili tek etim, bir etki alanını gerçekten "satın alamamanızdır": yalnızca birini kiralayabilirsiniz. Bazı bozo bir fatura ödemeyi unutuyor (ve bu birkaç yüksek profilli vakada oldu) ve yapılandırmanızın temel bir kısmı rastgele bir şekilde çömelmeye başladı. Yani şirketinizin alanını mı kullanıyorsunuz? Yöneticiler yeniden markalaşmaya ya da satın alınmaya karar veriyorlar ve eski bir isimle takılıp kalıyorsunuz. .local yeterince iyi çalışıyordu, ama şimdi belli bir şirket tarafından iyi oynamayı reddeden bir şekilde önlendi. Gerçekten .lan veya .internal gibi resmen bu amaç için ayrılmış bir şey görmek isterdim, ama o zamana kadar bu en iyi seçenek.

— Joel Coel

6

@Joel Coel ile aynı fikirdesin, sen bir kiracısın, daha fazlası değil. Dahili kullanım için yalnızca halka açık olarak geçersiz sayılan ve halka açık ağlar tarafından erişilemeyen iki ayrılmış TLD adı olmalıdır. Bir isim dahili ev kullanımı için, ikinci isim dahili iş kullanımı için olacaktır. Her ikisi de aynı şekilde "özel TLD'ler" olarak kabul edilir ve aynı şekilde yönlendirilemeyen "özel alt ağlarımız" vardır (192.168.xx ve ilk). Bu, ev kullanıcılarının .local ve mDNS'ye zorlanmaktan başka bir şey yapmasını sağlar. Etki alanı olmayan bir NAT arkasında dahili bir LAN çalıştıran küçük işletmeler için aynen.

— Avery Payne

49

İnternette bulunması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 DNS adlarını dahili DNS sunucularınızda barındırın.) Hayali Örnek Corporation için bazı örnekler.

İnternete bakan sunucular:
www.example.com
mail.example.com
dns1.example.com

Dahili makineler:
dc1.corp.example.com
dns1.corp.example.com
istemcisi1.corp.example.com

Bu alt etki alanının dahili şirket ağındaki makineleri tanımladığını belirtmek için "corp" kullandım, ancak burada "internal" gibi bir şey kullanabilirsiniz: client1.internal.example.com.

Ayrıca, DNS bölgelerinin ve alt etki alanlarının ağ numaralandırma planınızla aynı hizada olması gerekmediğini unutmayın. Örneğin, şirketim, her biri kendi alt ağına sahip 37 konum var, ancak tüm konumlar aynı (dahili) etki alanı adını kullanıyor. Bunun tersine, yalnızca bir veya birkaç alt ağa sahip olabilirsiniz, ancak makinelerinizi düzenlemenize yardımcı olacak birçok iç alan veya alt alan seviyeleri olabilir.

— Jay Michaud
kaynak

32

Dahili bir alt etki alanı kullanmanın başka bir avantajı var: akıllıca arama soneklerini ve FQDN yerine yalnızca ana bilgisayar adlarını kullanarak, hem 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ın.

Geliştirme sunucusunda, arama sonekini "dev.example.com" => kullanılan veritabanı sunucusuna ayarlayın: dbserv1.dev.example.com

QA sunucusunda, arama sonekini "qa.example.com" => kullanılan veritabanı sunucusuna ayarlayın: dbserv1.qa.example.com

Ve üretim sunucusunda, arama sonekini kullanılan "example.com" => veritabanı sunucusuna ayarlayın: dbserv1.example.com

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

— geewiz
kaynak

2

Bu mükemmel.

— Chris Magnuson

19

Birisi iş istasyonunu bir sorunu test etmek için üretim arama sonekiyle yanlış bir şekilde yapılandırana ve daha sonra istemeden bir sürü üretim kaydını günceller.

— Joel Coel

1

Bu oldukça ham, SRV kayıtlarının ayrıştırılması çok basittir ve aynı db sunucusu birkaç bölgeye hizmet verecek şekilde herhangi bir bölgeye yerleştirilebilir. Bu durumda, bir miktar kod yapılandırma dosyalarınızdaki değeri dolduruyor olacaktır. Ve veritabanının adını SRV anahtarı olarak ve elbette ana bilgisayar adına işaret eden değeri kullanabilirsiniz. Asla arama eklerine güvenmem. Ayrıca TXT kayıtlarıyla oldukça yaratıcı olabilirsiniz ve bunları sırlarsa aes-256 şifreli (daha sonra base64 ile kodlanmış) değerlerle doldurabilirsiniz. Her tür şey için TXT kayıtlarını kullanabilirsiniz.

— figtrap,

bakın, ancak istediğim şey example.com, example.dev ve example.stg. Son 2 tanesi yalnızca özel bir ağda, sıfır yapılandırma erişimi için yerel bir DNS sunucusu kurabilir miyim? Yine de tüm siteler için benzer bir konfigürasyon kullanıyor, sadece tld'ye kadar değişiklikleri taşımak. Bir ana bilgisayar dosyası ile .dev için kolay, ama sıfır yapılandırma ...

— DigitalDesignDj

14

Bu sorunun önceki cevapları yazıldığı için, rehberliği bir şekilde değiştiren birkaç RFC vardı. RFC 6761 , özel ağlara özel rehberlik sağlamadan özel kullanım alan adlarını tartışır. RFC 6762 hala kayıtlı olmayan TLD'lerin kullanılmamasını önerir, ancak yine de yapılacak vakaların olduğunu da kabul eder. Yaygın olarak kullanılan .local Ç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:

intranet
iç
özel
corp
ev
lan

IANA her iki RFC'yi de tanıyor gibi gözüküyor, ancak (şu anda) Ek G'de listelenen adları içermiyor.

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

— blihp
kaynak

Ek G'de teklif ettiğiniz listeden önce: "Kayıtlı olmayan üst düzey alan adlarının kullanılmasını önermiyoruz". Bu daha çok anahtar nokta. Verilen isimler "kullanılması" tavsiye edilmezler, sadece .localEk G

— Patrick Mevzek

2

Katılmıyorum. Buradaki kilit nokta, tavsiyenin saçmalıklarıdır: 'yapma ... ama yaptığın zaman ...' Ev / küçük işletme / halka açık olmayan ağların TLD'ye kaydolması beklentisi gerçekçi değildir. İnsanlar , herkese yardımcı olmak için kayıt dışı TLD'leri daha iyi kullanacaklar ve 'Tamam, işte dahili olarak kullanabileceğiniz kayıtsız TLD'lerin bir listesi' diyerek herkesin zorlu tavsiyelere uyduğunu iddia etmek yerine kullanacaklar.

— blihp

O zaman anlaşmazlık içinde kalacağız. Bazı kişilerin TLD'yi içlerinde olduğu gibi kullanması (örneğin .MAIL birçok belgede bulundu), bu TLD'lerin delege edilmesinin mümkün olmamasının ve şimdi de süresiz olarak ölmelerinin sebebidir. Bu nedenle, insanlara TLD'leri bu şekilde kullanmalarını tavsiye etmeye devam etmek, küresel İnternet topluluğuna bir olumsuzluktur. Tavsiye, bazı TLD'lerin zaten bu şekilde kötüye kullanıldığı için, insanların kötüye kullanılması durumunda yenilerini kötüye kullanmak yerine bunları yeniden kullanmaları gerektiğini söylüyor. RFC2606, TLD'lerin işe yarayacak dahili olarak kullanması için açık:.EXAMPLE .TEST .INVALID

— Patrick Mevzek

12

Daha önce de söylediğim gibi, özel ağınız için kayıt dışı bir TLD kullanmamalısınız. Özellikle şimdi ICANN hemen hemen herkesin yeni TLD'leri kaydetmesine izin veriyor. Daha sonra gerçek bir alan adı kullanmalısınız

Diğer taraftan, RFC 1918 açıktır:

Bu tür adreslere dolaylı referanslar işletme içinde yer almalı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 üzerinden iletilmesini önlemek için görünümleri de kullanmalıdır.

— Benoit
kaynak

10

Ana bilgisayarların sanal adlandırmalarında fiziksel olarak hiçbir fark gözetmediğimizi düşünüyoruz - aslında, ana bilgisayar yapılandırmasını (yazılımı) fiziksel katmandan soyutlamak için aldık.

Bu yüzden, Donanım Öğeleri satın alıyoruz 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 makine bulunduğunda, DNS belirleyici faktör olmamalıdır - makineler bir alandan diğerine geçtikçe - örneğin düşük performanslı bir webapp'ın pahalı CPU döngüleri tüketmesine gerek kalmaz - sanallaştırın ve adlandırma düzenini korur, her şey çalışmaya devam eder.

— Mike Fiedler
kaynak

-4

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

Kullanmamaya karar vermen gereken bazı TLD'ler olduğunu biliyorum, ama bunların dışında bunun çok katı olduğunu sanmıyorum.

Kimlik doğrulama kaynağını TLD olarak kullanacakları daha büyük bir şirkette çalıştım, yani eğer bir MS / Windows sunucusu olsaydı, Active Directory'yi kimlik doğrulama kaynağı olarak kullanıyorsa, olur .adve diğerleri de olur .ldap(Neden onlar değildi? sadece aynı kaynağı mı kullanıyorsunuz ya da aynı dizin hizmetinden kopyalayan sunucular mı? Bilmiyorum, oraya vardığımda öyleydi)

İyi şanslar

— Justin
kaynak

2

Amazon şimdi .awsbir TLD olarak kayıt yaptırdı , bu yüzden sonunda problemleri görmeye başlayabilirsiniz: nic.aws

— Mark McKinstry

1

Bilgi için .aws son zamanlarda "25 Mart 2016" => newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

Sahte bir TLD kullanmanın çok büyük bir şey olduğunu düşünmemekle birlikte, en azından bütün sistem kapalıysa ve internet üzerinden iletişim kurmak için bir proxy kullanıyorsanız, ".aws" siz olmadıkça kötü bir seçimdir. AWS degilsin! Artık AWS ile iletişim kuramayacağınız akla gelebilecek çok fazla senaryo var.

— figtrap