[Network] 개발자가 알아야 할 DNS 핵심: System, Server, and Records

[Network] 개발자가 알아야 할 DNS 핵심: System, Server, and Records

최근 프로젝트 배포 과정에서 로컬 IP 대신 도메인을 연결하는 작업을 진행하며, 문득 익숙하게 쓰던 'DNS'라는 용어의 정확한 개념과 레코드 타입별 차이를 명확히 정리해 둘 필요성을 느꼈다.

 

단순히 "도메인 연결해 주세요"를 넘어, 엔지니어로서 DNS의 작동 원리와 레코드별 기술적 차이를 이해하고 있어야 더 효율적인 아키텍처를 설계할 수 있기 때문이다.

 

이 글은 실무에서 마주친 DNS System과 Server의 구분, 그리고 가장 빈번하게 사용되는 주요 레코드(A, CNAME)의 개념을 기록하기 위한 기술 노트다.

---

1. 용어의 재정의: System vs Server

흔히 "DNS에 등록한다"라고 표현하지만, 엄밀히 말하면 Domain Name System(체계)과 Name Server(구현체)는 구분해서 이해해야 한다.

Domain Name System (DNS)

전 세계 인터넷(혹은 사내망)에 분산된 거대한 계층형 데이터베이스 시스템 그 자체를 의미한다.
Root(.)부터 TLD(.com, .kr), 그리고 하위 도메인까지 이어지는 트리 구조의 프로토콜 집합이다.

• 핵심 역할: FQDN(Fully Qualified Domain Name)을 IP 주소로 변환(Resolve)하거나 그 반대를 수행.
• 비유: 전 세계 전화번호가 국가번호-지역번호-개인번호로 규격화되어 관리되는 '국제 전화번호 표준 체계'.

DNS Server (Name Server)

DNS라는 거대한 시스템 안에서, 실제로 클라이언트(Resolver)의 쿼리(Query)를 받아 "그 도메인의 IP는 이것이다"라고 응답(Response) 해 주는 소프트웨어 혹은 서버다. (e.g., BIND, Microsoft DNS, AWS Route53)

• Technical Note: 우리가 실무에서 설정을 변경하거나 레코드를 추가하는 대상은, 해당 도메인의 관리 권한(Authority)을 가진 Authoritative Name Server다.

---

2. DNS Record: 매핑의 규칙 (The 3 Key Types)

DNS 서버는 단순한 Key-Value 저장소가 아니라, '레코드 타입(Record Type)'에 따라 동작 방식과 리졸빙(Resolving) 비용이 달라진다. 개발자가 반드시 숙지해야 할 3가지 타입을 정리한다.

① A Record (Address Mapping)

가장 기본적이고 직관적인 레코드. 도메인 이름을 특정 IPv4 주소에 1:1로 매핑한다.

• 구조: Domain Name ➡ 32-bit IPv4 Address
• 설정 예시:

project-x.internal  IN  A  10.159.57.115

• 동작 원리:
  클라이언트가 질의하면 DNS 서버는 별도의 해석 과정 없이 즉시 10.159.57.115라는 IP를 반환한다. (가장 빠르고 단순함)
• Use Case:
  • 고정 IP가 할당된 웹 서버(Web Server) 연결.
  • L4/L7 스위치의 VIP(Virtual IP)에 도메인을 직접 할당할 때.

② CNAME Record (Canonical Name)

도메인에 '별칭(Alias)'을 부여하는 레코드. IP 주소가 아닌 '또 다른 도메인 이름(Canonical Name)'을 가리킨다.

• 구조: Alias Domain ➡ Canonical (Real) Domain
• 설정 예시:

admin.project-x.internal  IN  CNAME  project-x.internal

• 동작 원리 (Recursive Lookup):

1. 클라이언트가 admin...을 질의한다.
2. DNS 서버는 IP 대신 "진짜 이름은 project-x.internal이야"라고 응답한다.
3. 클라이언트는 다시 project-x.internal의 A 레코드를 조회하여 최종 IP를 얻는다. (쿼리가 한 번 더 발생함)

• Use Case:
  • Cloud/CDN 환경: AWS ELB나 CloudFront처럼 IP가 수시로 변동되는 리소스를 바라봐야 할 때.
  • 관리의 일원화: www, api, dev 등 여러 서브 도메인이 결국 하나의 Origin을 바라볼 때, IP 변경 시 A 레코드 하나만 수정하면 되도록 구성할 때.

③ MX Record (Mail Exchanger)

웹 개발만 한다면 낯설 수 있지만, 서비스 내 메일 발송/수신 기능을 다룬다면 필수적이다.

• 역할: 해당 도메인(@company.com)으로 수신되는 이메일을 처리할 메일 서버(MTA)를 지정한다.
• 특징: Priority(우선순위) 값을 가져, 주 서버 장애 시 보조 서버로 트래픽을 라우팅 하는 Failover 구성이 가능하다.

---

3. Summary & Takeaways

실무에서 DNS 설정을 요청하거나 직접 구성할 때, 무조건 "연결해 주세요"라고 하기보다 목적에 맞는 레코드를 선정하는 것이 중요하다.

레코드 타입	매핑 대상	특징 및 비유
A Record	IP 주소(IPv4)	"직통 전화번호" 가장 빠르고 명확함. IP가 바뀌면 직접 수정해야 함.
CNAME	도메인 이름	"착신 전환" IP가 바뀌어도 원본 도메인만 살아있으면 됨. (관리 편의성 ↑, 조회 비용 약간 발생)
MX	메일 서버	"우편물 수취함" 웹 접속이 아닌 이메일 라우팅 전용.

 

Closing Thought:
DNS는 네트워크 트래픽이 시작되는 첫 번째 관문이다. A 레코드와 CNAME의 차이를 이해하고 상황에 맞게 사용하는 것은, 안정적이고 유지보수가 용이한 시스템을 설계하는 기본기가 된다.