재귀 DNS 쿼리와 반복 DNS 쿼리

브라우저가 example.com을 찾아야 할 때, 컴퓨터는 단 하나의 DNS 쿼리를 보내고 답을 기다립니다. 질문 하나, 응답 하나. 하지만 그 단순함 뒤에서 DNS 리졸버는 완전히 다른 방식의 쿼리를 여러 번 실행하고 있습니다. 스스로 일하기를 거부하는 서버들의 참조를 하나씩 따라가면서요.

재귀(recursive)와 반복(iterative), 이 두 가지 쿼리 방식은 모든 DNS 조회에서 함께 작동합니다. 이를 이해하면 DNS가 어떻게 수십억 대의 기기에는 단순하게 보이면서도 전 세계 계층 구조 전반에 걸쳐 작업을 분산시키는지 알 수 있습니다.

재귀 쿼리: "나 대신 찾아줘"

재귀 쿼리는 책임의 위임입니다. "방법은 상관없으니 답만 가져다줘."

컴퓨터가 DNS 리졸버에 example.com을 쿼리할 때, 이것이 재귀 쿼리입니다. 질문 하나가 들어가고, 답 하나가 나옵니다. 컴퓨터는 참조를 원하지 않습니다. "다른 곳에 물어봐"라는 말도 듣고 싶지 않습니다. IP 주소가 필요하거나, 해당 도메인이 존재하지 않는다는 확인이 필요합니다.

컴퓨터 → 리졸버: "example.com의 IP 주소가 뭐야?"
리졸버 → [필요한 모든 작업 수행]
리졸버 → 컴퓨터: "93.184.216.34"

리졸버가 모든 책임을 떠안습니다. 답을 찾기 위해 다섯 군데 서버를 돌아다닐 수도 있지만, 컴퓨터는 그 과정을 전혀 볼 수 없습니다. 스마트폰, 노트북, 스마트 온도 조절기 모두 이런 방식으로 작동합니다. 재귀 쿼리를 보내고 나머지는 리졸버에게 맡기는 것입니다.

반복 쿼리: "저쪽에 물어봐"

반복 쿼리는 다른 종류의 응답을 받습니다. 서버가 현재 알고 있는 최선의 답, 그리고 더 잘 아는 곳으로 가라는 참조입니다.

리졸버가 재귀 쿼리를 받았는데 캐시에 답이 없으면, 권한 DNS 서버들에 차례로 반복 쿼리를 보내기 시작합니다:

리졸버 → 루트 서버: "example.com의 IP 주소가 뭐야?"
루트 서버 → 리졸버: "몰라. 192.5.6.30에 있는 .com 서버에 물어봐"

리졸버 → .com 서버: "example.com의 IP 주소가 뭐야?"
.com 서버 → 리졸버: "몰라. 199.43.133.53에 있는 example.com 네임서버에 물어봐"

리졸버 → example.com 네임서버: "example.com의 IP 주소가 뭐야?"
example.com 네임서버 → 리졸버: "93.184.216.34"

각 서버는 자신이 아는 것만 답합니다. 루트 서버는 .com을 담당하는 곳을 알고 있습니다. .com 서버는 example.com의 권한이 어디에 있는지 알고 있습니다. 권한 네임서버는 실제 IP 주소를 알고 있습니다.

리졸버는 최종 답을 가진 서버에 닿을 때까지 각 참조를 따라갑니다.

왜 이런 분업이 존재하는가

재귀 쿼리는 편리합니다. 반복 쿼리는 버텨낼 수 있게 해줍니다.

루트 서버가 "나 대신 찾아줘"를 받아들인다면, 전 세계 모든 리졸버를 대신해 외부로 쿼리를 날려야 합니다. 순식간에 무너질 것입니다. 대신 루트 서버는 거의 아무것도 하지 않으면서 초당 수만 건의 쿼리를 처리합니다. "내 영역이 아니야. 저쪽에 물어봐."

클라이언트가 재귀 쿼리를 사용하는 이유:

• 질문 하나, 답 하나. 기기 쪽에서는 아무 복잡함이 없음
• 스마트폰과 노트북은 DNS 계층 구조를 직접 탐색하도록 설계되지 않았음
• 캐싱은 리졸버에서 이루어지므로 같은 리졸버를 쓰는 모든 사람이 혜택을 받음
• 수십억 대의 단순한 기기가 단순하게 유지됨

리졸버가 반복 쿼리를 사용하는 이유:

• 권한 서버는 자신의 영역에 관한 질문에만 답함
• 어느 서버도 다른 서버가 대신 쿼리를 실행하는 것을 허용하지 않음
• 부하가 계층 구조 전체에 자연스럽게 분산됨
• 루트 서버는 아무를 대신해 일하지 않기 때문에 과부하 없이 운영될 수 있음

이것은 한계가 아닙니다. DNS가 전체 인터넷을 서비스하면서 살아남는 방식입니다.

전체 경로

www.connected.app에 처음 접속할 때:

1. 컴퓨터 → 리졸버: 재귀 쿼리 ("www.connected.app을 찾아줘")
2. 리졸버 → 루트 서버: 반복 쿼리 → ".app 서버에 물어봐"
3. 리졸버 → .app 서버: 반복 쿼리 → "connected.app 네임서버에 물어봐"
4. 리졸버 → connected.app 네임서버: 반복 쿼리 → "76.76.21.21"
5. 리졸버 → 컴퓨터: "76.76.21.21"

컴퓨터는 쿼리를 한 번 보냈습니다. 리졸버는 세 번 쿼리했습니다. 컴퓨터는 복잡한 과정을 리졸버에게 맡겼고, 리졸버는 아무도 믿지 않았습니다. 각 단계를 직접 확인했습니다.

실용적인 의미

이 차이는 문제가 생겼을 때 중요해집니다:

• 재귀 쿼리에 응답 없음: 리졸버가 다운되었거나 연결할 수 없는 상태
• 리졸버가 반복 쿼리를 완료할 수 없음: 방화벽이 외부 DNS 트래픽을 차단하거나 상위 서버에 접근 불가
• DNS 포이즈닝 공격: 주로 리졸버와 권한 서버 사이의 반복 경로를 노림
• 느린 조회: 반복 경로의 각 홉이 지연 시간을 더함. 좋은 리졸버는 적극적인 캐싱으로 이를 줄임

Cloudflare(1.1.1.1)나 Google(8.8.8.8) 같은 공용 리졸버가 인기 있는 이유는 가용성이 높고 반복 쿼리 성능이 뛰어난 재귀 리졸버이기 때문입니다. 사용자가 맡긴 신뢰를 잘 처리해줍니다.

재귀 DNS 쿼리와 반복 DNS 쿼리에 관해 자주 묻는 질문

컴퓨터가 직접 반복 쿼리를 할 수 있나요?

기술적으로는 가능하지만, 실제로 그렇게 하는 경우는 거의 없습니다. 직접 반복 쿼리를 하려면 컴퓨터가 어디서부터 시작해야 하는지(루트 서버), 여러 참조를 어떻게 따라가야 하는지, DNS 계층 구조를 탐색하는 복잡한 과정을 모두 처리해야 합니다. 재귀 쿼리를 사용하면 이 모든 작업을 그 역할에 맞게 설계된 리졸버에게 맡길 수 있습니다.

권한 서버가 재귀 쿼리를 받아들이지 않는 이유는 무엇인가요?

규모와 보안 때문입니다. 재귀 쿼리는 사실상 "나 대신 쿼리를 실행해달라"는 요청인데, 권한 서버는 그 책임을 거부합니다. 자신의 영역에 관한 질문에만 답하고 나머지는 참조로 안내합니다. 외부 쿼리도 없고, 복잡한 상태 관리도 없으며, 낯선 이를 대신하는 데서 오는 공격 표면도 없습니다.

참조가 가리키는 서버가 다운되면 어떻게 되나요?

여러 네임서버가 등록되어 있으면 리졸버가 다른 것을 시도합니다(대부분의 영역에는 최소 두 개가 있습니다). 권한 서버 전부에 접근할 수 없으면 리졸버는 재귀 쿼리에 SERVFAIL 오류를 반환하고, 컴퓨터에는 "DNS 조회 실패"가 표시됩니다.

캐싱이 두 쿼리 방식에서 다르게 작동하나요?

리졸버는 두 방식 모두에서 받은 답을 캐시하지만, 그 혜택은 재귀 쿼리 쪽으로 흘러갑니다. 컴퓨터가 리졸버가 최근에 조회한 도메인을 요청하면, 반복 쿼리 없이 캐시된 답을 즉시 돌려줍니다. 캐싱은 재귀 쿼리를 빠르게 만들고, 반복 쿼리는 그 캐시를 채웁니다.