DNS 재귀 조회와 반복 조회는 뭐가 다를까요?¶

DNS는 그냥 한 서버에게 물어보면 끝날 것 같죠? 사실은 "누가 끝까지 찾아주는가"에 따라 완전히 다른 대화가 돼요.

DNS는 어떻게 이름을 IP 주소로 바꿀까요?에서는 DNS를 이름을 숫자 주소로 바꿔주는 안내 데스크로 봤어요. 그리고 dig 출력은 어디부터 읽어야 할까요?에서는 그 조회 결과가 HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL 같은 구역으로 펼쳐진다는 것도 봤죠.

근데요, 여기서 한 가지가 은근히 헷갈려요.

• 내 브라우저는 DNS 서버에게 한 번만 물어본 것 같은데, 왜 루트 서버와 .com 서버 이야기가 나오죠?
• dig +trace 를 보면 내가 직접 여러 서버를 따라가는 것처럼 보이는데, 평소 조회도 그런 걸까요?
• rd 와 ra 플래그는 왜 자꾸 같이 보일까요?
• AUTHORITY SECTION 에 답 대신 다른 서버 이름이 오는 건 실패일까요, 힌트일까요?

이 글은 바로 그 질문을 풀기 위한 글이에요. 오늘은 재귀 조회와 반복 조회가 한마디로 무엇인지, 기본편의 DNS 조회 흐름과 어떻게 이어지는지, 왜 이 둘을 나눠서 봐야 하는지, 그리고 실제로 리졸버가 어떤 순서로 루트, TLD, 권한 서버를 따라가는지 같이 내려가볼게요. DNS의 큰 모델은 RFC 1034 4.3.1절과 RFC 1035 7절에서 잡은 재귀/반복 조회 감각을 바탕으로 볼게요.

왜 이 차이를 알아야 할까요?¶

평소에는 재귀 조회와 반복 조회를 몰라도 웹사이트가 잘 열려요. 문제는 DNS 장애나 운영 확인을 할 때예요.

예를 들어 dig example.com A 를 쳤는데 답이 없다고 해볼게요. 이때 바로 "권한 서버가 망가졌나?" 라고 단정하면 위험해요. 실제로는 아래 중 하나일 수 있거든요.

• 내 컴퓨터가 물어본 재귀 리졸버가 캐시된 예전 답을 들고 있음
• 리졸버가 루트나 TLD에서 받은 위임 힌트를 따라가다 실패함
• 권한 서버는 정상인데, 내가 물은 리졸버에서 재귀 기능을 제공하지 않음
• +trace 로 직접 따라간 결과와 평소 리졸버 결과가 서로 다른 경로를 보고 있음

즉 DNS를 볼 때는 "누가 누구에게 무엇을 부탁했는지" 를 먼저 나눠야 해요. 그 경계가 바로 재귀 조회와 반복 조회예요.

재귀 조회와 반복 조회는 한마디로 뭐예요?¶

먼저 짧게 잡으면 이래요.

재귀 조회는 "대신 끝까지 찾아주세요"이고, 반복 조회는 "다음에 물어볼 곳만 알려주세요"예요.

이 한 줄이 오늘의 핵심이에요.

여기서 중요한 건 브라우저와 리졸버 사이의 대화와 리졸버와 권한 계층 사이의 대화가 성격이 다르다는 점이에요.

브라우저는 보통 재귀 리졸버에게 이렇게 말해요.

"example.com 주소가 필요해요. 제가 직접 돌아다니긴 어렵고, 대신 끝까지 찾아주세요."

반면 리졸버가 루트나 TLD 서버에게 물어볼 때는 보통 이런 식이에요.

"example.com 을 알고 있나요? 모르면 다음에 누구한테 물어봐야 하는지 알려주세요."

이 두 대화를 한 덩어리로 뭉개면 dig 출력도, 캡처도, 장애 원인도 흐려져요.

전체 흐름을 먼저 한 장으로 볼까요?¶

평소 브라우저가 example.com 에 접속하려고 할 때의 흐름을 크게 그리면 이렇게 돼요.

sequenceDiagram
    participant 앱 as 브라우저 / OS
    participant 재귀 as 재귀 리졸버
    participant 루트 as 루트 서버
    participant TLD as .com TLD 서버
    participant 권한 as example.com 권한 서버

    앱->>재귀: example.com A?<br/>재귀 조회 요청
    재귀->>루트: example.com A?<br/>반복 조회
    루트-->>재귀: .com 서버에게 물어보세요
    재귀->>TLD: example.com A?<br/>반복 조회
    TLD-->>재귀: example.com 권한 서버에게 물어보세요
    재귀->>권한: example.com A?<br/>반복 조회
    권한-->>재귀: example.com A = 93.184.216.34
    재귀-->>앱: example.com A = 93.184.216.34

