← Posts

Network · DNS · Domain

이름을 주소로 바꾼다 - DNS

우리는 142.250.72.14가 아니라 google.com을 친다. 그 이름을 IP 주소로 바꿔주는 게 DNS다. 이름을 뒤에서부터 단계로 찾아 내려가는 조회, 그리고 캐싱과 TTL이 왜 DNS 변경을 늦게 퍼지게 하는지.

목차
  1. 우리는 숫자를 외우지 않는다
  2. DNS는 인터넷의 전화번호부
  3. 이름은 뒤에서부터 읽는다
  4. 조회는 단계로 내려간다
  5. 매번 물으면 느리다: 캐싱
  6. TTL: 얼마나 믿을지의 시간
  7. DNS가 흔히 문제인 이유
  8. 실무에서: DNS를 만나는 자리
  9. 정리

우리는 142.250.72.14가 아니라 google.com을 친다. 사람은 이름을, 기계는 숫자 주소를 쓴다. 그 사이를 이어주는 전화번호부가 DNS다.

우리는 숫자를 외우지 않는다

패킷은 IP 주소를 들고 간다. 하지만 우리가 그 숫자를 외울 수는 없다. 사이트마다 다르고, 바뀌기도 한다. 그래서 사람은 example.com 같은 이름을 쓰고, 기계로 보내기 직전에 그 이름을 숫자 주소로 바꾼다.

이 “이름 → 주소” 변환을 하는 게 DNS(Domain Name System) 다. 주소창에 이름을 치면, HTTP 요청이 나가기 전에 DNS 조회가 먼저 일어나 진짜 목적지 IP를 알아낸다.

DNS는 인터넷의 전화번호부

DNS를 전화번호부에 비유하면 쉽다. “홍길동”이라는 이름으로 전화번호를 찾듯, example.com이라는 이름으로 IP 주소를 찾는다.

plaintext
example.com  →  DNS 조회  →  203.0.113.45

다만 이 전화번호부는 한 권이 아니다. 세상의 모든 도메인을 한 곳이 다 아는 건 불가능하니, 여러 단계로 나눠 관리한다. 이 나눔이 DNS의 핵심이다.

이름은 뒤에서부터 읽는다

www.example.com을 컴퓨터는 뒤에서부터 읽는다. 점으로 나뉜 각 부분이 계층을 이룬다.

plaintext
www . example . com
 │      │        └ 최상위(TLD): com·org·kr 등
 │      └ 도메인: example
 └ 그 안의 호스트: www

com이 가장 큰 분류이고, 그 안에 example이 있고, 그 안에 www가 있다. 주소가 “국가 → 도시 → 번지”로 좁혀지듯, 도메인도 오른쪽(큰 분류)에서 왼쪽(구체)으로 좁혀진다. 이 계층 덕에 조회를 단계로 나눌 수 있다.

조회는 단계로 내려간다

이름을 처음 찾을 때, DNS는 큰 분류부터 차례로 물어 내려간다. 이 심부름을 대신하는 게 리졸버(resolver) 다(보통 통신사나 공용 DNS).

diagramdiagram

리졸버가 루트에게 “com은 어디서 관리하나” 묻고, com 서버에게 “example.com은 누가 아나” 묻고, 마지막으로 example.com을 관리하는 서버에게 실제 주소를 받는다. 큰 분류에서 구체로 한 단계씩 내려가며 최종 주소를 알아낸다.

매번 물으면 느리다: 캐싱

이 여러 단계를 요청마다 반복하면 느리다. 그래서 DNS는 캐싱을 적극 쓴다. 한 번 알아낸 “이름 → 주소”를 기억해 두고, 다음엔 물어보지 않고 바로 쓴다.

리졸버가 기억하고, 운영체제가 기억하고, 브라우저도 기억한다. 그래서 같은 사이트를 두 번째 열 땐 DNS 조회가 아예 생략되기도 한다. 가장 빠른 요청은 안 보내는 요청이라던 그 원리가 DNS에도 그대로 있다.

TTL: 얼마나 믿을지의 시간

캐시엔 함정이 있다. 주소를 기억해 뒀는데 그새 주소가 바뀌면 낡은 걸 쓰게 된다. 그래서 각 DNS 응답엔 TTL(Time To Live) 이라는 유효기간이 붙는다 - “이 답을 이 시간(예: 300초) 동안은 믿어도 된다.”

TTL이 지나면 캐시를 버리고 다시 물어본다. 이 TTL이 DNS 변경이 즉시 안 퍼지는 이유다. 서버 IP를 바꿔도, 세상 곳곳의 캐시에 남은 옛 주소가 각자의 TTL이 끝날 때까지 살아 있다. 그래서 “도메인을 새 서버로 옮겼는데 어떤 사용자는 아직 옛 서버로 간다”가 생긴다.

DNS가 흔히 문제인 이유

DNS는 모든 접속의 첫 관문이라, 여기서 막히면 그 뒤는 시작도 못 한다. 그래서 “인터넷이 안 된다”의 상당수가 실은 DNS 문제다 - 기계엔 IP로 닿는데 이름 조회만 실패하는 것이다.

흔한 원인은 캐시다. 옛 주소가 캐시에 남아 이미 옮긴 서버로 안 가거나, 잘못된 답이 캐시에 눌어붙는다. “DNS 캐시를 비웠더니 됐다”가 그래서 나온다.

실무에서: DNS를 만나는 자리

  • 배포 전환은 TTL을 미리 낮춘다 - 서버를 옮기기 전, TTL을 짧게(예: 60초) 바꿔 두면 전환이 빨리 퍼진다. 옮긴 뒤 다시 늘린다. TTL을 안 낮추고 옮기면 옛 서버를 한참 더 켜둬야 한다.
  • “나는 되는데 남은 안 된다” - 내 캐시엔 새 주소가, 남의 캐시엔 옛 주소가 있을 수 있다. 전파 중인 상태다. TTL이 다 지나야 모두가 같아진다.
  • DNS로 트래픽을 나누기도 - 같은 이름에 여러 IP를 줘서 부하를 분산하거나, 지역별로 다른 IP를 주기도 한다. 로드 밸런싱의 한 형태가 DNS 단계에서 일어난다.

정리

  • 사람은 이름, 기계는 숫자 주소를 쓴다 - DNS가 이름을 IP로 바꿔, HTTP 요청 전에 목적지를 알아낸다.
  • 도메인은 뒤에서부터(com → example → www) 계층이라, 조회도 큰 분류에서 구체로 단계로 내려간다(리졸버가 대신).
  • 매번 묻지 않게 캐싱하고, 각 답엔 TTL(유효기간)이 붙는다 - 이 TTL이 DNS 변경을 늦게 퍼지게 한다.
  • DNS는 접속의 첫 관문이라 흔한 장애 지점이고, 배포 전환 땐 TTL을 미리 낮춰 대비한다.

다음 글은 기계까지 온 패킷이 그 안의 어느 프로세스로 가는지를 정하는 - 포트로 간다.