Google Cloud DNS ile Zone Yönetimi Nasıl Yapılır?

Google Cloud DNS, Google'ın küresel altyapısı üzerinde çalışan yönetilen bir DNS hizmetidir. Kendi nameserver'larınızı kurmak ve bakımını üstlenmek yerine bu hizmet aracılığıyla zone'larınızı ve kayıtlarınızı tek bir noktadan yönetebilirsiniz. Google Cloud Platform (GCP) üzerinde uygulama geliştiren ekipler için DNS yönetimini aynı proje ortamında tutmak, erişim kontrolü ve fatura izlemesini kolaylaştırır.

Hizmet; Google Cloud Console, gcloud CLI ve REST API olmak üzere üç farklı arayüz üzerinden erişilebilir. Bu çok katmanlı erişim seçeneği, hem tek seferlik manuel değişiklikler hem de CI/CD süreçlerine entegre otomatik güncellemeler için aynı altyapıyı kullanmanıza olanak tanır. Zone oluşturulduğunda Google, dünya genelindeki anycast noktalarına bağlı nameserver adresleri atar ve bu adresler değiştirilemez.

Zone kavramı, yönetim sürecinin merkezindedir. Bir zone, tek bir alan adına karşılık gelir ve A, CNAME, MX, TXT gibi kayıt setlerini içinde barındırır. Google Cloud DNS bu zone'ları iki farklı görünürlük modunda çalıştırır: internetten erişilebilen public zone ve yalnızca VPC ağı içinde görünen private zone. Hangi modun ne zaman gerektiğini anlamak, gereksiz karmaşıklıktan kaçınmanın başlangıç noktasıdır.

Public ve private zone arasındaki fark

Public zone, alan adınızın dışa açık kayıtlarını içerir. Web sunucunuza ait A kaydı, mail sisteminiz için MX ve TXT kayıtları, CDN veya üçüncü taraf servislere işaret eden CNAME kayıtları burada tanımlanır. Zone oluşturulduğunda Google dört nameserver adresi atar; bunları domain registrar panelinizde mevcut nameserver'larla değiştirmeniz gerekir. Bu adım tamamlanmadan zone teknik olarak hazır olsa bile dış sorgulara yanıt veremez.

Private zone ise yalnızca belirlediğiniz VPC ağlarına yanıt verir. api.internal.example.com gibi bir adres dış dünyaya kapalı kalırken, VPC içindeki makineler bu adrese sorunsuz erişir. Bu yapı özünde split-horizon DNS mantığıdır: aynı alan adı için iç ve dış ağlar farklı sonuçlar alır; kayıtlar ayrı zone'larda tutulduğundan çakışma riski ortadan kalkar.

İki zone türü birbirini dışlamaz. Aynı alan adı için hem public hem private zone oluşturabilirsiniz; Cloud DNS öncelik sırasını VPC politikasına göre belirler. İç trafiği farklı bir IP bloğuna yönlendirirken dış kullanıcılar başka bir hedefe çözümleme yapar. Private zone hangi VPC'nin sorgu gönderebileceğini "authorized networks" listesiyle kontrol eder; listeye eklenmeyen ağlar private zone'u göremez, public yanıtı alır.

Private zone ne zaman gereksizdir? Tek projede, tek VPC içinde çalışan ve dışa açılma planı olmayan küçük servisler için Google'ın dahili DNS mekanizmaları çoğu durumda yeterlidir. Cloud DNS private zone, farklı projelerdeki VPC'lerin aynı iç adres uzayını paylaşması gereken durumlarda gerçek değerini gösterir.

Zone oluşturma ve nameserver yapılandırması

Console üzerinden zone açmak birkaç adımdan oluşur. "Network services > Cloud DNS" bölümüne gidin, "Create zone" seçeneğine tıklayın, zone türünü belirleyin ve yönetmek istediğiniz alan adını girin. Zone adı yalnızca Cloud DNS içinde geçerli olan bir etiket olduğundan alan adıyla aynı olmak zorunda değildir; tanımlayıcı bir isim seçmek birden fazla zone çalıştırdığınızda yönetimi kolaylaştırır.

Nameserver atanır. Ardından bu dört adresi registrar panelinizde tanımlamanız gerekir; bu adım tamamlanmadan Google Cloud DNS dış sorgulara yanıt veremez. Değişiklik sonrasında propagasyon başlar ve bu süre mevcut TTL değerine bağlıdır. Planlı bir geçiş yapıyorsanız, nameserver değişikliğinin ayrıntılarını önceden planlamak kesinti riskini hesaplanabilir kılar.

