이름이 확인되지 않을 때(DNS)

이 장애의 증상은 알아보기 쉽습니다. ping 1.1.1.1은 작동하는데 ping millida.net은 “Temporary failure in name resolution”이라고 응답하고, apt update는 멈춘 뒤 시간 초과로 끝납니다. 네트워크 자체는 멀쩡하고, 이름을 주소로 바꾸는 변환만 깨진 상태입니다.

1단계. 문제가 이름에 있는지 확인하기

ping -c3 1.1.1.1
getent hosts millida.net
dig +short millida.net @1.1.1.1

서버를 명시한 dig는 응답하는데 getent는 응답하지 않는다면, 시스템이 어느 리졸버에 물어봐야 할지 모르는 것입니다. 이는 연결 문제가 아니라 설정 문제입니다.

2단계. 이름 변환을 담당하는 대상 확인하기

cat /etc/resolv.conf
systemctl status systemd-resolved
resolvectl status

가능한 상황은 세 가지입니다.

• 파일이 비어 있거나 nameserver 줄이 없음 — 리졸버가 지정되지 않았습니다.
• 파일에 nameserver 127.0.0.53이 있지만 systemd-resolved가 실행 중이 아님 — 요청이 아무 데도 도달하지 않습니다.
• 저희 네트워크에서 접근할 수 없는 서드파티 서버가 설정되어 있음.

3단계. 해결하기

apt와 curl을 되살리는 빠른 복구 방법입니다.

echo 'nameserver 1.1.1.1' > /etc/resolv.conf
echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

즉시 작동하지만 재부팅하거나 다음번에 네트워크가 재구성될 때까지만 유지됩니다. 영구적인 해결 방법은 시스템에 따라 다릅니다.

systemd-resolved를 사용하는 Debian과 Ubuntu:

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl dns ens18 1.1.1.1 8.8.8.8

AlmaLinux와 CentOS Stream:

nmcli con mod "System ens18" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "System ens18"

/etc/resolv.conf가 /run을 가리키는 심볼릭 링크라면 이 파일을 직접 편집하지 마세요. 이런 파일은 서비스가 덮어쓰기 때문에 변경 사항이 첫 재부팅 때 사라집니다. 그러면 일주일 뒤에 같은 장애를 겪고도 그 이유를 기억하지 못하게 됩니다.

4단계. 특수한 경우

리졸버는 작동하는데 특정 이름만 찾지 못하는 경우입니다. 레코드가 아예 공개되어 있는지 확인해 보세요.

dig millida.net A @1.1.1.1
dig millida.net A @8.8.8.8

두 서버에서 서로 다른 응답이 나온다면 존이 최근에 변경되었는데 어딘가에 예전 캐시가 남아 있다는 뜻입니다. dig 응답에 나온 레코드의 TTL(Time To Live)만큼 기다리세요.

머신 주소의 역방향 레코드(PTR)는 이 문제와 관련이 없습니다. 이는 메일 서버에 필요한 것으로 “Access” 탭에서 설정하며, 머신이 스스로 이름을 해석하는 방식에는 영향을 주지 않습니다.

또 자주 발견되는 원인은 마이그레이션 후 남은 오래된 줄이 들어 있는 /etc/hosts입니다. 시스템은 DNS보다 이 파일을 먼저 확인하므로 계속 예전 주소로 가려고 합니다.

cat /etc/hosts

불필요한 줄을 지우고 127.0.0.1 localhost와 머신 자신의 이름이 적힌 줄만 남기세요.

어떤 서버에서도 이름이 해석되지 않는다면

문제가 더 광범위한 것입니다. 머신의 네트워크 끊김 문서를 참고해 기본 연결을 확인하고, 자신의 패킷 필터가 아웃바운드 포트 53을 막고 있지 않은지 확인하세요.