Temporary Failure in Name Resolution Hatası: Sunucu DNS Çözemiyor

Sunucuya SSH ile bağlanabiliyorsunuz, top çalışıyor, disk yerinde, servisler ayakta. Ama apt update çalıştırdığınız anda ekran şu satırla doluyor: Temporary failure resolving 'archive.ubuntu.com'. curl https://api.ornek.com deniyorsunuz, Could not resolve host diyor. ping google.com yazıyorsunuz, cevap kısa ve net: ping: google.com: Temporary failure in name resolution. Buna karşılık ping 8.8.8.8 sorunsuz çalışıyor — paketler dışarı çıkıyor, internet var.

Bu tablo neredeyse her zaman tek bir şeyi anlatır: sunucunun ağ bağlantısı değil, ad çözümlemesi bozuk. IP adresi verdiğinizde her şey normal, isim verdiğinizde hiçbir şey çalışmıyor. Buradan sonra çoğu kişi aynı şeyi yapar — /etc/resolv.conf dosyasına nameserver 8.8.8.8 yazar, sorun anında çözülür, sunucu yeniden başlatılınca hata geri gelir. Aynı döngü haftada bir tekrarlanır.

Bu yazı o döngüyü kırmak için yazıldı. Önce hatanın hangi katmandan geldiğini (getaddrinfo ve EAI_AGAIN), sonra 90 saniyede ağ / çözümleyici / NSS ayrımını yapmayı, ardından resolv.conf düzenlemesinin neden kalıcı olmadığını ve kalıcı düzeltmenin hangi dosyada yapılması gerektiğini ele alacağız. Sonda da aynı hataya yol açan üç yan senaryo var: güvenlik duvarında kapalı 53. port, farklı DNS kullanan Docker konteynerleri ve dig çalışırken ping çalışmadığında bakılacak nsswitch.conf. Bu yazı sunucunun kendi çözümlemesiyle ilgilidir; ziyaretçinin bilgisayarında çıkan benzer hatalar için DNS sunucusu yanıt vermiyor rehberine bakın.

"Temporary Failure in Name Resolution" Tam Olarak Neyi Söyler#

Bu metni üreten şey ping, curl veya apt değildir; C kütüphanesidir. Bir isim çözülmesi gerektiğinde program getaddrinfo() çağrısını yapar ve bu çağrı başarısız olduğunda bir hata kodu döner. Buradaki kod EAI_AGAIN'dir ve karşılığı metin olarak "Temporary failure in name resolution"dır.

EAI_AGAIN sözlük anlamıyla "geçici bir hata, sonra tekrar dene" demektir. Pratikte ise şu üç durumdan birini kapsar:

• Sisteme tanımlı bir DNS sunucusu yok (/etc/resolv.conf boş ya da hiç yok).
• Tanımlı DNS sunucusu var ama yanıt vermiyor (erişilemiyor, filtreleniyor, çökmüş).
• Çözümleme mekanizması hiç devreye girmiyor (nsswitch.conf içinde dns yok, systemd-resolved kapalı).

Karıştırılmaması gereken kardeş hata NXDOMAIN'dir: o, "sordum ve DNS sunucusu böyle bir isim yok dedi" anlamına gelir; yani çözümleme çalışmıştır, sonuç olumsuzdur. EAI_AGAIN ise sorunun cevabına hiç ulaşılamadığını söyler. Bu ayrım tüm teşhisin temelidir: birinde DNS kaydına, diğerinde sunucunun kendi çözümleyici yapılandırmasına bakarsınız.

Belirti Kümesi: apt, curl, cron ve Composer Aynı Anda Patlar#

Bu hatanın en belirgin işareti tek bir aracın değil, isim çözen her aracın aynı anda bozulmasıdır. Tipik bir sunucuda şu kümeyi bir arada görürsünüz:

Buna karşılık IP ile yapılan her iş çalışır: ping 1.1.1.1, ssh 203.0.113.10, IP'ye yapılan curl istekleri. Bu asimetri teşhisi tek başına yarıya indirir; ağ katmanında bir arıza olsaydı IP tabanlı erişim de çalışmazdı. Ağ tarafını yine de doğrulamak isterseniz ping, traceroute ve mtr rehberindeki sıralamayı izleyebilirsiniz.

Sinsi bir varyant da vardır: sunucu ismi çözüyor ama çok yavaş çözüyor. Bu durumda apt bazen çalışır bazen çalışmaz, PHP uygulaması aralıklı olarak 502 döner. Genelde birden fazla nameserver tanımlıdır ve birincisi cevapsızdır; sistem zaman aşımı süresi dolana kadar bekleyip ikinciye geçer.

90 Saniyelik Teşhis: Ağ mı, Çözümleyici mi, NSS mi?#

