Bu Konu Neden Önemli?
DNS isim çözümleme, DHCP ise dinamik IP dağıtımı sağlar; dinamik DNS güncellemeleri kullanıldığında iki servis arasındaki yetki ve kayıt yaşam döngüsü dikkatle yönetilmelidir.
Karar Verirken Kontrol Edilecek Noktalar
Forward ve reverse zone tasarımını birlikte yapın.
Dynamic update yetkilerini sınırlandırın.
Eski/stale kayıt temizleme politikasını tanımlayın.
DHCP lease süresini cihaz davranışına göre ayarlayın.
Mimari ve çalışma modeli
DHCP adres dağıtır; DNS isimleri adreslere çözer. Dinamik güncellemede kaydı istemci veya DHCP sunucusu oluşturabilir; kayıt sahipliği ve güvenli update yetkisi önemlidir. Lease bitişi ile DNS kayıt temizliği aynı anda olmak zorunda değildir. A/PTR uyumu ve stale kayıtlar özellikle adres yeniden kullanıldığında incelenmelidir.
- 1DHCP lease
- 2Yetkili DNS update
- 3A ve PTR kaydı
- 4Yenileme ve temizleme
Tasarım parametreleri
- Dinamik kayıt yetkisi
- DNS kaydını hangi kimliğin oluşturduğunu ve yenilediğini belirleyin; DHCP lease kaydı tek başına DNS güncellemesi değildir.
- TTL ve temizleme
- Lease süresi, DNS TTL ve aging/scavenging farklı saatlerdir; temizlemeyi gerçek yenileme davranışıyla planlayın.
- Adres ve yönlendirme
- Subnet, gateway, route ve NAT kapsamını çizimde ayrı gösterin. DNS cevabı ile hedef IP’ye gerçek yolu birlikte doğrulayın.
- Yedek yol
- Yedek bağlantının aynı cihaz, enerji veya operatör arızasını paylaşmadığını kontrol edin. Geçiş süresini uygulama üzerinden ölçün.
- Taşıma kapasitesi
- Port hızı, uplink yoğunluğu, paket kaybı ve kuyrukları birlikte değerlendirin. Tek bir test akışı bütün kapasiteyi temsil etmeyebilir.
- İşletim görünürlüğü
- Arayüz sayaçları, komşuluklar, hata kayıtları ve zaman senkronizasyonunu izleyin. Normal davranış için başlangıç ölçümü tutun.
Hesap ve uygulama örneği
Örnek istemci IP’si değiştirildiğinde forward ve reverse cevapları kontrol edilir. Eski lease ve kayıt kalıntısının başka cihazı yanlış isimle göstermediği sınanır. Statik sunucu kayıtlarını dinamik temizleme kapsamından yanlışlıkla silmemek için kayıt türlerini ayırın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| IP doğru, isim eski adrese gidiyor | Eski cache veya yenilenmemiş A/PTR kaydı olabilir. | Yetkili DNS cevabı ile istemci cacheini ve güncelleme kaydını karşılaştırın. |
| Aynı VLAN çalışıyor, uzak ağ çalışmıyor | Gateway, route, ACL veya dönüş yolu farklı olabilir. | Kaynak ve hedef tarafında adres, route ve politika kayıtlarını karşılaştırın. |
| Küçük istek çalışıyor, büyük aktarım duruyor | MTU, paket kaybı veya hedef depolama beklemesi olası ayrımlardır. | Paket boyutu ve yeniden iletimleri ölçün; ağ sorununu disk beklemesinden ayırın. |
| Yedek bağlantı var ama kesinti uzun | Algılama, yeniden yakınsama, DNS veya oturum yenilenmesi süreyi büyütebilir. | Arıza zamanını ve ilk başarılı uygulama işlemini aynı saatle kaydedin. |
Kabul ve doğrulama kontrolleri
- IP değişikliği sonrasında kayıt sahipliği, TTL ve eski kayıt temizliğini doğrulayın.
- İzin verilen ve engellenen ağ çiftleri için erişim matrisi test edin.
- Tek bağlantı ve tek cihaz arızalarını ayrı uygulayın.
- Yoğun yükte kayıp, gecikme ve kuyruk sayaçlarını kaydedin.
- Değişiklik öncesi yapılandırma ve geri dönüş adımını saklayın.
- Yönetim erişiminin kullanıcı ağından gerektiği gibi ayrıldığını doğrulayın.
İlgili kavramlar
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun