Alan Adını Hostinge Bağlama: DNS ve SSL Kurulumu

Alan Adını Hosting Hesabına Bağlamak Neden Bu Kadar Önemli?

Yeni bir alan adını kullanıma açarken hosting hesabının alan adını tanıması, DNS kayıtlarının doğru hizmetlere işaret etmesi ve HTTPS’in geçerli bir sertifikayla çalışması gerekir. E-posta kullanıyorsanız onun yönlendirmesi de ayrıca korunmalıdır. Bu rehber, yeni kurulumda ve mevcut bir siteyi taşırken bu işleri doğru sırayla planlamanıza yardımcı olur.

Alan adını hosting hesabına bağlama sırası şöyledir: erişimleri ve hosting hesabını hazırlayın, DNS’in nerede yönetileceğini seçin, kayıtları hazırlayın, ardından gerekli DNS değişikliğini yayımlayın ve HTTPS’i doğrulayın. Nameserver değiştirmek zorunlu değildir; mevcut DNS sağlayıcısında yalnızca web kayıtlarını güncellemek de mümkündür. Örneklerdeki alan adlarını ve IP adreslerini kendi sağlayıcınızın doğruladığı değerlerle değiştirin.

Teknik Temeli Kısaca Netleştirelim: Domain, DNS, Nameserver ve SSL

Adım adım anlatıma geçmeden önce, neyin neyi yaptığını netleştirirsek ileride hata ayıklamak çok daha kolay olur. Bu konuyu genişçe anlattığımız web hosting, domain, DNS ve SSL’in birlikte nasıl çalıştığını anlatan rehbere mutlaka göz atmanızı öneririz; burada ise hızlı bir özet geçelim:

• Alan adı: Kayıt kuruluşundan kaydettiğiniz ve yenilediğiniz isimdir; örneğin example.com.
• Yetkili nameserver: Alan adının DNS bölgesindeki kayıtları yayımlar. Kayıt kuruluşundaki delegasyon, hangi nameserver’lara başvurulacağını belirler.
• DNS kayıtları: Web, e-posta ve başka hizmetler için adres veya hizmet bilgisi taşır. A, AAAA, CNAME, MX, TXT ve SRV kayıtları rehberimiz türler arasındaki farkı açıklar.
• SSL/TLS: Sertifika sunucunun adını doğrulamaya yardımcı olur; TLS, HTTPS bağlantısındaki trafiği şifreler. Geçerli sertifika, doğru sunucu ayarı ve doğru alan adı birlikte gerekir.

Akış, alan adı → yetkili DNS → hizmet adresi → doğru web sitesi şeklindedir. Sunucu da alan adını doğru siteyle eşleştirmelidir. HTTPS kurulumunu doğruladıktan sonra web isteklerini http:// yerine https:// adreslerine yönlendireceğiz.

Adım 1: Erişimleri ve Hosting Hesabını Hazırlayın

Yeni aldığınız alan adını hosting hesabına bağlamak için önce hangi bilgilere ihtiyacınız olduğunu netleştirelim. Bu adımı düzgün yaparsanız, sonraki tüm adımlar daha akıcı ilerler.

• Kayıt kuruluşu ve DNS erişimi: Nameserver değiştirecekseniz kayıt kuruluşuna; kayıtları düzenlemek için yetkili DNS sağlayıcısına erişim gerekir. Yetki devrini mümkünse ayrı kullanıcı ve sınırlı rollerle yapın.
• Hosting bilgileri: Kontrol paneli adresi, hesabın yetkileri, web sunucusunun IPv4 adresi ve varsa doğrulanmış IPv6 adresini alın. Nameserver kullanacaksanız, o hizmete atanmış adresleri ayrıca doğrulayın. Panel adresi örneği https://cp.example.com:2083 gerçek hizmet adresiniz değildir.
• Site ve veri: Uygulama, dosyalar, veritabanı, document root ve yedekleri hazırlayın. Taşımada son veri eşitlemesini, değişiklik sırasında yazma trafiğini ve geri dönüşü planlayın.
• E-posta ve diğer kayıtlar: Mevcut DNS bölgesinin kopyasını alın; MX, SPF, DKIM, DMARC, CAA, SRV ve doğrulama kayıtlarını envantere ekleyin. Nameserver değişikliği bu kayıtları veya posta kutularını otomatik taşımaz.

