IANA, registry ve registrar üç katmanlı yetki hiyerarşisi PCB diyagramı

Domain Registrar ile Registry Arasındaki Fark Nedir?

Bir domain adı kayıt ettirdiğinizde iki ayrı kuruluşla aynı anda ilişki kurarsınız: registrar ve registry. Bu iki katman birbirinden teknik ve idari açıdan belirgin biçimde ayrışır, ancak son kullanıcı perspektifinden genellikle tek bir işlem gibi görünür. Bu görünmezlik, transfer sorunlarını, sözleşme anlaşmazlıklarını ve DNS değişikliklerinin neden gecikmeli yansıdığını anlamayı güçleştirir.

Pratikte karışıklık şöyle ortaya çıkar: registrar'ınızı değiştirdiğinizde domain'inizin nameserver kayıtlarının neden etkilenmediğini ya da bazı değişikliklerin neden anında yansırken bazılarının saatler aldığını merak edersiniz. Ya da bir transfer sırasında "sponsoring registrar" gibi teknik bir terimle karşılaşır ve bunun kayıt sahibi kimliğinizle nasıl ilişkili olduğunu anlayamazsınız. Bu sorular, registrar ve registry arasındaki teknik sınırı anladığınızda netlik kazanır.

Domain kayıt sisteminin mimarisi gerçekte üç katmandan oluşur: küresel koordinasyonu sağlayan IANA, belirli TLD'lere özgü zone'ları yöneten registry'ler ve son kullanıcıyla doğrudan temas kuran registrar'lar. Bu üç katmanın birbirinden farklı sorumlulukları vardır ve her biri ayrı bir sözleşme ilişkisi içindedir.

IANA, registry ve registrar: üç katmanlı yetki hiyerarşisi

Hiyerarşinin tepesinde IANA (Internet Assigned Numbers Authority) yer alır. IANA şu anda ICANN bünyesinde işlev görür ve root DNS zone'unu — yani "." nokta zone'unu — yönetir. Hangi TLD'lerin var olduğunu, her TLD için hangi registry'nin yetkili olduğunu ve root nameserver'larının içeriğini IANA belirler. Doğrudan son kullanıcılarla hiçbir ilişkisi yoktur; yetki delegasyonu yapan bir üst merci konumundadır.

İkinci katmanda registry'ler bulunur. Her TLD'nin bir registry'si vardır ve o TLD altındaki tüm kayıtların otoritatif veritabanını bu kuruluş tutar. Örneğin .com ve .net uzantılarının registry'si Verisign'dır; .org'un registry'si PIR (Public Interest Registry)'dir. Türkiye'ye özgü ülke kodu TLD'si olan .tr ise Orta Doğu Teknik Üniversitesi bünyesindeki NIC.tr tarafından yönetilir. Registry, ICANN ile imzaladığı sözleşme çerçevesinde TLD'yi işletir; son kullanıcılarla doğrudan ilişki kurmaz.

