Google PCNE: Cloud DNS, Hizmet Keşfi ve Hibrit Ad Çözümlemesi — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network Engineer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Cloud DNS, Google Cloud’un hem genel yetkili bölgeleri (public authoritative zones) hem de VPC’ler için özel DNS’i (private DNS) destekleyen, ölçeklenebilir ve yüksek erişilebilirliğe sahip DNS hizmetidir. Ayrıca, şirket içi (on-premises) DNS ve çoklu bulut (multi-cloud) ile entegrasyon için yönlendirme (forwarding), eşleme (peering), gelen sunucular (inbound servers), yanıt politikaları (response policies) ve DNS politikaları gibi hibrit ad çözümleme temel bileşenlerini de sağlar. Bu bölüm; yetkili DNS yaşam döngüsünü, özel bölge (private-zone) görünürlüğünü ve paylaşımını, hibrit çözümlemeyi, hizmet keşfi (service discovery) desenlerini, güvenlik ve bütünlüğü (DNSSEC ve bölge transferleri dahil), yönlendirme politikalarıyla gelişmiş trafik yönetimini, özel hizmet uç noktaları (private service endpoints) için DNS’i ve sorun giderme, önbelleğe alma, günlükleme ve geçiş/birlikte var olma stratejileri gibi 2. gün operasyonlarını (day-2 operations) kapsamaktadır.

Yetkili DNS ve DNS Yaşam Döngüsü

Yönetilen bölgeler (managed zones) ve kayıtlar
- Yönetilen bölge (managed zone), tek bir DNS adı (zone apex) için kaynak kayıt kümelerini (RRsets) içeren bir kapsayıcıdır.
- Kayıt türleri: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (ve daha fazlası). Cloud DNS, zone apex’te CNAME’i desteklemez; apex eşlemesi için bir yük dengeleyicinin (load balancer) IP’si ile A/AAAA kullanın.
- Yaşam döngüsü: bölge oluşturma, kayıt ekleme/değiştirme (transactional değişiklikler), yayma (propagate) ve işletme (izleme/günlükleme/güvenliğini sağlama).
- Geçişi hızlandırmak için mevcut BIND dosyalarından içe aktarma:
  - Örnek: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Genel (public) ve özel (private) bölgeler
- Genel bölgelere, Google’ın genel yetkili ad sunucuları (public authoritative nameservers) aracılığıyla küresel olarak erişilebilir. Alan adı kayıt kuruluşunda (registrar), üst (parent) alandaki NS kayıtlarını güncelleyerek yetki devri yapın.
- Özel bölgeler yalnızca bağlı oldukları VPC ağları için yanıt verir. Bu VPC’lerdeki sanal makineler (instances) için Google’ın VPC kapsamlı çözümleyicileri (VPC-scoped resolvers) tarafından ve isteğe bağlı olarak gelen yönlendirme (inbound forwarding) aracılığıyla hibrit istemciler tarafından çözümlenirler.
Yayılma (propagation) ve TTL’ler
- Google Cloud içinde kayıt değişiklikleri saniyeler içinde etkinleşir; harici önbelleklerin geçersiz kılınması TTL’e bağlıdır.
- TTL ödünleşimleri: kısa TTL’ler çeviklik ve daha güvenli geçişler (cutover) sağlar ancak sorgu yükünü artırır ve önbellek verimliliğini düşürebilir; uzun TTL’ler yükü azaltır ancak eski (stale) yanıtların süresini uzatır. Yaygın uygulama: dinamik hizmetler için 60–300 saniye; kararlı kayıtlar için 600–3600 saniye. Geçişlerden önce, TTL’i 24–48 saat önceden düşürün.

Özel Bölge Görünürlüğü, VPC İlişkilendirmesi ve Projeler Arası Tasarım

