Mühendisliğin kendi DNS bölgesi, delegesi veya alt etki alanı olmalı mı?

Kuruluşumuzun birincil alan adımız (AD ile) example.com var. Geçmişte, önceki yöneticiler dmn.com, lab.example.com, dmn-geo.com vb. Gibi çeşitli bölgeler ve bunların hepsi farklı mühendislik grupları için olan alt alan adları ve delegeler oluşturmuşlardır. Şu anda DNS'miz biraz karışık. Ve elbette bu, example.com'daki bir iş istasyonundaki birisinin bu diğer bölgelerden / alt alanlardan herhangi birindeki bir sisteme bağlanması gerektiğinde veya bunun tersi olduğunda (kısmen bölge aktarımı ve temsilci seçme çoğu için düzgün yapılandırılmadığı için) sorunlara neden olur. .

Üretim DNS'imiz Active Directory ile entegredir, ancak mühendislik sistemleri AD'den izole edilmelidir.

DNS'yi yeniden düzenlemenin ve tüm bu farklı girişleri birleştirmenin yollarını tartışıyoruz. Alabileceğimiz üç farklı yol görüyorum:

• Yeni bir bölge oluşturun, yani 'dmn.eng'. Bu, DNS sunucularımız kullanılarak BT tarafından veya ad sunucularını kullanarak mühendislik yoluyla yönetilebilir.
• Eng.example.com adlı yeni bir temsilci oluşturun, mühendislik DNS'sini bu alt etki alanında birleştirin ve mühendislerin temsilci için ad sunucusunu yönetmesine izin verin.
• Temsilci olmadan yeni bir alt etki alanı eng.example.com oluşturun ve alt etki alanı için DNS'yi kendimiz yönetin.

Bir delege alt etki alanı oluşturmayı ve mühendislerin bu alt etki alanı içinde kendi DNS yapıları üzerinde tam denetime sahip olmasını sağlamayı tercih ediyorum. Avantajı, DNS'leri çalışmazsa, büyük olasılıkla benim hatam değildir;). Bununla birlikte, bir şey işe yaramadığında sorumluluk konusunda hala bir belirsizlik vardır ve bunun kurulması, yapılandırılması ve yönetilmesi için mühendislik ile koordinasyon gerektirecektir.

Alt alan için temsilci seçmezsek, üretim BT'si üretim dışı DNS'yi ele almak için çok daha fazla iş anlamına gelir (ki aslında zaten çok şey yapıyoruz). Avantajı, tüm DNS üzerinde tam kontrole sahip olmamız ve bir şey çalışmadığında, kimin sorumluluğunu düzelteceğine dair şüphe yoktur. Ayrıca mühendisliğe ihtiyaç duyduklarında daha fazla esneklik ve kontrol sağlamak için geo.eng.example.com gibi delegeler de ekleyebiliriz.

Yeni bir bölge yaratmanın gerekliliği veya yararları konusunda gerçekten emin değilim, dmn.eng.

Peki bu gibi durumlar için sektördeki en iyi uygulamalar ve öneriler nelerdir? Mühendislik ve üretim arasında sorunsuz isim çözümlemesi uygulamak ve sağlamak için en basit çözüm hangisidir? Eksik olabileceğim her çözümün bazı potansiyel faydaları veya tuzakları nelerdir?

Biraz daha bilgi eklemek için oldukça büyük bir üretim şirketiyiz. Bu mühendisler Ar-Ge, Geliştirme ve Kalite Güvencesi alanlarında çalışmaktadır. Laboratuvarların sıklıkla kendi alt ağları veya tüm ağları, DHCP, vb. Vardır. Organizasyon ve teknoloji ile ilgili olarak, kendi küçük dünyalarıdır.

Üretim ortamımızı korumak için mühendislik laboratuarları ve ağları için bir miktar ağ yalıtımı sağlamak istiyoruz ( önceki bir soruya bakın) mühendislik DHCP sunucularını yetkili AD DHCP sunucuları olarak ekleyen ve gerçekleşmemesi gereken mühendislerle ilgili ). Ancak, laboratuardaki bir iş istasyonundaki bir kullanıcının üretim ağımızdaki bir kaynağa erişmesi gerekir veya üretim ağımızdaki bir iş istasyonundaki bir kullanıcının bir laboratuar sistemine bağlanması gerekir ve bu, bir türü haklı çıkarmak için yeterli sıklıkta olur - birleştirilmiş DNS.

Mevcut delegelerin mühendislik tarafından yönetilen DNS sunucuları zaten vardır, ancak bu sunucuların kurulduğu farklı laboratuvarlardaki mühendisler arasında iletişim yoktur, bu nedenle en yaygın sorun alt etki alanları arasındaki ad çözümlemesinin başarısız olmasıdır. Mühendisler bu delege sunucularına sahip olduklarından, NS girişlerini birbirleriyle konuşmaları için düzeltemiyorum - dolayısıyla tamamen BT'ye ait olan temsilci olmayan DNS avantajı. Ancak üretim ve mühendislik için DNS'yi yönetmek , özellikle mühendislik günlük olarak DNS değişiklikleri yapabildiğinden, bir baş ağrısıdır. Ancak BigHomie'nin cevabında belirttiği gibi, bu muhtemelen mühendisliğin gerçek bir DNS yöneticisi kiralaması (veya ataması) anlamına gelir; ve o kişi ve ben oldukça iyi tanışmamız gerekecek.