DNS’i değiştirmeden önce alan adını hosting hesabına ekleyin. Güncel cPanel’de Domains → Create a New Domain → Registered Domain yolunu kullanın; ayrı bir site için Share document root seçimini kaldırıp doğru dizini seçin, aynı içeriği paylaşacak ek alan adı için paylaşım seçeneğini değerlendirin. Özellikler ve kota sağlayıcınıza bağlıdır. Ekleme işlemi henüz taşınmamış DNS nedeniyle engellenirse önce sağlayıcıyla hazırlığı koordine edin. Dosyaları doğru dizine yükleyip alan adı/Host ve TLS SNI eşleşmesini koruyan bir önizlemeyle kontrol edin.

Adım 2: DNS Yönetimini ve Taşıma Planını Seçin

DNS yönetimini mevcut sağlayıcıda tutabilir veya başka bir yetkili DNS hizmetine taşıyabilirsiniz. Mevcut nameserver’lar kalacaksa web için A/AAAA ve gerekli www kaydını orada güncelleyin; e-posta kayıtlarını sırf hosting değişti diye değiştirmeyin. Nameserver taşıyacaksanız yeni DNS bölgesini ve tüm gerekli kayıtları delegasyonu değiştirmeden önce hazırlayın. DCHost planınızın yetkili DNS içerip içermediğini ayrıca doğrulayın.

2.1. Atanmış Nameserver Adreslerini Doğrulayın

Paylaşımlı hosting, VPS veya dedicated sunucunun DNS hizmeti ve yönetim kapsamı farklı olabilir. Yetkili DNS hizmetini kullanacaksanız hizmet detaylarından gerçek nameserver adreslerini alın. Aşağıdakiler yalnızca biçim örneğidir; kayıt kuruluşuna kopyalamayın:

• ns1.example.net
• ns2.example.net

Kesin adresleri:

• DCHost müşteri panelinizde ilgili hosting hizmeti detaylarında,
• Veya size gönderilen karşılama e-postasında

görebilirsiniz; görünmüyorsa sağlayıcıdan doğrulayın. Özel nameserver kullanıyorsanız NS adları ve gerekli glue kayıtları ayrıca hazırlanmalıdır. Nameserver adını bir web sunucusu IP adresiyle karıştırmayın.

2.2. TTL ve Önbellek Sürelerini Planlayın

DNS değişikliğinin görünmesi, sağlayıcının yayınına ve önceden önbelleğe alınmış verinin süresine bağlıdır. 24–48 saat gibi aralıklar kesin sınır değildir. Web kaydının TTL’si, üst bölgedeki NS/DS delegasyonunun önbelleği ve daha önce alınmış NXDOMAIN gibi olumsuz yanıtların süresi farklı olabilir.

• Alan adınız bazı cihazlarda eski yere, bazılarında yeni yere gidebilir,
• Yeni kayıtları görmeyen kullanıcılar “site açılmıyor” hatasıyla karşılaşabilir.

Planlı taşımada değiştireceğiniz kayıtların TTL’sini, önceki TTL süresinin dolmasına fırsat verecek kadar önceden düşürün. Bu işlem zaten önbelleğe alınmış yanıtların veya üst bölgedeki NS/DS kayıtlarının süresini geriye dönük kısaltmaz. Taşıma için TTL stratejileri rehberimiz planlama konusunda yardımcı olabilir; TTL tek başına kesintisizlik garantisi değildir.

Adım 3: Web ve E-posta DNS Kayıtlarını Hazırlayın

Yeni bir DNS sağlayıcısına geçiyorsanız alan adının bölgesini ve aşağıdaki kayıtları orada şimdi oluşturun. Mevcut DNS’i koruyorsanız değişecek web kayıtlarının değerlerini hazırlayın ve kesim anında yayımlayın. Her iki durumda da hosting panelindeki alan adı/site kurulumu hazır olmalı; mevcut e-posta ve doğrulama kayıtları korunmalıdır.

3.1. DNS Yönetim Ekranına Giriş

Kayıtları, alan adınızın yetkili DNS hizmetine gerçekten bağlı arayüzde düzenleyin. Örneğin:

• cPanel DNS bölgenizi yetkili olarak yayımlıyorsa Zone Editor kullanılabilir; görünmeyen kayıtlar veya yetkiler için sağlayıcıya başvurun.
• Yetkili DNS kayıt kuruluşunda ya da üçüncü bir hizmetteyse kayıtları onun panelinde düzenleyin. Hosting panelindeki yerel değişiklik kendiliğinden o hizmete aktarılmaz.

Varsayılan kayıtları kontrol edin; panelin oluşturduğu değerlerin web ve e-posta hizmetinize uyduğunu varsaymayın. DNS sağlayıcısını değiştirirken yeni bölgeyi eski envanterle karşılaştırın; sadece A ve www kaydını kopyalamak yeterli olmayabilir.

3.2. Web Kayıtları: A, AAAA ve www

Örnekler aşağıdadır; gerçek IP adreslerini sağlayıcınızdan alın. @ ve boş alanın anlamı panele göre değişebileceğinden oluşan tam kayıt adını kontrol edin:

• A: example.com için sunucunun IPv4 adresini kullanın; 203.0.113.10 yalnızca belge örneğidir. TTL örneği 3600 saniyedir; taşıma planına göre seçin.
• AAAA: Yalnızca doğru IPv6 adresinde yönlendirme, web dinleyicisi, güvenlik duvarı ve HTTPS/ACME doğrulama yolu çalışıyorsa yayımlayın. Eski veya yanlış AAAA kaydı, A doğru olsa bile bağlantı ve sertifika doğrulamasını bozabilir. IPv6 geçiş rehberimiz hazırlığı ayrıntılandırır.
• www: Örneğin www.example.com CNAME example.com. kullanabilirsiniz; son noktanın veya tam adın nasıl girileceği panele bağlıdır. CNAME hedefine URL yolu değil DNS adı yazılır; aynı www adında çakışan A/AAAA gibi başka veri olmamalıdır.

CNAME, www adının hedef alan adının adres kayıtlarını izlemesini sağlar; tarayıcı adresini değiştiren bir HTTP yönlendirmesi değildir. Kök alan adı ve www, web sunucusunda ve sertifikada ayrıca kapsanmalıdır. Kök adın NS/SOA kayıtlarıyla çakışacağı için standart CNAME’i kök alana eklemeyin; sağlayıcının ALIAS/ANAME veya flattening özelliği varsa ayrı kurallarını kontrol edin. DNS kayıtları A’dan Z’ye rehberimiz ek örnekler sunar.

3.3. E-posta: MX, SPF, DKIM ve DMARC

E-posta hizmetini mevcut sağlayıcıda tutacaksanız onun kayıtlarını ve posta kutularını koruyun. Yalnızca web hosting değişikliği, MX’i yeni web sunucusuna çevirmenizi gerektirmez. Yeni e-posta kurulumunda sağlayıcının verdiği değerleri kullanın:

• MX: Gelen postanın hedef sunucusunu ve önceliğini belirtir; hedef bir DNS adıdır, IP veya CNAME takma adı olmamalıdır. Örneğin mail.example.com kullanılıyorsa o adın adres kaydı gerçek posta sunucusuna gitmelidir; bu örnek bir DCHost mail ayarı değildir.
• SPF: Zarf göndereni/HELO kimliği için yetkili gönderici IP’lerini değerlendirir. Aynı ad için birden fazla SPF politikası oluşturmayın; tüm gerçek gönderim hizmetlerini tek geçerli politikada birleştirin.
• DKIM: Gönderici sunucu özel anahtarla imzalar; alıcı, seçiciye bağlı DNS kaydındaki açık anahtarla doğrular. Sadece TXT kaydı eklemek göndericide imzalamayı açmaz.
• DMARC: Görünen From alan adıyla hizalı ve başarılı en az bir SPF veya DKIM sonucu geçiş sağlayabilir. İkisi de hizalı başarı üretmezse alan adı politikası alıcının yerel değerlendirmesini etkiler; teslimat garanti edilmez.

cPanel kullanıyorsanız Email Routing ayarını da gerçek posta hizmetiyle uyumlu tutun. Otomatik algılama yalnızca yerel zone dosyasına bakar; dış yetkili DNS’i sorguladığını varsaymayın. Harici posta hizmetinde uygun yönlendirmeyi sağlayıcınızla doğrulayın. SPF, DKIM ve DMARC kurulum rehberimiz doğrulama adımlarını ayrıntılandırır.

