DNS (Domain Name System)

 

1. DNS (Domain Name System)

DNS란, 사람이 기억하기 쉬운 도메인 이름(예: www.google.com)을 컴퓨터가 통신할 때 사용하는 IP 주소(예: 172.217.175.4)로 변환해주는, 거대한 분산 네트워크 데이터베이스 시스템입니다. 전 세계에 퍼져있는 서버들이 협력하여 이 변환 작업을 수행하며, 인터넷의 전화번호부와 같은 역할을 담당합니다. 

---

2. DNS 쿼리 과정

사용자가 브라우저에 도메인을 입력하면, 우리의 컴퓨터는 다음과 같은 여정을 통해 최종 IP 주소를 찾아냅니다.

1. 브라우저 및 OS 캐시 확인: 가장 먼저 자신의 컴퓨터 내부에 이전에 조회했던 기록(캐시)이 있는지 확인합니다. 만약 기록이 있다면, 이 단계에서 바로 IP 주소를 얻고 과정이 종료됩니다.
2. Recursive DNS 서버에 요청: 캐시에 정보가 없다면, 보통 통신사(KT, SKT 등)에서 제공하는 Recursive DNS 서버(리졸버)에 도메인 주소를 물어봅니다. 이 서버는 IP 주소를 찾기 위한 모든 과정을 대신 책임지고 수행해 줍니다.
3. Root DNS 서버에 요청: Recursive 서버에도 정보가 없다면, 인터넷의 최상위 관문인 Root DNS 서버에 접속하여 ".com"을 관리하는 서버가 누구인지 물어봅니다.
4. TLD (Top-Level Domain) 서버에 요청: Root 서버로부터 받은 정보로 ".com" 도메인을 담당하는 TLD 서버에 찾아가 "https://www.google.com/search?q=google.com"을 관리하는 서버는 누구인지 다시 물어봅니다.
5. Authoritative DNS 서버(권한 네임서버)에 요청: TLD 서버가 알려준 "https://www.google.com/search?q=google.com"의 최종 정보를 관리하는 Authoritative DNS 서버에 도달합니다. 이 서버는 www.google.com의 실제 IP 주소가 무엇인지 정확히 알고 있으며, 이 정보를 Recursive 서버에게 응답합니다.
6. 최종 응답 및 캐싱: IP 주소를 응답받은 Recursive 서버는 이 정보를 자신의 캐시에 저장하고(다음에 같은 요청이 오면 더 빠르게 응답하기 위함), 최종적으로 사용자 컴퓨터에 IP 주소를 전달합니다. 이제 브라우저는 이 IP 주소를 가지고 서버와 통신을 시작할 수 있습니다.

---

3. DNS 레코드 - 도메인의 이력서

Authoritative DNS 서버에는 도메인에 관한 여러 정보가 '레코드'라는 형식으로 저장되어 있습니다. 백엔드 개발자가 자주 접하게 될 핵심 레코드는 다음과 같습니다.

레코드 종류	설명	주요 사용 사례
A	도메인 이름을 IPv4 주소에 직접 매핑합니다.	웹 서버의 공인 IP 주소를 도메인에 연결하는 가장 기본적인 작업입니다.
AAAA	도메인 이름을 IPv6 주소에 매핑합니다.	IPv6 환경에서 서버를 운영할 때 사용됩니다.
CNAME	특정 도메인 이름을 다른 도메인 이름(별칭)으로 매핑합니다.	AWS의 로드 밸런서(ELB)나 CloudFront와 같이 유동적인 주소를 우리 도메인에 연결할 때 필수적입니다.
MX	도메인의 메일 서버를 지정합니다.	my-service.com으로 오는 이메일을 어떤 서버가 처리할지 지정할 때 사용됩니다.
TXT	도메인에 대한 임의의 텍스트 정보를 제공합니다.	SPF, DKIM 등 이메일 스푸핑 방지 설정이나 SSL 인증서 발급 시 도메인 소유권을 증명하는 데 사용됩니다.
NS	이 도메인의 정보를 관리하는 Authoritative DNS 서버가 누구인지 지정합니다.	가비아에서 산 도메인을 AWS Route 53에서 관리하고 싶을 때, 가비아에 AWS의 NS 레코드를 등록합니다.

