Knowledgebase

적용 환경

DNS 문제인지 먼저 구분하기

DNS 설정을 변경하기 전에 서버 자체의 네트워크가 정상인지 확인해야 합니다. 먼저 인터페이스 주소와 기본 라우팅 경로를 확인합니다.

ip -br addr
ip route

인터페이스가 UP 상태이고 서버에 정상적인 IP 주소가 있으며 default via로 시작하는 기본 경로가 존재하는지 확인합니다.

다음으로 도메인을 사용하지 않고 외부 IP 주소에 직접 통신해 봅니다.

ping -c 3 1.1.1.1

IP 주소로 통신은 되지만 다음과 같은 도메인 조회만 실패한다면 DNS 문제일 가능성이 높습니다.

getent hosts ubuntu.com
resolvectl query ubuntu.com

systemd-resolved 상태 확인

Ubuntu 22.04의 기본적인 DNS 이름 해석은 systemd-resolved가 담당합니다. 서비스가 실행 중인지 확인합니다.

systemctl is-active systemd-resolved.service
systemctl status systemd-resolved.service --no-pager

active가 아니라면 부팅 로그와 서비스 로그를 확인합니다.

sudo journalctl -u systemd-resolved.service -b --no-pager

서버가 Ubuntu의 기본 Netplan + systemd-resolved 구성을 사용하고 있으며 별도의 DNS 데몬을 의도적으로 운영하지 않는 환경이라면 서비스를 다시 활성화할 수 있습니다.

sudo systemctl enable --now systemd-resolved.service
systemctl is-active systemd-resolved.service

sudo ss -lntup | grep ':53 '

현재 DNS 서버 확인

resolvectl을 사용하면 각 네트워크 인터페이스에 적용된 DNS 서버와 검색 도메인을 확인할 수 있습니다.

resolvectl status

외부 통신에 사용되는 인터페이스 아래에서 Current DNS Server와 DNS Servers 항목을 확인합니다. 인터페이스명을 모른다면 기본 경로도 함께 확인합니다.

ip route show default
resolvectl status ens3

위 예시의 ens3는 실제 서버에서 확인한 인터페이스명으로 변경해야 합니다.

DNS 서버가 표시되지만 응답하지 않는 경우에는 이름 조회를 직접 시도해 응답 여부를 확인합니다.

resolvectl query ubuntu.com

/etc/resolv.conf 상태 확인

Ubuntu의 기본 systemd-resolved 구성에서는 /etc/resolv.conf를 직접 관리하기보다 /run/systemd/resolve/stub-resolv.conf를 가리키는 심볼릭 링크로 사용합니다.

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

기본 stub 구성에서는 최종 대상이 다음 경로여야 합니다.

/run/systemd/resolve/stub-resolv.conf

이 파일 안에 nameserver 127.0.0.53가 표시되는 것은 정상적인 동작입니다. 127.0.0.53은 외부 DNS 서버 주소가 아니라 로컬의 systemd-resolved stub resolver입니다.

심볼릭 링크가 삭제되었거나 일반 파일로 잘못 바뀐 것이 확실하고, 서버가 기본 systemd-resolved 구성을 사용한다면 다음과 같이 복원할 수 있습니다.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved.service

readlink -f /etc/resolv.conf
resolvectl status

임시 DNS 서버로 원인 확인

현재 DHCP에서 받은 DNS 서버가 응답하지 않는지 확인하려면 resolvectl로 특정 인터페이스에 DNS 서버를 임시 지정할 수 있습니다. 아래 명령은 재부팅이나 네트워크 재설정 후 유지되지 않는 진단용 설정입니다.

sudo resolvectl dns ens3 1.1.1.1 8.8.8.8
resolvectl status ens3
resolvectl query ubuntu.com

임시 DNS를 지정한 직후 이름 해석이 정상화된다면 기존 DHCP DNS 또는 기존 Netplan DNS 설정에 문제가 있을 가능성이 높습니다.

테스트가 끝나면 인터페이스별 임시 설정을 원래 상태로 되돌립니다.

sudo resolvectl revert ens3
resolvectl status ens3

DNS 서버 변경 후 캐시가 원인인지 확인할 필요가 있다면 다음 명령으로 resolver 캐시를 비울 수 있습니다.

sudo resolvectl flush-caches

Netplan에 DNS 서버를 영구 설정

임시 DNS 변경으로 문제가 해결되었다면 Netplan 설정에 정상적인 DNS 서버를 영구 등록할 수 있습니다. 먼저 현재 설정 파일을 확인합니다.