Özel bölgeleri VPC’lere bağlama
- Bir özel bölge, açıkça bir veya daha fazla VPC ağıyla ilişkilendirilir. Bu ilişkilendirme, projeler arası olabilir (bölge üzerinde dns.admin gibi uygun IAM izinleri ve ağları bağlama izni ile).
- Öncelik: Bir VPC’ye bağlı özel bölgeler arasında en uzun sonek eşleşmesi (longest-suffix match) kazanır; özel bölgeleri çakıştırırken dikkatli olun (örneğin, svc.corp.internal. ve corp.internal.).
- VPC’ler arası paylaşım desenleri
  - Doğrudan bağlama (Direct attach): aynı özel bölgeyi birden fazla VPC’ye bağlayın. Operasyonel olarak basittir; etki alanını (blast radius) azaltmak için gereksiz yerlere bağlamaktan kaçının.
  - Shared VPC: alt ağların VPC’sini bölgelere bağlayarak DNS’i hizmet projelerine (service projects) açarken, DNS yönetimini ana projede (host project) merkezileştirin.
  - DNS eşleme bölgeleri (DNS peering zones): ağlar arasında VPC peering kullanıldığında, tüketici (consumer) VPC’deki bir eşleme bölgesi, bölgeleri kopyalamadan üretici (producer) VPC’den özel kayıtları çözümleyebilir.
Hata modları ve koruma mekanizmaları (guardrails)
- Gölgeleme (Shadowing): genel bir bölgeyle aynı ada sahip bir özel bölge, bağlı VPC’lerdeki istemcilerin özel yanıtları tercih etmesine neden olarak genel uç noktalara erişimi potansiyel olarak bozabilir. Split-horizon’u kasıtlı olarak kullanın, belgeleyin ve test edin.
- Aşırı bağlama (Over-attachment): bir özel bölgeyi geniş bir alana bağlamak, dahili adların sızmasına neden olabilir. En az ayrıcalık ilkesini (least privilege) izleyin ve kapsamı sınırlamak için ayrı alt alan adları (bölge/hizmet kapsamlı) kullanın.
- IAM ayrımı: ayrı yönetim alanları (admin domains) oluşturmak için DNS değiştirme haklarını (dns.admin) ağ bağlama haklarından (ağları bağlama izni) ayrı olarak devredin.

Kısa örnek: özel bir bölge oluşturma ve bağlama

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

Hibrit Ad Çözümlemesi: Yönlendirme, Eşleme ve Politikalar

Yönlendirme bölgeleri
- Belirli bir sonek (örneğin, onprem.corp.) için sorguları yetkili bir şekilde belirli ad sunucularına (şirket içi veya diğer bulutlar) yönlendirir. Bölgeyi Cloud DNS’te barındırmadığınız ancak GCP’den sorunsuz çözümleme ihtiyacınız olduğunda kullanılır.
- Döngülerden kaçının: şirket içi yönlendiricilerin aynı sonek için tekrar Cloud DNS’i işaret etmediğinden emin olun.
Eşleme bölgeleri
- Eşlenmiş bir VPC’de barındırılan özel bölgeleri çözümler. VPC eşleme bağlantısı gerektirir; geçişli (transitive) değildir. Özel DNS’i bir merkez (hub) VPC’de merkezileştirmek için hub-and-spoke tasarımlarında kullanılır.
DNS politikaları
- Giden yönlendirme: bir VPC’deki sanal makineler, Cloud DNS özel bölgelerinde çözümlenmeyen alan adları için özyinelemeli (recursive) sorguları şirket içi çözümleyicilere gönderir. Hedef ad sunucusu IP’lerinin Cloud VPN/Interconnect üzerinden erişilebilir olduğu bir DNS politikası aracılığıyla yapılandırılır.
- Gelen sunucular: şirket içi çözümleyiciler, Cloud DNS özel bölgelerini çözümlemek için sorguları Google tarafından sağlanan gelen yönlendirme IP’lerine (otomatik olarak atanan 35.199.192.0/20) yönlendirir. GCP özel DNS’ini şirket içine ve diğer bulutlara genişletmek için kullanılır.
- Sorgu günlük kaydı: analiz ve sorun giderme için çözümleyici sorgu günlüklerini Cloud Logging’e göndermek üzere politika düzeyinde etkinleştirilir. Genel bölgeler için, yetkili sorgular için bölge başına sorgu günlük kaydını etkinleştirin.
Yanıt politikaları
- Yanıtları değiştirmek için kurallar tanımlar (örneğin, bilinen kötü amaçlı alan adları için NXDOMAIN döndürmek veya genel yanıtları geçersiz kılmak için dahili A kayıtları sentezlemek). Dikkatli uygulayın; kritik üçüncü taraf alan adlarının istemeden engellenmediğini doğrulayın.
Bağlantı önkoşulları
- Giden/gelen yönlendirmenin çalışması için, hibrit bağlantının (Cloud VPN veya Interconnect) ve güvenlik duvarı kurallarının gerektiği gibi her iki yönde de UDP/TCP 53’e izin verdiğinden emin olun. EDNS0 ve UDP parçalanma davranışı ağlar arasında farklılık gösterir—MTU sorunları ortaya çıkarsa, TCP geri düşüşüne (fallback) izin verin ve şirket içi çözümleyicilerde EDNS(0) arabellek ayarlamasını (buffer tuning) göz önünde bulundurun.
Yaygın tuzaklar
- Asimetrik erişilebilirlik: giden yönlendirme şirket içi çözümleyicileri işaret ediyor ancak geri dönüş trafiği güvenlik duvarı veya yönlendirme asimetrisi tarafından engelleniyorsa, sorgular zaman aşımına uğrar. Cloud Router’ın öğrendiği rotaları doğrulayın ve DNS yanıt akışlarına izin verin.
- Bölünmüş sonekler: çakışan kurumsal sonekler (corp.local vs corp.internal) beklenmedik çözümleyici arama yolu (search-path) eşleşmelerine neden olabilir. Arama yollarını ve sonek sahipliğini standartlaştırın.

