Alt Alan Adı (Subdomain) Nedir? Kullanım Rehberi

Subdomain nedir, ne işe yarar?

Gece vardiyasında yeni bir servis açarken ilk yaptığım işlerden biri hostname’i belirlemektir. Çünkü api.ornek.com ile panel.ornek.com yalnızca okunaklı isimler değildir; DNS, web sunucusu, sertifika ve erişim politikası bu isimler üzerinden birbirine bağlanır.

Subdomain, Türkçesiyle alt alan adı, ana alan adının altında yer alan isimdir. ornek.com ana alan adıysa blog.ornek.com, panel.ornek.com ve api.ornek.com onun alt alan adlarıdır.

Teknik açıdan subdomain, DNS hiyerarşisinde ana alan adının altında bulunan ve ayrı DNS kayıtlarıyla farklı bir IP adresine, sunucuya ya da hizmete yönlendirilebilen hostnamedir. Yeni bir domain satın almanız gerekmez. ornek.com alan adının DNS yönetimine erişiminiz varsa vps.ornek.com kaydını oradan oluşturabilirsiniz.

Alt alan adı yeni bir alan adı değildir; fakat web sunucusu, uygulama ve DNS açısından ana alan adından bağımsız davranabilir. Bu ayrımı baştan kurmak önemli. DNS kaydı yalnızca trafiğin nereye gideceğini söyler. İsteği karşılayan taraf ise sunucudaki Nginx, Apache veya doğrudan uygulamadır.

Ben subdomain’leri servisleri birbirinden ayırmak için kullanıyorum. Evdeki Proxmox laboratuvarımda monitoring, dosya paylaşımı ve parola yöneticisi aynı makinede çalışsa bile her hizmetin ayrı bir hostname’i olması sertifika ve erişim kurallarını daha anlaşılır tutuyor.

Alan adı hiyerarşisinde subdomain’in yeri

status.ornek.com adresini parçalara ayırırsak, en sağdaki com üst seviye alan adıdır. ornek alan adı, status ise bu alan adının altındaki etikettir. Birden fazla seviye de kullanılabilir:

dev.api.ornek.com

Burada api.ornek.com bir alt alan adı, dev.api.ornek.com ise onun altında yer alan başka bir seviyedir. DNS bu yapıyı destekler. İsim uzadıkça sertifika kapsamı, çerez politikası, log takibi ve kullanıcı deneyimi biraz daha karmaşık hale gelir. İhtiyaç yoksa üç veya dört seviyeli hostname’ler kurmam.

DNS tarafında bir subdomain için farklı kayıt tipleri kullanılabilir:

• A kaydı: Hostname’i IPv4 adresine yönlendirir.
• AAAA kaydı: Hostname’i IPv6 adresine yönlendirir.
• CNAME kaydı: Bir hostname’i başka bir hostname’e yönlendirir.
• MX kaydı: E-posta teslimi için kullanılır; subdomain üzerinde ayrı bir e-posta akışı gerektiğinde karşınıza çıkar.
• TXT kaydı: Doğrulama, SPF, DKIM veya çeşitli servislerin sahiplik kontrolleri için kullanılır.

VPS’inizin IPv4 adresi 203.0.113.20 ise DNS panelinde şu kaydı oluşturabilirsiniz:

Tür: A
Ad: app
Değer: 203.0.113.20
TTL: 3600

Bu kayıt, app.ornek.com adresinin söz konusu IPv4 adresine çözülmesini sağlar. Panel bazı sağlayıcılarda “Ad” alanına yalnızca app, bazılarında ise tam hostname yazmanızı bekler. Alan açıklamasını okumadan kopyala-yapıştır yapmak, DNS tarafında küçük ama can sıkıcı hatalara yol açabiliyor.

Subdomain hangi durumlarda kullanılır?

Alt alan adının güçlü tarafı, aynı alan adı altında farklı işlevleri ayırabilmesidir. Her servise ayrı bir domain almak yerine DNS ve web sunucusu seviyesinde sınırlar kurarsınız.

