도메인 주소를 입력했는데 사이트가 안 열릴 때, 또는 메일이 안 간다거나, CDN이 이상하게 작동할 때… 이럴 때 가장 먼저 확인해야 할 건 DNS가 제대로 작동하는지 여부 다.
dig 명령어는 DNS 서버에 직접 질의하고 응답을 분석할 수 있는 도구로, 네트워크 문제를 추적하거나 도메인 설정이 잘 되었는지 확인할 때 실무에서 매우 자주 사용된다고 한다.
-> 웹사이트에 접속하거나 메일을 보내는 거의 모든 인터넷 서비스는 DNS를 거친다. 그래서 DNS 오류는 곧바로 서비스 장애로 이어진다.
2. 실제 어떤 문제가 생겼을 때 dig 명령어로 문제를 파악할 수 있을까?
2-1. 웹사이트 접속 불가 시 -> A 레코드 오류 확인
dig address.com A
사용자가 도메인을 입력했는데, 웹 사이트가 열리지 않는다. -> A 레코드가 잘못된 IP 를 가르키고 있어서 다른 서버로 연결
IP 가 변경되었는데도 예전 IP 로 응답한다. -> TTL 설정 문제
2-2. 메일 수신 및 발신 장애 시 -> MX / SPF 레코드 오류 확인
dig address.com MX
dig address.com TXT(SPF)
외부에서 메일이 들어오지 않는다. -> MX레코드가 없거나 오타가 있을 가능성이 있다.
내가 보낸 메일이 스팸으로 분류된다. -> SPF 설정이 누락되었거나 오류일 가능성이 있다.
메일 서버를 이전했는데 적용이 안된다 -> MX TTL 문제일 가능성이 높다.
2-3. 도메인 연결 지연 / 불안정 시 -> DNS 전파 상태 확인
dig @8.8.8.8 address.com
dig @1.1.1.1 address.com
도메인을 구입하거나 IP 를 바꿨는데, 일부 지역에서 접속이 안되는 경우
DNS가 여러 서버에 제대로 전파되지 않아 접속 여부가 랜덤하게 바뀔 수 있음
DNS TTL 이 너무 길어 변경 사항이 늦게 반영될 수 있음
2-4. 내부망 전용 서비스의 오작동 -> 내,외부 DNS 응답차이 비교
dig @내부DNS
dig @8.8.8.8
내부에서만 열려야 하는 서비스가 외부에서 노출 될 수 있다.
내부에서는 접속되지만 외부에서는 "도메인 없음" 오류가 발생
VPN 접속 사용자에게 내부 리소스 연결이 DNS 문제로 불가할 수 있음
3. 명령어를 직접 입력해보자!
3-1. dig google.com ( dig google.com A )
dig google.com
<<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> google.com -> 사용한 dig 명령어의 버전과 옵션이 출력된다. ubuntu 24.02.2 에 설치된 9.18.30 의 dig 명령어가 사용되었고, 'google.com' 에 대한 기본 질의( A 레코드) 가 수행 됨.
global options: +cmd -> dig 의 글로벌 옵션을 의미. 지금은 +cmd(기본명령)만 사용되었다. 다른 옵션들도 있음.(+short, +trace, +noall)
Got answer: -> DNS 서버로부터 응답을 성공적으로 받았음을 나타낸다.
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56371 -opcode : QUERY -> 일반적인 DNS 질의 유형 (조회 요청) -status : NOERROR -> 오류 없이 질의가 성공적으로 처리됨 -id:56371 -> 요청 - 응답을 매칭하기 위한 식별자(ID), 래덤 값임.
flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 - flags : qr ( 이 메시지는 응답 ), rd ( 재귀 질의 요청), ra (서버가 재귀 질의 허용) - QUERY: 1 : 요청한 레코드는 1개 ( google.com 의 A 레코드 1 개를 요청함) - ANSWER: 1 : 요청에 대한 응답된 레코드 1개 - AUTHORITY:0 : 권한 있는 네임서버 정보는 포함되지 않음 - ADDITIONAL:1 : 추가 정보가 하나 있음
OPT PSEUDOSECTION: EDNS: version: 0, flags:; udp: 65494- EDNS(확장 DNS) 의 0 버전 사용 중 - udp: 65494 : 이 클라이언트는 최대 65494바이트까지 UDP 응답을 받을 수 있음. (기본 DNS 512 b, EDNS 65494 b)
QUESTION SECTION: google.com. IN A - 질의한 내용 : google.com - 클래스는 IN : Internet - 타입 : A -> IPv4 주소 요청 (AAA -> IPv6 주소)
ANSWER SECTION: google.com. 119 IN A 142.250.206.206 - 도메인 이름 : google.com - 이 응답은 119초간 로컬에서 캐시 가능 - 클래스는 IN : Internet - 타입 A -> IPv4 주소 - 응답 값 : 142.250.206.206 (실제 google.com 의 ip 주소)
Query time: 3 msec - DNS 질의 후 응답까지 걸린 시간 ( 보통 1~100ms 사이)
SERVER: 127.0.0.53#53(127.0.0.53) (UDP) - 실제 DNS 질의를 처리한 서버 ( 로컬 DNS 리졸버 주소임 / system-resolved 가 사용 됨) - #53 번 포트가 사용 됨. ( DNS 기본 포트)
WHEN: Mon Apr 07 16:49:43 KST 2025 - 제일 쉽다. 질의를 한 시점
MSG SIZE rcvd: 55 - 응답 메시지의 크기 ( 55 바이트 )
3-2. dig google.com MX
명령어에 대한 결과는 비슷하지만 질의문에 MX 를 입력하여 질의 하였더니, 응답에서 smtp.google.com 을 통해 응답이 왔다. 네트워크 관리사 및 정보처리기사 시험 문제를 공부하며 맨날 봤던 메일 프토토콜이다!
지금은 메일과 관련된 에러가 없으니 정상적으로 질의를 주고 받았지만, 문제가 생기면 해당 명령어로 DNS 에 대해 문제가 있는지 확인할 수 있다.
3-3. dig @8.8.8.8 naver.com
@8.8.8.8 로 DNS 를 명시하는 것. 기본적으로 로컬 DNS 리졸버( 127.0.0.53) 에게 질의하지만, @ 를 사용하여 특정 DNS 서버IP 를 사용하면, 특정 DNS 서버에게 질의 하겠다. 라고 명시하는 것.
따라서 naver.com 이라는 도메인을 google의 퍼블릭 DNS (8.8.8.8) 에 질의한 것.
4개의 ANSWER 이 응답했고, 이는 naver.com 도메인을 여러 서버에서 분산하여 처리하고 있다는 의미이다 (로드 밸런싱)
4개의 각기 다른 IP 주소에서 naver.com 이라는 요청에 대해 분산하여 응답을 보내주고 있다.
기본적으로 dig address.com 으로 질의를 하면 로컬 DNS 서버에 질의하게 되는데, 이 경우 IP 주소가 바뀌었음에도 캐시 하고 있을 수 있기 때문에 최신 도메인 정보가 반영되지 않았을 수 있다. 따라서 최신 DNS 가 제대로 전파(업데이트) 되었는지 확인하기 위해 특정 도메인을 google DNS 나 기타 퍼블릭 DNS 에 질의하여 확인해 보는 것 이다.
3-4. dig @8.8.8.8
도메인명을 입력하지 않으면 -> 기본값으로 루트 도메인에 대한 질의가 자동으로 들어간다.
즉, 인터넷 DNS의 가장 최상위 계층에 대한 DNS 레코드 잘의를 한 것.
그 결과로 루트 도메인을 관리하는 13개의 네임 서버 주소를 반환 받았다.
전 세계에 분산된 a.root-servers.net ~ m.root-servers.net 은 수십~수백 대의 물리 서버로 운영된다고 한다.
내부 도메인의 경우는 "나만 사용하고, 아무에게도 공개되지 않는 도메인" 이기 때문에, 퍼블릭 DNS 에게 질의한다고 해도 아무런 정보가 없어야 한다. (dig @8.8.8.8 내부도메인)
내부 도메인(ex. my.nas) 으로 dig my.domain 으로 질의할 경우 내부 DNS 로 응답이 와야 한다. (192.168.0.20)
이렇기 설정에 따른 기대 응답이 올바르지 않을 경우 DNS 설정 오류 여부 및 VPN 환경 구성 필요 여부를 알아낼 수 있다.
4. 마무리 및 보충사항 (로컬 네임 서버)
dig는 단순한 명령어 같지만, 정말 많은 정보를 담고 있다.
DNS를 보면 서비스가 왜 안 되는지가 보이고, 구성상의 문제도 잡아낼 수 있다.
nslookup에 비해 더 상세하고, 구조화된 응답을 주기 때문에 서버나 네트워크 담당자들이 더 선호한다고 한다.
<< 로컬 네임 서버는 퍼블릭 네임 서버에서 정보를 학습하고 저장하는가? >>
로컬 네임 서버는 재귀적 질의를 통해 퍼블릭 네임서버 또는 상위 DNS 서버에서 도메인 정보를 가져오고, 캐시에 저장한다.
naver.com 이라는 도메인에 접속하려고 하면
로컬 네임서버가 먼저 질의를 받는다. ( 보통 공유기나 내부 DNS )
naver.com 에 처음 접속하는 경우 ip 주소를 모르니, 상위 DNS 서버나 퍼블릭 DNS 서버에게 차례대로 물어본다.
응답을 받아오면, 그 IP 정보를 캐시에 저장해두고, 다시 naver.com 을 질의할 경우 로컬 캐시에서 바로 응답한다.
5. 주의사항 및 기타
dig 결과는 캐시 상태나 DNS 서버 위치에 따라 다르게 나올 수 있다. → 그래서 +trace 옵션이나 @dns서버를 붙여서 확인하는 게 중요할 때도 있다
TXT, MX 레코드는 보안 설정(SPF, DMARC 등)과도 관련 있으니 민감한 서비스에서는 반드시 확인 필요하다.
개인 NAS 에 있는 DNS 서버를 구축한다면? -> NAS 의 주소 (192.168.0.20) 를 IP 로 외우지 않고, home.nas 식으로 도메인 설정 가능 -> 자주 방문하는 사이트는 외부 DNS 를 거치지 않기 때문에 응답 속도가 빨라진다. -> 광고차단 DNS 나 도메인 필터링도 사용 가능
