GCP Cloud DNS Yönetimi: Google Cloud’da DNS Yapılandırması

Tarafındankomut
0 Comments

DNS yönetimi, her altyapının bel kemiğidir. GCP’ye geçiş yaptığınızda ya da hibrit bir yapı kurduğunuzda, Cloud DNS’i doğru yapılandırmak operasyonel olgunluğunuzun en temel göstergelerinden biri haline gelir. Bu yazıda Cloud DNS’i sadece “alan adı kayıt etme” perspektifinden değil, gerçek bir sysadmin’in günlük iş akışına entegre edecek şekilde ele alacağız.

Cloud DNS Nedir ve Neden Önemlidir?

Google Cloud DNS, Google’ın küresel ağ altyapısı üzerinde çalışan, anycast tabanlı bir DNS hizmetidir. 100% SLA sunar ve düşük gecikme süreleriyle sorguları yanıtlar. Kendi DNS sunucunuzu yönetmek yerine bu servisi kullanmanın birkaç somut faydası var:

  • Yönetim yükü sıfır: BIND ya da PowerDNS gibi çözümleri patch’leyip izlemek zorunda kalmazsınız
  • Küresel replikasyon: Kayıtlarınız otomatik olarak Google’ın PoP noktalarına dağıtılır
  • IAM entegrasyonu: Kim hangi zone’u düzenleyebilir, bunu GCP IAM ile yönetirsiniz
  • Audit log: Cloud Audit Logs sayesinde kim ne zaman hangi kaydı değiştirdi, tam görünürlük

Ama şunu da net söyleyelim: Cloud DNS’i yanlış yapılandırırsanız, TTL değerlerini görmezden gelirseniz ya da zone delegasyonunu eksik yaparsanız, saatler süren kesintilerle karşılaşabilirsiniz. Dolayısıyla bu konuya hak ettiği ciddiyetle yaklaşmak gerekiyor.

Temel Kavramlar: Zone Türleri

Cloud DNS üzerinde çalışmadan önce zone türlerini net anlamak şart.

Public Zone: İnternetten erişilebilir kayıtları barındırır. Örneğin example.com için A, MX, CNAME kayıtları buraya girer.

Private Zone: Sadece belirttiğiniz VPC ağları içinden erişilebilir. Internal servisler, mikroservis iletişimi, database endpoint’leri için kullanılır. Dışarıdan sorgulanamazlar.

Forwarding Zone: Belirli domain’ler için sorguları başka bir DNS sunucusuna yönlendirir. On-premise ile hibrit yapı kurduğunuzda hayat kurtarır.

Peering Zone: Farklı GCP projeleri arasında DNS çözümlemeyi paylaşmak için kullanılır. Büyük organizasyonlarda farklı takımlar farklı projelerde çalışıyorsa bu yapıya ihtiyaç duyarsınız.

gcloud ile Zone ve Kayıt Yönetimi

GCP Console üzerinden da yapılabilir elbette, ama sysadmin olarak her şeyi script’e dökebileceğiniz gcloud CLI’ı tercih etmenizi öneririm. Hem tekrarlanabilirlik açısından hem de CI/CD pipeline’larına entegrasyon için çok daha uygun.

İlk Zone’u Oluşturmak

Public bir zone oluşturmak için:

gcloud dns managed-zones create example-public 
  --dns-name="example.com." 
  --description="Production public zone" 
  --visibility=public 
  --project=my-prod-project

Private bir zone oluşturmak içinse VPC ağını belirtmeniz gerekiyor:

gcloud dns managed-zones create example-private 
  --dns-name="internal.example.com." 
  --description="Internal services zone" 
  --visibility=private 
  --networks=https://www.googleapis.com/compute/v1/projects/my-prod-project/global/networks/prod-vpc 
  --project=my-prod-project

Burada --networks parametresine dikkat edin. Birden fazla VPC eklemek istiyorsanız virgülle ayırarak liste verebilirsiniz.

DNS Kayıtları Ekleme

Cloud DNS’te kayıt eklemek transaction tabanlı çalışır. Önce bir transaction başlatırsınız, değişikliklerinizi yaparsınız, sonra commit edersiniz. Bu yaklaşım atomik güncelleme sağlar.

# Transaction başlat
gcloud dns record-sets transaction start 
  --zone=example-public 
  --project=my-prod-project

# A kaydı ekle
gcloud dns record-sets transaction add 
  --zone=example-public 
  --name="www.example.com." 
  --ttl=300 
  --type=A 
  "34.102.136.180" 
  --project=my-prod-project

# MX kaydı ekle
gcloud dns record-sets transaction add 
  --zone=example-public 
  --name="example.com." 
  --ttl=3600 
  --type=MX 
  "10 mail.example.com." 
  --project=my-prod-project

