İnternet nasıl çalışır: domain’den sayfaya teknik yolculuk

İnternet, kullanıcıdan gelen bir isteği tek bir “sayfa” haline getiren bir dizi teknik adımdan oluşur. Bu yolculuk, domain kaydıyla başlar; DNS çözümleme, IP adresi bulma ve ardından tarayıcı-sunucu konuşmasıyla devam eder. Bu yazıda, "domain yazdım ve sayfa açıldı" sürecinin her bileşenini somut adımlar ve karşılaştırmalı örneklerle açıklıyoruz. Böylece hosting, CDN ve DNS ayarlarının neden bu kadar kritik olduğunu daha net yorumlayacaksınız.

1) Domain adı niye yetmiyor? DNS’in görevi ve çözüm sırası

Tarayıcıya bir domain yazdığınızda tarayıcı doğrudan “sayfayı” istemez. Önce domain adını ağın kullanabileceği bir hedefe çevirir: IP adresi.

Bu dönüşüm DNS (Domain Name System) ile olur. DNS sistemi hiyerarşik çalışır ve sorgu zinciri tipik olarak şu şekilde ilerler:

Tarayıcı/istemci, yerel çözümleyiciden (çoğu zaman ISP DNS’i veya özel resolver) domain için kayıt ister.
Resolver, ilgili alan adının authoritative DNS’lerini (alan adının gerçek DNS sunucuları) bulmak için adım adım sorgu yapar.
İlgili kayıt tipi döner: - A kaydı: domain → IPv4 (ör. 93.184.216.34) - AAAA kaydı: domain → IPv6 - CNAME: domain → başka domain (ör. www → example.com)

Hız ve başarım: cache (önbellek) neden fark yaratır?

DNS sorguları her seferinde zincir boyunca tekrar edilmez. Resolver cache’ler. Cache süresi DNS kaydında TTL (Time To Live) olarak tanımlıdır.

TTL kısa: Değişiklikler (IP güncelleme) daha hızlı yayılır; ancak sorgu trafiği artabilir.
TTL uzun: DNS daha stabil ve az sorgu oluşur; fakat IP değişimlerinde yayılma yavaşlar.

Aynı domain için bir kullanıcı 30 saniyede yeni IP’ye giderken, başka bir kullanıcı saatler sonra gidebilir. Bu fark, geçiş planı yapan hosting kullanıcıları için pratikte en çok yaşanan konudur.

2) IP bulundu: tarayıcı hedef sunucuyla nasıl bağlantı kurar?

DNS bittiğinde tarayıcıda artık hedef IP vardır. Sıradaki iş, veri alışverişi için uygun taşıma katmanını kurmaktır.

TCP mi? QUIC/HTTP-3 mü?

HTTP katmanı uygulamadır; fakat önce bağlantı kurulur. Geleneksel akışta: - Tarayıcı → sunucu: TCP üçlü el sıkışma (SYN, SYN-ACK, ACK) - Ardından TLS ile güvenli kanal kurulur (HTTPS)

HTTP-3 (QUIC) devreye girdiğinde ise: - TCP yerine QUIC (UDP tabanlı) kullanılır - Bağlantı kurulum adımları farklıdır

Bu konuda kritik nokta şu: DNS doğru dönse bile, ağ katmanında gecikme/packet kaybı varsa sayfanın açılması değişebilir. Bu nedenle CDN veya lokasyon tabanlı routing (rota seçimi) önemli hale gelir.

3) HTTPS geldi: TLS konuşmasının “kimlik doğrulama” kısmı

HTTPS istekleri için tarayıcı, sunucuyla güvenli görüşme başlatır. Bu aşamada TLS (Transport Layer Security) devrededir.

TLS tarafında iki temel ihtiyaç var: 1. Sunucu “ben doğru kişiyim” diyebilmeli (sertifika doğrulaması) 2. Şifreleme anahtarları güvenli kurulmalı

Sertifika neden domain ile ilişkilidir?

Sertifika, domain adını kapsamalıdır (SAN/Wildcard vb.). Sertifika doğrulaması tarayıcıda gerçekleşir. Sertifika hatalı/yanlışsa tarayıcı sayfayı açmaz veya kullanıcı uyarı görür.

Burada hosting seçiminin ve otomasyonun rolü şudur: - Sertifikanın güncel kalması (yenileme) - Sertifikanın doğru virtual host’a bağlanması - Gerekirse ara sertifikaların zincir halinde doğru servis edilmesi

Bu zincir düzgün kurulmazsa “DNS çalışıyor ama sayfa açılmıyor” senaryosu yaşanır.

4) HTTP istekleri: tarayıcının sayfa için ne sorduğu

TLS tamamlandığında sıra HTTP isteğine gelir. Tarayıcı genellikle sayfa açmak için bir dizi istek atar:

İlk istek: HTML (ör. GET /)
Sonra CSS, JavaScript, görseller (ör. GET /assets/app.js)
Gerekirse API çağrıları (ör. GET/POST /api/...)

HTTP yöntemleri ve durum kodları neden önemlidir?

İletişim, HTTP durum kodlarıyla okunur: - 200: içerik geldi - 301/302: yönlendirme - 403: erişim reddedildi - 404: kaynak bulunamadı - 500/502/503/504: sunucu veya aradaki bileşen kaynaklı hata

Örneğin 504 (Gateway Timeout) görüyorsanız, sorun salt “hosting yavaş” değildir. CDN, reverse proxy (Nginx/HAProxy), load balancer gibi katmanlardan biri upstream’e zamanında yanıt veremiyor olabilir.

5) CDN, cache ve WAF: “sayfayı sunmak” sadece sunucu değildir

Birçok sitede istekler doğrudan origin (orijinal sunucu) yerine CDN üzerinden akar. CDN’in mantığı basittir: - İlk istek origin’den gelir, içerik cache’e alınır. - Sonraki istekler cache’den döner.

Bu şu sonuçları doğurur: - Daha kısa yanıt süreleri - Origin sunucu yükünde azalma - Bazı saldırılara karşı katman bazlı koruma (WAF)

CDN + WAF + Rate limiting: davranış farkı

CDN/edge katmanında WAF (Web Application Firewall) ve rate limiting uygulanabilir. Bu bileşenler, istek davranışına göre: - zararlı örüntüleri engeller - belirli IP/anahtar bazında aşırı istekleri yavaşlatır - bazı istekleri challenge ile doğrulatır

Net etkiler somut olarak şunlardır: - Bir kullanıcının “bazen açılıyor bazen açılmıyor” dediği durumlarda, rate limiting veya WAF kuralı tetikleniyor olabilir. - CDN cache davranışı yanlış ayarlanırsa güncel içerik yerine eski içerik dönebilir.

Bu yüzden hosting tarafında değil, DNS-CDN-uygulama zincirinde de inceleme yapmak gerekir.

6) Domain’den sayfaya giden yolun “uçtan uca” haritası

Şimdi tüm süreci tek bir şema gibi düşünün. Aşağıdaki tablo, en sık görülen bileşenleri ve kontrol edilecek noktaları özetler.

Adım	Bileşen	Ne olur?	Kullanıcının yaşadığı tipik sorun
1	Tarayıcı/istemci	Domain’i DNS’e sorar	DNS hatası, NXDOMAIN
2	Resolver	Cache/TTL doğrular, yetkiliye gider	Eski IP’ye gitme
3	DNS kaydı	A/AAAA/CNAME ile IP veya hedef döner	Yanlış kayıt, yanlış hedef
4	IP bağlantısı	TCP/QUIC bağlantısı kurulur	Bağlantı zaman aşımı
5	TLS	Sertifika doğrulanır	Sertifika hatası, uyarı
6	HTTP	HTML/CSS/JS/APIs istenir	403/404/5xx
7	CDN/WAF (varsa)	Edge cache/koruma uygular	Bazı isteklerde tutarsız davranış
8	Origin (hosting)	Uygulama çalışır, içerik döner	Performans düşüşü, 5xx artışı

7) DNS değişikliği yaptıysanız: TTL, propagasyon ve doğrulama

Domain’den sayfaya yolculukta en sık yapılan hata şudur: IP değiştirilir ama TTL ve cache davranışı hesaba katılmaz.

Pratik geçiş planı (IP veya isim değişikliği)

Değişiklikten önce TTL’i düşürün. - Amaç: Resolver cache’lerinin daha hızlı güncellenmesi.
Kayıtları doğru doğrulayın. - A/AAAA ve CNAME zincirini kontrol edin.
Son kontrol: Farklı lokasyonlardan doğrulayın. - Çünkü cache yayılımı aynı hızda olmayabilir.

Hangi kayıt seti kritik?

Apex (root) domain: example.com
Genelde A/AAAA kullanılır; bazen provider ALIAS/ANAME yaklaşımı sunar.
www alt alan adı: www.example.com
Sıklıkla CNAME ile apex’e bağlanır.
CDN kullanılıyorsa: CNAME/A kaydı CDN edge yönlendirmesini temsil eder.

Burada doğruluk, sayfanın açılmasını doğrudan etkiler.

8) Yönlendirmeler ve köprüler: CNAME, reverse proxy ve sanal hostlar

Hosting tarafında aynı IP’ye birden fazla site bind edilebilir. Bu da “doğru siteye doğru istek gitmesi” anlamına gelir.

HTTPS’te tarayıcı SNI (Server Name Indication) kullanarak doğru sertifikayı seçer.
Reverse proxy (Nginx/Apache) Host header’ına göre ilgili uygulamaya yönlendirme yapar.

Bu zincir yanlış konfigüre edilirse: - DNS doğru döner ama başka bir site görüntülenir - Sertifika uyumsuzluğu yüzünden uyarılar çıkar

Kontrol listesi

Domain için Host header uygulamada doğru mu?
Sertifika o domain için geçerli mi?
Reverse proxy routing doğru mu?

9) Performans ölçümü: “sayfa açılıyor mu”dan fazlası

Sayfanın açılmasını etkileyen tek şey sunucu değildir. DNS, TLS kurulumu, CDN cache ve uygulama yanıtı birlikte çalışır.

Ölçümde bakılacak metrikler

DNS çözüm süresi (ilk adım)
Bağlantı süresi (TCP/QUIC)
TLS kurulumu süresi (HTTPS)
HTML TTFB (ilk yanıt süresi)
Kaynak yüklenme süreleri (CSS/JS/görseller)

Bir sayfa açılıyorsa bile, bazı kullanıcı segmentlerinde performans düşebilir. Örneğin IPv6 yolu daha hızlı ama yanlış yapılandırılmışsa bazı kullanıcılar daha uzun süre bekler.

10) Güvenlik perspektifi: domain, DNS ve uygulama katmanı birlikte değerlendirilir

Domain’den sayfaya yolculuk güvenlik açısından da çok katmanlıdır. Basit bir DNS yanlışlığı bile kullanıcıyı başka bir hedefe taşıyabilir.

DNS’in güvenliği için koruma yaklaşımı şunları kapsar: - DNS sahteciliğine karşı bütünlük doğrulaması - Cache poisoning gibi saldırılarda zincir kontrolü

Bu yüzden DNS altyapısını ve hosting tarafındaki doğrulamaları birlikte düşünmek gerekir.

Sonuç: Planlı değişiklik yapın, uçtan uca kontrol edin

İnternet yolculuğunu domain → DNS → IP → TCP/QUIC → TLS → HTTP → CDN/WAF → origin şeklinde parçaladığınızda hata ayıklama hızlanır. Aksiyon olarak şu sırayı izleyin: (1) DNS kayıtlarını ve TTL’i doğru planlayın, (2) HTTPS/TLS tarafında sertifikanın doğruluğunu kontrol edin, (3) CDN/WAF varsa cache ve kural etkilerini inceleyin, (4) 4xx/5xx durum kodları ve yanıt süreleriyle kök nedeni bulun.

Bu yaklaşım, “neden sayfa açılmıyor” sorusunu tahminden çıkarıp somut kontrole dönüştürür.