Reverse Proxy Kullanırken DNS Nasıl Planlanır?

Reverse proxy, gelen istekleri arka plandaki bir ya da birden fazla sunucuya yönlendiren bir ara katmandır. DNS açısından bakıldığında reverse proxy, domain'in A kaydının nereye işaret etmesi gerektiğini değiştirir: artık origin sunucunun IP'si değil, proxy'nin IP'si kaydedilir. Bu değişiklik basit görünür ama birden fazla domain, wildcard sertifika ve farklı backend'ler söz konusu olduğunda DNS planlaması önemli ölçüde karmaşıklaşır.

Nginx, HAProxy, Caddy ya da Cloudflare gibi çok farklı araçlar reverse proxy olarak çalışabilir. Bunların her birinde DNS'in nasıl yapılandırılması gerektiği biraz farklılaşır. Ama temel ilke değişmez: DNS, isteği doğru kapıya ulaştırır; proxy, o kapıdan giren isteği doğru arka uca yönlendirir.

Proxy IP'si ile origin IP'si arasındaki fark ve DNS kaydı ilişkisi

Reverse proxy olmayan bir yapıda domain'in A kaydı doğrudan sunucunun IP'sine işaret eder. Kullanıcı sirket.com sorgusunu çözdüğünde 93.184.216.34 gibi bir IP alır ve bu IP, web sunucusunun çalıştığı makineye aittir.

Reverse proxy devreye girdiğinde katmanlar artar. Artık iki IP söz konusudur: proxy IP'si (kullanıcının bağlandığı) ve origin IP'si (proxy'nin isteği ilettiği arka uç). DNS, yalnızca proxy IP'sini bilir ve yalnızca onu yayar. Origin IP'si gizli kalır — en azından bu tercih edilen yapıdır.

# DNS: sirket.com → proxy IP
sirket.com.  300  IN  A  203.0.113.10   ; proxy IP

# Kullanıcı isteği akışı:
# 1. DNS sorgusu: sirket.com → 203.0.113.10
# 2. Kullanıcı → 203.0.113.10:443 (proxy'ye bağlanır)
# 3. Proxy → 192.168.1.20:8080 (origin'e iletir)
# 4. Origin yanıtı proxy üzerinden kullanıcıya döner

# Origin IP dışarıya sızdırılmamalı:
# dig @1.1.1.1 sirket.com A +short
203.0.113.10   # yalnızca proxy IP görünür

Origin IP'nin gizli tutulması yalnızca güvenlik açısından değil, operasyonel açıdan da önemlidir. Origin IP doğrudan internete açıksa, proxy'yi bypass eden doğrudan bağlantı denemeleri mümkün olur. DDoS koruması, WAF kuralları ve rate limiting gibi proxy katmanındaki önlemler bu bypass ile devre dışı kalır. Bu nedenle origin sunucu güvenlik duvarı kurallarıyla yalnızca proxy IP'sinden gelen bağlantılara izin verecek şekilde yapılandırılmalıdır.

A kaydı planlaması: tek proxy, çok domain senaryosu

Tek bir reverse proxy birden fazla domain'i yönetiyorsa DNS planlaması buna göre şekillendirilir. Her domain kendi A kaydıyla aynı proxy IP'sine işaret edebilir; proxy gelen isteğin Host başlığına bakarak hangi backend'e yönlendireceğini belirler.

; Her domain aynı proxy IP'sine işaret ediyor
sirket.com.      300  IN  A  203.0.113.10
blog.sirket.com. 300  IN  A  203.0.113.10
api.sirket.com.  300  IN  A  203.0.113.10
musteri.com.     300  IN  A  203.0.113.10

Bu yapıda DNS tarafında yapılacak tek şey her domain için proxy IP'sine işaret eden A kaydı oluşturmaktır. Proxy tarafında ise her domain için ayrı bir sanal sunucu (virtual host / server block) yapılandırılır ve her biri kendi backend adresine yönlendirilir. DNS değişikliği gerektirmeden yeni bir domain eklemek ya da backend değiştirmek proxy konfigürasyonuna dokunmak anlamına gelir.

Alt domain yapılandırması söz konusu olduğunda wildcard A kaydı kullanmak yönetim yükünü azaltabilir. *.sirket.com için proxy IP'sine işaret eden bir wildcard A kaydı, tüm alt domain'leri tek kayıtla proxy'ye yönlendirir. Yeni bir alt domain eklediğinizde DNS kaydı oluşturmak gerekmez; yalnızca proxy konfigürasyonu güncellenir.

sirket.com.   300  IN  A  203.0.113.10
*.sirket.com. 300  IN  A  203.0.113.10

; dig kontrolü:
$ dig yeni-servis.sirket.com A +short
203.0.113.10   ; wildcard eşleşmesi

Cloudflare Proxied modunda DNS planlaması

Cloudflare'in Proxied modu, bir reverse proxy hizmetidir. Kaydı "Proxied" (turuncu bulut) olarak işaretlediğinizde Cloudflare, origin IP'nizi gizler ve trafiği kendi altyapısı üzerinden geçirir. DNS sorgusu artık origin IP'yi değil, Cloudflare'in anycast IP adreslerinden birini döndürür.

Bu modda DNS kaydı olarak origin IP'yi girseniz bile kullanıcılar origin'e ulaşamaz; Cloudflare araya girer. Dolayısıyla Cloudflare Proxied kullanan bir yapıda origin IP'yi gizlemek için ayrı bir konfigürasyona gerek yoktur — bu Cloudflare'in varsayılan davranışıdır. Ancak şunu bilmek gerekir: origin IP'yi başka bir DNS kaydında ya da sertifika loglarında açığa çıkardıysanız, Cloudflare bu sızıntıyı düzeltemez.

; Cloudflare panelinde gördüğünüz (origin IP):
sirket.com.  A  93.184.216.34   [Proxied]

; Dışarıdan gelen DNS sorgusu (Cloudflare IP'si döner):
$ dig sirket.com A +short
104.21.45.67    ; Cloudflare anycast IP
172.67.183.19   ; Cloudflare anycast IP (ikinci)

Cloudflare Proxied moduyla uyumsuz durumlar da vardır. Bazı protokoller HTTP/HTTPS dışında çalıştığından Cloudflare'in standart proxyleme altyapısından geçemez. Mail trafiği (SMTP, IMAP, POP3) bunların başında gelir; MX kayıtları ve bunlara bağlı A kayıtları Proxied değil DNS Only olarak ayarlanmalıdır. Oyun sunucuları, SSH bağlantıları ve bazı API protokolleri de bu kategoriye girebilir. Cloudflare Spectrum gibi ek ürünler bazı protokolleri kapsasa da bunlar standart planda yer almaz.

Sertifika ve SNI davranışı: DNS ile TLS'in kesişimi

Reverse proxy kullanımında TLS sertifikaları, DNS planlamasıyla doğrudan ilişkilidir. SNI (Server Name Indication), TLS el sıkışmasında istemcinin hangi domain için bağlantı kurduğunu proxy'ye bildirmesini sağlar. Proxy bu bilgiye göre doğru sertifikayı sunar ve isteği doğru backend'e yönlendirir.

Bu bağlamda DNS planlamasında dikkat edilmesi gereken iki senaryo vardır. Birinci senaryoda her domain için ayrı sertifika kullanılır. Bu durumda her domain'in A kaydının proxy IP'sine işaret etmesi yeterlidir; proxy SNI üzerinden gelen domain adını okur ve eşleşen sertifikayı sunar. İkinci senaryoda wildcard sertifika kullanılır — örneğin *.sirket.com. Bu durumda wildcard A kaydı ile wildcard sertifika birlikte çalışır; yeni alt domain ekleme süreci yalnızca proxy konfigürasyonunu güncellemeyi gerektirir.

DNS geçiş planlaması: proxy arkasına taşırken TTL yönetimi

Mevcut bir domain'i reverse proxy arkasına taşırken DNS geçişinin nasıl yapılandırılacağı önemlidir. Origin IP'den proxy IP'sine yapılan ani bir A kaydı değişikliği, yüksek TTL değeri nedeniyle saatlerce önbellekte kalabilir. Bu süre boyunca bazı kullanıcılar eski origin IP'sine, bazıları yeni proxy IP'sine ulaşır.

Standart yaklaşım şudur: geçişten 24-48 saat önce TTL değerini 300 saniyeye (5 dakika) düşürün. Bu düşürme işlemi yayıldıktan sonra A kaydını proxy IP'sine değiştirin. Geçiş sorunsuz tamamlandıktan sonra TTL'i tekrar yükseltebilirsiniz.

; 1. Adım — geçişten 48 saat önce TTL'i düşür:
sirket.com.  300  IN  A  93.184.216.34   ; origin IP, TTL 300

; 2. Adım — TTL yayıldıktan sonra proxy IP'ye geç:
sirket.com.  300  IN  A  203.0.113.10   ; proxy IP, TTL 300

; 3. Adım — geçiş stabil olduktan sonra TTL'i yükselt:
sirket.com.  3600  IN  A  203.0.113.10  ; proxy IP, TTL 3600

Geçiş sırasında hem origin hem de proxy'nin aynı içeriği sunduğundan emin olmak kritiktir. DNS propagasyonu tamamlanana kadar bazı kullanıcılar doğrudan origin'e ulaşmaya devam eder. Bu süre için origin'i kapatmak ya da erişimi kesmek hizmet kesintisine yol açar. DNS propagasyon süresini göz önünde bulundurarak geçiş penceresini yoğun olmayan saatlere planlamak operasyonel riski azaltır.

Reverse proxy ile DNS planlamasının kesişimi, çoğunlukla göz ardı edilen ama hata yapıldığında doğrudan erişim sorununa dönüşen bir konudur. Proxy IP'si, origin IP'si, TTL ve sertifika yapılandırması birbirine bağımlıdır; birindeki eksiklik diğerinin çalışmasını etkiler. DNS sorunlarını teşhis ederken hangi katmanda sorun olduğunu ayırt etmek — DNS mi, proxy mi, origin mi — doğru araçla doğru yerde sorgulamayı gerektirir. Bu ayrımı netleştirmek, hem kurulum hem de sorun giderme süreçlerini önemli ölçüde kolaylaştırır.