# Transaction'ı commit et
gcloud dns record-sets transaction execute 
  --zone=example-public 
  --project=my-prod-project

Eğer transaction sırasında bir hata yaptıysanız ve baştan başlamak istiyorsanız:

gcloud dns record-sets transaction abort 
  --zone=example-public 
  --project=my-prod-project

Mevcut Kayıtları Listelemek

gcloud dns record-sets list 
  --zone=example-public 
  --project=my-prod-project

Belirli bir tip için filtrelemek isterseniz:

gcloud dns record-sets list 
  --zone=example-public 
  --filter="type=A" 
  --project=my-prod-project

Gerçek Dünya Senaryosu 1: Hibrit Yapıda Forwarding Zone

Diyelim ki şirketinizin on-premise’de çalışan bir Active Directory ortamı var. corp.example.com domain’i on-premise DNS sunucularında çözümleniyor. GCP’deki VM’lerinizin bu domain’e erişmesi gerekiyor.

Bu senaryoda forwarding zone kuruyoruz:

gcloud dns managed-zones create onprem-forwarding 
  --dns-name="corp.example.com." 
  --description="Forward corp queries to on-premise DNS" 
  --visibility=private 
  --networks=https://www.googleapis.com/compute/v1/projects/my-prod-project/global/networks/prod-vpc 
  --forwarding-targets=10.10.0.53,10.10.0.54 
  --project=my-prod-project

--forwarding-targets parametresine on-premise DNS sunucularınızın IP adreslerini giriyorsunuz. Burada dikkat edilmesi gereken nokta: Bu IP adresleri Cloud VPN ya da Cloud Interconnect üzerinden GCP VPC’nize erişilebilir olmalı.

Ayrıca on-premise taraftaki DNS sunucularınızın da GCP’nin 35.199.192.0/19 adres bloğunu tanıması gerekiyor. GCP’den on-premise’e DNS sorguları bu bloktan gelir.

Gerçek Dünya Senaryosu 2: Multi-Project DNS Mimarisi

Büyük organizasyonlarda farklı takımlar farklı GCP projelerinde çalışır. Merkezi bir DNS projesi kurup diğer projelere peering ile DNS çözümleme yetkisi vermek, hem yönetimi kolaylaştırır hem de tutarlılığı sağlar.

Merkezi DNS projesinde zone oluşturuyoruz:

# Hub projede zone oluştur
gcloud dns managed-zones create shared-internal 
  --dns-name="shared.internal." 
  --description="Shared internal DNS zone" 
  --visibility=private 
  --networks=https://www.googleapis.com/compute/v1/projects/dns-hub-project/global/networks/hub-vpc 
  --project=dns-hub-project

Spoke projesinde bu zone’a peering yapıyoruz:

# Spoke projede peering zone oluştur
gcloud dns managed-zones create spoke-peering 
  --dns-name="shared.internal." 
  --description="Peer to hub DNS zone" 
  --visibility=private 
  --networks=https://www.googleapis.com/compute/v1/projects/spoke-project/global/networks/spoke-vpc 
  --dns-peer-project=dns-hub-project 
  --dns-peer-managed-zone=shared-internal 
  --project=spoke-project

Bu sayede spoke-project içindeki VM’ler *.shared.internal sorgularını hub projedeki zone üzerinden çözümler.

TTL Stratejisi: Genellikle Göz Ardı Edilen Kritik Detay

TTL değerleri, DNS yönetiminin en çok ihmal edilen ama en kritik parametrelerinden biridir. Yanlış TTL değerleri hem kesinti süresini uzatır hem de gereksiz DNS sorgu maliyeti oluşturur.

Pratikte kullandığım strateji şu şekilde:

  • Statik altyapı kayıtları (mail sunucuları, legacy sistemler): 3600 saniye ya da daha yüksek
  • Dinamik servisler (load balancer IP’leri, ölçeklenen yapılar): 300 saniye
  • Geçici veya test ortamları: 60 saniye
  • Failover öncesi hazırlık: Kesinti planladığınızda 1-2 gün önceden TTL’i düşürün

Kritik bir migration öncesinde TTL’i nasıl düşüreceğinizi görelim:

# Önce mevcut kaydı sil, düşük TTL ile tekrar ekle
gcloud dns record-sets transaction start 
  --zone=example-public 
  --project=my-prod-project

gcloud dns record-sets transaction remove 
  --zone=example-public 
  --name="api.example.com." 
  --ttl=3600 
  --type=A 
  "34.102.136.180" 
  --project=my-prod-project

