DNS 해석(resolution)은 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

**DNS**(Domain Name System)는 인터넷의 전화번호부다: `example.com` 같은 사람이 읽을 수 있는 이름을 `93.184.216.34` 같은 IP 주소로 번역한다. 해석은 계층적 조회이며, 보통 **recursive resolver**(당신의 ISP 것이거나 8.8.8.8 같은 공용 resolver)가 당신을 대신해 **authoritative** name server의 트리를 훑으며 처리한다:

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

Resolver는 **root** 서버(TLD 서버를 안다)에게 묻고, 그다음 `.com`을 위한 **TLD** 서버(`example.com`에 대해 누가 authoritative인지 안다)에게, 그다음 **authoritative** 서버(실제 레코드를 보관)에게 묻는다. 매번 이를 반복하지 않기 위해 결과는 모든 계층 — 브라우저, OS, resolver — 에 **cache**되며, 각각이 레코드의 **TTL**(time-to-live)을 존중한다. 따뜻한 cache는 마이크로초 안에 해석하고; 차가운 조회는 여러 번의 round trip이 들 수 있다.

흔한 **레코드 유형**: `A`(name → IPv4), `AAAA`(name → IPv6), `CNAME`(다른 이름에 대한 별칭), `MX`(메일 서버), `TXT`(임의 텍스트, SPF/검증에 사용), `NS`(zone 위임). 해석 과정을 직접 확인할 수 있다:

```bash
dig example.com A       # A 레코드와 어느 서버가 응답했는지 보여줌
```

## 왜 중요한가

DNS는 이름에서 시작하는 *모든* request의 임계 경로(critical path)에 있으므로, 느리거나 잘못 구성된 resolver는 모든 것에 지연을 더한다. 면접관이 이 질문을 좋아하는 이유는 그것이 당신이 **계층 구조와 캐싱**을 이해하는지 — 전 세계적, 분산 시스템이 수십억 개의 query에 빠르게 답하게 하는 두 아이디어 — 를 드러내기 때문이다. 그것은 또한 실제 프로덕션 사고의 잦은 원천이다("항상 DNS 탓이야"): 만료된 레코드, 잘못된 TTL, 변경 후 전파 지연 — 그러므로 캐싱과 TTL이 어떻게 작동하는지 아는 것은 직접적으로 실용적이다.

왜 중요한가

관련 질문