도메인, DNS와 HTTPS
서론
브라우저에 www.google.com을 입력하고 Enter를 누르면 배경에서 무슨 일이 일어날까요? 이 간단해 보이는 동작의 배경에는 도메인 해석, DNS 쿼리, TLS 암호화 핸드셰이크 등 일련의 정밀한 협력 과정이 있습니다. 이러한 메커니즘을 이해하는 것은 모든 개발자의 필수 과정입니다 — 웹사이트에 접속할 수 있는지, 데이터가 탈취될지와 직접적인 관련이 있으니까요.
이 글에서 무엇을 배우게 될까요?
이 장을 마치면 다음을 얻게 됩니다:
- DNS 원리: 도메인이 IP 주소로 번역되는 전체 과정 이해
- 레코드 유형: A, CNAME, MX 등 일반적인 DNS 레코드의 용도 파악
- HTTPS 메커니즘: TLS 핸드셰이크가 보안 연결을 설정하는 방법 이해
- 인증서 체계: 디지털 인증서의 신뢰 체인과 검증 메커니즘 이해
- 보안 인식: HTTPS가 현대 웹의 최소 요구 사항인 이유 파악
| 장 | 내용 | 핵심 개념 |
|---|---|---|
| 제1장 | DNS 해석 | 재귀 쿼리, 반복 쿼리 |
| 제2장 | DNS 레코드 | A, CNAME, MX, TXT |
| 제3장 | HTTPS와 TLS | 핸드셰이크 과정, 암호화 통신 |
| 제4장 | 인증서 신뢰 체인 | CA, 루트 인증서, 중간 인증서 |
| 제5장 | HTTP vs HTTPS | 평문 vs 암호화, 보안 비교 |
0. 전체 그림: 도메인에서 보안 연결까지
인터넷 통신은 IP 주소(예: 142.250.80.46)를 기반으로 하지만, 인간은 이 숫자를 기억하지 못합니다. 그래서 도메인 이름 시스템(DNS)이 발명되었습니다 — 인터넷의 "전화번호부"로, 사람이 읽을 수 있는 도메인을 기계가 읽을 수 있는 IP 주소로 번역합니다.
서버를 찾는 것만으로는 충분하지 않습니다. 통신 내용이 평문으로 전송되면, 중간에 있는 누구나 도청하거나 데이터를 변조할 수 있습니다. HTTPS가 이 문제를 해결합니다 — HTTP 위에 TLS 암호화 계층을 추가하여 전송 중인 데이터의 기밀성과 무결성을 보장합니다.
완전한 웹페이지 접속 과정
- 도메인 해석: 브라우저가 DNS에 "www.google.com의 IP가 무엇인가요?"라고 묻고, DNS가 "142.250.80.46"이라고 답변
- TCP 연결: 브라우저와 서버가 TCP 3-way 핸드셰이크 수행
- TLS 핸드셰이크: 양측이 암호화 알고리즘 협상, 인증서 검증, 키 교환
- 암호화 통신: 모든 HTTP 데이터가 암호화된 채널을 통해 전송
1. DNS 해석: 인터넷의 "전화번호부"
DNS(Domain Name System)의 작동 원리는 전화번호부를 조회하는 것과 같습니다: 상대방의 이름(도메인)을 알고 있고, 전화번호(IP 주소)를 찾아야 합니다. 하지만 인터넷의 "전화번호부"는 한 권이 아니라 계층화된 분산 시스템입니다.
🔍 DNS Resolution Simulator
DNS 해석의 네 단계
- 브라우저 캐시: 먼저 로컬 캐시를 조회하여, 이전에 이 도메인에 접속한 적이 있으면 캐시된 IP를 직접 사용
- 재귀 해석기: 캐시 미적중 시, ISP의 재귀 해석기(예: 8.8.8.8)에 요청을 보냄
- 계층별 쿼리: 재귀 해석기가 루트 네임서버 → 최상위 도메인 서버(.com) → 권한 네임서버(google.com) 순으로 질의
- 결과 반환: 권한 서버가 최종 IP를 반환하고, 재귀 해석기가 결과를 캐싱하여 브라우저에 반환
| 계층 | 서버 | 역할 | 수량 |
|---|---|---|---|
| 루트 도메인 | Root Server | 모든 최상위 도메인의 주소를 알고 있음 | 전 세계 13그룹 |
| 최상위 도메인 | TLD Server | .com, .kr, .org 등 관리 | 각 접미사별 한 그룹 |
| 권한 도메인 | Authoritative | 구체적인 도메인의 DNS 레코드 저장 | 각 도메인당 최소 2개 |
| 재귀 해석기 | Resolver | 사용자를 대신해 전체 쿼리 과정을 완료 | ISP 또는 공용 DNS |
2. DNS 레코드 유형: 도메인 이면의 "설정표"
DNS는 단순히 도메인을 IP로 번역하는 것만이 아닙니다. 다양한 유형의 DNS 레코드를 통해 이메일 배달, 도메인 리다이렉트, 서비스 디스커버리 등의 여러 동작을 제어할 수 있습니다.
📋 DNS Record Type Cheatsheet
Maps a domain name to an IPv4 address. This is the most common DNS record type and is ultimately what browsers need when visiting a site.
example.com. IN A 93.184.216.34- Point a website domain to a server IP
- Point subdomains to different servers
- Return multiple IPs for load balancing
| 레코드 유형 | 용도 | 예시 |
|---|---|---|
| A | 도메인 → IPv4 주소 | example.com → 93.184.216.34 |
| AAAA | 도메인 → IPv6 주소 | example.com → 2606:2800:220:1:... |
| CNAME | 도메인 → 다른 도메인(별칭) | www.example.com → example.com |
| MX | 메일 서버 지정 | example.com → mail.example.com |
| TXT | 텍스트 정보 저장 | SPF 검증, 도메인 소유권 확인 |
| NS | 권한 네임서버 지정 | example.com → ns1.example.com |
실제 시나리오의 DNS 설정
- 웹사이트 배포: A 레코드를 추가하여 서버 IP를 가리키거나, CNAME으로 CDN 도메인을 가리킴
- 이메일 설정: MX 레코드를 추가하여 메일 서버를 가리키고, TXT 레코드로 SPF/DKIM 스팸 방지 설정
- 도메인 소유권 확인: 클라우드 서비스 제공자가 특정 TXT 레코드를 추가하여 도메인 소유를 증명하도록 요구
- 로드 밸런싱: 같은 도메인에 여러 A 레코드를 설정하여 DNS 라운드 로빈으로 트래픽 분산
3. HTTPS와 TLS: 데이터에 "방탄복" 입히기
HTTP 프로토콜의 데이터는 평문으로 전송됩니다 — 엽서를 보내는 것과 같아서, 우체부(중간자)가 내용을 마음대로 읽을 수 있습니다. HTTPS는 HTTP 위에 TLS(Transport Layer Security) 암호화 계층을 추가한 것으로, 엽서를 밀봉 봉투에 넣는 것과 같습니다.
TLS 핸드셰이크는 보안 연결을 설정하는 핵심 단계로, 공식적으로 데이터를 전송하기 전에 신원 확인과 키 협상을 완료합니다.
🤝 TLS Handshake Demo
TLS 1.3 핸드셰이크의 핵심 단계
- Client Hello: 클라이언트가 지원하는 암호화 알고리즘 목록과 난수 하나를 전송
- Server Hello: 서버가 암호화 알고리즘을 선택하고, 디지털 인증서와 난수를 반환
- 인증서 검증: 클라이언트가 서버 인증서가 신뢰할 수 있는지 확인(CA 서명, 유효기간, 도메인 일치 확인)
- 키 교환: 양측이 ECDHE 알고리즘을 통해 공유 키를 협상(키 자체는 네트워크에서 전송하지 않음)
- 암호화 통신: 이후 모든 데이터는 협상된 대칭 키로 암호화되어 전송
4. 인증서 신뢰 체인: 이 웹사이트를 왜 믿을 수 있는가?
TLS 핸드셰이크에서 가장 중요한 단계는 "인증서 검증"입니다. 브라우저는 어떻게 웹사이트의 인증서가 진짜이고 공격자가 위조한 것이 아닌지 판단할까요? 정답은 인증서 신뢰 체인 — 계층별 보증의 신뢰 체계입니다.
🔗 Certificate Trust Chain
Click each certificate layer to inspect its details and role in the trust chain.
인증서 신뢰 체인의 3계층 구조
- 루트 인증서(Root CA): 신뢰받는 인증 기관에서 발급되어 운영체제와 브라우저에 사전 설치됨. 신뢰의 "닻".
- 중간 인증서(Intermediate CA): 루트 CA가 발급하며, 최종 인증서 발급에 사용됨. 루트 CA가 직접 웹사이트 인증서를 발급하지 않는 것은 보안 격리를 위해서임.
- 최종 인증서(Leaf Certificate): 웹사이트가 실제로 사용하는 인증서로, 중간 CA가 발급하며 도메인, 공개 키, 유효기간 등의 정보를 포함.
5. HTTP vs HTTPS: 왜 암호화가 최소 요구 사항인가?
2024년, 전 세계 웹 트래픽의 95% 이상이 이미 HTTPS를 통해 전송됩니다. Chrome 브라우저는 HTTP 웹사이트에 "안전하지 않음" 경고를 표시하고, 검색 엔진도 HTTP 웹사이트의 순위를 낮춥니다. HTTPS는 더 이상 "선택 사항"이 아니라 현대 웹의 최소 요구 사항입니다.
🔐 HTTP vs HTTPS Data Transfer
password=MySecret123&user=zhangsan| Item | HTTP | HTTPS |
|---|---|---|
| Port | 80 | 443 |
| Data encryption | None (plaintext) | TLS symmetric encryption |
| Identity verification | None | CA certificate verifies server identity |
| Data integrity | No guarantee | MAC check prevents tampering |
| SEO impact | Search engines may rank it lower | Preferred by search engines |
| Performance cost | No extra overhead | TLS handshake adds about 1-2 RTT |
무료 HTTPS 인증서 받기
Let's Encrypt는 무료이자 자동화된 인증 기관으로, 어떤 웹사이트든 제로 비용으로 HTTPS를 활성화할 수 있게 합니다. Certbot 도구와 함께 사용하면 원클릭으로 인증서를 신청하고 자동 갱신할 수 있습니다. 대부분의 클라우드 플랫폼과 CDN 서비스 제공자도 무료 SSL 인증서를 제공합니다.
요약
도메인, DNS, HTTPS는 인터넷 인프라의 세 기둥입니다. DNS는 사람이 읽을 수 있는 이름으로 웹사이트에 접속할 수 있게 하고, HTTPS는 통신 과정을 안전하고 신뢰할 수 있게 합니다.
핵심 포인트 복습:
- DNS는 계층적 시스템: 루트 도메인 → 최상위 도메인 → 권한 도메인, 계층별 쿼리, 캐시로 가속
- 레코드 유형마다 용도가 다름: A 레코드는 IP를 가리키고, CNAME은 별칭, MX는 이메일, TXT는 검증
- TLS 핸드셰이크가 신뢰를 구축: 인증서 검증 + 키 협상, TLS 1.3은 1-RTT만 필요
- 인증서 신뢰 체인: 루트 CA → 중간 CA → 최종 인증서, 계층별 보증
- HTTPS는 최소 요구 사항: 무료 인증서(Let's Encrypt)로 암호화 제로 장벽
더 읽어보기
- How DNS Works - 만화 형식의 DNS 작동 원리 설명
- Let's Encrypt 문서 - 무료 SSL 인증서 신청 가이드
- Cloudflare Learning Center - DNS와 네트워크 보안 시스템 튜토리얼
- TLS 1.3 RFC 8446 - TLS 1.3 프로토콜 사양
- SSL Labs - 온라인 웹사이트 HTTPS 설정 품질 검사