DNS 레코드
DNS 레코드
요약
DNS는 도메인을 IP로 연결하는 체계이며, 단순한 A 레코드 외에도 CNAME, ANAME/ALIAS, NS, SOA 등 다양한 레코드가 존재합니다. 이들의 차이와 루트 도메인 사용 가능 여부를 이해해야 안정적이고 확장성 있는 서비스 구성이 가능합니다.
1. DNS의 기본 역할
DNS는 도메인 이름을 실제 서버의 IP 주소로 바꿔주는 시스템입니다.
사용자가 https://www.google.com을 입력하면, 브라우저는 로컬/OS 캐시를 먼저 확인하고, 없으면 재귀(Recursive) 리졸버(ISP DNS, 1.1.1.1, 8.8.8.8, DoH 등)에 질의합니다. 리졸버는 Root → TLD → 권한 네임서버 순서로 탐색하여 IP를 얻어온 뒤, 브라우저에 응답합니다. 이후 TCP/TLS 핸드셰이크를 통해 안전한 통신을 시작합니다.
2. A / AAAA 레코드 – 가장 기본
- A 레코드: 도메인을 IPv4 주소로 직접 매핑합니다.
- AAAA 레코드: 도메인을 IPv6 주소로 직접 매핑합니다.
예:
example.com. IN A 192.0.2.1
example.com. IN AAAA 2001:db8::1
📌 핵심: 가장 단순하면서도 반드시 필요한 레코드입니다. 서버 IP가 바뀌면 직접 수정해야 합니다.
3. CNAME 레코드 – 별칭(alias)
- 도메인 별칭을 다른 도메인으로 연결합니다.
- IP를 직접 가리키지 않고, “다른 도메인”을 가리킵니다.
- 주로 서브도메인에 사용됩니다.
예:
www.example.com. IN CNAME example.com.
📌 제약: 루트 도메인(example.com)에는 사용할 수 없습니다.
이유는 루트에는 NS, SOA, MX 같은 필수 레코드가 반드시 존재해야 하는데, CNAME은 해당 도메인을 전부 다른 도메인으로 위임해 버리기 때문입니다.
4. ANAME / ALIAS 레코드 – 루트에서 CNAME처럼
클라우드 서비스(CloudFront, ALB, Netlify, Vercel 등)는 고정 IP가 없습니다. → 따라서 A 레코드로 직접 연결할 수 없고, 원래라면 CNAME을 써야 합니다. → 하지만 루트 도메인에는 CNAME을 사용할 수 없으므로 ANAME/ALIAS가 등장했습니다.
- DNS 제공자가 내부적으로 CNAME을 해석한 뒤
- 클라이언트에는 A 레코드(IP)처럼 응답해 줍니다.
예 (AWS Route53 ALIAS):
example.com. ALIAS d123.cloudfront.net.
📌 핵심: 루트 도메인에서 클라우드 리소스를 연결할 때 반드시 필요합니다.
5. NS / SOA 레코드 – 신뢰성의 기반
NS (Name Server) 레코드
- “이 도메인의 최종 권한 네임서버는 누구인가”를 지정합니다.
- 루트 도메인에는 반드시 존재해야 합니다.
예:
example.com. IN NS ns1.dns-provider.com.
example.com. IN NS ns2.dns-provider.com.
SOA (Start of Authority) 레코드
- DNS 존(zone)의 시작점 정보를 담습니다.
- 주 네임서버, 관리자 이메일, TTL, 갱신 주기 등을 포함합니다.
📌 핵심:
- NS와 SOA는 DNS 체계가 올바르게 동작하기 위한 필수 요소입니다.
- 따라서 루트 도메인에는 절대 CNAME을 둘 수 없습니다.
6. 실무 사례
CloudFront / ALB 연결
- ALB와 CloudFront는 고정 IP가 없습니다. → 권장 연결 방식은 **ANAME/ALIAS(Route53 ALIAS, Cloudflare CNAME Flattening)**입니다.
- 루트 도메인(
example.com)을 CloudFront 도메인(d123.cloudfront.net)이나 ALB 도메인(xxx.alb.amazonaws.com)에 매핑하면, DNS가 내부적으로 IP를 플래트닝하여 A/AAAA로 응답합니다.
구글 접속 예시 (요약)
https://www.google.com입력 → 브라우저 캐시 확인 → 재귀 리졸버 질의 → Root → TLD → AUTH 순으로 탐색 → IP 획득 → TCP 443 + TLS → HTTPS
운영 팁: TTL과 전파
- TTL(Time To Live): 캐시 유지 시간입니다. 낮추면 빠른 변경 반영, 높이면 쿼리 감소/안정성 향상 효과가 있습니다.
- 네거티브 캐싱: NXDOMAIN 응답도 캐시됩니다. → 잘못된 설정 후 수정해도 잠시 동안 실패가 지속될 수 있습니다.
- 전파(Propagation) 오해: DNS는 ‘퍼지는’ 것이 아니라 각 리졸버 캐시가 TTL 만료 시 재조회하는 구조입니다.
7. 레코드별 루트/서브도메인 사용 요약 표
| 레코드 타입 | 루트 도메인 (example.com) | 서브도메인 (www.example.com) | 특징 |
|---|---|---|---|
| A | ✅ 가능 | ✅ 가능 | IPv4 직접 매핑, 가장 기본적인 레코드입니다. |
| AAAA | ✅ 가능 | ✅ 가능 | IPv6 직접 매핑, IPv6 환경에서 필수입니다. |
| CNAME | ❌ 불가능 | ✅ 가능 | 별칭 제공, 루트에는 불가(NS/SOA와 충돌)입니다. |
| ANAME/ALIAS | ✅ 가능 | ✅ 가능 | 루트에서도 CNAME처럼 동작, 클라우드 서비스 연결에 최적입니다. |
| NS | ✅ 필수 | ❌ 보통 사용하지 않음 | 권한 네임서버 지정, 루트에 반드시 필요합니다. |
| SOA | ✅ 필수 | ❌ 없음 | 존(zone) 시작 정보, 루트에 반드시 필요합니다. |