DNS nedir ve VPS baglantisi nasil yapilir?

DNS nedir ve alan adınız neden henüz VPS'nize ulaşmıyor

DNS (domain name system), example.com gibi bir ismi 203.0.113.10 gibi bir IP (internet protocol) adresine dönüştürür. Bir tarayıcı bir isme bağlanamaz. Bir adrese bağlanır, bu nedenle her sayfa yükleme işlemi bir DNS sorusu ve cevabı ile başlar. Yeni bir alan adı ve kendi VPS'nizi satın aldıysanız ve hiçbir şey yüklenmiyorsa, şu iki durumdan biri geçerlidir: ismi sunucunuzun adresine bağlayan bir kayıt henüz yoktur ya da bir kayıt vardır ancak yol üzerindeki bir nokta hala eski bir cevabı iletiyordur.

Her iki durum da normaldir ve hiçbir şeyin bozuk olduğu anlamına gelmez. Aşağıdaki bölümler, parçaları karşılaşacağınız sırayla ele alır; en çok zaman kaybettiren kısımla, yani kayıtlarınızı gerçekte hangi kontrol panelinin tuttuğuyla başlar.

Buradaki her kontrol, yeni bir Ubuntu veya Debian makinesinde varsayılan olarak yüklü olmayan dig aracını kullanır.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver ve DNS sağlayıcı: hangisinde düzenleme yapmalı

Bu üç isim farklı görevleri tanımlar. Bunları birbirine karıştırmak, yapılan bir düzenlemenin hiçbir şeyi değiştirmemesinin en yaygın nedenidir.

• Registrar (Alan adı kayıt kuruluşu), alan adını satın aldığınız şirkettir. Kritik görevi yetkilendirmedir: TLD'nizi (üst düzey alan adı, yani .com kısmı) yöneten kayıt kuruluşuna, alan adınız için hangi nameserver'ların yetkili olduğunu bildirir.
• Yetkili nameserver'lar, bölgeniz (zone) için gerçek kayıtları tutar. Bölge, alan adınızı ve altındaki isimleri ifade eder.
• DNS sağlayıcı, bu nameserver'ları işleten taraftır. Bu, registrar'ın kendisi, ayrı bir sağlayıcı veya kendi sunucunuzda çalışan bind9 olabilir.

Satın alma işlemini registrar üzerinden yaparsınız. Düzenlemeyi ise DNS sağlayıcıda yaparsınız. Alan adınızı başka bir sağlayıcının nameserver'larına taşıdıysanız, registrar'ın kendi DNS paneli size hala bir bölge gösterir ve düzenlemelerinizi kaydeder; ancak internetteki hiç kimse o bölgeye soru sormaz. Kayıtlar gerçektir. Sadece hiçbir zaman başvurulmazlar.

Dünyanın nereye soru sorduğunu öğrenin:

dig example.com NS +short
dig +trace example.com

İlk komut, bugün alan adı için yanıt veren nameserver'ları yazdırır. İkincisi, kök sunuculardan başlayan zinciri takip eder ve TLD sunucularının verdiği yönlendirmeyi yazdırır; bu, registrar'ınızın kontrol ettiği yetkilendirmedir. Eğer bu isimler tanımadığınız bir sağlayıcıya aitse, ihtiyacınız olan panel o sağlayıcıya aittir.

Tek bir sorgunun izlediği yol

Bu süreçte dört taraf yer alır ve her biri öğrendiği bilginin bir kopyasını tutar.

