Özel Ad Sunucusu Kurulumunda Hangi Kayıtlar Gerekir?
Hiç başınıza geldi mi? Bir sabah kahvenizi koyup sitenizi açmaya niyetleniyorsunuz, ama sayfa dönüp duruyor. Örnek bir özel ad sunucusu kurulumunu düşünelim. Her şey hazır görünüyor: sunucu kurulu, web dosyaları yerinde, sertifika tamam. Ama alan adı bir türlü bizim sunucunun IP’sine oturmuyor. Derken konu dönüp dolaşıp o meşhur iki kelimeye geldi: özel ad sunucusu ve glue record. İtiraf edeyim, ilk kez yaklaşan biri için isimleri bile hafif ürkütücü duruyor.
İşte bu yazıda, kafadaki bu sis perdesini aralayacağız. Özel ad sunucusu nedir, neden işimize yarar, glue record ne işe yarar ve en önemlisi ikisini adım adım nasıl kurarız, birlikte ilerleyeceğiz. Kurulumla ilgili püfleri de serpiştireceğim; mesela TTL’yi ne zaman düşürmek iyi fikirdir, firewall neden şaka kaldırmaz, ya da tek bir rakam hatası nasıl gününüzü karartır. Rahat olun, konu teknik gibi görünse de, birkaç doğru dokunuşla gayet keyifli bir yolculuğa dönüşüyor.
Yazının sonunda, siz de alan adınızı kendi ns1 ve ns2 adreslerinizle yönetebilecek, glue record’ları doğru yere yerleştirip olası hataları hızlıca teşhis edebileceksiniz. Hadi başlayalım; önce şu özel ad sunucusu işi nedir, onu netleştirelim.
Özel Ad Sunucusu Nedir, Ne Zaman İşe Yarar?
Özel ad sunucusu dediğimiz şey, alan adınızın kendi adını taşıyan ad sunucularıdır. Yani ns1.sizinalanadiniz.com ve ns2.sizinalanadiniz.com gibi. Dışarıdan bir DNS sağlayıcısının ns’lerini kullanmak yerine, kendi markanızla görünür olursunuz. Bir nevi dükkanın tabelasını kendi adınızla asmak gibi düşünebilirsiniz. Mesela bir ajanssanız, müşterilerinize kendi ns’lerinizle hizmet verirsiniz; kurumsal tarafta ise iç sistemlerle dış dünyayı aynı elde toplamak daha düzenli ilerler.
Peki ne zaman mantıklı? DNS altyapısını da kendiniz işletiyorsanız, tam kontrol istediğinizde. Kayıtlar, TTL’ler, zone şablonları; hepsi sizin elinizde. İkincisi, müşteri deneyimi. Tek bir çatı ve tek bir isim altında yönetmek güven verir. Üçüncüsü, otomasyon. CI/CD süreçlerine DNS’i katmak gerektiğinde, dış servise bağımlı kalmadan ilerlemek hoş olur. Dezavantaj olarak, sorumluluk sizdedir. Yani erişilebilirlik, güvenlik, güncellemeler ve yedek planları. Ama iyi bir plan bu yükü ve kesinti riskini azaltabilir.
Burada bir parantez açayım: DNS tarafındaki değişikliklerin dünyaya yayılması anlık olmaz. Yayılım ve kesintisiz geçişler için DNS yayılımını hızlandıran TTL stratejileri üzerine yazımız hoş bir rehber olur. Dönüşümlerde paniklemek yerine önceden hazırlık yapmak, günün sonunda en büyük kazanç.
Glue Record Nedir? Neden Bazen En Başa Dönüyoruz?
Glue record, özel ad sunucularının kalp atışı gibi. Kısa bir özetle, üst DNS bölgesinde yayımlanan, gerektiğinde registrar üzerinden tanımlanan ad sunucusu IP adresi kaydıdır. Neden kritik? Çünkü alan adınızın ad sunucuları yine alan adınızın altındadır. Yani ns’lerin IP’sini bilmiyorsak, ns’lere gidip alan adının IP’sini nasıl soracağız? Burada sonsuz bir döngüye gireriz. İşte glue record bu düğümü keser; “ns1.sizinalanadiniz.com şu IP’de” diye tesciller ve çözüm zinciri akmaya başlar.
Glue record kavramını sade bir dille anlatan bir referans isterseniz, glue record kavramını sade bir dille anlatan bu kaynak gayet anlaşılır. Bir de registrar bakış açısından görmek isterseniz, glue record’ların registrar tarafındaki mantığı işin mutfağına pencere açar. Ama siz bu yazıyı bitirdiğinizde, büyük ihtimalle tekrar dönüp bakmanız gerekmeyecek.
Hazırlıklar: IP’ler, DNS Yazılımı, Güvenlik ve Kritik Ayrıntılar
Kurulumdan önce birkaç taş yerine oturmalı. İlk olarak, registrar’ın NS/IP koşullarını kontrol edin. Dayanıklılık için farklı hata alanlarında en az iki yetkili DNS sunucusu planlayın; aynı sunucudaki iki IP yedeklilik sağlamaz. İkincisi, yetkili DNS yazılımını ve işletme sorumluluğunu belirleyin. Panel kullanmak zone oluşturma, ikinci sunucuyla eşitleme ve dışarıdan erişim kontrollerini ortadan kaldırmaz. Bu rehber ortak kurulum sırasını açıklar; seçtiğiniz yazılımın sürümüne uygun zone ve servis yapılandırmasını tamamlamanız gerekir.
Güvenlik tarafında, yetkili DNS hizmetine UDP ve TCP 53 üzerinden erişilebilmelidir; herkese açık recursive çözümleme kapalı tutulmalıdır. Firewall ve güvenlik duvarı servisleriniz, DNS trafiğini bloklamamalı. Bu, gözden kaçtığında “Her şey doğru ama çalışmıyor” hissine sebep olur. Bir de günün birinde IPv6’ya dokunmanız neredeyse kesinleşecek; şimdiden IPv6 dalgası sizi ne zaman yakalar diye bir göz atmak kötü fikir değildir. Glue kayıtlarının AAAA kayıtlarıyla uyumu, geleceği bugün düzenler.
Son olarak, planlama. Bir alan adını aktif trafikte kullanıyorsanız, taşıma günü öncesinde TTL’leri düşürmek, test alanı açmak ve geri dönüş planı yapmak huzur verir. DNS değişiklikleri bir koşu bandından çok, ritmi olan bir dans gibidir; adımları doğru atarsanız, performans bir anda akmaya başlar.
Adım Adım: Registrar Üzerinde Glue Record Oluşturma
İşe en tepedeki kilitten, yani alan adınızın kayıt şirketinden başlıyoruz. Panelden ‘host’ ya da ‘child nameserver’ gibi bir menü göreceksiniz. Bazı panellerde ‘private nameserver’ olarak geçer. Burada ns1 ve ns2 için IP adreslerinizi tek tek tanımlarsınız. Önce ns1.sizinalanadiniz.com için IP’yi yazın, kaydedin. Sonra ns2’yi ekleyin. IPv6 kullanacaksanız registrar’ın IPv6 glue desteğini kontrol edin. Zone’a AAAA eklemek üst bölgedeki glue kaydının yerini tutmaz; yayımlanan IPv6 adresinde DNS hizmeti erişilebilir olmalıdır.
Bu adımda yapılan en yaygın hata, IP’lerin karışması ya da rakam atlamalarıdır. Bir kez daha kontrol edin. Bir noktada “Kayıt başarıyla alındı” gibi bir mesaj görürsünüz. İşlenme süresi registrar ve registry’ye bağlıdır; paneldeki onay, eski önbelleklerin yenilendiği anlamına gelmez. Görevimiz burada bitmedi. Sırada sunucu tarafı var ve o da en az burası kadar keyifli.
Yeri gelmişken, wildcard sertifikalarla uğraşıyorsanız DNS tarafı hayatınızı kolaylaştırır. Bunun için DNS-01 ile wildcard SSL otomasyonu yazısında anlattığımız pratikler, özel ad sunucusu kurduktan sonra resmen doğru zemine oturur.
Sunucuda NS ve Zone’ları Hazırlama: cPanel, Plesk ve BIND/PowerDNS
cPanel/WHM ile hızlı kurulum
Önce WHM’de Nameserver Selection üzerinden kullanılacak DNS hizmetinin etkin olduğunu doğrulayın. Ardından ‘Basic WebHost Manager Setup’ kısmında ad sunucusu isimlerinizi belirlersiniz. ns1 ve ns2 adlarını girin; Configure Address Records ile her ad için gerçek IPv4 ve gerekiyorsa IPv6 adres kaydını oluşturun. Bu işlem sunucu arabirimine yeni IP tahsis etmez. Gerekli A kayıtlarının alan adınızın DNS bölgesinde bulunduğunu doğrulayın; otomatik eklendiğini varsaymayın. Ardından ‘DNS Functions’ bölümünde domain’inize ait zone dosyasında NS kayıtlarının ns1 ve ns2’yi gösterdiğini ve A kayıtlarının yerli yerinde durduğunu kontrol edin. İkinci yetkili sunucuya da aynı zone verilerini aktarın ve güncel tutulmasını sağlayın. Her iki sunucuyu dış bir ağdan doğrudan sorgulayarak yetkili yanıt verdiğini kontrol edin. Resolver Configuration, sunucunun kendi dış DNS sorguları için /etc/resolv.conf dosyasını düzenler; yetkili DNS hizmetinizin çalıştığını doğrulamaz.
Plesk ile akıcı yapılandırma
Plesk’te ‘Tools & Settings > DNS Settings’ bölümündeki sunucu geneli DNS şablonu ve domain bazlı DNS ayarları işimizi görür. Domain’in zone’u içinde ns1.sizinalanadiniz.com ve ns2.sizinalanadiniz.com için A kayıtlarını yazın; NS kayıtlarının bu iki ad sunucusunu gösterdiğini doğrulayın. Üst bölgedeki delegasyon ayrıca registrar üzerinden değiştirilir. İlgili alan adının DNS hizmetinin etkin olduğunu, zone’un sunucuya yüklendiğini ve ikinci yetkili sunucuyla güncel tutulduğunu doğrulayın. Son kontrolü her iki sunucunun IP adresine dış bir ağdan doğrudan sorgu göndererek yapın. Küçük bir ipucu: Plesk’te şablonları düzenleyip yeni domain’ler için aynı özel ns’leri otomatik tanıtabilirsiniz.
BIND/PowerDNS ile yalın kurulum
BIND’de kayıtlar zone dosyasında, PowerDNS Authoritative’de ise seçilen backend’de tutulur; yalnız BIND backend’i zone dosyalarını kullanır. Zone’un tepesindeki NS kayıtları yetkili sunucuları belirtir; ns1 ve ns2’nin A kayıtları IPv4 adreslerini tutar. Örneğin ‘ns1 IN A 203.0.113.10’ ve ‘ns2 IN A 203.0.113.11’ satırlarında kısa adlar zone origin’ine göre tamamlanır. Bu IP’ler yalnız dokümantasyon içindir; gerçek kurulumda size tahsis edilmiş herkese açık adresleri kullanın. İki A kaydı tek başına zone oluşturmaz: zone tepesinde SOA ve seri numarası, sonu noktalı tam NS hedefleri, ad sunucularının A/AAAA kayıtları ve alan adının bütün gerekli hizmet kayıtları bulunmalıdır. BIND’de zone’u named.conf üzerinden tanımlayın; PowerDNS’de seçilen backend’in yöntemini izleyin. İkinci sunucuyu yetkilendirilmiş zone transferi veya kullandığınız DNS kümesinin eşitleme yöntemiyle güncel tutun. Sözdizimini doğruladıktan sonra hizmeti yeniden yükleyin; günlükleri ve iki sunucunun SOA/NS yanıtlarını kontrol edin. Küçük bir virgül, beklenmedik bir nokta veya TTL satırındaki yazım hatası, saniyeler içinde göze batmasa da günün sonunda çözümü etkiler. Dikkatli bir son okuma her zaman kazandırır.
Domain’i Özel NS’lere Taşıma, Test ve Yayılım
Delegasyonu değiştirmeden önce eski zone’un A/AAAA, MX, TXT (SPF, DKIM, DMARC), CAA ve diğer gerekli kayıtlarını yeni hizmete aktarın. İki yeni sunucunun her birini IP adresiyle doğrudan sorgulayın: SOA/NS yanıtları yetkili olmalı, hizmet kayıtları eski zone ile eşleşmeli ve UDP/TCP 53 erişimi çalışmalıdır. Alan adında DS kaydı varsa DNSSEC anahtarları ve imzalarıyla geçişi koordine edin; eski DS’ye uymayan yeni anahtarlar doğrulama hatasına yol açar. Bu kontroller tamamlandığında taşıma adımına geçin. Registrar panelinde domain’in DNS sunucularını ns1.sizinalanadiniz.com ve ns2.sizinalanadiniz.com olarak değiştirin. Eski yetkili DNS hizmetini ve güncel zone verilerini, önbelleklerdeki eski delegasyon ve adres kayıtlarının süreleri dolana kadar çalışır durumda tutun. Geçiş sırasında eski ve yeni sunuculara sorgular gelebilir. Burada sabır kadar, öncesinde yapılan TTL hazırlığı önemlidir. TTL’leri eski süreleri dolacak kadar önceden düşürmek kayıt geçişini hızlandırabilir; zone TTL’leri üst bölgedeki NS ve glue önbellek sürelerini belirlemez. Bu konuda tekrar not düşeyim: planlı TTL değişimiyle kesintisiz geçiş yazısı eşlik etsin.
Test için yerel bilgisayarınızdan veya bir uzak sunucudan çözümleme deneyebilirsiniz. ‘dig alanadiniz.com @8.8.8.8’ gibi basit bir sorgu size A kaydını, ‘dig NS alanadiniz.com’ ise çözümleyicinin döndürdüğü NS kayıtlarını gösterir; önbellekteki bu yanıt, üst bölgedeki güncel delegasyonu tek başına doğrulamaz. ‘dig ns1.sizinalanadiniz.com’ ile ns1’in IP’si doğru dönüyor mu bakarsınız; ‘+trace’ parametresiyle kökten itibaren adım adım çözümlenmesini izlemek de ufuk açar. Komut detayları için dig komutunun kullanımına göz atmak faydalı olacaktır.
Bu aşamada bir şeyler yolunda değilse, genellikle üç ihtimal var: glue’da yanlış IP, zone’da eksik/yanlış A kaydı ya da firewall’ın 53 numaralı kapıyı kapatması. Bir de nadir görülen ama sinir bozan ters yazım hataları.
Yaygın Hatalar ve Hızlı Kurtarma Senaryoları
Özel ad sunucusu kurarken tek bir ad sunucusuyla yetinmek dayanıklılığı azaltır. İki ayrı IP tek başına yeterli değildir; bağımsız sunucular ve ağlar ortak arıza riskini azaltır. Bir diğer hata, gerekli glue kayıtlarının unutulmasıdır. NS adları delege edilen alan adının içindeyse, üst bölgede glue bulunmaması döngüsel bağımlılık yaratabilir. Üçüncüsü ise firewall. UDP 53 ve TCP 53’e erişimi netleştirin.
Hataları teşhis ederken bir yöntem önerim var: parçala ve yeniden kur. Önce ns1 ve ns2’nin A kayıtlarını doğrudan sorgula; sonra domain’in NS kayıtlarını; ardından domain’in A ve MX kayıtlarını. Bu kontrollerin yanında üst bölgedeki delegasyonu, yetkili sunucuların erişilebilirliğini ve varsa DNSSEC doğrulamasını da inceleyin. TTL’leri önceden kısaltmak denemeleri kolaylaştırabilir; mevcut önbellekler eski TTL dolana kadar değişmez. Zone TTL’leri, üst bölgedeki delegasyon ve glue TTL’lerini değiştirmez.
Bu arada, alan adı dünyasında marka ve SEO tarafını da düşünüyorsanız, adımlarınızı daha geniş bir resmin içine koymak iyi gelir. Doğru uzantı seçimi bazen teknik operasyondan daha uzun vadeli etki bırakır. Bu bakış için alan adı ve TLD seçimi üzerine notlar faydalı bir okuma olur.
İleri Seviye Dokunuşlar: IPv6, Anycast, DNSSEC ve Otomasyon
Temelleri sağlam attıktan sonra, birkaç ileri seviye başlık yolunuzu açar. IPv6 ile glue kayıtlarını AAAA düzeyinde tamamlamak, sizi bir sonraki dalgaya hazırlar. Anycast dağıtımı, ns’lerinizi coğrafyaya yayarak tek bir lokasyona bağımlılığı azaltır; sunucular büyüdükçe bu tatlı bir rahatlık getirir. DNSSEC ise imzalı kayıtlarla güven zincirine anlamlı bir halka ekler; kurarken dikkat ister ama karşılığı büyüktür.
Otomasyon tarafında, yeni domain eklediğinizde zone kayıtlarının şablondan gelmesi size zaman kazandırır; üst bölgedeki NS delegasyonu ise registrar tarafında ayrıca yönetilir. CI/CD boru hattına “dns deploy” adımı eklemek, staging’den prod’a geçişte tutarlılığı artırabilir; hatasızlığı garanti etmez. Bir de TLS/SSL konusuna değinmiştik; wildcard sertifikalar için DNS-01 otomasyonu, özel NS adından değil, yetkili DNS’te TXT kayıtlarını güvenli biçimde güncelleyebilmekten yararlanır. Bu noktada yine DNS-01 ile wildcard otomasyonu pratikleri elinizi güçlendirir.
Önbellek katmanlarını, CDN’i ve uygulama tarafı optimizasyonlarını da denklemden esirgemeyin. DNS sadece yön gösterir; arkasındaki dünya ne kadar hazırlıklıysa, gerçek hız o kadar artar. Merak edenler için, uygulama ve altyapı tarafındaki iyileştirmeleri daha geniş bir resimde görmek her zaman ufuk açar.
Sahada Küçük Ama Hayat Kurtaran İpuçları
Önce düşük riskli bir domain ile tatbikat yapın. Her şey sorunsuz aktığında, üretimde kullandığınız domain’i taşıyın. Bu, özellikle e-posta kayıtlarımız (MX, SPF, DKIM) ve alt alan adları çoksa, huzur verir. Taşıma gününde, sunucu günlüklerini bir kenarda açık tutmak faydalıdır; başarısız sorgular ya da timeout’lar ipucu verir. Bir de metin dosyasında “kontrol listesi” bulundurun: glue IP’leri, ns A kayıtları, firewall durumu, NS delegasyonları, TTL’ler…
Testlerde tek bir resolver’a güvenmeyin. Farklı ağlardan, farklı çözüm sunucularından bakmak iyi fikir. Bazen ISS’in önbelleği beklenenden uzun süre tutar ve sizi yanıltır. ‘+trace’ çıktısını okumayı öğrenmek, trafik sıkışıklığında alternatif güzergâh bilmek gibidir. Anlarsanız, rahat edersiniz.
Son olarak, yazıya eşlik eden dış kaynakları elinizin altında tutun. Kimi zaman bir görsel ya da tanım, kavramı şıp diye yerine oturtur. Bu yazıda linkini verdiğim glue record özetleri, registrar tarafı açıklamaları ve dig komutu dokümantasyonu bu işin küçük el kitapları gibi çalışır.
Kapanış: Kendi DNS’inin Direksiyonunda
Kurulumun tamamlanması için üç katman birbiriyle tutarlı olmalıdır: üst bölgedeki glue ve delegasyon, her yetkili sunucudaki zone verileri ve bu sunuculara ağ erişimi. Bir recursive çözümleyicide doğru NS adlarını görmek tek başına bu üç katmanı doğrulamaz.
Geçiş sırası: IP ve yedekliliği planlayın; gerekli zone kayıtlarını her iki yeni sunucuya aktarın ve eşitleyin; glue adreslerini kaydedin; SOA/NS ve hizmet yanıtları ile UDP/TCP 53 erişimini dışarıdan doğrulayın. Varsa mevcut DS kaydı ve DNSSEC imzalarıyla geçişi koordine edin. Ancak bu kontrollerden sonra registrar’da NS delegasyonunu değiştirin. Eski DNS hizmetini güncel verilerle, önbelleklerdeki eski delegasyon ve adres kayıtlarının süreleri dolana kadar çalıştırın ve geçişi farklı ağlardan izleyin.
Her aşamada kullanılan adresleri, zone seri numarasını ve test sonuçlarını kaydedin. Sorun varsa sonraki adıma geçmeden ilgili katmanı düzeltin; böylece geri dönüş planınız da hangi değişikliğin ne zaman yapıldığına dayanır.