Blog, mağaza ve dokümantasyon

Kurumsal sitenin ana sayfasını ornek.com, içerik bölümünü blog.ornek.com, ürün kataloğunu da magaza.ornek.com altında çalıştırabilirsiniz. Bu bölümler farklı uygulamalarda veya farklı hosting hesaplarında barınıyorsa subdomain pratik bir bağlantı noktası olur.

Her içeriği otomatik olarak subdomain’e taşımak doğru değildir. Arama motoru açısından blog.ornek.com ayrı bir site gibi değerlendirilebilir. İçeriğin ana domain ile aynı yapı içinde büyümesini istiyorsanız ornek.com/blog biçimindeki alt dizin daha uygun olabilir.

API ve yönetim panelleri

Bir uygulamanın API uçlarını api.ornek.com, kullanıcı panelini panel.ornek.com, durum sayfasını da status.ornek.com altında yayınlamak yaygın bir düzendir. Nginx üzerinde her hizmet için ayrı server bloğu yazabilir, rate limit ve erişim politikalarını birbirinden ayırabilirsiniz.

Geliştirme ve test ortamları

staging.ornek.com veya dev.ornek.com gibi isimler, canlı sistemden ayrılmış test ortamlarında işe yarar. Fakat hostname’in içinde staging yazması sistemi güvenli yapmaz. Ben parola koruması, IP kısıtlaması veya VPN erişimi olmayan test adresini internete açık canlı servis gibi ele alırım.

Harici hizmetleri alan adına bağlamak

Dokümantasyon sağlayıcısı, CDN, yardım masası veya durum sayfası size bir CNAME hedefi verebilir. Servis sağlayıcı customer.example-service.net hedefini verdiyse, DNS tarafında docs.ornek.com için şu kaydı oluşturursunuz:

Tür: CNAME
Ad: docs
Değer: customer.example-service.net
TTL: 3600

CNAME kaydının değerine IP adresi yazılmaz. Kök alan adında, yani doğrudan ornek.com için CNAME kullanımı da birçok sağlayıcıda desteklenmez veya farklı bir mekanizmayla uygulanır. Subdomain seviyesinde ise bu beklenen kullanımdır.

Subdomain ve alt dizin aynı şey değil

ornek.com/blog bir alt dizindir. blog.ornek.com ise subdomain’dir. Tarayıcıda benzer görünseler de DNS, çerez, TLS ve uygulama dağıtımı açısından farklı davranırlar.

Seçimi alışkanlıkla değil, mimari ihtiyaca göre yapın. Blog uygulamasını ayrı bir ekip, ayrı bir sunucu ve ayrı bir yayın döngüsü yönetiyorsa subdomain mantıklıdır. Tek bir WordPress kurulumu içindeki içerik kategorileri için alt dizin çoğu zaman daha az bakım ister.

Benim yaptığım hatalardan biri, ayrı bir uygulama için subdomain açınca her şeyin otomatik olarak izole olacağını düşünmekti. Uygulama aynı veritabanını, aynı Redis’i veya geniş kapsamlı oturum çerezlerini kullanıyorsa hostname’i değiştirmek tek başına sınır oluşturmaz.

DNS panelinde subdomain oluşturma

İlk adım, subdomain’in hangi hizmete gideceğini belirlemektir. Hedef bir VPS ise A veya AAAA kaydı; başka bir hostname ise CNAME; e-posta doğrulaması ise TXT kaydı kullanılır. Kayıt türünü rastgele seçmeyin.

VPS için A kaydı

app.ornek.com adresini bir VPS’e bağlamak için örnek kayıt şöyledir:

app.ornek.com. 3600 IN A 203.0.113.20

Değişiklikten sonra sorguyu terminalden kontrol ederim:

dig +short app.ornek.com

Beklediğiniz IP adresini görüyorsanız kullandığınız DNS sunucusu kaydı çözmüş demektir. Boş çıktı; yanlış kayıt, henüz önbellekten düşmemiş değişiklik veya sorgunun farklı bir DNS sağlayıcısına gitmesi anlamına gelebilir. Ben DNS derdinde panel ekranını yenilemek yerine önce dig +short çalıştırıyorum.