1. Makinenizdeki stub resolver. Kendisi arama yapmaz. Yapılandırılmış tek bir sunucuya sorar ve gelen cevaba güvenir. Ubuntu üzerinde /etc/resolv.conf genellikle /run/systemd/resolve/stub-resolv.conf dosyasına sembolik bir bağdır (symlink) ve yerel olarak kendi önbelleğiyle çalışan systemd-resolved olan 127.0.0.53 servisini işaret eder.
2. Recursive resolver. Bu, ISP'niz (internet servis sağlayıcınız) tarafından çalıştırılan, 1.1.1.1 gibi herkese açık bir servis veya bizzat sizin çalıştırdığınız bir çözümleyicidir. Cevabı bulmak için asıl işi yapan budur.
3. Root ve TLD sunucuları. Recursive resolver, kök (root) sunucuya sorar; kök sunucu adresinizi bilmez ancak .com sunucularına bir yönlendirme ile cevap verir. Onlar da sizin isim sunucularınıza (nameservers) yönlendirme yapar.
4. Authoritative nameserver. Kimseye sormaz. Kendi bölgesindeki (zone) bilgilerle cevap verir ve cevabı yetkili (authoritative) olarak işaretler.

dig +trace example.com, bu işlemin gerçekleştiğini size gösterir; çünkü sorguya kök dizinden başlar ve bir önbelleğe sormak yerine her yönlendirmeyi ekrana yazdırır. Delegasyon ile bölge (zone) ayarlarının birbiriyle uyumlu olup olmadığını görmenin en hızlı yolu budur.

Sunucu çalıştırırken önemli olan DNS kayıtları

• A: bir ismi IPv4 adresine eşler. example.com. A 203.0.113.10. Alan adınızı VPS'nize yönlendiren kayıt budur.
• AAAA: bir ismi IPv6 adresine eşler, örneğin 2001:db8::10. Yalnızca servisiniz gerçekten bu adreste dinleme yapıyorsa yayınlayın. IPv6 ağlarındaki istemciler önce AAAA yanıtını dener; bu nedenle yanıt vermeyen bir adres, her ziyarette gecikmeye neden olur.
• CNAME: bir isimden diğerine takma ad (alias) oluşturur. www.example.com. CNAME example.com., www ziyaretçilerini çıplak alan adının çözümlendiği yere gönderir. CNAME, kök dizinde (çıplak example.com) bulunamaz; çünkü kök dizin kendi SOA (yetki başlangıcı) ve NS kayıtlarını taşımalıdır ve bir CNAME'in başka bir kayıtla aynı ismi paylaşmasına izin verilmez. Sağlayıcılar, ALIAS, ANAME veya CNAME flattening gibi isimler altında geçici çözümler sunar.
• MX: alan adı için postaların nereye teslim edileceğini belirler. Bir ana bilgisayar adı ve bir öncelik numarası içerir; daha düşük olan numara önce denenir. Bir MX, adres kaydı olan bir isme işaret etmelidir. Bir CNAME'e işaret etmek geçersizdir ve bazı gönderici sunucular bunu reddeder.
• TXT: kanıt ve politika için kullanılan serbest metin alanıdır. Posta kimlik doğrulama kayıtları (SPF, DKIM, DMARC) ve joker karakterli sertifika düzenleyen ACME (otomatik sertifika yönetim ortamı) belirteci burada yer alır.
• NS: bölgeye (zone) hangi isim sunucularının hizmet vereceğini belirler. Dünyanın nereye soracağını belirleyen kopya, kendi bölgenizdeki kopya değil, üst bölgede yer alan ve kayıt kuruluşunuzun delegasyonundan gelen kopyadır.

İki detay, kayıt türlerinin kendisinden daha fazla kafa karışıklığına neden olur. Nokta ile biten bir isim mutlak kabul edilir, bu nedenle www.example.com. tam olarak o anlama gelir ve fazlası değildir. Çoğu panel göreceli bir isim bekler ve alan adını sizin yerinize ekler; bu nedenle isim kutusuna www.example.com yazmak, kimse için çözümlenmeyen www.example.com.example.com sonucunu verir. Diğer detay ise @ ifadesidir; bu, neredeyse her panelde kök dizin anlamına gelir: yani alt alan adı olmayan, doğrudan alan adının kendisi.

A kaydını VPS adresinize yönlendirme

Öncelikle sunucunuzun internet üzerinden görünen adresini öğrenin:

curl -4 https://ifconfig.me
ip -brief -4 address show