Kısa örnekler:

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

Hizmet Keşfi, Split-Horizon ve Özel Uç Noktalar

Split-horizon DNS
- Aynı ad için dahili ve harici olarak farklı yanıtlar sunar. Tipik model: genel foo.example.com, genel bir Anycast IP’ye çözümlenir; dahili foo.example.com, bir ILB’nin RFC1918 adresine çözümlenir. Aynı ada sahip bir genel bölge ve bir özel bölge ile uygulanır, özel bölge dikkatlice uygun VPC’lerle sınırlandırılır.
Dahili hizmet adlandırması
- Tutarlı dahili sonekler (örneğin, svc.corp.internal) ve hizmet odaklı kayıtlar (A/AAAA, SRV veya keşfe özgü TXT) kullanın. Dinamik olarak ölçeklenen hizmetler için düşük TTL değerleri tutun.
- GKE hizmet keşfi: küme içi adlar CoreDNS içinde kalır (svc.cluster.local). Ad alanları/VPC’ler arası erişim için, ILB VIP’lerini Cloud DNS özel bölgelerinde yayınlayın veya Service Directory entegrasyonunu kullanın.
Service Directory entegrasyonu
- Service Directory ve Cloud DNS aracılığıyla hizmet uç noktalarını DNS’e otomatik olarak yayınlayarak ad alanı/hizmet başına SRV ve A kayıtları oluşturur. Üreticileri ve tüketicileri birbirinden ayırmak ve hizmet örneklerinin sağlık durumuna duyarlı keşfini desteklemek için kullanışlıdır.
Özel hizmet uç noktaları
- Google API’lerine Private Service Connect (PSC): PSC uç noktalarını kullanarak googleapis.com’u özel olarak yönlendirin veya googleapis.com için özel bir bölge ile Kısıtlanmış Google API’leri VIP’lerini (199.36.153.8/30) kullanın. PSC, uç nokta başına kontrol ile bölgesel olarak yerel, özel IP bağlantısı sağlar; Kısıtlanmış VIP daha basittir ancak yine de varsayılan rotalar üzerinden erişilebilen genel IP aralıklarını kullanır.
- Üretici hizmetlerine PSC: özel bir bölgede PSC uç noktasına veya ILB VIP’sine işaret eden A/AAAA kayıtları oluşturun. Özel dahili alan adları için, özel bölgeyi Cloud DNS’te yönetin ve tüketici VPC’lerine ekleyin.
Artılar ve eksiler
- PSC vs Kısıtlanmış VIP: PSC, ayrıntılı kontrol sunar ve giden denetim yollarından kaçınır; bölge başına uç nokta/DNS kurulumu gerektirir. Kısıtlanmış VIP’nin dağıtımı hızlıdır ancak paylaşılan VIP’ler kullanır ve giden yönlendirme politikalarıyla etkileşime girebilir.
- Split-horizon riski: yanlış kapsamlandırılmış özel bölgeler, genel SaaS’a erişimi karartabilir (black-hole). Geniş çaplı dağıtımdan önce kanarya (canary) VM’ler ve sorgu günlük kaydı aracılığıyla doğrulayın.

