DNS는 그냥 한 서버에게 물어보면 끝날 것 같죠? 사실은 “누가 끝까지 찾아주는가”에 따라 완전히 다른 대화가 돼요.DNS는 어떻게 이름을 IP 주소로 바꿀까요?에서는 DNS를 이름을 숫자 주소로 바꿔주는 안내 데스크로 봤어요. 그리고 dig 출력은 어디부터 읽어야 할까요?에서는 그 조회 결과가
HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL 같은 구역으로 펼쳐진다는 것도 봤죠.
근데요, 여기서 한 가지가 은근히 헷갈려요.
- 내 브라우저는 DNS 서버에게 한 번만 물어본 것 같은데, 왜 루트 서버와
.com서버 이야기가 나오죠? dig +trace를 보면 내가 직접 여러 서버를 따라가는 것처럼 보이는데, 평소 조회도 그런 걸까요?rd와ra플래그는 왜 자꾸 같이 보일까요?AUTHORITY SECTION에 답 대신 다른 서버 이름이 오는 건 실패일까요, 힌트일까요?
여기서는 재귀 리졸버가 대신 끝까지 찾아주는 흐름과 권한 서버가 다음 힌트만 돌려주는 흐름을 구분하는 데 집중해요.
DNSSEC 검증, QNAME minimization, resolver 구현별 캐시 정책, DoH/DoT 전송 경로는 여기서 깊게 열지 않을게요.
그런 주제는 DNS 축의 뒤 글에서 따로 이어보면 돼요.
왜 이 차이를 알아야 할까요?
평소에는 재귀 조회와 반복 조회를 몰라도 웹사이트가 잘 열려요. 문제는 DNS 장애나 운영 확인을 할 때예요. 예를 들어dig example.com A 를 쳤는데 답이 없다고 해볼게요.
이때 바로 “권한 서버가 망가졌나?” 라고 단정하면 위험해요.
실제로는 아래 중 하나일 수 있거든요.
- 내 컴퓨터가 물어본 재귀 리졸버가 캐시된 예전 답을 들고 있음
- 리졸버가 루트나 TLD에서 받은 위임 힌트를 따라가다 실패함
- 권한 서버는 정상인데, 내가 물은 리졸버에서 재귀 기능을 제공하지 않음
+trace로 직접 따라간 결과와 평소 리졸버 결과가 서로 다른 경로를 보고 있음
재귀 조회와 반복 조회는 한마디로 뭐예요?
먼저 짧게 잡으면 이래요.재귀 조회는 “대신 끝까지 찾아주세요”이고, 반복 조회는 “다음에 물어볼 곳만 알려주세요”예요.이 한 줄이 오늘의 핵심이에요.
여기서 중요한 건 브라우저와 리졸버 사이의 대화와 리졸버와 권한 계층 사이의 대화가 성격이 다르다는 점이에요.
브라우저는 보통 재귀 리졸버에게 이렇게 말해요.
“example.com 주소가 필요해요. 제가 직접 돌아다니긴 어렵고, 대신 끝까지 찾아주세요.”
반면 리졸버가 루트나 TLD 서버에게 물어볼 때는 보통 이런 식이에요.
“example.com 을 알고 있나요? 모르면 다음에 누구한테 물어봐야 하는지 알려주세요.”
이 두 대화를 한 덩어리로 뭉개면 dig 출력도, 캡처도, 장애 원인도 흐려져요.
전체 흐름을 먼저 한 장으로 볼까요?
평소 브라우저가example.com 에 접속하려고 할 때의 흐름을 크게 그리면 이렇게 돼요.
이 그림에서 앞뒤를 나눠 보는 게 중요해요.
앱 → 재귀 리졸버 구간은 “대신 끝까지 찾아주세요”에 가깝고, 재귀 리졸버 → 루트/TLD/권한 서버 구간은 “알면 답하고, 모르면 다음 힌트를 주세요”에 가까워요.
재귀 조회는 누가 끝까지 책임지는 흐름일까요?
재귀 조회에서는 질문을 받은 쪽이 최종 답을 구해서 돌려주는 책임을 져요. 보통 여러분의 컴퓨터나 브라우저가 직접 루트 서버를 따라다니지 않고, 집 공유기나 통신사 DNS, 회사 DNS, 공용 DNS 같은 재귀 리졸버에게 맡기는 이유가 여기에 있어요. 재귀 리졸버는 먼저 캐시를 봐요. 이미 답을 알고 있으면 루트 서버까지 가지 않고 바로 돌려줄 수 있어요. 캐시에 없으면 그때 루트, TLD, 권한 서버를 차례로 따라가죠. 이때 DNS 메시지 헤더에서는RD 와 RA 를 자주 보게 돼요.
RD 와 RA 는 비슷하게 생겼지만 같은 말이 아니에요.
RD 는 부탁이고, RA 는 가능 여부예요.
반복 조회는 왜 “힌트만 주는” 방식일까요?
반복 조회에서는 질문을 받은 서버가 자기가 아는 만큼만 답해요. 최종 답을 알고 있으면 답을 주고, 모르면 보통 다음에 물어볼 곳을 알려줘요. 루트 서버를 생각해볼까요? 루트 서버는 전 세계 모든 도메인의 IP 주소를 직접 들고 있지 않아요. 대신.com, .net, .kr 같은 큰 구역을 누가 담당하는지 알고 있어요.
이 그림에서 루트와 TLD는 보통 최종 IP를 직접 주지 않아요.
대신 다음 담당자 정보를 줘요.
이런 응답을 흔히 referral, 즉 위임 힌트처럼 읽어요.
dig 출력에서는 이 힌트가 AUTHORITY SECTION 과 ADDITIONAL SECTION 쪽에 나타날 수 있어요.
여기서
AUTHORITY SECTION 에 뭔가 나왔다고 해서 항상 실패는 아니에요.
오히려 반복 조회 중간에서는 “다음은 여기로 가세요” 라는 정상적인 안내일 수 있어요.
dig +trace 는 왜 평소 조회와 다르게 보일까요?
DNS를 공부하다 보면 dig +trace example.com 을 자주 보게 돼요.
이 명령은 평소처럼 한 재귀 리졸버에게 끝까지 맡기는 조회가 아니에요. dig가 루트부터 각 단계에 직접 질의하며 위임 힌트를 수동으로 따라가 보는 연습에 가까워요.
dig +trace 전체 출력을 옮긴 게 아니라, 위임 순서만 남긴 단순화된 개념도예요.
- 루트에서 시작해요.
.com담당자를 받아요.example.com담당자를 받아요.- 마지막 권한 서버에서
A답을 받아요.
dig example.com A 는 보통 여러분이 설정한 재귀 리졸버에게 물어요.
반면 +trace 는 계층을 따라가는 모습을 보여주기 때문에, 둘의 결과가 다르게 보일 때도 있어요.
캐시, 접근 제한, 네트워크 경로, 권한 서버 응답 차이 같은 것들이 사이에 끼어들 수 있거든요.
캐시는 이 흐름을 어떻게 바꿀까요?
처음 조회에서는 리졸버가 여러 단계를 따라갈 수 있어요. 하지만 같은 이름을 다시 묻는다면 이야기가 달라져요. 이 장면 때문에 DNS 장애가 더 헷갈려져요. 권한 서버의 설정을 바꿨는데도 어떤 사람은 새 주소를 보고, 어떤 사람은 예전 주소를 볼 수 있거든요. 그 차이는 어느 재귀 리졸버를 쓰는지, 그 리졸버가 언제 답을 캐시했는지, TTL이 얼마나 남았는지에 따라 달라질 수 있어요. 여기서는 캐시가 조회 흐름을 짧게 만들 수 있다는 점까지만 잡을게요. TTL 때문에 값이 오래 남는 문제는 DNS TTL과 캐시에서 따로 더 열어볼게요.실제로 헷갈리기 쉬운 장면을 나눠볼까요?
재귀 조회와 반복 조회를 구분하면, 아래 장면들을 훨씬 덜 성급하게 판단할 수 있어요.
이 표에서 핵심은 하나예요.
DNS 문제를 볼 때는 결과값만 보지 말고, 그 결과를 누가 대신 찾아줬는지 같이 봐야 해요.
그럼 진짜 DNS 조회를 볼 때는 어디부터 읽을까요?
운영 화면이나 터미널에서 DNS를 볼 때는 이런 순서가 편해요.- 내가 누구에게 물었는지 봐요.
dig출력의SERVER:줄을 먼저 확인해요.
- 재귀 조회를 기대하는 장면인지 봐요.
- 일반 조회라면 보통
rd,ra플래그가 보일 수 있어요.
- 일반 조회라면 보통
- 답이 직접 답인지 힌트인지 봐요.
ANSWER,AUTHORITY,ADDITIONAL을 나눠 읽어요.
- 캐시 가능성을 의심해요.
TTL이 남아 있으면 예전 답이 정상적으로 보일 수도 있어요.
- 필요할 때만
+trace로 위임 사슬을 따라가요.- 평소 리졸버 답과 권한 계층 흐름을 구분해서 봐요.
자, 정리해볼까요?
- 재귀 조회는 클라이언트가 리졸버에게 “대신 끝까지 찾아주세요” 라고 맡기는 흐름이에요.
- 반복 조회는 서버가 최종 답을 모르면 “다음에 여기로 가세요” 라는 힌트를 주는 흐름이에요.
RD는 재귀를 원한다는 부탁이고,RA는 재귀를 제공할 수 있다는 표시예요.AUTHORITY SECTION은 실패 표시가 아니라, 위임 힌트나 부정 응답 근거일 수 있어요.dig는 재귀 리졸버의 답을 보고,dig +trace는 위임 사슬을 수동으로 따라가는 과정을 보여줘요.
이어서 보면 좋은 글
- 재귀 리졸버가 돌려주는 답을 실제
dig화면에서 읽고 싶다면 — dig 출력은 어디부터 읽어야 할까요? - DNS 메시지의
flags,ANSWER,AUTHORITY칸 자체를 더 자세히 보고 싶다면 — DNS 메시지는 왜 질문 하나에 칸이 이렇게 많을까요? - 캐시 때문에 바뀐 값이 바로 안 보이는 장면을 이어서 보고 싶다면 — DNS TTL과 캐시는 왜 바뀐 주소를 바로 안 보여줄까요?
- DNS의 큰 흐름부터 다시 잡고 싶다면 — DNS는 어떻게 이름을 주소로 바꿔줄까요?