Ardından DNS sağlayıcınızda bir kayıt oluşturun: tür olarak A, ad olarak @ seçin, değer kısmına sunucu adresinizi girin ve TTL (yaşam süresi) değerini 300 olarak ayarlayın. www için ikinci bir kayıt ekleyin; bu kayıt ya aynı adrese sahip başka bir A ya da kök dizini işaret eden bir CNAME olabilir.

Şimdi çözümlemenin çalıştığını, tercihen sunucunun kendisinden değil dizüstü bilgisayarınızdan doğrulayın:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

İlk komut, önbellekler dahil olmak üzere makinenizin normal yolunu kullanır. İkincisi yerel önbelleği atlar ve herkese açık bir özyinelemeli çözümleyiciye (recursive resolver) sorar. Üçüncüsü ise doğrudan yetkili isim sunucunuza (authoritative nameserver) sorar; bu nedenle aldığı yanıt, hiçbir önbellek katmanı içermeyen güncel gerçektir. Üçüncü komut adresinizi döndürüyor ancak ilki döndürmüyorsa, DNS yapılandırmanız doğrudur ve yalnızca eski yanıtın önbellekten silinmesini bekliyorsunuz demektir.

Çözümleme yüklenmiyor

İsim çözümleme, DNS'in çalıştığını kanıtlar. Web sunucunuz hakkında hiçbir şey kanıtlamaz. dig doğru adresi döndürdüğünde, bağlantıyı test edin:

curl -I http://example.com

curl: (6) Could not resolve host: example.com bir DNS sorunudur. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused bir DNS sorunu değildir: isim çözümlenmiş ve paket ulaşmıştır, dolayısıyla sorun o portta hiçbir şeyin dinlemede olmamasıdır. Asılı kalan ve ardından zaman aşımına uğrayan bir istek, genellikle güvenlik duvarının paketi reddetmek yerine sessizce düşürdüğü anlamına gelir. DNS konusunun bittiği ve portlar ve dinleme soketleri ile VPS üzerindeki ufw güvenlik duvarı kuralları konusunun devraldığı nokta burasıdır. Bağlantı tamamlandıktan sonra, sayfa yüklemesinin geri kalanı HTTP'nin kendi işini yapmasıdır.

Tarayıcı neden hala eski ana bilgisayarı gösteriyor

Hiçbir şey kendiliğinden yayılmaz. Hiçbir sunucu, yaptığınız değişikliği dışarıya doğru zorla göndermez. Yetkili isim sunucunuz (authoritative nameserver), siz kaydettiğiniz anda yeni değeri tutar; ancak önceki cevabın her bir önbellek kopyası, kendi zamanlayıcısı dolana kadar geçerli kalır. Bu zamanlayıcı, kayıt iletildiğinde üzerinde taşıdığı saniye cinsinden TTL değeridir.

Kopyalar insanların tahmin ettiğinden daha fazla yerde yaşar: tarayıcının kendi kısa süreli önbelleği, makinedeki stub resolver, ağın kullandığı recursive resolver ve istemciye yüklenmiş bir VPN'in kullandığı herhangi bir çözümleyici. Her biri, aldığı TTL süresi boyunca kendi kopyasını tutar. İki farklı ağdaki iki kişi saatlerce iki farklı cevap görebilir ve her iki makine de doğru şekilde davranıyordur.

Bir önbellekleme çözümleyicisine karşı geri sayımı izleyin:

dig @1.1.1.1 example.com +noall +answer

Bunu birkaç saniye arayla iki kez çalıştırın. Cevaptaki TTL değerinin düştüğünü göreceksiniz. Değer sıfıra ulaştığında, çözümleyici kaydı atar ve isim sunucunuza tekrar sorar.

Neredeyse kimsenin hesaba katmadığı ikinci bir önbellek türü daha vardır: negatif cevaplar. Bir çözümleyiciye bir ismin mevcut olmadığı söylendiğinde, bölge (zone) SOA kaydınızın son alanında belirlenen süre boyunca bu NXDOMAIN cevabını da önbelleğe alır.