Kısa örnek: dahili ILB eşlemesi

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

Güvenlik, Trafik Yönetimi, Operasyonlar ve Taşıma

DNSSEC ve bütünlük
- Herkese açık bölgeler: Sahtekarlığa (spoofing) ve önbellek zehirlenmesine (cache poisoning) karşı koruma sağlamak için Cloud DNS’te DNSSEC imzalamayı etkinleştirin ve kayıt kuruluşunda (registrar) DS kaydını yayınlayın. Anahtar devri pencerelerini planlayın ve doğrulama hatalarını izleyin.
- Özel bölgeler: Çözümleme güvenilir ağlar üzerinden gerçekleştiği için DNSSEC doğrulama/imzalama genellikle gereksizdir; aktarım güvenliğine (hibrit bağlantılar) ve çözümleyici (resolver) sağlamlaştırmasına odaklanın.
Yönetilen bölge transferleri
- Cloud DNS, AXFR/IXFR için birincil (primary) veya ikincil (secondary) olarak hareket edebilir. Transferleri doğrulamak/yetkilendirmek için TSIG ve zamanında yayılım için NOTIFY kullanın. Bölge transferi desenleri, taşıma sırasında birlikte var olmayı basitleştirir ve yasal veya dayanıklılık ihtiyaçları için şirket içi ikincil sunucuları destekler.
- Hata modları: transferin güvenlik duvarları tarafından engellenmesi, TSIG anahtar uyuşmazlığı, SOA seri numarasının artırılmaması veya birincil sunucuda IXFR’nin devre dışı bırakılarak tam AXFR’lere neden olması.
Yönlendirme politikaları ve sağlık kontrolleri
- Cloud DNS, trafik yönlendirme politikalarını (ağırlıklı, coğrafi, gecikme ve yük devretme) destekler. Sağlıksız yanıtları otomatik olarak geri çekmek için uç noktalara (endpoints) sağlık kontrolleri ekleyin.
- Tasarım ipuçları: politika hedefi başına kayıt kümelerini küçük tutun; kullanıcı ayak iziyle uyumlu bölgesel kapsamlandırmayı tercih edin; yük devretme süresini sınırlamak için düşük TTL’leri hata algılama aralıklarıyla birleştirin.
- Potansiyel sorunlar: aşırı ayrıntılı coğrafi haritalar operasyonel karmaşıklığa neden olabilir; tutarlı bir sağlık sinyalinin olmaması dalgalanmaya (flapping) yol açar—uygulama davranışıyla uyumlu stabilizasyon eşikleri ve sağlık kontrolü zaman aşımları kullanın.
Sorun giderme
- Araçlar: zincirleri doğrulamak için +trace, +short ve +dnssec ile dig/nslookup; çözümleyici sorgu günlükleri (DNS politikaları) ve yetkili sorgu günlükleri (yönetilen bölgeler) için Cloud Logging’i inceleyin.
- Önbelleğe alma: hangi çözümleyiciyi test ettiğinizi doğrulayın (VM’in /etc/resolv.conf dosyası genellikle Google’ın VPC çözümleyicisine işaret eder). TTL değişikliklerini test ederken yerel çözümleyici önbelleklerini temizleyin. Negatif önbelleğe almayı (RFC 2308) göz önünde bulundurun: NXDOMAIN yanıtları, SOA MINIMUM/negatif TTL başına önbelleğe alınır.
- Yaygın sorunlar: giden yönlendirme (outbound forwarding) ile şirket içi koşullu yönlendiriciler (conditional forwarders) arasındaki döngüler; kesilmiş (truncated) yanıtlara neden olan engellenmiş UDP 53 veya MTU sorunları; herkese açık bölgelerin özel bölgeler tarafından gölgelenmesi.
Operasyonel desenler
- Değişiklik kontrolü: değişiklikleri işlemlerle (transactions) toplu olarak yapın, geçişlerden (cutovers) önce TTL’leri azaltın ve görünürlüğü doğrulamak için kanarya VPC bağlantısı (canary VPC attachment) kullanın.
- Günlük kaydı ve izleme: sorgu günlüğünü seçici olarak etkinleştirin; eğilim analizi için günlükleri BigQuery’ye aktarın ve SERVFAIL/NXDOMAIN artışları için uyarılar oluşturun.
- Erişim kontrolü: kayıt değiştirme rollerini ağ bağlantı rollerinden ayırın; istenmeyen alan adı engellemelerinden kaçınmak için yanıt politikası düzenleyicilerinde (response-policy editors) en az ayrıcalık ilkesini uygulayın.
Taşıma ve birlikte var olma
- Birlikte var olma: Şirket içi DNS birincil kalırken, Cloud DNS’i AXFR/IXFR aracılığıyla ikincil olarak kurun; veya tam tersi (Cloud DNS birincil, şirket içi ikincil sunucular). TSIG ve izin listesi (allow-listing) kullanın.
- Koşullu yönlendirme: Şirket içinde kalmaya devam eden alan adları için yönlendirme bölgeleri (forwarding zones) veya giden yönlendirme politikaları (outbound forwarding policies) oluşturun. Hibrit bağlantıların yüksek oranda erişilebilir olduğundan emin olun (farklı eşlere (peers) ve Cloud Router’a sahip çift VPN).
- Çoklu organizasyon köprülemesi: VPC’leri Cloud VPN/Cloud Router aracılığıyla bağlayın, uygun şekilde karşılıklı koşullu yönlendirme veya eşleme (peering) kurun ve yeniden barındırılan (rehomed) bölgeler için bölge transferlerini kullanın. Kayıt kuruluşu (registrar) NS veya DS değişikliklerinden çok önce TTL’leri düşürün.

