DNS 완전 정복 — 재귀 질의, `TTL`, `A`/`AAAA`/`CNAME`, 권한 DNS까지
DNS, 왜 따로 알아야 하나요?
HTTPS 요청 과정 글까지 읽고 나면 이런 질문이 자연스럽게 남습니다.
- 브라우저가
https://example.com에 접속하기 전에DNS에서는 정확히 무슨 일이 일어날까요? DNS는 그냥 "도메인을 IP로 바꿔 주는 시스템"이라고만 이해해도 충분할까요?TTL은 왜 바꿨는데도 적용이 늦어지는 원인이 될까요?A,AAAA,CNAME,MX,NS,TXT레코드는 각각 언제 쓰일까요?- 장애가 났을 때
DNS문제인지, 네트워크나TLS문제인지 어떻게 구분해야 할까요?
핵심은 이것입니다.
DNS는 단순한 주소록이 아니라, 계층적이고 분산된 이름 시스템 위에서 도메인 이름을 IP 주소와 각종 자원 정보로 해석하는 인프라입니다
즉:
- 사람은
example.com같은 이름을 기억하고 - 네트워크는 결국 IP 주소로 목적지를 찾아가며
DNS는 그 사이에서 이름을 주소와 자원 정보로 바꾸는 역할을 합니다
이 글에서는 DNS를 "도메인 -> IP 변환"에서 끝내지 않고, 재귀 질의, 반복 질의, Root/TLD/권한 DNS, 캐시와 TTL, 주요 레코드 타입, UDP와 TCP 사용 지점 을 기준으로 정리하겠습니다.
기준: 이 글은 DNS 개념과 계층 구조는
RFC 1034, 프로토콜과 레코드 형식은RFC 1035, 일부 동작과TTL해석의 보충은RFC 2181, 고수준 개요는 MDN DNS 문서를 기준으로 설명합니다.
먼저 가장 짧은 답부터 보면
브라우저가 example.com에 접속하기 전에 일어나는 DNS 흐름을 아주 짧게 줄이면 이렇습니다.
| 단계 | 핵심 질문 | 하는 일 |
|---|---|---|
| 1 | 이 이름은 이미 알고 있나? | 브라우저/OS/리졸버 캐시 확인 |
| 2 | 모르면 누구에게 물을까? | 로컬 또는 ISP의 recursive resolver에 질의 |
| 3 | 최종 답은 어디에 있나? | Root -> TLD -> authoritative name server 순서로 추적 |
| 4 | 얼마나 믿고 저장할까? | 응답의 TTL을 최대 상한으로 삼아 캐시 |
| 5 | 실제로 무엇을 얻을까? | A, AAAA, CNAME, MX 같은 레코드 응답 |
가장 짧게 줄이면 이렇습니다.
DNS는 이름을 IP 주소나 다른 자원 정보로 바꾸는 시스템입니다- 클라이언트는 보통
recursive resolver에 묻고, resolver가 대신 끝까지 찾아옵니다 - 한 번 찾은 결과는 보통
TTL을 최대 상한으로 삼아 캐시되므로, 설정을 바꿔도 바로 안 바뀔 수 있습니다
Phase 1. 왜 DNS가 필요한가?
먼저 가장 기본부터 보면, 인터넷은 결국 IP 주소 기반으로 동작합니다.
즉, 라우터와 호스트는:
93.184.216.342001:db8::10
같은 주소를 기준으로 목적지를 찾습니다.
하지만 사람은 이런 숫자를 기억하기 어렵습니다. 그래서:
example.com
같은 이름을 쓰고, DNS가 이를 실제 네트워크 주소로 바꿉니다.
MDN도 DNS의 가장 대표적인 기능을, 사람이 읽기 쉬운 도메인 이름을 수치 IP 주소로 변환하는 것이라고 설명합니다.
DNS는 IP 주소만 주는 시스템은 아니다
여기서 자주 놓치는 점이 있습니다.
DNS는 단순히:
도메인 -> IP
만 저장하는 시스템이 아닙니다.
실제로는:
- 메일 서버 정보
- 다른 이름으로 가리키는 별칭
- 어떤 네임서버가 이 도메인을 책임지는지
- 검증용 텍스트 정보
같은 자원 정보도 함께 다룹니다.
즉, DNS는 더 정확히 말하면:
도메인 이름 공간에 다양한 자원 레코드를 매핑하는 분산 데이터베이스
에 가깝습니다.
Phase 2. DNS 이름 공간은 어떻게 나뉠까?
DNS를 제대로 이해하려면 계층 구조를 먼저 봐야 합니다.
DNS는 계층적 이름 공간이다
RFC 1034는 DNS를 계층적인 이름 공간으로 설명합니다.
예를 들어:
www.example.com.
이라는 이름은:
- 최상위의
.(root) comexamplewww
처럼 라벨이 계층적으로 이어진 구조입니다.
즉, example.com은 com 아래의 하위 도메인이고, www.example.com은 다시 example.com 아래의 하위 이름입니다.
그래서 관리도 나눠 맡을 수 있다
이 계층 구조 덕분에 전 세계 모든 이름을 한 서버가 들고 있을 필요가 없습니다.
예를 들어:
- Root는 최상위 위임 정보만 알고
.com은example.com같은 하위 도메인의 위임 정보를 알고example.com의 권한 DNS는 그 안의 실제 레코드를 관리합니다
즉, DNS는 계층적 이름 구조 + 분산 관리 구조가 결합된 시스템입니다.
Phase 3. 조회는 실제로 어떻게 진행될까?
많은 분이 이 부분에서 가장 헷갈립니다.
브라우저가 example.com을 조회한다고 해서, 곧바로 root 서버에 직접 물어보는 것은 아닙니다.
보통은 recursive resolver에 먼저 묻는다
클라이언트는 보통:
- 운영체제가 설정한 DNS 서버
- 회사/집 공유기 DNS
- ISP DNS
- 퍼블릭 리졸버
같은 recursive resolver에게 먼저 물어봅니다.
즉, 클라이언트 입장에서는:
example.com의 `A` 또는 `AAAA`를 알려 줘
라고 한 번 묻고, resolver가 대신 나머지 과정을 수행합니다.
resolver는 보통 반복적으로 추적한다
resolver가 캐시에 답이 없으면, 보통 이런 식으로 따라갑니다.
Resolver -> Root
Resolver -> .com TLD
Resolver -> example.com 권한 DNS
그리고 최종 응답을 클라이언트에게 돌려줍니다.
즉, 실무에서 흔한 흐름을 단순화하면:
- 클라이언트와 resolver 사이에서는 재귀 질의
- resolver는 상위 DNS들의 referral을 따라가며 반복적으로 추적
처럼 이해하면 실무 감각에 가깝습니다.
Phase 4. 재귀 질의와 반복 질의는 무엇이 다를까?
이 둘은 말은 비슷하지만 역할이 다릅니다.
재귀 질의
재귀 질의는:
"최종 답을 찾아서 나에게 가져와 주세요"
에 가깝습니다.
즉, 클라이언트는 보통 recursive resolver에게:
- 최종 IP
- 또는
NXDOMAIN같은 최종 결과
를 기대합니다.
반복 질의
반복 질의는:
"내가 가진 범위 안에서는 이렇게 알고 있고, 다음은 저쪽에 물어보세요"
에 가깝습니다.
예를 들어 root 서버는 보통:
- "
example.com의A는 직접 모르지만" - "
.com을 담당하는 네임서버는 여기다"
같은 응답을 줍니다.
즉, 반복 질의에서는 서버가 최종 답을 끝까지 대신 찾아오지 않고, 다음 단계의 힌트를 주는 쪽에 가깝습니다.
그래서 실무에서 보이는 흐름은 보통 이렇다
브라우저/OS
↓ 재귀 질의
recursive resolver
↓ 반복 질의
Root
↓ 반복 질의
TLD
↓ 반복 질의
권한 DNS
이 구조를 이해하면 "DNS가 느리다"는 말을 들었을 때:
- 로컬 캐시 문제인지
- resolver 문제인지
- 권한 DNS 문제인지
를 더 잘 나눠 볼 수 있습니다.
Phase 5. Root, TLD, 권한 DNS는 각각 무엇을 들고 있을까?
이 부분도 역할이 섞여 보이면 금방 헷갈립니다.
Root 서버
Root는 최상위 이름 공간의 시작점입니다.
Root 서버가 보통 직접 알려 주는 것은:
.com.net.org.kr
같은 TLD를 어디가 담당하는지입니다.
즉, Root는 모든 도메인의 최종 IP를 아는 서버가 아니라, 최상위 위임 정보를 아는 서버에 가깝습니다.
TLD 서버
.com 같은 TLD 서버는 그 아래의:
example.comopenai.com
같은 도메인에 대한 위임 정보를 관리합니다.
즉, TLD 서버는 보통 "example.com을 누가 authoritative하게 관리하는가"를 알려 주는 단계입니다.
권한 DNS 서버
실제 도메인의 레코드를 들고 있는 곳은 보통 authoritative name server입니다.
예를 들어:
example.com의Awww.example.com의CNAME- 메일용
MX
같은 실제 레코드는 여기서 내려옵니다.
즉, 최종적으로 진짜 답을 갖고 있는 곳은 보통 권한 DNS입니다.
Phase 6. TTL은 왜 중요할까?
실무에서 가장 많이 문제처럼 보이는 개념 중 하나가 TTL입니다.
TTL은 캐시 수명이다
TTL은 응답이 얼마 동안 캐시될 수 있는지의 최대 상한을 나타냅니다.
예를 들어 TTL = 300이면, 보통 최대 300초 범위 안에서 같은 응답을 캐시해서 재사용할 수 있습니다.
이 덕분에:
- 같은 도메인을 매번 root부터 다시 물을 필요가 없고
- 지연 시간을 줄이며
- 권한 DNS 부하도 줄일 수 있습니다
왜 바꿨는데 바로 안 보일까?
가장 흔한 현상이 이것입니다.
- DNS 레코드를 바꿨는데
- 어떤 사용자는 이미 새 값이 보이고
- 어떤 사용자는 한동안 예전 값이 계속 보입니다
이때 가장 먼저 의심할 것이 TTL입니다.
즉, 레코드를 바꿨더라도:
- 브라우저 캐시
- OS 캐시
- resolver 캐시
어딘가에 이전 값이 남아 있으면, 그 캐시가 만료되기 전까지는 예전 값이 계속 보일 수 있습니다.
TTL은 짧다고 항상 좋은 것도 아니다
TTL을 너무 짧게 잡으면:
- 변경 전환은 빨라질 수 있지만
- 캐시 이점이 줄고
- 권한 DNS 조회 빈도가 늘 수 있습니다
즉, TTL은 전환 민첩성과 캐시 효율 사이의 절충점에 가깝습니다.
Phase 7. 자주 쓰는 레코드 타입은 무엇일까?
레코드 타입은 DNS를 실무적으로 이해하는 핵심입니다.
A
도메인을 IPv4 주소에 매핑합니다.
example.com -> 93.184.216.34
AAAA
도메인을 IPv6 주소에 매핑합니다.
example.com -> 2001:db8::10
CNAME
한 이름을 다른 이름의 별칭으로 가리킵니다.
즉:
www.example.com -> example.com
처럼 "이 이름의 최종 답은 저 이름을 따라가라"는 의미입니다.
MX
이 도메인의 메일을 어느 서버가 받을지 지정합니다.
즉, 메일 시스템이 목적지 메일 서버를 찾을 때 주로 씁니다.
NS
어떤 네임서버가 이 도메인 또는 존을 책임지는지 나타냅니다.
즉, 위임 구조를 이해할 때 핵심입니다.
TXT
임의 텍스트 정보를 담는 레코드입니다.
실무에서는:
- 도메인 소유권 검증
- 메일 정책
- 외부 서비스 연동 검증
같은 용도로 매우 자주 씁니다.
PTR
역방향 조회에 쓰입니다.
즉:
IP -> 도메인 이름
방향의 조회에 사용됩니다.
Phase 8. DNS는 UDP만 쓸까?
많은 분이 DNS를 UDP 전용처럼 기억하지만, 실제로는 조금 더 정확히 볼 필요가 있습니다.
일반 조회는 보통 UDP가 흔하다
RFC 1035는 DNS가 UDP와 TCP를 모두 사용할 수 있음을 정의합니다. 전통적으로 일반 질의/응답은 짧고 빠른 응답이 많아서 UDP가 흔했습니다.
즉, DNS는:
- 짧은 질의/응답
- 연결 상태 단순성
측면에서 UDP가 잘 맞는 경우가 많았습니다.
하지만 TCP도 중요하다
예를 들어:
- 응답이 커지는 경우
- 존 전송 같은 작업
에서는 TCP가 필요할 수 있습니다.
즉, "DNS = UDP"라고 외우면 반쯤만 맞습니다. 더 정확히는:
일반 조회는
UDP가 흔하지만, DNS 자체는TCP도 사용합니다
Phase 9. 장애 상황에서는 무엇부터 보면 될까?
실무에서 DNS 문제는 네트워크, 인증서, 로드밸런서 문제처럼 보이기도 합니다.
자주 보는 증상
- 어떤 지역에서만 접속이 안 됨
- 배포 후 일부 사용자만 예전 서버로 감
A는 맞는데AAAA때문에 일부 환경에서 이상함- 인증서가 맞는데도 엉뚱한 서버로 감
- 도메인은 살아 있는데 메일만 안 됨
이럴 때 먼저 나눠 봐야 할 것
- 이름이 올바른 IP로 해석되는가?
- 캐시 때문에 예전 값이 남아 있지 않은가?
A와AAAA가 의도대로 관리되고 있는가?- 권한 DNS와 resolver 중 어디서 값이 달라지는가?
- 문제 레코드가
A인지,CNAME인지,MX인지 구분했는가?
즉, "접속이 안 된다"는 말은:
DNS가 잘못된 것인지- IP는 맞는데 그다음
TCP/TLS가 깨지는 것인지
를 먼저 나눠 보는 것이 중요합니다.
핵심만 다시 정리하면
마지막으로 DNS를 한 번 더 정리하면 이렇게 볼 수 있습니다.
| 구분 | 핵심 의미 |
|---|---|
DNS |
이름을 IP 주소와 자원 정보로 바꾸는 계층적 분산 시스템 |
recursive resolver |
클라이언트 대신 최종 답을 찾아오는 역할 |
| Root / TLD / 권한 DNS | 위임 구조를 따라 최종 답을 찾게 해 주는 계층 |
TTL |
응답을 얼마나 캐시할지 정하는 시간 |
| 레코드 타입 | A, AAAA, CNAME, MX, NS, TXT, PTR 등 목적별 정보 |
핵심 포인트는 다섯 가지입니다.
DNS는 단순한 전화번호부가 아니라, 도메인 이름 공간을 계층적으로 관리하는 분산 시스템입니다.- 클라이언트는 보통
recursive resolver에 재귀 질의를 보내고, resolver가 Root, TLD, 권한 DNS를 반복적으로 따라가며 최종 답을 찾습니다. TTL은 성능과 캐시 효율에 중요하지만, 변경 전파가 늦어지는 원인이 되기도 합니다.DNS는A/AAAA만 다루는 것이 아니라, 별칭, 메일, 위임, 검증용 텍스트 같은 다양한 자원 정보를 저장합니다.- 장애 분석에서는 "
DNS가 틀렸는지"와 "이후TCP/TLS가 틀렸는지"를 먼저 분리해서 봐야 합니다.
결국 DNS는 "이름을 주소로 바꾼다"는 한 문장으로 시작할 수는 있지만, 실제로는 이름 공간의 위임 구조, 캐시 전략, 레코드 타입, 질의 방식이 함께 맞물려 인터넷의 첫 단계 응답을 만들어 내는 시스템에 가깝습니다.