dig example.com SOA +short

O satırdaki son sayı negatif TTL değeridir ve genellikle 3600'dür. Bu nedenle, staging.example.com kaydını oluşturmadan önce sorgulamak, kaydı oluşturduktan sonra bile bir saat boyunca onu görmenizi engelleyebilir. Önce kaydı oluşturun, sonra sorgulayın.

İsim sunucularını değiştirmek, bir kaydı değiştirmekten daha yavaştır ve bunun nedeni mekaniktir. .com bölgesindeki yetkilendirme (delegation) kayıtları 172800 saniyelik, yani iki günlük bir TTL ile sunulur. Bu yüzden eski isim sunucularınızı önbelleğe alan bir çözümleyici, o süre boyunca onlara sormaya devam edebilir. "48 saate kadar bekleyin" tavsiyesi buradan gelir. Bu durum isim sunucusu değişiklikleri için geçerlidir, sıradan kayıt düzenlemeleri için değil.

Bir geçiş sürecini TTL ile savaşmak yerine ona göre planlayın:

1. Kaydın TTL değerini 300'e düşürün ve kaydedin.
2. Eski TTL süresinden daha uzun süre bekleyin; böylece eski değeri taşıyan tüm önbellek kopyalarının süresi dolmuş olur.
3. Adresi değiştirin.
4. Trafik taşındıktan sonra TTL değerini tekrar 3600 veya daha yüksek bir seviyeye çıkarın; çünkü düşük TTL, her çözümleyicinin isim sunucularınıza çok daha sık soru sorması anlamına gelir.

Kendi makinenizin tuttuklarını temizlemek için:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics, isabet ve ıskalama sayaçlarını içeren bir önbellek bölümü yazdırır; bu nedenle temizleme işleminden hemen sonraki ilk sorgu ıskalama (miss) olarak görünür. Tarayıcılar ayrı bir önbellek tutar, bu da sistem önbelleği boş olsa bile Chrome'un eski bir cevabı kullanmaya devam edebileceği anlamına gelir. Onu chrome://net-internals/#dns üzerinden temizleyin. Ayrıca /etc/hosts dosyasını da kontrol edin; çünkü oradaki artık bir satır, o makinedeki DNS sorgusunu geçersiz kılar ve sadece o makineyi etkiler. getent hosts example.com, sistemin gerçekten kullanacağı cevabı, /etc/hosts dahil olmak üzere gösterir.

Wildcard sertifikaları TXT kaydı ile doğrulanır

Bir CA (sertifika yetkilisi), sertifika düzenlemeden önce alan adı üzerindeki kontrolü denetler. HTTP-01 sınaması, ilgili ana makine adında 80 numaralı port üzerinden bir dosya sunar; bu yöntem tek bir alan adı için sorunsuz çalışır. Wildcard sertifikası, CA'nın dosya çekemeyeceği ucu açık bir ana makine adı kümesi olan *.example.com ifadesini kapsar; bu nedenle Let's Encrypt, wildcard sertifikalarını yalnızca DNS-01 sınaması aracılığıyla düzenler. CA tarafından verilen bir belirteci içeren TXT kaydını _acme-challenge.example.com adresinde yayınlarsınız ve bölge üzerindeki kontrolünüz bu şekilde kanıtlanmış olur.

Bu durum, DNS sağlayıcınızı sertifika yenileme sürecinin bir parçası haline getirir. Certbot, her yenileme işleminde bu TXT kaydını sizin müdahaleniz olmadan oluşturup silmek zorundadır; bu nedenle bir API'ye ve sağlayıcınızla uyumlu bir eklentiye ihtiyaç duyar. Doğrulama başarısız olduğunda genellikle DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com mesajı alınır; bu, CA'nın kayıt görünür hale gelmeden önce sorgu yaptığı anlamına gelir: kayıt hiç kaydedilmemiş olabilir veya olumsuz bir yanıt önbellekte tutuluyor olabilir. İşlemin tamamı DNS-01 sınaması ile wildcard sertifikaları rehberi içerisinde yer almaktadır.