Kısa örnekler:

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

Pratik Problem Senaryosu

Contoso Retail ve Fabrikam Payments, ağları ve DNS’i minimum kesinti süresiyle entegre ederken bir yıl boyunca birlikte çalışması gereken iki ayrı Google Cloud organizasyonudur. Her organizasyon çakışmayan 10.0.0.0/8 alanını kullanır. Contoso, dahili hizmetleri svc.contoso.internal altında barındıracak; Fabrikam ise pay.fabrikam.internal’ı şirket içinde barındırmaya devam edecektir. Her iki tarafın da birbirlerinin özel adlarını çözümlemesi ve bazı bölgeleri kademeli olarak Cloud DNS’e taşıması gerekmektedir.

Yaklaşım:

Dayanıklı hibrit bağlantı kurun
- Contoso’nun merkez VPC’si ile Fabrikam’ın şirket içi yönlendiricileri arasında, her biri farklı bir Fabrikam genel IP’sine gidecek şekilde iki Cloud VPN tüneli oluşturun ve her iki tünelde de Cloud Router BGP kullanın.
- Gerekçe: Çift tünel ve dinamik yönlendirme, yol yedekliliği sağlar ve DNS hedefleri için rotaları otomatik olarak yayarak UDP/TCP 53 için asimetrik yönlendirme risklerini azaltır.
Her iki yönde de koşullu ad çözümlemesi uygulayın
- Contoso’da, Fabrikam’ın şirket içi DNS sunucularına (örneğin, 172.20.10.53 ve 172.20.11.53) yönlendirme yapan bir fabrikam.internal yönlendirme bölgesi (forwarding zone) oluşturun ve bunu uygulama VPC’lerine bağlayın.
- Fabrikam’da, şirket içi DNS üzerinde, svc.contoso.internal’ı bir Cloud DNS gelen politikası (inbound policy) tarafından sağlanan Contoso’nun Cloud DNS gelen yönlendirme IP’lerine yönlendirmek için koşullu yönlendiriciler (conditional forwarders) yapılandırın.
- Gerekçe: Yönlendirme bölgeleri, yetki tekrarını önler ve her iki tarafın da DNS’ini mevcut yerinde tutmasına olanak tanır. Gelen sunucular, çözümleyicilerini geniş çapta değiştirmeden Cloud DNS özel çözümlemesini Fabrikam’a genişletir.
Yönlendirme döngülerine karşı koruma sağlayın ve görünürlük sınırlarını uygulayın
- Fabrikam’ın koşullu yönlendiricilerinin, Fabrikam’ın hala sahibi olduğu adlar için contoso.internal’ı Contoso’ya geri yönlendirmediğinden emin olun; benzer şekilde, Contoso da yalnızca fabrikam.internal’ı yönlendirmelidir.
- Contoso’nun özel bölgelerini yalnızca onlara ihtiyaç duyan VPC’lere bağlayın; patlama yarıçapını (blast radius) azaltmak için genel olarak bağlamayın.
- Gerekçe: DNS özyineleme (recursion) döngülerini ortadan kaldırır ve özel bölgelerin herkese açık alan adlarını gölgelemesini (shadowing) önler.
Yönetilen bölge transferlerini kullanarak paylaşılan bir bölgeyi taşıyın
- Şu anda Fabrikam’ın BIND birincil sunucusunda barındırılan eski bir paylaşılan bölge olan legacy.shared.internal için, Cloud DNS’i TSIG ile ikincil (secondary) olarak yapılandırın ve AXFR/IXFR için Fabrikam’ın birincil sunucusunu izin listesine (allow-list) ekleyin. Birlikte var olma dönemi boyunca Fabrikam’ı birincil olarak tutun.
- Gerekçe: İkincil mod, istemcileri değiştirmeden canlı senkronizasyon sağlar. Tek bir doğruluk kaynağını korurken Contoso’da güvenli doğrulamayı mümkün kılar.
Dışarıya açık hizmetler için split-horizon uygulayın
- Müşteriler için genel bir HTTPS yük dengeleyici IP’sine işaret eden kayıtlara sahip bir contoso.example herkese açık bölgesi oluşturun. Aynı adları dahili ILB adreslerine eşleyen, dahili VPC’lere bağlı, aynı ada sahip bir özel bölge oluşturun.
- Gerekçe: Dış kullanıcılar uç yük dengeleyicilere ulaşmaya devam eder; dahili hizmetler ise RFC1918 üzerinden özel ILB’lere ulaşarak tutarlı ana bilgisayar adlarını korurken gecikmeyi ve maliyeti optimize eder.
Güvenlik duvarlarından çıkış yapmadan Google API’lerine özel erişim sağlayın
- Harici IP’leri olmayan Contoso VM’leri için, Google API’leri için Private Service Connect’i etkinleştirin ve PSC uç noktalarına eşlenen googleapis.com için yönetilen özel DNS bölgesini oluşturun.
- Gerekçe: BigQuery ve Pub/Sub erişiminin özel ve VPC’ye yerel kalmasını sağlar, üçüncü taraf çıkış cihazlarından (egress appliances) kaçınır ve güvenlik duruşunu korur.
Gözlemlenebilirlik ve kontrolü etkinleştirin
- İlgili VPC’ler için Contoso’nun DNS politikasında Cloud DNS sorgu günlüğünü ve herkese açık bölgelerde yetkili sorgu günlüğünü açın. Bilinen kötü amaçlı alan adlarını organizasyon genelinde engellemek için yanıt politikası kuralları (response policy rules) oluşturun.
- Gerekçe: Sorgu telemetrisi, sorun gidermeyi ve kapasite planlamasını destekler; yanıt politikaları, her çözümleyiciye dokunmadan güvenlik için merkezi kontrol sağlar.
Değişiklik yönetimini güvenli TTL’lerle yürütün
- Değişikliklerden bir hafta önce taşınan kayıtlar için TTL’leri 60 saniyeye düşürün. Doğrulama ve geçişten sonra (örneğin, bir hizmeti şirket içinden GCP ILB’ye geçirmek), TTL’leri kademeli olarak 300-600 saniyeye yükseltin.
- Gerekçe: Kısa TTL’ler geçişler sırasında riski sınırlar; daha yüksek TTL’leri geri yüklemek, stabilizasyon sonrası önbellek verimliliğini artırır.
Test edin, doğrulayın ve sağlamlaştırın
- Her iki taraftaki kanarya VM’lerinden, +trace ile dig çalıştırın ve yetkili yolları doğrulayın, günlüklerde SERVFAIL/NXDOMAIN artışları olmadığını onaylayın ve VPN yedekliliği ile DNS davranışını gözlemlemek için bağlantı hatalarını simüle edin.
- Gerekçe: Proaktif doğrulama, döngü/görünürlük sorunlarını erken tespit eder; hata simülasyonları, hibrit çözümlemenin aktarım olaylarından kullanıcı etkisi olmadan kurtulduğunu doğrular.