3.4. CAA ve Hizmete Özel Kayıtlar

CAA, hangi sertifika otoritelerinin alan adı için sertifika düzenleyebileceğini sınırlar. Mevcut CAA kayıtlarının seçtiğiniz CA’yı ve gerekiyorsa wildcard düzenlemeyi yetkilendirdiğini kontrol edin; hata gidermek için bütün CAA kayıtlarını düşünmeden silmeyin. CAA değişikliği mevcut sertifikayı iptal etmez. Bir SSL sertifikası alamıyorsanız, CAA kayıtları rehberimiz üzerinden yetkiyi ve yetkili DNS yanıtlarını kontrol edin. SRV ve sahiplik doğrulama TXT kayıtları gibi diğer hizmet kayıtlarını da koruyun.

Adım 4: Hazırlanan DNS Değişikliğini Yayımlayın

Web sunucusu ve DNS kayıtları hazır olduğunda hangi yolu seçtiğinize göre ilerleyin. Nameserver’ları koruyorsanız yalnızca gerekli web kayıtlarını mevcut yetkili DNS’te güncelleyin. DNS sağlayıcısını değiştirecekseniz yeni nameserver’ların web ve e-posta kayıtlarını doğru yanıtladığını kontrol edip aşağıdaki sırayı izleyin.

DNSSEC açıksa: Eski ve yeni sağlayıcı arasında anahtarları koruyan koordineli geçiş planı varsa onu uygulayın. Böyle bir plan yoksa kayıt kuruluşundan eski DS kaydını kaldırın; eski bölgeyi imzalı ve erişilebilir tutarak üst bölgedeki DS kaydının kalkmasını ve önceki DS TTL’sinin dolmasını bekleyin. Ardından nameserver değiştirilebilir. Bu aralıkta DNSSEC doğrulama koruması yoktur. Yeni delegasyon yerleşip yeni sağlayıcının imzalı bölgesi doğrulandıktan sonra onun verdiği yeni DS kaydını yayımlayın. Yalnızca A/AAAA değiştiriyorsanız DNSSEC’i bu nedenle kapatmanız gerekmez.

1. Alan adını kaydettiğiniz kuruluşun panelinde ilgili alan adını açın.
2. Nameserver / Ad Sunucuları bölümünde özel nameserver kullanımını seçin.
3. Yeni DNS sağlayıcısının gerçekten atadığı tüm nameserver adlarını girin; örnek adresleri kullanmayın.
4. Yeni bölge, e-posta ve varsa DNSSEC hazırlığı tamamlandıysa değişikliği kaydedin.
5. Üst bölgedeki delegasyonu, yetkili sunucu yanıtlarını ve farklı çözümleyicilerin sonuçlarını izleyin; eski DNS/hosting hizmetini önbellek ve veri geçişi tamamlanmadan kapatmayın.

Kayıt kuruluşu yeni delegasyonu yayımladığında çözümleyiciler yeni nameserver’lara ulaşabilir; önbellekteki eski NS ve kayıtlar bir süre kullanılabilir. Bir cihazdaki başarılı sonuç, tüm ağların yeni veriyi gördüğünü kanıtlamaz. Nameserver değişikliği web dosyalarını, veritabanını veya posta kutularını taşımaz.

Adım 5: Sertifikayı ve HTTPS’i Etkinleştirin

Siteyi kullanıcı verisi almaya açmadan önce HTTPS’i doğrulayın. HTTP bağlantısı şifrelenmez; bir sertifika dosyasının bulunması da tek başına çalışan HTTPS demek değildir. Taşımada yeni sunucunun sertifikasını, desteklenen DNS doğrulaması veya uygun doğrulama yönlendirmesiyle kesimden önce hazırlayabilirsiniz; yalnızca yerel hosts dosyası değişikliği CA’nın genel DNS çözümlemesini değiştirmez.

5.1. Let’s Encrypt ile Ücretsiz SSL Kurulumu