VPN, çözümleyicinizi devraldığında

Bir VPN (sanal özel ağ) istemcisi, bağlı olduğu süre boyunca normalde sistem çözümleyicisinin yerini alır; çünkü sorguları yerel ağa göndermek, ziyaret ettiğiniz her sitenin adını o ağa bildirmek anlamına gelir. Bu doğru bir davranıştır ancak iki yönde de başarısız olabilir.

Tünel kurulduğunda adresler çalışmaya devam ederken ad çözümleme durursa, istemcinin yüklediği çözümleyici tünel içinden erişilemez durumdadır. ping 1.1.1.1 başarılı olur ve curl https://example.com, curl: (6) Could not resolve host: example.com değerini döndürür. Eğer tünel kurulmasına rağmen sorgular hala bulunduğunuz yerel ağa gitmeye devam ediyorsa, trafiğiniz tünelleniyor olsa bile yerel çözümleyici sorduğunuz her adı görmeye devam eder.

resolvectl status

Bu komut, her bağlantı için kullanımda olan çözümleyiciyi yazdırır; böylece tünelin hangisini yüklediğini ve bunun amaçladığınız çözümleyici olup olmadığını görebilirsiniz. Bir WireGuard tüneli bunu istemci yapılandırmasındaki DNS = satırından ayarlar ve WireGuard çözümleyiciyi devraldığında DNS sorunlarını giderme konusu, systemd-resolved ve resolvconf durumlarını ayrıntılı olarak ele alır.

Yanıt kodları ve her birinin anlamı

• NXDOMAIN: Yetkili bir sunucu, ismin mevcut olmadığını belirtir. Yazımı kontrol edin, alan adı sonekinin iki kez yazılıp yazılmadığına bakın ve yetkilendirme (delegation) işaretçinizin yönlendirdiği bölgeyi (zone) düzenlediğinizden emin olun.
• NOERROR ve boş bir ANSWER SECTION: İsim mevcuttur ancak sorguladığınız türde bir kayıt bulunmamaktadır. Yalnızca A kaydı varken AAAA sorgusu yapmak tam olarak bu sonucu verir.
• SERVFAIL: Çözücü (resolver) denedi ancak bir yanıt üretemedi. Bunun iki yaygın nedeni, yanıt vermeyen yetkili sunucular ve DNSSEC (domain name system security extensions) doğrulamasının başarısız olmasıdır. Doğrulamayı devre dışı bırakan dig @1.1.1.1 example.com A +cd ile test edin. Doğrulama kapalıyken +cd ve SERVFAIL ile yanıt alınıyorsa sorun imzalardadır; bu durum genellikle bir isim sunucusu taşımasından sonra üst kuruluşun hala eski DS (delegation signer) kaydını yayınlamasıyla oluşur.
• REFUSED: Sorguladığınız sunucu bu soruya yanıt vermeyecektir; bunun nedeni genellikle dig parametresini, hizmet vermediği bir alan adı için yetkili bir sunucuya yönlendirmenizdir.
• ;; connection timed out; no servers could be reached: dig hiçbir çözücüye ulaşamadı. Bu, sizin tarafınızdaki bir ağ veya çözücü sorunudur; dolayısıyla sorun alan adı ile ilgili değildir.

ping: example.com: Temporary failure in name resolution, dig yerine glibc tarafından bildirilen aynı hata sınıfıdır.

Kendi VPS'niz üzerinde isim sunucusu (nameserver) çalıştırmalı mısınız?