gcloud dns record-sets transaction add 
  --zone=example-public 
  --name="api.example.com." 
  --ttl=60 
  --type=A 
  "34.102.136.180" 
  --project=my-prod-project

gcloud dns record-sets transaction execute 
  --zone=example-public 
  --project=my-prod-project

Bu değişikliği uyguladıktan sonra eski TTL süresini beklemeniz gerekiyor. 3600 saniyelik TTL değiştirdiyseniz, saatlik cache’lenmiş sorgular hala eski TTL’i görecek. Sabırlı olun.

DNS Politikaları ile İnbound ve Outbound Forwarding

Cloud DNS, zone tabanlı yönlendirmenin yanı sıra VPC seviyesinde politikalar tanımlamanıza da imkan tanır.

Inbound DNS Policy: GCP VPC’nizde bir DNS forwarder noktası oluşturur. On-premise sistemleriniz bu IP’ye sorgu göndererek GCP private zone’larınızı çözümleyebilir.

gcloud dns policies create inbound-policy 
  --description="Allow on-premise to query GCP private zones" 
  --networks=prod-vpc 
  --enable-inbound-forwarding 
  --project=my-prod-project

Bu komutu çalıştırdıktan sonra GCP, VPC’nizin 10.x.x.253 adresine (subnet’e göre değişir) bir DNS forwarder dinleyicisi ekler. On-premise tarafından bu IP’ye yönlendirme yaparak GCP’deki private kayıtlara ulaşabilirsiniz.

Outbound DNS Policy: VPC içindeki tüm DNS sorgularını belirttiğiniz alternatif sunuculara yönlendirmek için kullanılır. Bu, zone bazlı forwarding’den farklıdır; tüm çözümlenmemiş sorguları yakalar.

gcloud dns policies create outbound-policy 
  --description="Custom DNS resolution for VPC" 
  --networks=prod-vpc 
  --alternative-name-servers=10.10.0.53,10.10.0.54 
  --project=my-prod-project

Terraform ile Cloud DNS Yönetimi

Üretim ortamlarında manuel gcloud komutları yerine Infrastructure as Code yaklaşımını benimsemek gerekiyor. Terraform, Cloud DNS kaynakları için mükemmel bir provider sunar.

# Temel Terraform yapısı için provider konfigürasyonu
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

resource "google_dns_managed_zone" "prod_public" {
  name        = "prod-public-zone"
  dns_name    = "example.com."
  description = "Production public DNS zone"
  project     = var.project_id

  dnssec_config {
    state = "on"
  }
}

resource "google_dns_record_set" "www" {
  name         = "www.${google_dns_managed_zone.prod_public.dns_name}"
  managed_zone = google_dns_managed_zone.prod_public.name
  type         = "A"
  ttl          = 300
  project      = var.project_id

  rrdatas = ["34.102.136.180"]
}

Terraform’u kullanmanın en büyük avantajı state yönetimi. Hangi kaynakların mevcut olduğunu takip eder ve terraform plan ile değişiklik önizlemesi yapabilirsiniz. DNS gibi hassas altyapı bileşenlerinde bu önizleme adımı son derece değerli.

DNSSEC Yapılandırması

Eğer public zone yönetiyorsanız DNSSEC’i aktif etmeyi ciddi ciddi düşünmelisiniz. DNS spoofing ve cache poisoning saldırılarına karşı kriptografik imza sağlar.

gcloud dns managed-zones update example-public 
  --dnssec-state=on 
  --project=my-prod-project

DNSSEC aktif hale geldikten sonra zone’un DS (Delegation Signer) kaydını domain registrar’ınızda tanımlamanız gerekiyor. Bu kaydı almak için:

gcloud dns managed-zones describe example-public 
  --project=my-prod-project 
  --format="value(managedZoneOperationsLink)"

# DNSSEC DS kaydı detaylarını görüntüle
gcloud dns dns-keys list 
  --zone=example-public 
  --project=my-prod-project

Çıktıdaki keyTag, algorithm, digestType ve digest değerlerini registrar panelinize girmeniz gerekiyor. Bu adımı atlamak ya da hatalı girmek, domain’inizin tamamen erişilemez hale gelmesine yol açabilir. Test ortamında mutlaka pratik yapın.

Monitoring ve Alerting

DNS kayıtlarında beklenmedik değişiklikler yaşandığında haberdar olmak istiyorsunuz. Cloud Audit Logs bu iş için biçilmiş kaftan.

Önce DNS aktivitelerini izlemek için bir log-based metric oluşturun:

gcloud logging metrics create dns-record-changes 
  --description="Track DNS record set changes" 
  --log-filter='protoPayload.serviceName="dns.googleapis.com"
  AND protoPayload.methodName=~"dns.changes.create|dns.resourceRecordSets"' 
  --project=my-prod-project