CLI tercih edenler için temel komut şu şekilde çalışır: gcloud dns managed-zones create ornek-zone --dns-name="ornek.com." --description="Ana zone" --visibility=public. Alan adı sonundaki nokta (ornek.com.) root'u temsil eden standart DNS notasyonudur; gcloud bu noktayı otomatik ekler, ancak manuel kayıt girişlerinde bu ayrıntıyı atlamak hata doğurabilir.

Nameserver'lar değiştirildikten sonra doğrulama yapmak iyi bir pratiktir. dig NS ornek.com komutu hangi nameserver'ların görüntülendiğini gösterir; Google'a ait dört adres listeye girmişse propagasyon tamamlanmıştır. Farklı coğrafi konumlardan sorgulama yapmak için @8.8.8.8 parametresini ekleyerek Google'ın public resolver'ına yönlendirebilirsiniz.

DNS kayıtlarını ekleme ve düzenleme

Kayıt yönetimi "record sets" kavramı üzerinden işler. Aynı ad ve aynı tiple eşleşen tüm değerler tek bir record set içinde tutulur; iki farklı IP için iki A kaydı eklemek istediğinizde bunları aynı record set'e ayrı değerler olarak girersiniz. Yük dağıtımı veya yedekleme senaryolarında bu yapı bir seçenek değil, zorunluluktur.

Console'da kayıt eklemek için zone detay sayfasında "Add standard" seçeneğine tıklayın, kayıt tipini seçin, TTL ve hedef değerini girin. MX kaydı için öncelik (priority) değeri zorunludur; düşük sayı yüksek öncelik anlamına gelir, 10 değeri 20'den önce denenir. TXT kayıtları, özellikle SPF, DKIM ve DMARC değerleri için doğru yazım kritiktir. Mail sunucusu taşırken bu kayıtları doğru sırayla güncellemek gerekir; MX geçişini hatasız yürütmek için yeni sunucu tam olarak devreye girmeden MX kaydını değiştirmek hataya davetiye çıkarır.

Toplu değişiklikler için CLI'daki transaction yapısı kullanılır. Önce gcloud dns record-sets transaction start komutuyla işlem başlatılır, ardından ekleme ve silme komutları sıralanır, son olarak gcloud dns record-sets transaction execute ile değişiklik uygulanır. Bir adımda hata oluşursa tüm işlem geri alınır; bu yapı birden fazla kaydı atomik biçimde güncellemek için tasarlanmıştır.

Kök alan kaydı burada ayrı bir not ister. example.com apex domain'inde standart DNS kuralları CNAME kullanımına izin vermez; bu kısıt özellikle CDN veya yük dengeleyici gibi sabit IP vermeksizin çalışan servislere bağlanmaya çalışırken sorun çıkarır. CNAME flattening bu kısıtı aşmak için geliştirilmiştir ve Google Cloud DNS tarafından desteklenir; flattened kaydın TTL davranışı sıradan kayıtlardan farklı olduğundan bu seçeneği kullanmadan önce propagasyon beklentinizi gözden geçirmeniz faydalı olur.

TTL yönetimi ve değişiklik planlaması

TTL (Time to Live), DNS yanıtının önbellekte ne kadar süre tutulacağını saniye cinsinden belirtir. Google Cloud DNS varsayılan değeri 300 saniyedir; üretimde bu süreyi yükseltmek TTL stratejisinin bir parçasıdır. Üretim ortamında sık değişmeyen kayıtlar için bu değeri yükseltmek, örneğin A kaydı için 3600 saniye, DNS sunucularına gelen sorgu yükünü azaltır ve çözümleme sürelerini kısaltır.

Planlı değişikliklerde TTL yönetimi belirleyici rol oynar. Değişiklikten 24-48 saat önce ilgili kaydın TTL'sini 300 saniyeye indirirseniz, asıl güncellemeyi yaptığınızda yayılma süresi de kısalır. İnce bir ayrıntı: TTL düşürüldükten sonra eski TTL süresi kadar beklemeniz gerekir. Eski değer 3600 saniyeyse bazı önbelleklerin yeni 300 saniyelik değeri alması için yaklaşık bir saat geçer; geçiş penceresini planlarken bu hesabı dahil etmek şarttır.