ls -l /etc/netplan/
sudo cat /etc/netplan/*.yaml

설정 파일 전체를 새로 작성하기보다 현재 인터페이스 설정에 nameservers 항목을 추가하는 방식이 안전합니다. 예를 들어 DHCP를 사용하면서 DHCP가 제공한 DNS 대신 직접 지정한 DNS를 사용하려는 systemd-networkd 환경은 다음과 같이 구성할 수 있습니다.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

ens3는 실제 인터페이스명으로 변경하고, 기존 설정에 고정 IP·라우팅·MTU·추가 주소 등이 있다면 반드시 그대로 유지해야 합니다. DHCP DNS가 정상이라면 use-dns: false는 넣지 않아도 됩니다.

설정 파일을 수정하기 전에 백업합니다.

sudo cp -a /etc/netplan /etc/netplan.backup

YAML 문법을 검사합니다.

sudo netplan generate

문법 오류가 없다면 원격 서버에서는 netplan try를 사용하는 것이 안전합니다. 일정 시간 안에 설정을 확인하지 않으면 되돌리는 기능이 있으므로 단순한 netplan apply보다 원격 작업에 적합합니다.

sudo netplan try

연결과 DNS가 정상인지 확인한 후 설정을 확정합니다. 콘솔에서 작업하거나 이미 충분히 검증된 경우에는 다음 명령으로 적용할 수 있습니다.

sudo netplan apply
resolvectl status

방화벽·NSS·hosts 파일 점검

외부 DNS 통신이 차단되지 않았는지 확인

서버에서 송신 트래픽을 제한하고 있다면 외부 DNS 서버의 UDP 53번과 TCP 53번 통신이 허용되어야 합니다. DNS 클라이언트 역할만 하는 서버라면 일반적으로 외부에서 들어오는 53번 포트를 열 필요는 없습니다.

sudo ufw status verbose
sudo nft list ruleset

클라우드 방화벽, 보안 그룹 또는 IDC 상위 방화벽에서 송신 DNS 트래픽을 별도로 제한하고 있는지도 함께 확인해야 합니다.

/etc/hosts 충돌 확인

/etc/hosts에 잘못된 정적 매핑이 있으면 DNS보다 먼저 적용될 수 있습니다.

cat /etc/hosts
getent hosts server.example.com

특정 도메인만 잘못된 IP로 해석된다면 /etc/hosts에 해당 도메인이 등록되어 있는지 확인합니다.

Name Service Switch 설정 확인

시스템에서 이름 해석 방법과 순서는 /etc/nsswitch.conf의 hosts: 항목에 영향을 받습니다.

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

이 파일을 과거에 수동 수정한 뒤 일반 애플리케이션만 이름 해석에 실패한다면 변경 이력을 확인하십시오. resolvectl query는 정상인데 getent hosts, curl, apt 등만 실패한다면 NSS 설정이 원인인지 점검할 필요가 있습니다.

해결 여부 확인

설정 변경 후에는 서비스 상태, DNS 서버, 이름 해석, 실제 애플리케이션 사용 여부를 순서대로 확인합니다.

systemctl is-active systemd-resolved.service
resolvectl status
resolvectl query ubuntu.com
getent hosts ubuntu.com

APT에서 DNS 오류가 발생했던 경우 패키지 목록 갱신도 확인할 수 있습니다.

sudo apt update

이름 해석이 정상이라면 저장소 호스트 이름을 더 이상 해석하지 못하는 오류가 발생하지 않아야 합니다. APT 저장소 자체의 URL 또는 서명 오류가 남는다면 DNS와는 별개의 문제로 진단해야 합니다.

자주 발생하는 오류와 해결 방법

원상복구 방법

Netplan 변경으로 문제가 발생했다면 현재 SSH 세션이나 콘솔에서 백업한 설정을 복구합니다.

sudo rm -rf /etc/netplan
sudo cp -a /etc/netplan.backup /etc/netplan

sudo netplan generate
sudo netplan try

임시로 적용한 resolvectl 설정만 되돌리려면 다음 명령을 사용합니다.

sudo resolvectl revert ens3

/etc/resolv.conf를 수동으로 변경하기 전의 구성을 알고 있다면 그 상태로 복구해야 합니다. Ubuntu 기본 systemd-resolved stub 구성으로 복구하려는 경우에만 다음 링크를 사용합니다.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved.service

공식 참고자료

자주 묻는 질문

/etc/resolv.conf에 nameserver 127.0.0.53이 보이는데 잘못된 설정인가요?

아닙니다. Ubuntu 22.04의 기본 systemd-resolved 구성에서 127.0.0.53은 로컬 DNS stub 주소이므로 정상입니다. 실제 외부 DNS 서버는 resolvectl status에서 확인해야 합니다.

/etc/resolv.conf에 8.8.8.8을 직접 넣어도 되나요?

일시적인 진단에는 사용할 수 있지만 Ubuntu 22.04의 기본 네트워크 구조에서는 영구 설정 방법으로 권장하지 않습니다. Netplan 또는 DHCP를 통해 DNS를 설정하는 편이 재부팅과 네트워크 재구성 후에도 일관되게 유지됩니다.

ping 8.8.8.8은 되는데 ping ubuntu.com만 안 됩니다. 무엇을 확인해야 하나요?

IP 통신은 정상이고 DNS 이름 해석만 실패하는 전형적인 상황입니다. systemd-resolved 상태, resolvectl status의 DNS 서버, /etc/resolv.conf 링크, DNS 송신 트래픽 차단 여부를 순서대로 확인하십시오.

DNS 변경 후 재부팅해야 하나요?

일반적으로 필요하지 않습니다. Netplan 설정을 정상 적용하고 systemd-resolved가 활성화되어 있다면 즉시 반영할 수 있습니다. 필요하면 resolvectl flush-caches로 기존 DNS 캐시를 비울 수 있습니다.

DNS 클라이언트 서버에서 방화벽 53번 포트를 열어야 하나요?

일반적인 DNS 클라이언트는 외부 DNS 서버로 나가는 UDP/TCP 53번 통신이 가능하면 됩니다. 서버가 직접 DNS 서비스를 제공하지 않는다면 외부에서 서버로 들어오는 53번 포트를 별도로 열 필요는 없습니다.