Ücretsiz ACME sertifikası ve otomatik yenileme desteği, kullandığınız panelin sürümüne, sağlayıcının ayarlarına ve hesap yetkilerine bağlıdır. cPanel AutoSSL ile DirectAdmin’in ACME arayüzü aynı iş akışı değildir. Let’s Encrypt kurulum rehberimiz ile birlikte hizmetinizdeki güncel arayüz ve destek kapsamını kontrol edin.

Genel akış şu şekildedir:

1. Kök alan adı ve www dahil istenen adların doğrulama yolunu hazırlayın. Let’s Encrypt HTTP-01, port 80 üzerindeki /.well-known/acme-challenge/ yanıtına erişmelidir; CDN, proxy ve birden çok web sunucusu varsa yanıt doğru yere ulaşmalıdır.
2. Yayımlanmış A ve AAAA kayıtlarını kontrol edin. Let’s Encrypt ilk bağlantıda IPv6’yı tercih eder; yanlış IPv6 yanıtını çalışan IPv4 her durumda kurtarmaz.
3. Güncel cPanel’de SSL/TLS Status veya birleşik SSL/TLS Certificates görünümünden kapsamı ve hataları izleyin. AutoSSL’in hesap için etkinleştirilmesi ve çalıştırma yetkisi sağlayıcı/sunucu yönetimine bağlıdır; kullanılabilir işlemleri hesabınızın güncel arayüzünden ve sağlayıcınızdan doğrulayın.
4. DirectAdmin’de özellik açıksa SSL Certificates → ACME settings bölümünü kullanın. Menü ve on-demand işlemler kurulu sürüm ile yetkilere bağlıdır.
5. DNS-01, _acme-challenge altında TXT doğrulaması kullanır ve wildcard alımını destekler; yenileme için yetkili DNS güncellemesi otomatikleştirilebilmelidir. cPanel’in yerleşik Let’s Encrypt wildcard akışı yerel cPanel DNS’i veya DNS kümesini gerektirir; üçüncü taraf DNS’te bu akışın çalışacağını varsaymayın.
6. Düzenleme tamamlanınca sertifikanın gerçek sitede sunulduğunu, adları, zinciri ve geçerlilik süresini kontrol edin.

Otomatik yenilemenin etkin olduğunu doğrulayın; süre ve hata bildirimlerini izleyin. DNS, CAA, HTTP doğrulama yolu veya DNS API yetkileri değişirse yenileme başarısız olabilir. Yeni sertifika alındığını ve hizmetin onu gerçekten sunduğunu düzenli olarak kontrol edin.

5.2. Kurumsal veya Özel SSL Sertifikaları

DV, OV ve EV doğrulama türleridir; wildcard ise kapsanan adlarla ilgilidir. Let’s Encrypt de DNS-01 ile wildcard sertifika düzenleyebilir. *.example.com, www.example.com gibi tek seviye alt adları kapsar; example.com ve a.b.example.com ayrıca kapsanmalıdır. Ücretli sertifika tercihini kuruluş doğrulaması ve hizmet şartlarıyla değerlendirin. Ücretsiz ve kurumsal SSL karşılaştırmamız seçim için ek bağlam sağlar.

5.3. HTTP’den HTTPS’e Yönlendirme ve SEO

SSL sertifikanız kurulduktan sonra, sitenizin hem HTTP hem de HTTPS üzerinden açıldığını görebilirsiniz. Bu durumda:

• Her iki adın HTTPS sertifikası ve site yanıtı doğruysa web isteklerini tercih ettiğiniz HTTPS adresine kalıcı yönlendirin; yol ve sorgu parametrelerini koruyup döngüleri test edin.
• Uygulama URL’lerini, canonical işaretlerini ve iç bağlantıları güncelleyin; 301 yönlendirme arama sıralamasının değişmeyeceğini garanti etmez.
• HSTS’yi ancak HTTPS ve yenileme kararlı olduğunda, kısa süreyle başlayarak değerlendirin. Tüm alt alanlar hazır olmadan includeSubDomains veya preload uygulamayın.

Bu adımları HTTP’den HTTPS’e geçiş rehberimiz ile birlikte değerlendirin. cPanel’de uygun alan adı için HTTPS yönlendirme seçeneği görünüyorsa kullanılabilir; Apache veya Nginx ayarıysa gerçek sunucu mimarisine uymalıdır. Veritabanında URL değiştirmeden önce yedek alın ve serileştirilmiş veriyi koruyan bir araçla önizleme yapın.