Ardından bu metrik üzerine bir alert policy tanımlayabilirsiniz. Özellikle gece yarısı yapılan DNS değişikliklerini hemen fark etmek için email ya da PagerDuty entegrasyonuyla alarm kurmanızı öneririm.

DNS sorgularının beklenmedik şekilde artıp artmadığını izlemek için de Cloud Monitoring’den DNS query count metriklerini kullanabilirsiniz. Ani bir spike, yanlış yapılandırılmış bir TTL ya da bir uygulamanın her istekte DNS sorgusu yapmasından kaynaklanıyor olabilir.

Yaygın Hatalar ve Çözümleri

Nokta işareti unutmak: DNS kayıt isimlerinin sonundaki nokta işareti (FQDN) çok önemlidir. www.example.com. ile www.example.com Cloud DNS’te farklı davranabilir. gcloud komutlarında her zaman trailing dot kullanın.

Zone silme sırası: Bir zone’u silmeden önce içindeki tüm NS ve SOA dışındaki kayıtları silmeniz gerekir. Aksi halde işlem hata verir.

# Zone içeriğini temizleyip zone'u silmek için
gcloud dns record-sets list 
  --zone=example-public 
  --project=my-prod-project 
  --format="csv[no-heading](name,ttl,type,DATA)" | 
  grep -v "^example.com.,.*,NS," | 
  grep -v "^example.com.,.*,SOA," | 
  while IFS=, read name ttl type data; do
    gcloud dns record-sets delete "$name" 
      --zone=example-public 
      --type="$type" 
      --project=my-prod-project
  done

Private zone VPC bağlantısı: Private zone oluşturup VM’lerinizin bu zone’u çözümleyemediğini fark ederseniz, ilk kontrol noktanız zone’un doğru VPC’ye bağlı olup olmadığıdır. Çok basit ama en sık yapılan hata bu.

Forwarding ve private zone çakışması: Aynı domain için hem forwarding zone hem de private zone varsa, Cloud DNS önce private zone’u değerlendirir. Bu davranışı bilmeden oluşturulan çakışmalar ciddi sorunlara yol açabilir.

Maliyet Yönetimi

Cloud DNS maliyet açısından oldukça uygun bir servis, ama büyük ölçekte göz ardı edilemez. Temel maliyet bileşenleri:

  • Zone başına ücret: Aylık sabit bir ücret. İlk 25 zone için birinci dilim fiyatı geçerli.
  • DNS sorgu başına ücret: Milyonlarca sorgu yapıyorsanız bu kalem önemli hale gelir. TTL değerlerini optimize ederek sorgu sayısını azaltabilirsiniz.
  • Internal DNS sorguları: GCP içindeki compute-default-internal DNS sorguları ücretsizdir, ek zone sorguları ücretlidir.

Maliyetleri takip etmek için Billing alert kurmanızı öneririm. DNS için ayrı bir billing alert belki abartı gibi görünse de, yanlış yapılandırılmış bir uygulama sonucu oluşan sorgu patlamaları gerçek maliyetler yaratabilir.

Sonuç

Cloud DNS, doğru yapılandırıldığında bakımı minimal, güvenilirliği yüksek bir altyapı servisidir. Ama bu “bakımı minimal” ifadesi, “kurup unut” anlamına gelmiyor. Zone türlerini doğru seçmek, TTL stratejinizi oluşturmak, DNSSEC’i aktif etmek ve değişiklikleri audit log ile takip etmek, olgun bir DNS yönetiminin temel unsurları.

Hibrit yapılar kuruyorsanız forwarding zone ve inbound/outbound policy kombinasyonunu iyi anlamanız gerekiyor. Multi-project ortamlarda peering zone yapısını erken tasarlayın, sonradan refactor etmek zahmetli oluyor.

Terraform’u production DNS yönetiminde kullananlar için şunu söyleyeyim: DNS kayıtlarını Terraform state’inden çıkarmak ve import etmek bazen beklenmedik sonuçlar doğurabilir. State dosyanızı düzenli backup alın ve özellikle terraform destroy komutunu DNS zone’larında kullanırken çok dikkatli olun.

Son olarak, DNS değişikliklerini her zaman off-peak saatlerde yapmanızı ve değişiklik öncesinde mevcut konfigürasyonu mutlaka kayıt altına almanızı öneririm. Bir şeyler ters gittiğinde geri dönüş planınız olsun. DNS kesintileri hızlı fark edilen, ama bazen yavaş düzelen sorunlardır ve bu durum hem kullanıcıları hem de ekibi ciddi ölçüde yorar.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir