노트

DNS와 CNAME

Domain Name System

인프라#network · 연결된 개념 9개

쉽게 말하면

DNS는 주소록처럼 사람이 외우기 쉬운 이름을 컴퓨터가 쓰는 IP 주소로 바꿔 줘요. 덕분에 숫자 주소를 몰라도 도메인 이름만으로 사이트에 접속하죠.

비유가 깨지는 곳 주소록은 한곳에 있지만 DNS는 루트, TLD, 권한 네임서버로 나뉜 분산 체계이고, 곳곳의 리졸버가 답을 TTL만큼 캐시해요. 그래서 레코드를 바꿔도 옛 값이 한동안 남아요.

도메인 이름을 IP(Internet Protocol) 주소로 바꿔 주는 분산 이름 체계. 브라우저는 app.example.com에 요청하기 전에 DNS로 IP를 알아낸다.

레코드 종류

  • A / AAAA: 이름 → IPv4 / IPv6 주소
  • CNAME(Canonical Name): 이름 → 다른 이름(별칭). 최종 IP는 대상 이름을 다시 조회해서 얻는다
  • MX(Mail Exchange): 메일 서버
  • TXT: 임의 텍스트. 도메인 소유권 확인, SPF(Sender Policy Framework)·DKIM(DomainKeys Identified Mail) 같은 메일 인증에 쓴다
  • NS(Name Server): 이 도메인(영역)의 레코드를 책임지는 권한 네임서버가 어디인지. 상위 영역(.com)에 적혀 있어 조회가 아래로 내려가는 길잡이가 된다

네임서버 두 종류

"DNS 서버"라는 말은 역할이 다른 두 서버를 함께 부른다.

  • 권한 네임서버(Authoritative Name Server): 특정 도메인의 레코드 원본을 가지고 답한다. 도메인을 산 뒤 등록 기관(registrar)에 "이 도메인의 네임서버는 여기"라고 적는 것이 상위 영역에 NS 레코드를 올리는 일이다. 네임서버를 Cloudflare 등으로 옮기면 이후 레코드는 그쪽 대시보드에서 관리한다
  • 재귀 리졸버(Recursive Resolver): 레코드를 갖고 있지 않고, 클라이언트 대신 여기저기 물어 답을 찾아 주고 캐시한다. ISP 리졸버나 1.1.1.1·8.8.8.8 같은 공용 DNS가 여기에 해당한다

조회 흐름

  1. 브라우저·OS(Operating System)의 DNS 캐시, 그리고 hosts 파일을 먼저 본다
  2. 없으면 리졸버(Resolver, ISP(Internet Service Provider)나 공용 DNS)에 묻는다
  3. 리졸버는 루트 서버 → .com 같은 TLD(Top-Level Domain) 서버 → 그 도메인의 권한 네임서버(Authoritative Name Server) 순으로 찾아간다
  4. 답이 CNAME이면 대상 이름으로 다시 조회해 IP를 얻는다
  5. 브라우저가 그 IP로 접속하고, Host 헤더에 원래 이름을 실어 보낸다. 한 서버(IP)가 여러 사이트를 이 헤더로 구분한다
sequenceDiagram
  participant B as 브라우저·OS
  participant R as 리졸버
  participant Root as 루트 서버
  participant T as TLD 서버 (.com)
  participant A as 권한 네임서버
  Note over B: 캐시·hosts 파일 먼저 확인
  B->>R: app.example.com의 IP는?
  R->>Root: 질의
  Root-->>R: .com TLD 서버 위치
  R->>T: 질의
  T-->>R: 권한 네임서버 위치 (NS)
  R->>A: 질의
  A-->>R: 답 (IP 또는 CNAME)
  Note over R,A: CNAME이면 대상 이름으로 다시 조회
  R-->>B: IP (캐시해 둠)
  Note over B: 그 IP로 접속, Host 헤더에 원래 이름

호스팅 서비스에 서브도메인 연결하기

Vercel 같은 호스팅에 app.example.com을 붙일 때는 보통 CNAME을 쓴다.

app   CNAME   cname.호스팅사.com
  • CNAME은 호스팅사가 IP를 바꿔도 따라가므로, IP를 직접 적는 A 레코드보다 관리가 쉽다
  • 루트 도메인(example.com)에는 표준상 CNAME을 둘 수 없어서 A 레코드나 DNS 업체의 ALIAS·플래트닝(CNAME Flattening) 기능을 쓴다
  • Cloudflare에서 프록시(주황 구름)를 켜면 응답 IP가 Cloudflare 것이 되어 호스팅사의 검증이 실패할 수 있다. 연결할 때는 DNS only로 둔다
  • 확인: dig app.example.com +short, nslookup app.example.com

TTL과 전파

레코드마다 TTL(Time To Live, 캐시 유지 시간)이 있다. 짧으면 변경이 빨리 퍼지지만 조회가 잦고, 길면 그 반대다. "전파에 최대 48시간"이라는 말은 곳곳의 캐시가 옛 값을 TTL만큼 들고 있기 때문이다. 바꾸기 전에 TTL을 미리 줄여 두면 빨리 넘어간다.

브라우저가 연결을 미리 준비하게 하려면 → dns-prefetch·preconnect. 테스트·문서용으로 예약된 이름은 예약 도메인(.test·.example·.invalid·.localhost), 컨테이너 안의 이름 해석은 컨테이너 네트워킹, 사설망 이름 해석은 Tailscale Serve와 Funnel 참고.

출처: MDN — What is a domain name?: How does a DNS request work? · Wikipedia — CNAME record · RFC 1035 — NS RDATA format · Wikipedia — Name server

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 커넥션 드레이닝과 무중단 재시작

    배포 중 서버를 재시작하는 몇 초 동안 로드밸런서가 그 서버로 요청을 보내면 502가 난다. 먼저 로드밸런서에서 빼고(드레이닝), 진행 중인 요청을 마친 뒤 재시작하고, 준비되면 다시 넣는다.

  • SEO

    SEO(Search Engine Optimization)는 검색 엔진이 페이지를 잘 찾고(크롤링, crawling), 이해해서 저장하고(색인, indexing), 알맞은 검색어로 노출하도록(순위, ranking) 사이트를 다듬는 일이다. 개발자가 맡는 부분은 대부분 앞의 두 단계, 즉 "검색 엔진이 읽을 수 있게 만드는 것"이다.

  • 업스트림과 다운스트림

    흐름의 방향을 강물에 빗댄 말이다. 다만 무엇의 흐름을 기준으로 하느냐에 따라 방향이 반대로 쓰인다. 서비스 간 호출을 말할 때는 요청이 흘러가는 쪽을 기준으로 다운스트림 = 내가 호출하는 쪽, 업스트림 = 나를 호출하는 쪽이라 부르는 경우가 많다. 아래 설명은 이 용법을 따른다.

  • XSS

    XSS(Cross-Site Scripting)는 공격자가 넣은 스크립트가 내 사이트의 출처(origin) 권한으로 사용자 브라우저에서 실행되는 공격이다. 같은 출처의 코드로 돌기 때문에 same-origin-policy가 막아 주지 못한다. 그 스크립트는 페이지를 바꾸고, 로그인한 사용자 행세를 하며 요청을 보내고, JS가 읽을 수 있는 데이터(localStorage의 토큰 등)를 빼 갈 수 있다.

  • Origin·Referer 헤더와 Referrer-Policy

    브라우저가 요청에 붙이는 두 헤더. Origin은 요청이 시작된 출처(프로토콜·호스트·포트)만, Referer는 요청을 일으킨 페이지의 URL(경로·쿼리까지)을 담는다. Referrer-Policy는 Referer에 얼마나 담을지 정한다.

보기 옵션