Aşağıdaki dört komutu sırayla çalıştırın; hangisinin kırıldığı, sorunun hangi katmanda olduğunu doğrudan söyler.

# 1) Ağ çıkışı var mı?
ping -c2 1.1.1.1

# 2) Harici bir DNS sunucusu doğrudan sorulduğunda cevap veriyor mu?
dig @1.1.1.1 example.com +short

# 3) Sistemin kendi çözümleyicisi çalışıyor mu?
dig example.com +short

# 4) Uygulamaların kullandığı NSS zinciri çalışıyor mu?
getent hosts example.com

Sonuçların yorumu şöyledir:

Dördüncü satır özellikle önemlidir, çünkü dig NSS katmanını atlar: doğrudan UDP/53 sorgusu yapar. ping, curl, PHP ve Python ise getaddrinfo() üzerinden gider. Bu yüzden "dig çalışıyor ama ping çalışmıyor" tablosu tuhaf değil, tam tersine çok bilgilendiricidir. dig çıktısını okumaya yeniyseniz dig ve nslookup ile DNS sorgulama yazısı iyi bir başlangıçtır.

Teşhisi tamamlamak için mevcut durumu da görün:

# resolv.conf gerçekten nereyi gösteriyor?
ls -l /etc/resolv.conf
cat /etc/resolv.conf

# systemd-resolved ne düşünüyor, hangi sunucuyu kullanıyor?
resolvectl status
resolvectl query example.com

# Yerel bir çözümleyici 53'te dinliyor mu?
ss -lnup | grep ':53'

/etc/resolv.conf'a Yazdığınız Nameserver Neden Kayboluyor#

Ubuntu 18.04 ve sonrasında /etc/resolv.conf çoğu kurulumda düz bir dosya değil, bir sembolik bağdır:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jul  4 11:22 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Bağın hedefi /run altındadır ve /run bir tmpfs'tir; yani her yeniden başlatmada içeriği sıfırlanır ve systemd-resolved tarafından yeniden üretilir. Dosyaya elle yazdığınız nameserver 8.8.8.8 satırı o an çalışır, ama bir sonraki açılışta üretilen dosyada yer almaz. Aynı şey netplan apply, systemctl restart systemd-resolved veya DHCP kirası yenilendiğinde de yaşanır.

Dosyanın normal hâlinde tek bir satır vardır ve çoğu kişiyi şaşırtan da budur:

nameserver 127.0.0.53
options edns0 trust-ad
search .

127.0.0.53 sizin DNS sunucunuz değildir; systemd-resolved'in yerel dinleyicisidir (stub listener). Uygulamalar sorularını buraya sorar, systemd-resolved de gerçek yukarı akış sunucularına yönlendirir. Gerçek sunucuları görmek için ya resolvectl status çıktısına ya da stub olmayan sürüme bakmanız gerekir:

cat /run/systemd/resolve/resolv.conf

Buradan çıkan sonuç nettir: /etc/resolv.conf bir yapılandırma dosyası değil, bir çıktıdır. Kalıcı düzeltme, o çıktıyı üreten katmanda yapılır. Yaygın bir kestirme yol olan chattr +i /etc/resolv.conf ile dosyayı kilitlemek de kötü bir fikirdir: ayar donar ama systemd-resolved dosyayı güncelleyemediği için hata basar, VPN ve DHCP kaynaklı meşru DNS değişiklikleri uygulanamaz ve ilerideki bir ağ değişikliğinde sunucu yine ad çözemez hâle gelir.

Kalıcı Düzeltme: Doğru Katmanı Seçmek#

Önce hangi katmanın sizde etkin olduğunu belirleyin, sonra yalnızca o katmanı düzenleyin. İki katmanı aynı anda ayarlamak, birinin diğerini ezmesine ve sorunun sürekli geri gelmesine yol açar.

Netplan ile (statik IP kullanan sunucularda en yaygın)#

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses: [203.0.113.25/24]
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
        search: [ornek.local]

netplan try          # 120 saniye içinde onaylanmazsa eski ayara döner
netplan apply
resolvectl status | grep -A2 'Link 2'

netplan try alışkanlığını edinin: yanlış bir yapılandırmayla SSH bağlantısını kaybettiğinizde otomatik geri dönüş sizi konsol başına gitmekten kurtarır. Netplan dosya yapısı ve girinti kuralları için Netplan ile statik IP ayarlama yazısına bakabilirsiniz.

systemd-resolved ile (arayüzden bağımsız global tanım)#

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9
DNSStubListener=yes

systemctl restart systemd-resolved
resolvectl status
resolvectl query archive.ubuntu.com

Burada bilinmesi gereken öncelik kuralı şudur: bir arayüz için netplan veya DHCP üzerinden DNS geldiğinde, resolved.conf içindeki DNS= satırı o arayüz için geçersiz kalır; global tanım yalnızca arayüze özgü bir sunucu yoksa devreye girer. "resolved.conf'a yazdım ama hâlâ sağlayıcının DNS'ini kullanıyor" şikayetinin nedeni budur. Arayüz seviyesindeki tanımı görmek ve geçici olarak değiştirmek için:

resolvectl dns            # arayüz başına aktif sunucular
resolvectl dns ens3 1.1.1.1 8.8.8.8   # yalnızca çalışma zamanı, kalıcı değil
resolvectl flush-caches

systemd-resolved Devre Dışıysa veya Çökmüşse#

Minimal imajlarda, bazı konteyner tabanlı sanallaştırmalarda ve elle sadeleştirilmiş kurulumlarda systemd-resolved kapalı olabilir. Bu durumda /etc/resolv.conf ya boş kalır ya da sembolik bağ kırık hedefe işaret eder — sonuç yine EAI_AGAIN'dir.

systemctl status systemd-resolved
journalctl -u systemd-resolved -n 50 --no-pager

Servisi kullanmaya devam edecekseniz etkinleştirip bağı doğru hedefe kurun:

systemctl enable --now systemd-resolved
ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl status

systemd-resolved kullanmak istemiyorsanız — bazı konteyner ve eski panel kurulumlarında tercih edilir — servisi tamamen kapatıp sabit bir dosya bırakabilirsiniz. Bu meşru bir kurulumdur; şart, çıktıyı üreten başka bir bileşenin kalmamasıdır:

systemctl disable --now systemd-resolved
rm -f /etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\noptions timeout:2 attempts:2\n' > /etc/resolv.conf

Bu yolu seçerseniz netplan tarafında nameservers bloğunu ve DHCP'nin DNS dağıtımını da kapatın; aksi hâlde bir gün başka bir bileşen dosyayı yeniden yazar.

Bir başka az bilinen neden DNSSEC doğrulamasıdır. Yukarı akış sunucusu bozuk imza döndürüyorsa systemd-resolved sorguyu reddeder ve uygulama tarafında bu yine geçici çözümleme hatası olarak görünür. Günlükte DNSSEC validation failed satırı görüyorsanız test amaçlı DNSSEC=no ile doğrulayın; kalıcı çözüm, düzgün çalışan bir yukarı akış sunucusuna geçmektir.

Güvenlik Duvarı 53. Portu Kapatmışsa#

Varsayılan kurulumlarda giden trafik açıktır, ancak sıkılaştırılmış sunucularda ufw default deny outgoing uygulanmış olabilir. Bu durumda DNS sorguları hiç çıkamaz ve tablo tam olarak bu yazının konusudur: ping 1.1.1.1 bile engellenmediyse çalışır, isim çözümleme çalışmaz.

ufw status verbose        # "Default: deny (outgoing)" satırını arayın
ufw allow out 53/udp
ufw allow out 53/tcp

iptables doğrudan kullanılıyorsa:

iptables -L OUTPUT -n --line-numbers | head -20
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

TCP kuralını atlamayın: büyük cevaplar ve DNSSEC yanıtları UDP'ye sığmadığında çözümleyici TCP'ye düşer, kural yoksa sorgular aralıklı olarak başarısız olur. Kural yönetimi için UFW güvenlik duvarı rehberindeki yapıyı izleyebilirsiniz. Portun gerçekten açık olduğunu doğrulamak için:

nc -vzu 1.1.1.1 53
dig +tcp @1.1.1.1 example.com +short

Docker Konteynerinde DNS Çözülmüyorsa#

Konteyner içinde EAI_AGAIN alıp host üzerinde her şeyin çalıştığını görmek şaşırtıcı gelir, ama davranış tasarım gereğidir. Docker, konteynerin /etc/resolv.conf dosyasını host'unkinden türetir; ancak host'ta yalnızca 127.0.0.53 yazıyorsa bu adres konteynerin ağ ad alanında anlamsızdır — orada systemd-resolved dinlemez. Docker bunu fark edip yerine kendi varsayılan genel sunucularını yazar ve bu sunucular sizin ağınızda engelliyse konteyner ad çözemez.

Önce durumu görün:

docker run --rm alpine cat /etc/resolv.conf
docker run --rm alpine nslookup example.com

Kalıcı çözüm daemon seviyesinde tanımlanır:

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "dns-search": ["ornek.local"]
}

# /etc/docker/daemon.json kaydedildikten sonra
systemctl restart docker

Tek bir servis için Compose tarafında da verilebilir:

services:
  uygulama:
    image: php:8.3-fpm
    dns:
      - 1.1.1.1
      - 8.8.8.8

Kendi ağ yapılandırmanızı kuruyorsanız Docker ağ yapılandırma yazısındaki köprü ve özel ağ mantığı bu ayarın nereye oturduğunu netleştirir. Aynı mantık LXC/LXD konteynerlerinde de geçerlidir: resolv.conf konteynerin kendi ağ ad alanına aittir ve host'un stub adresi orada işe yaramaz.