Mutlaka üst düzey etki alanı adı veya son eki ile yeni bir bölge oluşturma fikrinden hoşlanmıyorum, ancak zaten keyfi isimleri olan 5 bölgemiz var, bu yüzden tek bir bölgeye konsolide olmak hala bir gelişme. Kuruluşlarındaki farklı gruplar için ayrı üst düzey bölgelere sahip başka şirketlerin var olduğunu biliyorum, bu yüzden bunun ne zaman uygun olduğunu ve bu yaklaşımın avantajlarının / dezavantajlarının ne olduğunu merak ediyorum.

Bilginize, sadece birkaç aydır bu şirkette bulundum ve önceki AD / DNS yöneticisi şirketten ayrıldı, bu yüzden mevcut DNS yapısının neden var olduğuna dair referans yapacak hiçbir şeyim yok.

Bugünün dünyasında, keyfi üst düzey alan adlarına sahip yeni bölgeler oluşturmanızı önermiyorum , çünkü bunlar herhangi bir zamanda "resmi dns" haline getirebilir.

Ben şahsen alt alan delegasyon senaryosunu tercih ederim, çünkü yapmaya çalıştığınız şeye uyuyor gibi görünüyor. (Birleştirin ancak mühendisliği kontrol edin)

Belki de mühendisliğin kayıt ekleyebileceği / kaldırabileceği MS DNS için bir web ön ucu bile bulabilirsiniz, böylece sunucunun kendisi hala üretim BT'sine aittir ve "yönettikleri" tek şey DNS girişleridir.

Her şeyden önce, emin olun kendi kullandığınız plan alanadı.tld (mit.edu). Bu internete asla bağlanmasa bile, mesele bu değildir.

En azından bir şekilde kuruluşla eşleşen dns hiyerarşisine sahip olmanın büyük faydaları var . Bunu sadece IT departmanı açısından o departmanı yönetecek biri / insanlar olduğunda gördüm. Bu, AD amaçları için ayrı bölgelere sahip olmakla ilgilidir. Web adresleri vb. Ayrı bir konudur ve bu konu için geçerli değildir. DNS hiyerarşisi için zor ve hızlı bir kuralım yok ya da bilmiyorum, inanıyorum ki kuruluşunuzun ihtiyaçları bunu dikte edecektir. Bazı bölgeler bir alt etki alanı (eng.mit.edu) gerektirebilir ve bazıları istemez (örneğin hr.mit.edu). Elbette, tutarlılık için yalnızca bir üst düzey alan olmalıdır .

Bununla birlikte, bir borcun bir alt alana ihtiyacı olup olmadığını belirleyen nedir? Bu iş istasyonları içinse, kendi BT destekleri veya böyle bir sistemi yönetebilen insanlar var mı? Değilse, bir makinenin belirli bir bölümde olduğunu belirtmek için bir dns bölgesi kullanmanın bir anlamı yoktur, işi iyi yapacak çok sayıda başka yöntem vardır. Bunlar sadece kendinize sormanız gereken sorular.

Her bir bölgeyi yeniden değerlendirir ve

1. Hala alakalı olsa bile. Hala o bölgedeki herhangi bir şeye işaret eden sunucular veya iş istasyonları var mı?

2. Yeni bölgeyi kim yönetecek. Bölgenin yeni hiyerarşinize taşınması gerekeceğini söylemeye gerek yok, ancak sadece bölge için bir yönlendirme adresi / ad sunucusu bilgisi mi uyguluyorsunuz yoksa bölgeyi aktif olarak mı yöneteceksiniz ?

Hangi sistemler AD'den 'izole edilmiştir'? Bunlar ağ kimlik doğrulaması ve / veya yönetimi gerektirmez mi? Onları DNS perspektifinden ayırmanın nedeni nedir? Şüphelerinizi doğrulamak için her şey yönetim kolaylığı ile ilgilidir. Mühendisliğin bu kadar dns yönetimine ihtiyacı varsa , kendilerine bir DNS yöneticisi almaları gerekir.

Güncellemenize dayanarak bilgi eklemek için kişisel olarak onlara kendi alt alan adlarını eng.spacelysprockets.comve alt ağlarını veririm . İzin verilen uygun trafik ile ağın geri kalanından güvenlik duvarı olmalıdır. Gitmek ve yaratmak istiyorlarsa eng.eng.localveya eng.bikesonları durduramıyorsanız, bunu desteklemeye zorlanmamalısınız *.

Eğer güzel oynarlarsa, alt bölgeyi kullanın ve koparmak istediklerine karar verin lab.eng.spacelysprockets.comve alt ağın bir kısmı, bu üzerlerinde. Muhtemelen bu trafiği bölümlere ayırabilmeniz için sizi bilgilendirmek profesyonel nezaket olmalıdır, ancak herkes böyle düşünmez.

Altyapınız için gerçek bir alan adı, yönetim konusunda size ciddi bir avantaj sağlayacaktır, bunu düşünmelisiniz.

* Sen ve yapacak mısın iki farklı şey olursun, ama ben araştırıyorum.