CNAME ile harici hedef

Bir CNAME için sorgu çıktısında hedef hostname’i görebilirsiniz:

dig +short docs.ornek.com
customer.example-service.net.
198.51.100.40

İkinci satır CNAME hedefi, sonraki satır ise hedefin A kaydı olabilir. DNS istemcileri çoğu zaman zinciri sizin için takip eder. Yalnızca IP adresini görmek, kaydın A mı CNAME mi olduğunu göstermez; kayıt tipini ayrıca sorgulamak isterseniz dig docs.ornek.com CNAME kullanabilirsiniz.

TTL ve yayılma süresi

TTL, DNS cevabının önbellekte ne kadar tutulacağını belirler. Kayıt değişikliğinden önce TTL’i düşürmek geçişi hızlandırabilir; daha önce yüksek TTL ile alınmış cevaplar hemen silinmez. “DNS yayılmadı” cümlesi çoğu zaman farklı resolver’ların eski cevabı önbellekten sunması demektir.

DNS değişikliğinin tamamlandığını düşünmeden eski sunucuyu kapatmayın. Taşımalarda bir süre iki sistemi de erişilebilir tutuyor, farklı resolver’larla ve doğrudan yetkili nameserver’larla sorgu alıyorum.

DNS kaydı yetmez: web sunucusunu yapılandırmak

Subdomain IP adresine ulaştığında bağlantı doğrudan istediğiniz uygulamaya gitmez. Sunucudaki web server, gelen isteğin Host başlığına veya HTTPS tarafında SNI bilgisine bakarak doğru yapılandırmayı seçer.

Nginx üzerinde basit bir HTTP sanal host örneği:

server {
    listen 80;
    listen [::]:80;
    server_name app.ornek.com;

    root /var/www/app/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

server_name değeri DNS’teki hostname ile aynı olmalı. Aktif hostname’i kontrol etmeden Nginx reload etmiyorum; geçmişte staging sanılan production değişikliği bana bunu yeterince öğretti. Yapılandırmayı önce test etmek için:

sudo nginx -t
sudo systemctl reload nginx

İlk komut syntax is ok ve test is successful benzeri bir çıktı vermeden reload çalıştırmayın. reload mevcut bağlantıları mümkün olduğunca kesmeden yapılandırmayı yeniler; yanlış upstream veya dosya yolu gibi mantık hatalarını Nginx testi her zaman yakalayamaz.

Apache kullanıyorsanız benzer görev VirtualHost tanımıyla yapılır. DNS’in doğru olması, web sunucusunun doğru siteyi servis edeceğini garanti etmez. Varsayılan site açılıyorsa çoğu zaman sorun DNS’te değil, server_name veya sanal host sıralamasındadır.

HTTPS, sertifikalar ve wildcard subdomain

Her subdomain HTTPS sertifikasında ayrıca kapsanmalıdır. ornek.com için alınmış bir sertifika otomatik olarak app.ornek.com adresini kapsamaz. www.ornek.com da sertifikaya ayrıca eklenmelidir.

Let’s Encrypt ile tek bir subdomain için sertifika alabilirsiniz:

sudo certbot --nginx -d app.ornek.com

Birden fazla isim için:

sudo certbot --nginx -d ornek.com -d www.ornek.com -d app.ornek.com

Certbot’un Nginx yapılandırmasını değiştirmeden önce mevcut dosyayı yedeklemek ve yenileme testini yapmak iyi bir alışkanlıktır:

sudo certbot renew --dry-run

SSL kurulumu için VPS’te SSL Sertifikası Kurulumu: Let’s Encrypt Rehberi başlıklı yazıda DNS doğrulaması, Nginx ve yenileme kontrollerini ayrı adımlarla anlatmıştım.

Wildcard sertifika ne zaman gerekir?

*.ornek.com wildcard sertifikası tek seviyedeki subdomain’leri kapsar: app.ornek.com ve panel.ornek.com gibi. Kök alan adı ornek.com wildcard kapsamına girmez; gerekiyorsa sertifikaya ayrıca eklenmelidir. dev.api.ornek.com da doğrudan kapsanmaz, çünkü wildcard yalnızca bir etiket seviyesini karşılar.

Wildcard sertifikalarda genellikle DNS-01 doğrulaması kullanılır. Bu yöntemde DNS’e geçici bir TXT kaydı eklenir. DNS API anahtarını sunucuda geniş yetkilerle saklamak istemiyorsanız sertifikayı ayrı bir işlemle üretip yalnızca gerekli dosyaları dağıtmayı değerlendirin.

Subdomain kullanırken güvenlik ayrıntıları

Alt alan adı bir güvenlik sınırı değildir. Yalnızca isimlendirme ve yönlendirme katmanında ayrım sağlar. Uygulamanın erişim yetkileri, ağ kuralları ve kimlik doğrulaması ayrıca tasarlanmalıdır.

• Yönetim panelini mümkünse VPN, allowlist veya ek kimlik doğrulama arkasında tutun.
• Test subdomain’lerinde gerçek müşteri verisi kullanmayın; kullanıyorsanız maskeleyin.
• Her subdomain için yalnızca ihtiyaç duyulan portları ve upstream’leri açın.
• DNS’ten silinen bir servisin eski sunucuda hâlâ çalışmadığını kontrol edin.
• Subdomain ele geçirilmelerine karşı kullanılmayan DNS kayıtlarını kaldırın.
• Uygulama sırlarını hostname’e göre değil, güvenli yapılandırma ve erişim politikalarına göre yönetin.

Özellikle unutulmuş CNAME kayıtları dikkat ister. Daha önce kullandığınız harici servis hesabı kapatılmış, DNS kaydı ise bırakılmışsa başka biri aynı hedefi yeniden kaydederek hostname’i ele geçirebilir. Bu senaryo her sağlayıcıda aynı şekilde oluşmaz; kullanılmayan kayıtları temiz tutmak yine de düşük maliyetli bir önlemdir.

Çerez kapsamı da sık atlanan bir konu. Uygulama Domain=.ornek.com ile çerez gönderirse bu çerez ana domain altındaki başka subdomain’lere de taşınabilir. Panel ve kullanıcı uygulaması farklı güven seviyelerine sahipse host-only cookie, yani alan adı belirtilmeyen daha dar kapsamlı çerezler tercih edilebilir.

Sunucu güvenliği için Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım yazısındaki SSH, firewall ve servis azaltma kontrollerini subdomain mimarisinden bağımsız olarak uygulamak gerekir. DNS’te farklı isim kullanmak, açık SSH portunu veya zayıf parolayı düzeltmez.

Wildcard DNS ve çoklu tenant yapıları

Bazen her müşteri veya kullanıcı için ayrı bir subdomain gerekir: firma-a.ornek.com, firma-b.ornek.com gibi. Bu durumda tek tek A kaydı açmak yerine wildcard DNS kullanılabilir:

Tür: A
Ad: *
Değer: 203.0.113.20
TTL: 300

Bu kayıt, özel bir DNS kaydı bulunmayan alt alan adlarını aynı IP’ye yönlendirir. Mevcut kayıtların üzerine yazmaz. DNS yönlendirmesi de uygulamanın tenant seçimini kendi başına yapmaz; Nginx veya uygulama, gelen Host değerinden hangi müşterinin gösterileceğini belirlemelidir.

Wildcard kullanırken yanlış yazılmış hostname’lerin de uygulamaya ulaşması mümkündür. Uygulama yalnızca tanımlı tenant’ları kabul etmeli, bilinmeyen hostname’ler için 404 veya güvenli bir varsayılan cevap vermelidir. Aksi durumda tek bir hatalı yapılandırma, başka bir müşterinin içeriğinin yanlış alan adında görünmesine kadar gidebilir.

Subdomain kaynaklı yaygın hatalar

DNS çözülüyor ama site açılmıyor

Önce dig +short ile IP’yi kontrol edin. IP doğruysa sunucunun 80 ve 443 portlarını dinlediğine, firewall’un trafiği engellemediğine, Nginx server_name tanımının doğru olduğuna ve uygulamanın gerçekten çalıştığına bakın.

sudo ss -ltnp | grep -E ':80|:443'
curl -I http://app.ornek.com
curl -Ik https://app.ornek.com

curl -I yalnızca başlıkları ister. HTTP durum kodu, yönlendirme ve hangi web server’ın cevap verdiği hakkında hızlı fikir verir. Ben 502 gördüğümde DNS paneline dönmek yerine önce Nginx error log’u ve upstream soketini kontrol ederim.

Yanlış site veya varsayılan sayfa geliyor

Bu genellikle DNS’in yanlış olduğunu değil, web sunucusunun istek için eşleşen sanal host bulamadığını gösterir. server_name yazımını, aktif Nginx dosyasının sembolik bağlantısını ve HTTPS için sertifika bloklarını kontrol edin.

Sertifika geçersiz görünüyor

Sertifika subdomain’i içermiyor olabilir veya tarayıcı eski bir yönlendirme ve sertifika zinciri bilgisi tutuyor olabilir. Sunucunun sunduğu sertifikanın konu ve SAN alanlarını şu komutla görebilirsiniz:

openssl s_client -connect app.ornek.com:443 -servername app.ornek.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

-servername seçeneği burada kritik. Aynı IP üzerinde birden fazla HTTPS sitesi varsa SNI ile hangi hostname için sertifika istediğinizi belirtir.

Subdomain e-posta almıyor

Web subdomain’i ile e-posta alan adı aynı şey değildir. mail.ornek.com adresini web sunucusuna yönlendirmek, [email protected] için MX yapılandırması oluşturmaz. E-posta kullanacaksanız MX, SPF, DKIM ve DMARC kayıtlarını sağlayıcınızın istediği biçimde ayrıca tanımlayın.

Taşıma ve işletim sırasında kontrol listem

Yeni bir subdomain açarken şu sırayı kullanıyorum:

1. Hostname’in amacını ve kimin yöneteceğini yazılı hale getiriyorum.
2. Hedef IP, CNAME veya harici servisi doğruluyorum.
3. DNS kaydını oluşturup dig ile yetkili cevabı kontrol ediyorum.
4. Web sunucusunda yalnızca bu hostname’e ait yapılandırmayı ekliyorum.
5. Önce nginx -t, sonra reload çalıştırıyorum.
6. HTTPS sertifikasını alıp yenileme testini yapıyorum.
7. Uygulamanın canonical URL, callback URL, CORS ve çerez ayarlarını güncelliyorum.
8. Monitoring’e HTTP durum kodu, TLS süresi ve mümkünse içerik kontrolü ekliyorum.

Hostname kontrolünü atladığım bir geceyi hâlâ hatırlıyorum. Eski bir test VPS’inde temizlik yaparken rm -rf komutunu yazmış, hedef dizini tamamlamak için Tab tuşuna basmıştım. Shell prompt’unda production hostname’i belirince komutu çalıştırmadan durdum. O günden sonra özellikle tehlikeli işlemlerden önce hostname çıktısını ve aktif terminal sekmesini kontrol ediyorum. Küçük bir duraklama.

Taşıma sırasında eski DNS kaydını hemen silmek yerine kısa bir geçiş penceresi bırakın. Uygulama oturumları, webhook callback adresleri, OAuth dönüş URL’leri ve üçüncü parti entegrasyonlar yalnızca ana sayfayı kullanmayabilir. Bir subdomain’i değiştirmek, görünen web sayfasından daha fazla yeri etkileyebilir.

SEO açısından subdomain seçimi

SEO kararı yalnızca “subdomain mi, alt dizin mi daha iyi?” sorusuyla verilemez. İçeriğin ana siteyle ilişkisi, farklı ekiplerin yayın yapıp yapmadığı, backlink yapısı ve teknik bakım kapasitesi birlikte değerlendirilmelidir.

Blog, yardım merkezi veya dil sürümü ana markanın ayrılmaz parçasıysa alt dizin daha bütünlüklü bir yapı sağlayabilir. Farklı bir ürün, ayrı bir platform veya bağımsız bir topluluk yönetiyorsanız subdomain daha temiz bir ayrım sunar.

Hangi yapıyı seçerseniz seçin canonical etiketleri, sitemap dosyaları, robots.txt, HTTPS ve iç bağlantılar tutarlı olmalıdır. Subdomain’leri yalnızca anahtar kelime yerleştirmek için çoğaltmak bakım yükünü artırır ve arama motoru açısından otomatik bir avantaj sağlamaz.

Analytics ve Search Console yapılandırmasını da kontrol edin. Trafik ölçümünü tek mülk altında mı, ayrı mülklerde mi takip edeceğiniz; çerez kapsamına ve raporlama ihtiyacınıza göre değişir.

Bir subdomain açmadan önce kendinize sorun

Bu isim gerçekten ayrı bir uygulama veya güvenlik politikası gerektiriyor mu? Aynı sunucuda yalnızca farklı bir klasöre gidecekse alt dizin daha sade olabilir. Ayrı bir ekip, deployment süreci, farklı bir IP veya bağımsız bir erişim politikası varsa subdomain anlamlı hale gelir.

Yaşam döngüsünü de düşünün. Test için açılan old-staging.ornek.com aylarca unutulursa sertifika yenilemeleri, DNS kayıtları ve saldırı yüzeyi gereksiz yere büyür. Geçici kayıtların yanına artık silme tarihi koyuyorum; takvimde küçük bir not, aylar sonra yapılacak DNS aramasından daha ucuz.

İsimlendirmeyi baştan standartlaştırın. api, panel, status, staging gibi isimler herkesin anlayacağı kadar açık. Sunucu sayısı arttığında app1-new-final benzeri isimler kısa vadede işe yarasa da birkaç ay sonra kimin ne olduğunu anlatmaz.

Bir subdomain’in arkasında VPS çalıştıracaksanız kaynak planlamasını hostname’den bağımsız yapın. CPU, RAM, disk ve yedekleme ihtiyacını değerlendirmek için VPS Nedir, Ne İşe Yarar? Başlangıç Seviyesi Detaylı Rehber yazısındaki temel ayrımlara bakabilirsiniz. DNS kaydı küçük bir satırdır; arkasındaki uygulama bazen bütün bir sunucu operasyonudur.

Sık Sorulan Sorular

Subdomain oluşturmak için ayrı bir domain satın almak gerekir mi?

Hayır. Ana alan adınız üzerinde DNS yönetimi yapabiliyorsanız istediğiniz subdomain kayıtlarını oluşturabilirsiniz. Subdomain’in bağlanacağı hosting, VPS veya harici hizmetin ayrıca yapılandırılması gerekir.

Subdomain için ayrı SSL sertifikası gerekir mi?

Subdomain, kullanılan sertifikanın kapsamına dahil değilse ayrı bir sertifika veya yeni bir çoklu alan adı sertifikası gerekir. *.ornek.com wildcard sertifikası tek seviyedeki subdomain’leri kapsar; kök domain için ayrıca kapsam tanımlanmalıdır.

Subdomain mi, alt dizin mi kullanmalıyım?

Farklı sunucu, uygulama, ekip veya erişim politikası gerekiyorsa subdomain; ana sitenin parçası olan içerikler için alt dizin genellikle daha sade bir seçimdir. SEO, çerez ve bakım ihtiyaçlarını birlikte değerlendirin.

DNS kaydını ekledim ama subdomain neden açılmıyor?

dig +short sub.ornek.com ile kaydın doğru IP’yi döndürdüğünü kontrol edin. IP doğruysa web sunucusundaki server_name, firewall, portlar, uygulama logları ve HTTPS sertifikası sırayla incelenmelidir.