이 그림에서 앞뒤를 나눠 보는 게 중요해요. 앱 → 재귀 리졸버 구간은 "대신 끝까지 찾아주세요"에 가깝고, 재귀 리졸버 → 루트/TLD/권한 서버 구간은 "알면 답하고, 모르면 다음 힌트를 주세요"에 가까워요.

재귀 조회는 누가 끝까지 책임지는 흐름일까요?¶

재귀 조회에서는 질문을 받은 쪽이 최종 답을 구해서 돌려주는 책임을 져요. 보통 여러분의 컴퓨터나 브라우저가 직접 루트 서버를 따라다니지 않고, 집 공유기나 통신사 DNS, 회사 DNS, 공용 DNS 같은 재귀 리졸버에게 맡기는 이유가 여기에 있어요.

flowchart LR
    A[앱 / OS<br/><small>주소가 필요함</small>]
    B[재귀 리졸버<br/><small>대신 끝까지 찾음</small>]
    C[캐시<br/><small>이미 알면 바로 답</small>]
    D[DNS 계층<br/><small>루트, TLD, 권한 서버</small>]

    A -->|재귀 요청| B
    B --> C
    C -->|캐시에 있으면| B
    B -->|없으면 따라감| D
    D --> B
    B -->|최종 답| A

재귀 리졸버는 먼저 캐시를 봐요. 이미 답을 알고 있으면 루트 서버까지 가지 않고 바로 돌려줄 수 있어요. 캐시에 없으면 그때 루트, TLD, 권한 서버를 차례로 따라가죠.

이때 DNS 메시지 헤더에서는 RD 와 RA 를 자주 보게 돼요.

RD 와 RA 는 비슷하게 생겼지만 같은 말이 아니에요. RD 는 부탁이고, RA 는 가능 여부예요.

반복 조회는 왜 "힌트만 주는" 방식일까요?¶

반복 조회에서는 질문을 받은 서버가 자기가 아는 만큼만 답해요. 최종 답을 알고 있으면 답을 주고, 모르면 보통 다음에 물어볼 곳을 알려줘요.

루트 서버를 생각해볼까요? 루트 서버는 전 세계 모든 도메인의 IP 주소를 직접 들고 있지 않아요. 대신 .com, .net, .kr 같은 큰 구역을 누가 담당하는지 알고 있어요.

flowchart TD
    A[재귀 리졸버<br/><small>example.com A?</small>] --> B[루트 서버]
    B --> C[.com 서버를 보세요<br/><small>referral</small>]
    A --> D[.com TLD 서버]
    D --> E[example.com 권한 서버를 보세요<br/><small>referral</small>]
    A --> F[example.com 권한 서버]
    F --> G[93.184.216.34<br/><small>최종 답</small>]

이 그림에서 루트와 TLD는 보통 최종 IP를 직접 주지 않아요. 대신 다음 담당자 정보를 줘요. 이런 응답을 흔히 referral, 즉 위임 힌트처럼 읽어요.

dig 출력에서는 이 힌트가 AUTHORITY SECTION 과 ADDITIONAL SECTION 쪽에 나타날 수 있어요.

여기서 AUTHORITY SECTION 에 뭔가 나왔다고 해서 항상 실패는 아니에요. 오히려 반복 조회 중간에서는 "다음은 여기로 가세요" 라는 정상적인 안내일 수 있어요.

dig +trace 는 왜 평소 조회와 다르게 보일까요?¶

DNS를 공부하다 보면 dig +trace example.com 을 자주 보게 돼요. 이 명령은 평소처럼 한 재귀 리졸버에게 끝까지 맡기는 장면이라기보다, 루트부터 시작해서 위임 힌트를 따라가는 과정을 눈앞에 펼쳐보는 장면에 가까워요.

dig +trace example.com A

단순화하면 출력 흐름은 이런 식이에요.

.                       NS      a.root-servers.net.
com.                    NS      a.gtld-servers.net.
example.com.            NS      a.iana-servers.net.
example.com.            A       93.184.216.34

이건 실제 값 전체를 그대로 외우자는 뜻이 아니에요. 읽는 순서가 중요해요.

1. 루트에서 시작해요.
2. .com 담당자를 받아요.
3. example.com 담당자를 받아요.
4. 마지막 권한 서버에서 A 답을 받아요.