Adım 6: DNS, E-posta ve HTTPS’i Test Edin

Alan adının farklı ağlarda beklenen DNS ve site yanıtlarını verdiğini, HTTPS’in doğru adlarla çalıştığını ve e-posta akışının korunduğunu ayrı ayrı kontrol edin.

6.1. Temel Erişim Testleri

• http://example.com ve https://example.com ile www sürümlerini deneyin; yönlendirmelerin doğru hedefe gittiğini kontrol edin.
• Yetkili DNS’teki NS, A, AAAA, MX ve gerekli TXT yanıtlarını envanterle karşılaştırın; farklı çözümleyici/ağlardan sonucu gözleyin.
• IPv6 yayımlanıyorsa onu da test edin. Tek bir A sorgusu, DNSSEC doğrulamasını veya bütün ağların geçişini kanıtlamaz.
• Gerçek e-posta hizmetinde gelen/giden posta, SMTP yönlendirmesi ve kimlik doğrulama sonuçlarını kontrol edin.

NXDOMAIN, sorgulanan adın bulunmadığını bildiren yanıttır ve olumsuz önbellekte kalabilir. SERVFAIL ise DNSSEC doğrulama hatası dahil farklı nedenlerle oluşabilir. Yalnızca beklemek yerine yetkili yanıtları ve delegasyonu kontrol edin. DNS hataları yüzünden site açılmıyor rehberimiz teşhis adımlarını açıklar.

6.2. SSL ve Tarayıcı Uyarıları

Tarayıcının bağlantı ve sertifika ayrıntılarında hata varsa inceleyin; belirli bir kilit simgesinin görünmesi bütün tarayıcılarda ortak bir ölçüt değildir:

• Ziyaret edilen kök alan adı ve www’nin sertifikanın SAN adları içinde bulunduğunu kontrol edin.
• Wildcard’ın kök alan adını veya daha derin alt adları otomatik kapsamadığını unutmayın; doğru sertifika, ara sertifika zinciri ve süreyi inceleyin.
• HTTP ile çağrılan görsel, CSS ve JavaScript gibi mixed content kaynaklarını düzeltin. HTTPS yönlendirmesi, sayfa içindeki bütün HTTP bağlantılarını kendiliğinden düzeltmez.

Bu tip tarayıcı uyarılarını çözmek için SSL sertifika hataları rehberimiz size doğrudan uygulanabilir çözümler sunacaktır.

6.3. SEO ve Performans Kontrolleri

Alan adını hosting hesabına bağlama süreci tamamlandıktan sonra, sitenizi ilk defa yayına alıyorsanız SEO ve performans tarafında da birkaç temel kontrol yapmanızı öneririz. Yeni web sitesi için SEO ve performans kontrol listesi makalemizde; PHP sürümünden GZIP/Brotli sıkıştırmasına, önbellek ayarlarından güvenlik başlıklarına kadar uzanan kapsamlı bir liste bulacaksınız.

Gerçekçi Bir Senaryo

Varsayımsal bir örnek düşünelim: bir ajans, KOBİ için hazırladığı WordPress sitesini yeni hostinge taşıyacak; alan adı başka kayıt kuruluşunda, e-posta ise mevcut hizmetinde kalacak. Amaç, mevcut hizmetleri bozmadan geçişi hazırlamaktır.

Ajansın teknik ekibi şu sırayla ilerliyor:

