İki şube, tek özel DNS bölgesi: kayıtlar kime ait?

Yeşil şubeye bir ana makine eklersiniz, yeşil kullanıcılar için çözümlenir ve sarı ofis hâlâ NXDOMAIN alır. Bu bir VPN arızası da bozuk çözümleyici de değildir; özel bölge içindeki bir sahiplik boşluğudur. Bağımsız olarak düzenlenen iki kayıt listesi, yalnızca şubeler birbirine ulaşabildiği için tek bölge olmaz. Çözüm bir yayımlama planıdır, bir başka güvenlik duvarı kuralı değil.

Belirti, eksik sahibi adlandırır

Her şubede muhtemelen bir ad gerektiğinde birinin eklediği yerel geçersiz kılma, bir Pi-hole girdisi veya bir dnsmasq satırı vardır. Yeşil kayıt yalnızca yeşil çözümleyicide bulunur, bu yüzden sarıdaki istemci kendi çözümleyicisine sorar ve dürüst bir "böyle bir ad yok" yanıtı alır. Eski yanıt farklı görünür: ana makine taşındı, bir şube kopyasını güncelledi ve diğeri hâlâ eski adresi döndürüyor.

İki örüntü de önbelleği boşaltarak uzun süre düzelmez. Yönlendiren çözümleyicinin önbelleği bir zamanlar aldığı yanıtın kopyasıdır, yeni adlar yayımlayan bir yetki değildir, bu yüzden bugün çalışan bir önbellek yarının ana makinesi hakkında hiçbir şey söylemez. BIND belgeleri birincil, ikincil, yinelemeli ve yönlendiren rollerini tam da bu nedenle ayrı ayrı açıklar.

Dolayısıyla tasarım sorusu dar ve yanıtlanabilir: bir kaydı kim oluşturabilir ve o kayıt, onun için yanıt vermesi gereken her çözümleyiciye nasıl ulaşır?

Seçenek A: ikincillerle tek yetkili bölge

internal.example.com için bir birincil çalıştırın ve desteklenen ikincillerin bölgeyi her şubede edinmesine izin verin. Her şubenin yinelemeli çözümleyicisi yerel ikincilsine sorar, böylece yanıtlar önbellekten değil yetkili bir kaynaktan gelir ve bir kez yapılan değişiklik yeniden yazılmak yerine aktarılır.

Bu düzen, ertelenmesi kolay ve atlanması pahalı açık kararlar gerektirir. Bölgeyi kim düzenleyebilir? Hangi sunucuların onu aktarmasına izin verilir ve hangi adresler üzerinden? Şubeler arasındaki tünel kapalıyken istemciler ne görmeli? İkincil, son kopyasından yanıt vermeye devam eder ki bu genellikle istenen davranıştır, ancak bu açıklanmış bir seçim olmalıdır, kesinti sırasında bir sürpriz değil.

Bölge aktarımlarını adrese göre bilinen ikincillerle sınırlayın ve uygulamanın desteklediği yerlerde işlem imzalarını kullanın. Açık aktarım, bağlantı noktasına ulaşabilen herkes için iç ad alanınızın bir kopyasıdır.

Bedel koordinasyondur: tek düzenleme yolu, tek değişiklik incelemesi ve bir kayıt yanlış olduğunda kimin nöbette olduğuna dair ortak anlayış.

Seçenek B: her şube için bir alt alan adı

green.internal.example.com yeşil şubeye, yellow.internal.example.com sarı şubeye devredin. Her şube kendi adları için yetkili olur ve üst bölge yalnızca devir kayıtlarını taşır. Tek bir dosya üzerindeki çekişme ortadan kalkar ve yerel bir ekip merkezi bir değişikliği beklemeden ana makine ekleyebilir.

Devir, üst bölgede bulunmalı ve şubenin yetkili sunucularına işaret eden NS kayıtları içermelidir. Tam devir pratik olmadığında alt alan adı için koşullu yönlendirme geçerli bir alternatiftir, ancak bu bir çözümleyici ayarıdır, yayımlanmış bir gerçek değildir, bu yüzden her çözümleyici aynı kurala ihtiyaç duyar.

Bedel kaybolmak yerine yer değiştirir: üst bölgenin hâlâ bir sahibi olmalı ve yeni bir şube oluşturmak artık bir değil iki yerde değişikliktir.

Her çözümleyici seçimi izlesin

İstemcilere onaylanmış çözümleyiciyi ve arama alan adını desteklenen yapılandırmaları üzerinden verin ve şundan emin olun: çözümleyicinin sorgulaması gereken her uzak DNS sunucusuna izin verilmiş bir VPN yolu vardır. Uygulamaların da bu yanıtların döndürdüğü özel adreslere yollara ihtiyacı vardır, çünkü yolu olmayan doğru bir ad hâlâ kopuk bir bağlantıdır.

Pi-hole yerel çözümleme sağlıyorsa hangi kayıtlara sahip olduğunu ve hangi sorguları ilettiğini yazın. Bağımsız olarak düzenlenen iki Pi-hole listesi hâlâ çoğaltılmaz. Pi-hole v6'da özel dnsmasq satırları TOML, CLI veya ortam değişkenleri gibi ana makine tarafı seçeneklerle ayarlanır ve API üzerinden açığa çıkarılmaz; /etc/dnsmasq.d/ dosyalarını yüklemek varsayılan olarak kapalı ayrı bir seçenektir.

Ardından her yerde görünmesi gereken bir adla iki taraftan da test edin:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA yanıtı, sarı çözümleyicinin kendini yetkili sayıp saymadığını, bir ikincile mi sorduğunu yoksa yalnızca ilettiğini mi söyler. Bunlar farklı arıza biçimlerine sahip farklı tasarımlardır ve yanıt genellikle gerçekte hangisini kurduğunuzu belirtir.

Üç kabul durumuyla bitirin: her şubeden bir ad, bir saat içinde değiştirilmiş bir kayıt ve şubeler arası bağlantının kullanılamaması. Yalnızca ilkini geçen bir tasarımın kâğıt üzerinde yayımlama planı ve üretimde yerel geçersiz kılması vardır.