dig example.com 한 번이면 끝날 것 같죠? 사실은 답보다 주변 메모를 먼저 읽어야 할 때가 많아요.
DNS는 어떻게 이름을 IP 주소로 바꿀까요?에서는 DNS를 이름을 숫자 주소로 바꿔주는 안내 데스크로 봤어요. 그리고 DNS 메시지는 왜 질문 하나에 칸이 이렇게 많을까요?에서는 그 질문과 답이 실제 메시지 안에서 Header, Question, Answer, Authority, Additional 구역으로 나뉜다는 것도 봤죠.
근데요, 실제 터미널에서 dig를 열면 생각보다 이런 고민이 먼저 와요.
status: NOERROR인데 왜 답이 없죠?ANSWER SECTION이 없으면 조회가 실패한 걸까요?AUTHORITY SECTION은 답인가요, 아니면 힌트인가요?OPT PSEUDOSECTION은 갑자기 왜 끼어들었을까요?SERVER: 192.168.0.1#53은 내가 물어본 사이트 서버인가요?
dig 명령어 전체 설명서처럼 모든 옵션을 외우지 않고, 출력 한 덩어리를 위에서 아래로 읽는 순서에 집중할게요. 이전 글에서 본 DNS 메시지 구조가 여기서 그대로 이어지고, 다음 DNS 글들에서는 재귀 조회와 TTL/캐시 문제를 더 따로 열어볼 거예요.
여기서는
dig 출력의 기본 구조와 자주 헷갈리는 신호를 읽는 데 집중해요. +trace, DNSSEC 검증, DoH/DoT 경로, 리졸버 설정 파일까지는 깊게 들어가지 않을게요. 오늘 목표는 터미널 출력에서 어디가 질문이고, 어디가 답이고, 어디가 힌트인지 구분하는 거예요.왜 dig 출력을 읽을 줄 알아야 할까요?
DNS 문제는 겉으로 보면 다 비슷해 보여요. 브라우저에는 그냥 “사이트에 연결할 수 없음” 이라고 뜨고, 서버에서는 “외부 API가 안 붙어요” 라고 보일 수 있죠. 그런데dig 출력으로 내려오면 문제가 조금 더 잘게 갈라져요.
- 이름 자체가 없는지
- 이름은 있는데 내가 물은 레코드 종류만 없는지
- 답은 왔는데 캐시 때문에 오래된 값을 보고 있는지
- 내 컴퓨터가 어느 리졸버에게 물어보고 있는지
- 응답은 성공인데
CNAME을 따라가야 하는지
dig는 DNS의 최종 정답지만 보여주는 도구가 아니라, DNS 조회 장면의 영수증을 보여주는 도구에 가까워요.
이 표만 먼저 잡아도 출력이 훨씬 덜 낯설어요.
dig는 DNS 메시지의 칸을 사람이 읽기 좋게 펼쳐놓은 화면이라고 보면 돼요.
먼저 한 화면을 같이 볼까요?
예를 들어 A 레코드를 조회하면 이런 모양의 출력이 나와요. 실제 값은 조회 시점과 사용하는 리졸버에 따라 달라질 수 있어서, 아래 예시는 읽기 흐름을 보여주기 위해 단순화했어요.ANSWER SECTION 의 IP 주소만 보고 싶어져요. 당연해요. 근데 장애를 볼 때는 위에서 아래로 최소한 네 곳을 같이 봐야 해요.
- HEADER — 성공인지 실패인지, 답 개수는 몇 개인지
- QUESTION — 내가 정말 의도한 이름과 종류를 물었는지
- ANSWER / AUTHORITY / ADDITIONAL — 직접 답인지, 힌트인지, 보조 메모인지
- SERVER / Query time — 누구에게 물었고 얼마나 걸렸는지
dig가 화면에 OPT, QUESTION, ANSWER 등을 배치하는 순서는 사람이 보기 위한 표시 순서일 뿐, 앞에 나온 구역이 프로토콜에서 더 중요하다는 뜻은 아니에요.
HEADER는 결과표의 맨 위 요약이에요
dig 출력에서 제일 먼저 볼 줄은 여기예요.
여기서 제일 중요한 건
status 와 ANSWER 를 따로 읽는 거예요.
NOERROR 는 “처리 성공”이지, “답이 반드시 있다”는 뜻은 아니에요.
예를 들어 도메인은 존재하지만 AAAA 레코드가 없을 수도 있어요. 이때는 status: NOERROR 이면서 ANSWER: 0 이 나올 수 있어요. 반대로 이름 자체가 없으면 보통 NXDOMAIN 으로 보이죠.
이 차이를 놓치면 “DNS가 실패했다” 고 너무 빨리 단정하게 돼요. 실제로는 실패가 아니라 빈 답일 때가 꽤 있어요.
QUESTION은 내가 낸 질문표예요
그다음은QUESTION SECTION 을 봐요.
“example.com.의 인터넷 클래스(IN) A 레코드를 알려주세요.”
여기서 은근히 많이 생기는 실수가 있어요. 내가 A 레코드를 본다고 생각했는데 실제로는
AAAA 를 물었거나, www.example.com 을 봐야 하는데 example.com 을 보고 있을 수 있거든요.
그래서 장애를 볼 때는 답부터 보지 말고, 먼저 이렇게 물어보면 좋아요.
- 내가 정말 그 이름을 물었나요?
- 내가 정말 그 레코드 종류를 물었나요?
- 끝에 붙은 점, CNAME,
www유무 때문에 다른 이름을 보고 있지는 않나요?
ANSWER는 직접 답이고, TTL도 같이 읽어야 해요
ANSWER SECTION 은 우리가 가장 기대하는 부분이에요.
여기서 IP 주소만 보고 지나가면 아쉬워요. DNS 장애나 배포 전환을 볼 때는
TTL 도 같이 봐야 하거든요.
TTL 300 은 이 답을 300초 동안 캐시해도 된다는 뜻에 가까워요. 그래서 방금 DNS 설정을 바꿨는데 누군가는 예전 주소를 보고 있다면, 단순히 “DNS가 이상하다” 가 아니라 어딘가에 남은 TTL 동안 예전 답이 캐시되어 있을 수 있다고 보는 게 더 정확해요.
여기서는 TTL을 캐시의 유통기한 정도로만 잡고 갈게요. TTL이 리졸버 캐시, 브라우저, 운영체제 쪽에서 어떻게 체감되는지는 DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요?에서 더 자세히 이어서 볼 수 있어요.
AUTHORITY와 ADDITIONAL은 답처럼 보여도 역할이 달라요
이번에는 직접 답이 없는 장면을 볼게요. 예시는 단순화한 출력이에요.AUTHORITY SECTION 에 뭔가 적혀 있다고 해서, 그게 내가 물은 AAAA 의 직접 답이라는 뜻은 아니에요. 이 경우에는 직접 답은 없고, 권한 섹션에 이 영역에 대한 근거 메모가 붙은 장면으로 읽는 편이 좋아요.
즉
AUTHORITY는 상황에 따라 다음 위임을 알려주는 힌트이거나 직접 답이 없음을 설명하는 근거예요. ADDITIONAL은 그 힌트를 따라갈 때 필요한 서버 주소처럼, 앞 구역의 정보를 보조할 수 있고요.
OPT PSEUDOSECTION 은 이름부터 살짝 이상하죠. 이건 일반적인 도메인 레코드라기보다, DNS 메시지 자체의 확장 정보를 담는 특별한 메모에 가까워요. 지금은 udp: 1232 처럼 “이 정도 크기의 UDP 응답을 다룰 수 있어요” 같은 협상 정보가 보일 수 있다는 정도만 알아도 충분해요.
SERVER와 Query time은 어디서 물었는지 알려줘요
마지막 아래쪽 줄도 그냥 장식이 아니에요.SERVER 는 내가 질문을 보낸 DNS 리졸버예요. 내가 접속하려는 웹사이트 서버가 아니에요.
이 줄이 중요한 이유는 간단해요. 같은 이름을 물어도 어느 리졸버에게 물었느냐에 따라 캐시 상태, 정책, 응답 시간이 달라질 수 있거든요.
예를 들어 이렇게 명시해서 물을 수도 있어요.
짧게 보고 싶을 때는 +short, 구조를 보고 싶을 때는 기본 출력이에요
dig를 쓰다 보면 이런 명령도 많이 봐요.
+short 는 답만 빠르게 볼 때 편해요. 스크립트에서 값을 뽑거나, 지금 주소가 뭔지만 빠르게 확인할 때는 좋죠.
하지만 문제를 파악하는 중이라면 기본 출력이 더 나아요.
그러니까
+short 는 정상일 때 빠르게 확인하는 도구에 가깝고, 기본 출력은 이상할 때 이유를 찾는 도구에 가까워요.
헷갈리기 쉬운 장면 세 가지
1. NOERROR 인데 답이 없을 수 있어요
NOERROR 는 DNS 서버가 질문을 처리했다는 뜻이에요. 내가 물은 레코드가 실제로 있다는 뜻은 아니에요.
그래서 status: NOERROR, ANSWER: 0 을 보면 이렇게 읽어야 해요.
“이름이나 영역은 처리됐지만, 내가 물은 타입의 직접 답은 없을 수 있구나.”
2. AUTHORITY SECTION 을 직접 답으로 착각하기 쉬워요
AUTHORITY 에 SOA 나 NS 가 보이면 뭔가 답을 받은 것처럼 느껴져요. 하지만 ANSWER: 0 이면 직접 답은 없는 장면일 수 있어요.
AUTHORITY 는 대개 담당자 힌트나 부정 응답의 근거 쪽으로 먼저 읽는 게 덜 위험해요.
3. SERVER 는 목적지 웹 서버가 아니에요
SERVER: 192.168.0.1#53 을 보고 “example.com 서버가 192.168.0.1인가?” 라고 읽으면 안 돼요. 이건 내가 질문을 던진 DNS 리졸버예요.
웹사이트에 실제로 접속할 서버 주소는 ANSWER SECTION 의 A/AAAA 값 쪽에서 봐야 해요.
그럼 실제로는 어떤 순서로 읽으면 좋을까요?
처음에는 이 순서만 따라가도 충분해요. 이 순서가 좋은 이유는, 결론을 너무 빨리 내리지 않게 해주기 때문이에요. DNS 출력은 답 줄 하나가 아니라 질문, 상태, 직접 답, 힌트, 조회 위치가 같이 붙은 기록이니까요.자, 정리해볼까요?
dig기본 출력은 DNS 메시지를 사람이 읽기 좋게 펼쳐놓은 화면이에요.HEADER에서는status와ANSWER개수를 먼저 같이 봐야 해요.QUESTION은 내가 정말 의도한 이름과 레코드 타입을 물었는지 확인하는 자리예요.ANSWER에서는 값뿐 아니라TTL도 같이 읽어야 해요.AUTHORITY,ADDITIONAL,OPT PSEUDOSECTION은 직접 답이 아니라 힌트나 확장 메모일 수 있어요.dig의 화면 표시 순서는 프로토콜의 중요도 순서가 아니므로, 진단할 때는 상태와 질문부터 확인해요.SERVER는 목적지 웹 서버가 아니라, 내가 물어본 DNS 리졸버예요.
dig 출력은 암호문이 아니라 꽤 친절한 영수증처럼 보이기 시작해요.
이어서 보면 좋은 글
dig출력 뒤에 있는 원래 DNS 메시지 칸을 더 자세히 보고 싶다면 — DNS 메시지는 왜 질문 하나에 칸이 이렇게 많을까요?SERVER,RD,RA,AUTHORITY를 재귀 조회 관점에서 다시 읽고 싶다면 — DNS 재귀 조회와 반복 조회는 뭐가 다를까요?- 답은 맞는 것 같은데 예전 값이 남아 보이는 이유를 보고 싶다면 — DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요?
- CNAME과 apex 도메인을
dig로 확인하는 장면까지 이어서 보고 싶다면 — CNAME과 apex 도메인은 왜 같이 쓰기 어려울까요?