1. Müşteri, parolasını paylaşmak yerine desteklenen sınırlı yetkiyle ajansa erişim verir veya gerekli değişiklikleri kendisi yapar.
2. Ajans, DNS envanteri ve site/veritabanı yedeklerini alır; e-posta kayıtlarının korunacağını belirler.
3. Alan adını hosting hesabına ekler, doğru document root’u seçer, dosya ve veritabanını hazırlar; dinamik veriler için son eşitleme ve geri dönüş planlar.
4. Mevcut DNS’i tutacaksa web A/AAAA ve www değişikliğini hazırlar. DNS de taşınacaksa yeni bölgeyi tam olarak hazırlar ve DNSSEC/DS sırasını uygular.
5. Kesim zamanında gerekli kayıt veya nameserver değişikliğini yayımlar; eski hizmeti önbellek/veri geçişi tamamlanana kadar açık tutar.
6. dig example.com A ve dig example.com MX gibi ayrı sorguları gerçek alan adıyla kullanıp yetkili DNS ve çözümleyici sonuçlarını karşılaştırır; tek sorguyu küresel yayılım kanıtı saymaz.
7. Panelin desteklediği sertifika akışını tamamlar, kök alan adı ve www üzerinde HTTPS’i doğrular; sonra doğru web sunucusu/uygulama yönlendirmesini açar.
8. Web, IPv6 varsa IPv6, form ve e-posta akışlarını izler; eski hizmeti ancak bağımlılıklar ve trafik kontrol edildikten sonra kapatır.

İşin süresi veri miktarına, hazırlığa, DNS önbelleğine ve sertifika doğrulamasına bağlıdır; sabit bir dakika hedefi vermek doğru olmaz. Kontrol listesi, adımları doğrulanabilir hale getirir. E-ticaret veya başka yazma trafiği olan uygulamalarda DNS planına ek olarak veri tutarlılığı ve gerekirse planlı bakım gerekir.

DCHost ile Hizmet Kapsamını Netleştirin

Paylaşımlı hosting, VPS ve dedicated sunucu seçeneklerinde DNS ve sunucu yönetimi kapsamı farklı olabilir. Colocation gibi kendi donanımınızı içeren bir düzen düşünüyorsanız hizmetin mevcut olup olmadığını ve sorumlulukları ayrıca doğrulayın.

Hizmeti seçerken şu noktaları sorun:

• Yetkili DNS, panel ve alan adı kotası pakete dahil mi; kayıtları kim yönetecek?
• İlk DNS şablonu oluşuyorsa web ve mevcut e-posta sağlayıcısıyla uyumunu kim kontrol edecek?
• Otomatik sertifika düzenleme/yenileme, wildcard ve harici DNS desteği hangi koşullarda sunuluyor?
• Kendi ad sunucularınızı kuracaksanız DNS hizmeti, yedeklilik ve glue kayıtlarından kim sorumlu? Özel nameserver ve glue kayıtları rehberimiz hazırlığa yardımcı olabilir.

Alan adı kaydı, yetkili DNS, web hosting ve e-posta ayrı hizmetlerdir. Aynı firmadan alınmaları tek panel veya aynı yönetim kapsamı garantisi değildir; hizmet detaylarından erişimleri, otomasyonu ve destek sorumluluklarını doğrulayın.

Sonuç: Alan Adını Hostinge Bağlamak İçin Net Bir Yol Haritası

Yeni aldığınız alan adını hosting hesabına bağlamak; doğru sıralamayla ilerlediğinizde karmaşık değil, sadece dikkat isteyen bir süreç. Bu rehberde:

• Kayıt kuruluşu, yetkili DNS, web sunucusu ve TLS’in rollerini,
• Mevcut DNS’i koruma veya tam bölge hazırlığıyla nameserver taşıma seçeneklerini,
• Web ve e-posta kayıtlarını, DNSSEC sırasını ve önbellek planını,
• Panelin desteklediği sertifika akışını ve testten sonra HTTPS yönlendirmesini,
• Kurulum sonrası web, DNS ve e-posta kontrollerini

adım adım özetledik. Artık elinizde; yeni bir proje, kurumsal site ya da e-ticaret girişimi için tekrar tekrar kullanabileceğiniz net bir kontrol listesi var.

Eğer domain ve hosting tarafında daha derine inmek, çoklu alan adlarını yönetmek veya altyapınızı büyütmek istiyorsanız; DCHost blog’ta yeni alan adı sonrası 30 günlük DNS–SSL–e-posta–SEO kontrol listesi ve alan adı portföy yönetimi rehberi gibi daha ileri içerikler de bulabilirsiniz.

DCHost hizmetinizde bir adımda takılırsanız, ilgili alan adını, değişiklik zamanını ve gördüğünüz hata mesajını destek ekibine iletin. DNS, hosting veya e-posta farklı sağlayıcılardaysa değişikliğin hangi hizmette yapılması gerektiğini bu bilgilerle netleştirebilirsiniz.