# my-awesome-service.com의 DNS 설정 (Zone File 예시)

# 1. 주 도메인에 대한 IP 주소 (웹서버)
my-awesome-service.com.  300  IN  A  52.78.100.123

# 2. www 서브도메인은 주 도메인의 별칭으로 처리
www.my-awesome-service.com. 300 IN CNAME my-awesome-service.com.

# 3. 메일 서버는 Google Workspace를 사용 (숫자는 우선순위)
my-awesome-service.com.  3600 IN  MX  1  ASPMX.L.GOOGLE.COM.
my-awesome-service.com.  3600 IN  MX  5  ALT1.ASPMX.L.GOOGLE.COM.

# 4. 이메일 보안(SPF) 및 도메인 소유권 확인을 위한 텍스트 정보
my-awesome-service.com.  3600 IN  TXT  "v=spf1 include:_spf.google.com ~all"
_google-site-verification.my-awesome-service.com. 3600 IN TXT "google-site-verification=AbCdEfGhIjKlMnOpQrStUvWxYz"

# 5. 이 도메인의 정보를 관리하는 네임서버 목록
my-awesome-service.com.  172800 IN  NS  ns-123.awsdns-01.com.
my-awesome-service.com.  172800 IN  NS  ns-456.awsdns-02.net.

---

4. 다른 개념

TTL (Time To Live)

TTL은 DNS 레코드가 다른 DNS 서버에 캐시될 수 있는 시간(초 단위)을 의미합니다.

• TTL이 길면 (예: 86400초 = 24시간): DNS 조회 요청이 줄어들어 응답이 빠르지만, 만약 서버 IP를 변경했을 때 최대 24시간 동안 이전 IP로 접속될 수 있습니다.
• TTL이 짧으면 (예: 300초 = 5분): IP 변경 사항이 빠르게 전파되어 장애 대응이나 서버 이전에 유리하지만, DNS 조회 요청이 빈번해져 약간의 성능 부하가 발생할 수 있습니다.
• 실무 Tip: 서버 이전을 계획하고 있다면, 며칠 전부터 TTL 값을 300초 정도로 짧게 줄여두는 것이 정석입니다.

---

DNS Propagation (전파)

DNS 레코드를 변경했을 때, 그 내용이 전 세계의 모든 DNS 서버로 퍼져나가는 과정을 DNS 전파라고 합니다. 이 시간은 각 서버에 설정된 TTL 값에 따라 다르며, 짧게는 수 분에서 길게는 48시간까지 소요될 수 있습니다. 따라서 DNS 설정 변경 후에는 전파 상황을 확인하며 기다리는 시간이 필요합니다.

---

DNS를 이용한 로드 밸런싱 (Round Robin DNS)

가장 간단한 형태의 트래픽 분산 기술입니다. 하나의 도메인에 여러 개의 A 레코드(여러 개의 서버 IP)를 등록해두면, DNS 서버는 요청이 올 때마다 IP 목록을 순서대로 번갈아 가며 응답해 줍니다. 이 방식은 별도의 장비 없이 트래픽을 분산할 수 있지만, 특정 서버의 상태(Health Check)를 확인하지 못하는 단점이 있습니다.

---

도메인 구입과 네임서버 설정

1. 도메인 등록: 가비아, GoDaddy와 같은 도메인 등록 기관(Registrar)에서 원하는 도메인을 구입합니다.
2. DNS 서비스 선택: AWS Route 53, Cloudflare 등 전문적인 DNS 관리 서비스를 선택합니다.
3. 네임서버 연결: DNS 서비스 제공업체가 알려주는 네임서버(NS) 주소 2~4개를 복사하여, 도메인을 구입한 곳의 설정 페이지에 붙여넣습니다. 이로써 해당 도메인의 모든 DNS 제어권이 DNS 서비스 제공업체로 위임됩니다.