dig Çalışıp ping Çalışmıyorsa: /etc/nsswitch.conf#

Nadir ama teşhis edilmesi en zor durum budur. dig example.com düzgün cevap verir, ping example.com ise Temporary failure in name resolution der. Sebep DNS değil, isim servisi anahtarlama yapılandırmasıdır.

grep '^hosts:' /etc/nsswitch.conf

Sağlıklı bir systemd-resolved kurulumunda satır şuna benzer:

hosts: files resolve [!UNAVAIL=return] dns myhostname

systemd-resolved kullanılmayan bir sistemde ise en azından şu olmalıdır:

hosts: files dns

Satırda dns (veya resolve) hiç yoksa getaddrinfo() yalnızca /etc/hosts dosyasına bakar ve orada bulamadığı her ismi çözümsüz sayar. Bu durum genelde elle yapılan bir sadeleştirmeden, hatalı bir yapılandırma yönetimi şablonundan veya libnss-resolve paketi kaldırıldığında resolve anahtarının yetim kalmasından doğar. Düzelttikten sonra servisleri yeniden başlatın: uzun süredir çalışan süreçler eski NSS zincirini bellekte tutabilir.

Son bir ipucu: /etc/hosts içine geçici olarak eklenen bir satır (203.0.113.10 api.ornek.com) DNS'i tamamen atlar. Bu, acil durumda hizmeti ayakta tutmak için meşru bir geçici çözümdür; ancak unutulduğunda IP değiştiğinde teşhisi imkânsıza yakın bir arızaya dönüşür. Böyle bir satır bıraktıysanız yorumla tarih düşün.

Sıkça Sorulan Sorular#

/etc/resolv.conf dosyasına yazdığım nameserver neden yeniden başlatınca kayboluyor?#

Çünkü o dosya çoğu Ubuntu kurulumunda /run/systemd/resolve/stub-resolv.conf dosyasına giden bir sembolik bağdır ve /run bellekte tutulan geçici bir dosya sistemidir. Her açılışta içerik systemd-resolved tarafından yeniden üretilir. Kalıcı tanım netplan'ın nameservers bloğunda veya /etc/systemd/resolved.conf dosyasında yapılmalıdır.

chattr +i ile resolv.conf dosyasını kilitlemek çözüm mü?#

Hayır, sorunu erteler. Ayar donar ama systemd-resolved dosyayı güncelleyemediği için günlüğe hata basar; VPN, DHCP veya ağ değişikliğiyle gelen meşru DNS güncellemeleri uygulanamaz. Sunucuyu bir gün yeni bir ağa taşıdığınızda aynı hatayla, üstelik nedeni gizlenmiş hâlde karşılaşırsınız. Düzeltmeyi üreten katmanda yapın.

127.0.0.53 adresi nedir, gerçek DNS sunucum bu mu?#

Hayır. Bu, systemd-resolved'in yerel makinede dinlediği stub adresidir; uygulamalar sorularını buraya sorar, servis de gerçek yukarı akış sunucularına iletir. Kullanılan asıl sunucuları görmek için resolvectl status çıktısındaki "DNS Servers" satırlarına ya da /run/systemd/resolve/resolv.conf dosyasına bakın.

dig çalışıyor ama ping ve curl "temporary failure" veriyor, nasıl olur?#

dig doğrudan DNS sunucusuna UDP sorgusu gönderir ve sistemin isim servisi zincirini atlar. ping, curl, PHP ve Python ise getaddrinfo() üzerinden gider; bu çağrı /etc/nsswitch.conf içindeki hosts: satırını izler. O satırda dns veya resolve anahtarı yoksa çözümleme hiç denenmez. Önce o satırı kontrol edin.

resolved.conf dosyasına DNS yazdım ama sunucu hâlâ sağlayıcının DNS'ini kullanıyor?#

Arayüze özgü tanımlar globalden önceliklidir. Netplan üzerinden veya DHCP ile bir arayüze DNS geliyorsa, resolved.conf içindeki DNS= satırı o arayüz için devreye girmez. resolvectl dns komutuyla arayüz başına hangi sunucuların atandığını görün ve düzeltmeyi netplan tarafında yapın.

apt update DNS hatası verirken ping 8.8.8.8 çalışıyor, bu çelişkili değil mi?#

Tam tersine, en bilgilendirici belirtidir. IP tabanlı erişimin çalışması ağ katmanının, yönlendirmenin ve giden trafiğin sağlam olduğunu gösterir; kırılan tek şey isimden IP'ye çeviridir. Bu durumda ağ arayüzü ve ağ geçidi ayarlarını kurcalamayın, doğrudan çözümleyici yapılandırmasına ve 53. portun açık olup olmadığına bakın.