리눅스 서버를 운영하다 보면 인터넷 연결은 정상인데 특정 도메인에 접속하지 못하거나, curl, wget 같은 명령어에서 “Could not resolve host”와 같은 오류가 발생하는 경우가 있습니다. 이런 문제는 서버의 네트워크 자체가 끊어진 것이 아니라 DNS 설정이나 DNS 서버와의 통신에 문제가 있는 경우가 많습니다.
DNS는 사람이 입력하는 도메인 이름을 서버가 이해할 수 있는 IP 주소로 변환해 주는 시스템입니다. 따라서 DNS가 정상적으로 작동하지 않으면 웹사이트 접속, 패키지 설치, 외부 API 통신 등 여러 기능에 문제가 발생할 수 있습니다.
이번 글에서는 리눅스 서버에서 발생하는 DNS 문제를 nslookup과 dig 명령어를 이용해 단계적으로 확인하는 방법을 알아보겠습니다.
1. 리눅스 서버에서 DNS가 중요한 이유
사용자가 브라우저에서 example.com과 같은 도메인을 입력하면 컴퓨터는 먼저 해당 도메인에 연결된 IP 주소를 확인합니다. 이 과정에서 DNS 서버가 사용됩니다.
예를 들어 다음과 같은 명령어를 실행할 수 있습니다.
ping example.com정상적인 경우 도메인이 IP 주소로 변환되어 응답이 나타납니다.
반대로 다음과 같은 메시지가 나타난다면 DNS 문제를 의심할 수 있습니다.
ping: example.com: Temporary failure in name resolution다만 이런 오류가 발생했다고 해서 무조건 DNS 서버만 문제라고 판단해서는 안 됩니다. 네트워크 연결, /etc/resolv.conf, DNS 서버 주소, 방화벽, 로컬 DNS 서비스 등을 순서대로 확인하는 것이 좋습니다.
2. 먼저 네트워크 연결부터 확인하기
DNS 문제를 확인하기 전에 서버 자체가 인터넷에 연결되어 있는지 확인합니다.
ping -c 4 8.8.8.8IP 주소로 정상적인 응답이 돌아온다면 기본적인 네트워크 연결은 작동하고 있을 가능성이 높습니다.
이제 같은 서버에서 도메인을 확인합니다.
ping -c 4 google.comIP 주소로는 통신이 되는데 도메인 이름으로는 통신이 되지 않는다면 DNS 설정을 집중적으로 확인할 수 있습니다.
3. /etc/resolv.conf 확인하기
리눅스 서버의 DNS 설정을 확인할 때 가장 먼저 살펴볼 파일 중 하나가 /etc/resolv.conf입니다.
cat /etc/resolv.conf예를 들어 다음과 같이 DNS 서버가 설정되어 있을 수 있습니다.
nameserver 8.8.8.8
nameserver 1.1.1.1여기서 nameserver 뒤에 적힌 주소가 DNS 질의를 처리할 서버입니다.
/etc/resolv.conf의 권한이나 설정이 잘못된 경우 DNS 조회가 정상적으로 이루어지지 않을 수 있습니다. Red Hat의 기술 자료에서도 DNS 조회가 되지 않는 상황에서 /etc/resolv.conf의 권한과 설정을 확인하는 방법을 안내하고 있습니다.
단, 최근 리눅스 배포판에서는 systemd-resolved와 같은 서비스가 DNS 설정을 관리하는 경우도 있기 때문에 파일 내용만 보고 무조건 직접 수정해서는 안 됩니다. systemd-resolved는 로컬 애플리케이션의 이름 해석을 담당하며 DNS 서버 정보를 여러 방식으로 관리할 수 있습니다.
4. nslookup으로 DNS 확인하기
DNS 문제를 빠르게 확인할 때 사용할 수 있는 명령어가 nslookup입니다.
기본적인 사용법은 다음과 같습니다.
nslookup example.com정상적으로 조회된다면 DNS 서버 정보와 도메인의 IP 주소가 표시됩니다.
특정 DNS 서버를 지정해서 확인하는 것도 가능합니다.
nslookup example.com 8.8.8.8이렇게 하면 현재 서버의 기본 DNS 설정과 관계없이 지정한 DNS 서버에 직접 질의할 수 있습니다.
예를 들어 기본 DNS에서는 조회되지 않지만 8.8.8.8에서는 정상적으로 조회된다면 서버에 설정된 DNS 서버에 문제가 있을 가능성을 생각해 볼 수 있습니다.
nslookup은 DNS 서버에 질의하여 호스트와 도메인 정보를 확인하는 명령어이며, 일반적인 DNS 조회와 간단한 문제 확인에 유용합니다.
5. dig 명령어로 DNS 문제 자세히 확인하기
보다 정확하게 DNS 응답을 분석하려면 dig 명령어를 사용하는 것이 좋습니다.
dig example.comdig는 DNS 조회뿐만 아니라 이름 서버 구성과 응답 내용을 자세하게 확인할 수 있어 DNS 문제를 분석할 때 많이 사용됩니다. Red Hat 문서에서도 dig를 DNS 조회와 네임서버 구성 디버깅을 위한 명령줄 도구로 설명하고 있습니다.
출력 결과에서 다음과 같은 부분을 확인할 수 있습니다.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR여기서 status: NOERROR라면 DNS 질의가 정상적으로 처리되었다는 의미입니다.
반대로 다음과 같은 상태가 나타날 수 있습니다.
SERVFAIL
NXDOMAIN
REFUSED각각의 의미를 구분해서 확인해야 합니다.
- NOERROR : 정상적인 DNS 응답
- NXDOMAIN : 해당 도메인이 존재하지 않음
- SERVFAIL : DNS 서버가 질의를 정상적으로 처리하지 못함
- REFUSED : DNS 서버가 해당 질의를 거부함
6. 특정 DNS 서버에 직접 질의하기
DNS 문제의 원인을 찾을 때는 현재 서버가 사용하는 DNS 서버와 외부 DNS 서버를 비교하면 도움이 됩니다.
dig example.com그리고 다음과 같이 특정 DNS 서버에 직접 질의합니다.
dig @8.8.8.8 example.com또 다른 DNS 서버도 확인할 수 있습니다.
dig @1.1.1.1 example.com첫 번째 명령에서는 문제가 발생하지만 특정 DNS 서버에서는 정상적으로 응답한다면 현재 설정된 DNS 서버 또는 내부 네트워크의 DNS 구성에 문제가 있을 가능성이 있습니다.
dig는 별도의 DNS 서버를 지정하지 않으면 /etc/resolv.conf에 설정된 DNS 서버를 사용합니다.
7. A 레코드와 AAAA 레코드 확인하기
도메인의 IPv4 주소를 확인하려면 다음과 같이 사용할 수 있습니다.
dig example.com AIPv6 주소는 다음 명령어로 확인합니다.
dig example.com AAAA서버에서 IPv6 설정에 문제가 있는데 AAAA 레코드를 우선적으로 사용하면서 접속 문제가 발생하는 경우도 있기 때문에 IPv4와 IPv6를 나누어 확인하는 것이 좋습니다.
8. MX와 NS 레코드 확인하기
DNS 서버 자체의 설정을 좀 더 자세히 확인하려면 NS 레코드를 조회할 수 있습니다.
dig example.com NS이 명령어를 사용하면 해당 도메인의 네임서버 정보를 확인할 수 있습니다. Red Hat의 DNS 문서에서도 dig name NS 형식으로 특정 도메인의 네임서버를 조회하는 방법을 안내합니다.
메일 서버 설정이 의심된다면 MX 레코드를 확인합니다.
dig example.com MX이처럼 DNS 문제는 단순히 IP 주소 하나만 확인하는 것이 아니라 A, AAAA, MX, NS 등 필요한 레코드를 나누어 확인하면 원인을 찾는 데 도움이 됩니다.
9. DNS 서버에 연결되지 않을 때 확인할 것
다음과 같이 dig 실행 결과가 나오면서 DNS 서버에 연결할 수 없다는 메시지가 발생할 수 있습니다.
;; communications error
;; no servers could be reached이 경우 다음 항목을 순서대로 확인하는 것이 좋습니다.
- 서버의 네트워크 연결 상태
- /etc/resolv.conf 설정
- DNS 서버 IP 주소
- UDP/TCP 53번 포트 통신
- 방화벽 설정
- systemd-resolved 상태
- 내부 DNS 서버 상태
특히 /etc/resolv.conf에 등록된 DNS 서버 중 하나가 응답하지 않는 경우 nslookup이나 host 명령이 지연되거나 정상적으로 결과를 반환하지 않는 사례가 보고되어 있습니다.
10. systemd-resolved를 사용하는 서버 확인하기
Ubuntu 등 일부 리눅스 환경에서는 systemd-resolved가 DNS 확인을 담당할 수 있습니다.
서비스 상태는 다음과 같이 확인합니다.
systemctl status systemd-resolvedDNS 관련 현재 상태를 확인하려면 다음 명령어도 사용할 수 있습니다.
resolvectl statusDNS 캐시를 초기화해야 하는 상황에서는 다음 명령어를 사용할 수 있습니다.
sudo resolvectl flush-cachessystemd-resolved는 DNS 캐시를 관리하며 네트워크 설정이 변경될 때 캐시를 자동으로 비우기도 합니다. 수동으로 캐시를 초기화해야 할 경우 resolvectl flush-caches 사용이 권장됩니다.
11. nslookup과 dig의 차이
두 명령어 모두 DNS 확인에 사용할 수 있지만 활용 목적에는 차이가 있습니다.
nslookup
nslookup example.com간단하게 도메인이 어떤 IP 주소로 연결되는지 확인할 때 편리합니다.
dig
dig example.comDNS 응답 상태, 질의 시간, 서버 정보, 레코드 등을 자세하게 확인할 수 있어 장애 분석에 더 유용합니다.
따라서 서버 운영을 처음 시작했다면 nslookup으로 기본 상태를 확인하고, 원인을 더 자세하게 분석해야 할 때 dig를 사용하는 방법을 추천합니다.
12. 리눅스 DNS 문제를 해결하는 기본 순서
실제 서버 장애 상황에서는 다음 순서로 점검하면 편리합니다.
① 인터넷 연결 확인
↓
② /etc/resolv.conf 확인
↓
③ nslookup으로 도메인 확인
↓
④ dig로 상세 응답 확인
↓
⑤ 다른 DNS 서버에 직접 질의
↓
⑥ systemd-resolved 상태 확인
↓
⑦ 방화벽 및 53번 포트 확인예를 들어 다음 명령어를 순서대로 실행해 볼 수 있습니다.
ping -c 4 8.8.8.8
cat /etc/resolv.conf
nslookup example.com
dig example.com
dig @8.8.8.8 example.com
systemctl status systemd-resolved이 과정을 통해 단순한 네트워크 장애인지, DNS 서버 설정 문제인지, 특정 도메인의 DNS 문제인지 범위를 좁혀갈 수 있습니다.
마무리
리눅스 서버에서 발생하는 DNS 문제는 처음에는 원인을 찾기 어렵게 느껴질 수 있습니다. 하지만 네트워크 연결부터 확인한 다음 /etc/resolv.conf, nslookup, dig, systemd-resolved 순서로 점검하면 문제의 범위를 빠르게 좁힐 수 있습니다.
특히 nslookup은 간단한 DNS 조회에 적합하고, dig는 DNS 응답과 네임서버 정보를 자세하게 확인할 수 있기 때문에 서버 관리에서 매우 유용한 도구입니다.
DNS 장애가 발생했을 때 무작정 설정 파일을 수정하기보다는 현재 DNS 서버가 어디인지 확인하고, 다른 DNS 서버에 직접 질의해 결과를 비교하는 것이 중요합니다.
이러한 기본적인 DNS 점검 방법을 익혀두면 웹서버, 데이터베이스 서버, 클라우드 서버 등 다양한 리눅스 환경에서 발생하는 네트워크 이름 해석 문제를 보다 체계적으로 해결할 수 있습니다.