TTL'yi gereksiz yere düşük tutmak ters etki doğurabilir. 30 veya 60 saniyelik TTL, her sorgunun doğrudan nameserver'a ulaşması anlamına gelir; yüksek trafikli bir alan adında bu durum sorgu maliyetini belirgin biçimde artırır. Değişiklik frekansı düşük olan kayıtlar için 3600 hatta 86400 saniye makul bir seçimdir; sık değişen kayıtları ise 300 saniyede tutmak yeterlidir. Düşük TTL gerçekten gerekli olduğunda bilinçli tercih olarak kullanılmalı, varsayılan bırakılmamalıdır.

IAM ile zone erişim kontrolü

Google Cloud DNS, proje düzeyinde IAM rolleriyle entegre çalışır. dns.admin rolü tüm zone ve kayıt işlemlerine tam yetki sağlar; dns.reader yalnızca okuma hakkı verir. Büyük ekiplerde her üyeye admin yetkisi vermek yerine rolleri dar tutmak, yanlışlıkla yapılan değişikliklerin etkisini sınırlar.

Belirli zone'lar için kaynak düzeyinde (resource-level) IAM da uygulanabilir. Bir ekibin yalnızca kendi servisine ait zone'u düzenleyebileceği, diğer zone'lara dokunamayacağı bir yapı kurulabilir. Otomatik güncellemeler yapan uygulamalar için servis hesabı üzerinden minimum izin tanımlamak en güvenli yaklaşımdır; çoğu durumda dns.resourceRecordSets.* ve dns.changes.* izinleri yeterlidir, tam admin yetkisi gerekmez.

IAM değişikliklerinin DNS operasyonları üzerindeki etkisi anlıktır. Bir servis hesabından izin alındığında, o hesabın başlatacağı sonraki kayıt değişiklikleri reddedilir; aktif bağlantılar veya önbellekteki yanıtlar etkilenmez. Acil geri alma senaryolarında IAM değişikliği tek başına yeterli olmaz; kaydın kendisini de eski değerine döndürmeniz gerekir.

API ve otomasyon entegrasyonu

REST API üzerinden her kayıt değişikliği bir "change" nesnesi olarak modellenir. Tek bir istek içinde birden fazla ekleme ve silme işlemi gönderilebilir; bu yapı atomik güncelleme ve birbiriyle ilişkili kayıtları bir arada değiştirmek için kullanılır. Kimlik doğrulama API anahtarı yerine OAuth 2.0 veya servis hesabı kimlik bilgileriyle yapılır.

Terraform ile yönetim de yaygın bir tercih. google_dns_managed_zone kaynağı zone'u, google_dns_record_set kaynağı içindeki kayıtları temsil eder. Terraform state üzerinden mevcut durumu izleyebildiğinizden sürüklenme (drift) tespiti kolaylaşır; ekip içinde yapılan elle değişiklikler bir sonraki terraform plan çalıştırıldığında gün yüzüne çıkar.

Anycast tabanlı altyapı, Cloud DNS'in küresel ölçekte düşük gecikmeyle yanıt vermesini sağlar. Anycast DNS mantığında sorgu, kullanıcıya en yakın ağ noktasına yönlendirilir; farklı kıtalara dağılmış kullanıcı tabanına sahip servisler için bu mimari çözümleme sürelerini belirgin biçimde kısaltır.

Google Cloud DNS'in ücretlendirme modeli, zone başına sabit aylık ücret ve sorgu başına değişken ücret olmak üzere iki bileşenden oluşur. Yüksek trafikli ortamlarda sorgu maliyeti baskın kaleme dönüşebilir; TTL değerlerini artırmak hem önbellek verimliliğini iyileştirir hem de bu maliyeti aşağı çeker.

Zone sayısı büyüdükçe adlandırma ve etiketleme stratejisi önem kazanır. Proje başına tek zone yerine servis veya ekip başına ayrı zone yapısı, izin yönetimini ve fatura dağıtımını daha izlenebilir kılar. Çok sayıda domain barındıran yapılarda uygulanan DNS tutarlılığı ilkesi burada da geçerlidir: adlandırma kuralı, etiket şeması ve değişiklik kaydı farklı görünseler de aynı disiplini gerektirir.

Zone yönetiminde sık yapılan bir hata, kayıt silerken NS ve SOA kayıtlarına dokunmaktır. Cloud DNS bu iki kaydı otomatik yönetir; kullanıcı tarafından değiştirilir veya silinirse zone'un dışarıya görünürlüğü bozulur. Değişiklik yapmadan önce mevcut kayıtların yedeğini almak ve toplu işlemlerde transaction yapısını kullanmak bu riski önemli ölçüde azaltır.