Üçüncü katmanda registrar'lar yer alır. Bunlar ICANN'den akreditasyon alan ve registry ile doğrudan bağlantı kurma yetkisine sahip kuruluşlardır. GoDaddy, Namecheap, Google Domains (şimdi Squarespace'e devredilmiş), Name.com bunların iyi bilinen örnekleridir. Registrar, son kullanıcının domain kayıt ettirdiği, DNS panelini yönettiği ve yenileme işlemlerini gerçekleştirdiği arayüzü sunar.

IANA (root zone yönetimi, TLD delegasyonu)
  └── Registry — Verisign (.com, .net)
  │     └── Registrar — GoDaddy
  │     └── Registrar — Namecheap
  │     └── Registrar — Name.com
  └── Registry — PIR (.org)
  │     └── Registrar — GoDaddy
  │     └── Registrar — Google (Squarespace)
  └── Registry — NIC.tr (.com.tr, .net.tr, .org.tr)
        └── Registrar — Türk akrediteli kuruluşlar

Bu hiyerarşi katı bir yetki zinciri oluşturur. Registrar, registry'nin izin verdiği aralıkta hareket edebilir; registry ise IANA'nın ve ICANN'ın koyduğu kurallar çerçevesinde işler. Bir registrar'ın teknik altyapısı ya da iş modeli ne olursa olsun, belirli bir TLD'yi kayıt ettirebilmesi için o TLD'nin registry'siyle çalışma ilişkisi kurması zorunludur.

Registry'nin teknik ve idari rolleri

Registry'nin birincil teknik rolü, TLD zone dosyasını yönetmektir. Bu zone dosyası, o TLD altında kayıtlı her domain'in yetkili nameserver'larını (NS kayıtlarını) içerir. Bir kullanıcı registrar panelinden nameserver'larını değiştirdiğinde bu değişiklik EPP (Extensible Provisioning Protocol) üzerinden registry'ye iletilir ve registry TLD zone dosyasını günceller. Değişiklik yayılmaya başlaması için önce bu zone güncellemesinin gerçekleşmesi gerekir.

EPP, RFC 5730 ve ilgili RFC'lerle tanımlanmış standart bir protokoldür. Registrar'lar registry sunucularıyla XML tabanlı bu protokol üzerinden iletişim kurar; domain oluşturma, güncelleme, silme, transfer ve yenileme komutlarını bu kanal üzerinden gönderir. Registry sunucusu gelen komutu doğrular, politika kurallarıyla karşılaştırır ve işler. Son kullanıcı bu protokolü hiçbir zaman doğrudan görmez; registrar'ın arayüzündeki her işlemin arka planında EPP komutları çalışır.

Registry'nin ikinci önemli rolü WHOIS ve RDAP veritabanlarını tutmaktır. Bir domain hakkındaki kayıt tarihi, sona erme tarihi, sponsoring registrar bilgisi ve kayıt sahibi verileri (GDPR öncesi dönemde daha kapsamlıydı) registry'nin veritabanında tutulur. Registrar'ın kendi WHOIS servisi de bu veriyi gösterir, ancak kayıt kaynağı registry'dedir. WHOIS ve RDAP farkları yazısında bu veritabanlarına nasıl sorgu yapıldığı ve iki protokol arasındaki teknik ayrım ayrıntılı ele alınmaktadır.

İdari açıdan registry, TLD'ye özgü politikaları belirler: hangi domain adlarının rezerve edildiği, premium fiyatlandırmanın nasıl uygulandığı, hangi karakterlerin geçerli olduğu ve bazı TLD'lerde kayıt hakkının hangi kriterlere bağlı olduğu (örneğin .edu yalnızca akredite yükseköğretim kurumlarına açıktır) registry'nin belirlediği kurallardır. Registrar bu kurallar içinde hareket eder; kural dışına çıkamaz.

Registrar'ın son kullanıcıya dönük rolleri

Registrar, son kullanıcının domain ekosistemiyle temas kurduğu yüzeyin tamamını oluşturur. Domain müsaitlik sorgusu, kayıt sözleşmesi, ödeme işleme ve yenileme süreçleri registrar katmanında gerçekleşir. Alan adı sorgulama yazısında bu arayüzlerin nasıl çalıştığı ve WHOIS verisiyle nasıl ilişkilendiği anlatılmaktadır.

DNS panel yönetimi de registrar'ın sunduğu bir hizmettir — ancak önemli bir ayrımla. Registrar'ın DNS panelinde yönettiğiniz A, CNAME, MX, TXT gibi kayıtlar registrar'ın kendi nameserver'larında tutulur ve bu nameserver'lar registry TLD zone'undan tamamen bağımsızdır. Registry yalnızca hangi nameserver'ların yetkili olduğunu bilir; o nameserver'ların içindeki kayıtlarla ilgilenmez. Bu ayrım kritiktir: registrar'ı değiştirdiğinizde DNS kayıtlarınız (A, MX vb.) yeni registrar'a otomatik taşınmaz çünkü bunlar registry'de tutulmaz, registrar'ın kendi altyapısında tutulur.

WHOIS gizliliği (privacy proxy veya WHOIS protection) de registrar'ın sunduğu bir hizmettir. Bu özellik etkinleştirildiğinde registry'de gerçek kayıt sahibi bilgisi yerine registrar'ın proxy bilgileri görünür. Registry kaydındaki gerçek veriler silinmez; yalnızca halka açık WHOIS sorgularında gizlenir.

Yenileme bildirimleri, domain sona erme uyarıları ve otomatik yenileme ayarları da registrar tarafından yönetilir. Registry, bir domain'in sona erdiğini tespit ettiğinde bunu registrar'a bildirir; kullanıcıya iletişim kurma sorumluluğu registrar'a aittir. Domain sona erdiğinde ne olduğunu ve grace period mekanizmasını anlamak için domain süresi dolunca ne olur yazısı bu süreci ayrıntılı açıklamaktadır.

Akredite registrar ve reseller farkı

ICANN akreditasyonu, bir kuruluşun registry ile doğrudan EPP bağlantısı kurabilmesi için zorunludur. Akredite registrar, registry sunucusuna doğrudan bağlanır; domain kayıt, transfer ve güncelleme komutlarını kendi adına gönderir. Bu statüyü kazanmak belirli teknik altyapı, mali güvence ve ICANN politikalarına uyum gerektirir.

Reseller ise akredite bir registrar'ın altyapısını kullanarak son kullanıcıya hizmet sunan aracı kuruluştur. Kendi markasında domain satışı yapabilir, kendi DNS panelini sunabilir; ama tüm EPP işlemleri arka planda akredite registrar aracılığıyla gerçekleşir. Registry perspektifinden bakıldığında sponsoring registrar olarak akredite kuruluş görünür, reseller görünmez.

Bu ayrımın pratik önemi şuradan gelir: bir reseller üzerinden kayıt ettirilmiş domain'i transfer etmek istediğinizde, yalnızca reseller'ın arayüzünü değiştirmekle işlem tamamlanmaz. Gerçek transferin tamamlanması için underlying akredite registrar'dan EPP kodu (auth-code) almanız gerekebilir. Bazı durumlarda reseller, EPP kodunu doğrudan veremez ve sizi akredite registrar'a yönlendirmek zorunda kalır. Domain kilidi açma ve EPP kodu edinme süreci bu senaryoda kritik bir adım haline gelir.

Registry (örn. Verisign — .com)
  └── Akredite Registrar A (EPP bağlantısı var)
        └── Reseller X (Registrar A altyapısını kullanır)
        └── Reseller Y (Registrar A altyapısını kullanır)
  └── Akredite Registrar B (EPP bağlantısı var)
        └── Doğrudan son kullanıcıya hizmet

Registrar seçimi yaparken bu katmanı sorgulamak özellikle kurumsal domain portföyleri için önem taşır. Müşteri olduğunuz kuruluşun doğrudan akredite registrar mı yoksa reseller mı olduğunu WHOIS sorgusundan öğrenebilirsiniz: WHOIS çıktısındaki "Registrar" alanı, o domain için EPP yetkisi olan akredite kuruluşu gösterir.

Bir domain kaydında karar sürecinin katmanları

Domain'inize yaptığınız her işlemin hangi katmanda gerçekleştiğini anlamak, sorun giderme süreçlerini büyük ölçüde kolaylaştırır.

Yeni bir domain kaydında süreç şöyle işler: registrar EPP üzerinden registry'ye domain:create komutu gönderir. Registry bu komutu işler, domain'i veritabanına ekler ve TLD zone dosyasına NS kayıtlarını yazar. Bu aşamada registry, kayıt sahibinin kim olduğunu ve hangi nameserver'ların kullanıldığını bilir; başka hiçbir şey bilmez. Domain içeriğini, kullanım amacını veya DNS kayıtlarını (A, MX vb.) registry hiçbir zaman görmez.

Nameserver değişikliğinde registrar, registry'ye domain:update komutu gönderir ve yeni NS kayıtları iletilir. Registry TLD zone dosyasını günceller. Bu güncellemeden sonra TLD nameserver'larına yapılan sorgular yeni NS değerlerini döndürmeye başlar. Propagation süreci bu noktadan sonra başlar — registrar panelindeki değişiklik anında görünür olsa da dünya genelindeki resolver'ların eski değeri önbellekten temizlemesi zaman alır. Nameserver değişikliği yazısında bu sürecin teknik ayrıntıları adım adım açıklanmaktadır.

Domain transferinde karar süreci daha karmaşık bir yol izler. Transfer, bir akredite registrar'dan başka bir akredite registrar'a sponsorluk devridir. Registry'nin tuttuğu domain kaydı aynı kalır; yalnızca "sponsoring registrar" alanı değişir. Transferin gerçekleşebilmesi için mevcut registrar'dan EPP (auth-info) kodu alınması ve kayıt üzerindeki kilitlerin kaldırılması gerekir. Registrar lock ve transfer kontrolü yazısında bu kilitlerin teknik karşılığı olan EPP status kodları ele alınmaktadır.

Registrar değiştirdiğinizde DNS kayıtlarınız (A, MX, TXT vb.) otomatik taşınmaz. Bu kayıtlar eski registrar'ın nameserver'larında tutulur. Transfer tamamlanmadan önce yeni registrar'daki DNS paneline tüm kayıtları elle girmeniz, ardından nameserver'larınızı yeni registrar'a güncellemeniz gerekir. Aksi halde transfer sonrasında web siteniz veya e-postanız erişilemez hale gelebilir.

Registrar değiştirmenin registry'ye etkisi

Domain transferi tamamlandıktan sonra registry kayıtlarında yalnızca bir alan değişir: sponsoring registrar. Domain'in kayıt tarihi, sona erme tarihi, nameserver bilgileri ve kayıt sahibi verileri registry'de olduğu gibi korunur. Transfer, domain'in "sıfırlanması" değil, yönetim yetkisinin devridir.

Transfer süreci tamamlandıktan sonra nameserver'lar değişmediği sürece siteniz veya uygulamanız etkilenmez; çünkü DNS çözümlemesi nameserver'lara bakarak gerçekleşir ve nameserver'lar transfer boyunca aynı kalmaya devam eder. Ancak nameserver'larınız eski registrar'ın DNS hizmetine işaret ediyorsa transfer sonrasında bu nameserver'lara erişim kesintiye uğrayabilir. Eski registrar bazı durumlarda DNS hizmetini transfer tamamlanır tamamlanmaz sonlandırır.

Registry'nin transfer üzerindeki rolü onay sürecinde de görülür. Bir transfer başlatıldığında mevcut registrar, transfer isteğini reddedebilir veya onaylayabilir; belirli bir süre içinde yanıt vermezse transfer otomatik onaylanır. Registry bu iletişimi EPP üzerinden takip eder ve sonucu sponsoring registrar alanına yansıtır. Kullanıcı perspektifinden bu süreç çoğunlukla e-posta onayı ve birkaç günlük bekleme süresi olarak deneyimlenir; arka planda gerçekleşen EPP komut dizisi görünmez kalır. Domain transfer süreci yazısında bu adımların tamamı kullanıcı açısından ele alınmaktadır.

Registrar ve registry arasındaki sınırı kavramak, domain yönetimindeki pek çok "neden" sorusunun yanıtını doğrudan verir. Nameserver değişikliğiniz neden birkaç saat sürdü? Çünkü registrar'dan registry'ye EPP güncellemesi geçmesi ve TLD zone'unun yayılması gerekti. Registrar'ı değiştirdiğinizde neden DNS kayıtlarınız kayboldu? Çünkü bu kayıtlar registry'de değil registrar'ın kendi nameserver'larında tutuluyordu. Transfer sonrası auth-code neden geçersiz hale geldi? Çünkü EPP kodu tek kullanımlıktır ve transfer tamamlanınca geçerliliğini yitirir.

Bu katmanlı yapıyı anlamak aynı zamanda doğru destek kanalını seçmeyi kolaylaştırır. Nameserver'larınız registry'de yanlış görünüyorsa registrar desteğine başvurmanız gerekir — registry'nin son kullanıcıya doğrudan erişim noktası yoktur. Ama bir dispute (anlaşmazlık) durumunda ya da UDRP (Uniform Domain-Name Dispute-Resolution Policy) sürecinde registrar'ı aşan idari mekanizmalar devreye girer ve konu registry ile ICANN katmanında çözüme kavuşur. Her sorunun hangi katmanda çözüleceğini bilmek, gereksiz zaman kaybının ve yanlış yönlendirmelerin önüne geçer.

İlgili Yazılar