Çalıştırabilirsiniz. bind9, knot veya nsd, bölgenize (zone) sunucudan hizmet verecektir ve bu süreç size DNS konusunda herhangi bir panelin öğretebileceğinden daha fazlasını öğretir. İtirazlar ise pratiktir. Bir alan adı, farklı ağlar üzerinde en az iki isim sunucusuna sahip olmalıdır; bu nedenle tek bir VPS, e-posta dahil olmak üzere alan adındaki her servis için tek bir hata noktası haline gelir. Hizmet verdikleri alan adının içinde tanımlanan isim sunucuları, kayıt kuruluşunda (registrar) yapışkan kayıtlara (glue records) ihtiyaç duyar; bu, üst bölgede (parent zone) saklanan ns1.example.com adresidir, aksi takdirde sorgulama işleminin başlayabileceği bir yol olmaz. Bir çözümleyici (resolver) isim sunucunuza ulaşamadığında, web sitenize geri dönmez: tüm alan adı o kullanıcı için ortadan kaybolur. API destekli barındırılan DNS, çoğu insan için daha düşük riskli bir tercihtir. Kendi makineleriniz için VPS'nizde önbelleğe alan bir çözümleyici (caching resolver) çalıştırmak ise farklı bir iştir ve çok daha küçük bir sorumluluk gerektirir.

FAQ

DNS değişikliğim neden henüz yayılmadı?

Hiçbir şey yayılmaz. Yetkili isim sunucularınız, değişikliği kaydettiğiniz anda yeni değeri tutar; sorgu yapan her çözümleyici ise aldığı TTL süresi dolana kadar kendi önbelleğindeki kopyayı kullanmaya devam eder. dig @ns1.your-dns-host.net example.com A +short komutu ile yetkili sunucuya doğrudan sorgu yapın. Eğer bu komut yeni adresi döndürüyorsa değişiklik canlıdır ve geri kalan her şey önbellekleme ile ilgilidir. Kayıtlar yerine isim sunucularını değiştirdiyseniz, TLD delegasyonları iki günlük TTL ile dağıtıldığı için sürecin çok daha uzun süreceğini göz önünde bulundurun.

Alan adımın fiilen hangi isim sunucularını kullandığını nasıl bulurum?

dig example.com NS +short komutu, alan adı için şu anda yanıt veren isim sunucularını yazdırır; dig +trace example.com komutu ise TLD sunucularının dağıttığı delegasyon dahil olmak üzere kökten başlayan yönlendirme zincirini gösterir. Eğer bu isimler panelini düzenlediğiniz sağlayıcıya ait değilse, sorun buradadır. Ya delegasyonda belirtilen sağlayıcı üzerinden kayıtları düzenleyin ya da kayıt kuruluşunuz üzerinden delegasyonu istediğiniz yere yönlendirin.

Alan adım çözümleniyor ancak site yine de yüklenmiyor. Şimdi ne yapmalıyım?

dig example.com A +short komutu sunucunuzun adresini döndürdüğü an DNS süreci tamamlanmış demektir. Bundan sonraki sorun bağlantı ile ilgilidir. curl -I http://example.com komutunun Connection refused döndürmesi, o portta hiçbir servisin dinleme yapmadığı anlamına gelir. Zaman aşımına uğrayana kadar bekleyen bir istek, güvenlik duvarının paketi düşürdüğünü gösterir. Web sunucunuzun çalıştığını ve genel IP adresine bağlı olduğunu doğrulayın; ardından sunucu üzerindeki güvenlik duvarını ve sağlayıcınızın kontrol panelindeki ağ güvenlik duvarını kontrol edin.

Kök alan adımda neden CNAME kullanamıyorum?

CNAME, bir ismin başka bir ismin takma adı olduğunu belirtir ve CNAME kaydına sahip bir isim başka hiçbir kayıt türünü barındıramaz. Kök alan adınızın bir bölge (zone) olarak var olabilmesi için SOA ve NS kayıtlarını içermesi gerekir, bu nedenle aynı zamanda bir CNAME olamaz. Kök dizinde adresi tutan bir A kaydı kullanın veya sağlayıcınızın ALIAS, ANAME ya da CNAME flattening adıyla sunduğu, bir ismi kaydedip gelen sorgulara o ismin o an çözümlendiği adresi yanıt olarak dönen özelliği kullanın.