평소 dig example.com A 는 보통 여러분이 설정한 재귀 리졸버에게 물어요. 반면 +trace 는 계층을 따라가는 모습을 보여주기 때문에, 둘의 결과가 다르게 보일 때도 있어요. 캐시, 접근 제한, 네트워크 경로, 권한 서버 응답 차이 같은 것들이 사이에 끼어들 수 있거든요.

캐시는 이 흐름을 어떻게 바꿀까요?¶

처음 조회에서는 리졸버가 여러 단계를 따라갈 수 있어요. 하지만 같은 이름을 다시 묻는다면 이야기가 달라져요.

sequenceDiagram
    participant 앱 as 브라우저 / OS
    participant 재귀 as 재귀 리졸버
    participant 캐시 as 리졸버 캐시
    participant 권한 as 권한 서버

    앱->>재귀: example.com A?
    재귀->>권한: 캐시에 없어서 실제 조회
    권한-->>재귀: A 답변, TTL 300
    재귀->>캐시: 300초 동안 저장
    재귀-->>앱: A 답변

    앱->>재귀: example.com A?<br/>잠시 뒤 다시 조회
    재귀->>캐시: 아직 TTL 남았나?
    캐시-->>재귀: 남은 답 있음
    재귀-->>앱: 캐시된 A 답변

이 장면 때문에 DNS 장애가 더 헷갈려져요. 권한 서버의 설정을 바꿨는데도 어떤 사람은 새 주소를 보고, 어떤 사람은 예전 주소를 볼 수 있거든요. 그 차이는 어느 재귀 리졸버를 쓰는지, 그 리졸버가 언제 답을 캐시했는지, TTL이 얼마나 남았는지에 따라 달라질 수 있어요.

여기서는 캐시가 조회 흐름을 짧게 만들 수 있다는 점까지만 잡을게요. TTL 때문에 값이 오래 남는 문제는 다음 DNS 글에서 더 따로 열어볼게요.

실제로 헷갈리기 쉬운 장면을 나눠볼까요?¶

재귀 조회와 반복 조회를 구분하면, 아래 장면들을 훨씬 덜 성급하게 판단할 수 있어요.

이 표에서 핵심은 하나예요. DNS 문제를 볼 때는 결과값만 보지 말고, 그 결과를 누가 대신 찾아줬는지 같이 봐야 해요.

그럼 진짜 DNS 조회를 볼 때는 어디부터 읽을까요?¶

운영 화면이나 터미널에서 DNS를 볼 때는 이런 순서가 편해요.

1. 내가 누구에게 물었는지 봐요.
2. dig 출력의 SERVER: 줄을 먼저 확인해요.
3. 재귀 조회를 기대하는 장면인지 봐요.
4. 일반 조회라면 보통 rd, ra 플래그가 보일 수 있어요.
5. 답이 직접 답인지 힌트인지 봐요.
6. ANSWER, AUTHORITY, ADDITIONAL 을 나눠 읽어요.
7. 캐시 가능성을 의심해요.
8. TTL 이 남아 있으면 예전 답이 정상적으로 보일 수도 있어요.
9. 필요할 때만 +trace 로 위임 사슬을 따라가요.
10. 평소 리졸버 답과 권한 계층 흐름을 구분해서 봐요.

flowchart TD
    A[DNS 결과가 이상해요] --> B[SERVER 줄 확인<br/><small>누구에게 물었나</small>]
    B --> C[HEADER 확인<br/><small>status, flags, count</small>]
    C --> D{직접 답이 있나?}
    D -->|ANSWER 있음| E[TTL과 값 확인]
    D -->|ANSWER 없음| F[AUTHORITY / ADDITIONAL 해석]
    E --> G{캐시가 의심되나?}
    F --> G
    G -->|예| H[다른 리졸버 또는 +trace로 비교]
    G -->|아니오| I[다음 네트워크 구간 확인]

이 순서를 따르면 DNS가 틀렸다는 말이 조금 더 구체적으로 바뀌어요. "내가 쓰는 재귀 리졸버가 캐시된 답을 주는지", "권한 서버까지 위임 사슬이 이어지는지", "직접 답이 아니라 힌트를 보고 있는지" 처럼요.

자, 정리해볼까요?¶

재귀와 반복을 나눠서 보면, DNS가 갑자기 훨씬 덜 마법처럼 보여요. 누가 끝까지 찾아주는지, 누가 힌트만 주는지, 그리고 캐시가 어디에 끼어드는지만 나눠도 문제 장면을 훨씬 작게 쪼갤 수 있거든요.