도메인 이름 시스템(DNS), 도메인이 서버 주소로 바뀌는 과정

도메인을 샀다면 다음은 서버와 연결할 차례다.
등록 업체나 AWS의 Route 53 화면에는 A 레코드, CNAME, TTL, 네임서버 같은 칸이 있다.
서버의 IP 주소를 A 레코드에 넣어 저장하면 그 이름으로 서버에 접속할 수 있다.

그런데 서버를 옮기면서 이 주소를 바꾸면 이상한 일이 생긴다.
같은 이름으로 들어오는 요청이 한동안 옛 서버와 새 서버에 나뉘어 도착한다.

DNS는 이름을 IP 주소로 바꿔 준다

컴퓨터끼리는 IP 주소로 연결한다.
IP 주소가 무엇인지는 공인 IP와 사설 IP 글에서 다뤘다.
사람은 숫자를 외우기 어려우니 이름을 붙이고, 이름을 주소로 바꾸는 시스템을 따로 둔다.
이것이 DNS(Domain Name System)⁠다.

DNS에는 이름마다 레코드라는 항목을 적어 둔다.
A 레코드에는 그 이름이 가리키는 IPv4 주소를, AAAA 레코드에는 IPv6 주소를 적는다.
CNAME은 이 이름이 다른 이름의 별칭이라는 뜻이다.

CNAME이 붙은 이름을 물으면 그 다른 이름의 레코드를 이어서 찾아 주소를 얻는다.

처음에는 표 하나에 모든 이름이 있었다

1983년 당시 인터넷의 컴퓨터 이름과 주소는 HOSTS.TXT라는 표 하나에 모여 있었다.
이 표는 크기와 갱신 빈도가 관리할 수 있는 한계에 가까워져 있었다.

그해 Paul Mockapetris가 제안한 것은 분산된 데이터베이스였다.
이름을 점으로 나눈 마디마다 관리하는 곳을 따로 두는 방식이다.
www.example.com이라면 com을 관리하는 곳이 있고, example.com을 관리하는 곳이 따로 있다.

위 마디는 아래 마디의 답을 직접 갖지 않고, 그 답을 가진 서버가 어디인지만 알려 준다.
이렇게 넘겨주는 것을 위임(delegation)⁠이라고 한다.
이 설계는 몇 해 뒤 다시 정리돼 지금도 쓰인다.

위임은 지금도 설정 화면에서 만난다.
Route 53에서는 도메인 하나의 레코드를 호스팅 영역이라는 단위로 모아 관리하는데, 호스팅 영역을 만들면 그 도메인의 답을 맡을 네임서버 네 개가 정해진다.

도메인을 산 등록 업체에 이 네임서버들을 적어 넣는 일이 바로 위임이다.
등록 업체가 이 값을 com을 관리하는 곳에 넘기면, com을 맡은 서버는 NS 레코드라는 항목에 네 네임서버를 적어 두고 이 도메인을 묻는 질문에 그 이름들을 돌려준다.

답은 누가 찾아 줄까

실제 조회는 두 종류의 서버가 나눠 맡는다.
권한 서버는 어떤 이름의 최종 답을 가진 서버다.
재귀 서버는 사용자 대신 위 마디부터 차례로 물어 답을 모아 오는 서버다.

인터넷 제공자의 DNS나 공용 DNS라고 부르며 기기에 설정하는 주소가 재귀 서버다.
Route 53의 네임서버는 내 도메인의 권한 서버 쪽이다.

내 컴퓨터가 www.example.com의 주소를 모르면 재귀 서버에 묻는다.
재귀 서버는 루트 서버에서 com을 맡은 서버를 알아내고, 거기서 example.com의 권한 서버를 알아낸 뒤 최종 답을 받아 온다.

TTL은 답을 기억해도 되는 시간이다

재귀 서버가 매번 루트부터 물으면 위쪽 서버들이 버티지 못한다.
그래서 한 번 받은 답을 한동안 보관해 두고 다시 쓴다.
이것을 DNS 캐시라고 한다.

얼마나 보관해도 되는지는 답에 함께 붙어 온다.
이 값이 TTL(Time to Live)⁠이고 초 단위로 적는다.
TTL이 3600인 답을 받은 재귀 서버는 한 시간 동안 권한 서버에 다시 묻지 않고 그 답을 쓴다.

그래서 A 레코드를 새 주소로 바꿔도, 옛 답을 받아 둔 재귀 서버는 TTL이 끝날 때까지 옛 주소를 알려 준다.
요청이 옛 서버와 새 서버에 나뉘어 도착하는 것은 이 때문이다.

서버를 옮기기 전에 TTL을 미리 낮춰 두는 이유도 여기 있다.
지금 TTL을 낮춰도 이미 보관된 답의 남은 시간은 줄지 않는다.

받은 시각이 다른 캐시 두 곳에서는 주소 변경이 반영되는 때도 다르다.

권한 서버: 옛 주소 · TTL 4분

캐시 A

옛 주소

남은 1분

캐시 B

옛 주소

남은 3분

TTL을 줄여도 캐시에 이미 남은 시간을 줄이지는 못한다. 각 캐시가 만료된 뒤 다시 조회할 때 새 답을 받는다.

같은 4분짜리 답을 받았지만 받은 시각이 달라 남은 시간도 다르다.

권한 서버의 TTL을 1분으로 줄였다. 이미 보관한 답의 남은 1분·3분은 그대로다.

1분 뒤 A는 만료되어 새 답을 받았다. B는 아직 옛 답을 2분 더 쓸 수 있다.

A는 새 답을 다시 확인했다. B의 옛 답에는 아직 1분이 남았다.

B도 옛 답이 만료된 뒤 조회해 새 주소를 받았다. 두 곳 모두 새 주소를 안다.

가상의 분 단위이며 매번 권한 서버가 정상 응답하는 예시다. 만료 응답 재사용·없는 이름의 캐시·전 세계 전파 시간은 계산하지 않는다.

TTL을 변경이 퍼지는 최대 시간으로 외워 두면 틀릴 때가 있다.
권한 서버에 닿을 수 없을 때는 만료된 답을 제한적으로 계속 쓰는 재귀 서버도 있다.

이름이 없다는 답도 캐시된다.
레코드를 만들기 전에 그 이름을 조회하면 없다는 답이 한동안 남아, 새로 만든 레코드가 늦게 보일 수 있다.

도메인은 기간을 정해 등록해서 쓴다

도메인을 ‘산다’⁠고들 하지만 실제로는 정해진 기간 동안 등록해서 쓴다.
기간이 끝나기 전에 갱신해야 계속 쓸 수 있다.

만료된 도메인을 제때 갱신하거나 복구하지 않으면, 먼저 신청한 사람이 가져가는 선착순 등록으로 풀릴 수 있다.

다른 사람이 그 이름을 등록하면 DNS 레코드도 그 사람이 정한다.
그 이름으로 걸린 링크와 메일이 모두 새 주인이 정한 곳으로 간다.

HTTPS가 확인해 주는 것

주소를 찾았다고 끝은 아니다.
연결한 서버가 정말 그 이름의 서버인지, 중간에서 누가 내용을 엿보거나 바꾸지 않는지가 남는다.
HTTPS⁠는 웹 통신을 암호화된 연결 위로 보내 이 두 가지를 돕는다.

서버가 그 이름의 주인인지는 인증서로 확인한다.
인증서는 인증 기관이 이 서버가 그 도메인을 쓴다고 확인하고 서명해 준 전자 문서다.
브라우저는 접속할 때 인증서의 서명, 이름, 유효 기간을 검사한다.

인증서를 받으려면 그 이름을 내가 통제한다는 것을 보여 줘야 한다.
인증 기관 Let’s Encrypt는 정해진 웹 경로에 파일을 올리거나 DNS에 정해진 TXT 레코드를 넣게 해서 이를 확인한다.
그래서 DNS를 바꿀 권한을 빼앗기면 남이 그 이름으로 인증서를 받을 수도 있다.

Let’s Encrypt는 2015년 12월부터 누구나 무료로 인증서를 받을 수 있게 했다.
HTTPS를 웹의 기본으로 만드는 것이 목표였고, 그 전략의 중심에는 자동화가 있었다.

주소창의 자물쇠를 보고 사이트를 믿어도 된다고 생각하기 쉽다.
자물쇠가 말해 주는 것은 연결이 암호화됐고 서버가 그 이름의 주인이라는 데까지다.

피싱 사이트도 거의 다 HTTPS를 쓰니 자물쇠는 똑같이 뜬다.
Chrome이 2023년에 주소창의 자물쇠 아이콘을 다른 모양으로 바꾸기로 한 것도 이 때문이다.

무엇이	무엇을 맡나	이것만 잘못되면
도메인 등록	그 이름을 쓸 권리	기간이 끝나면 이름째 남에게 넘어갈 수 있다
DNS 레코드	이름이 가리키는 목적지	바꿔도 TTL이 지나기 전까지 옛 주소로 간다
인증서	연결한 서버가 그 이름의 주인임	만료되면 브라우저가 경고를 띄우고 접속을 막는다

서버를 옮길 때 챙길 것

서버를 옮기기 전에는 그 레코드의 TTL을 짧게 낮춰 둔다.
낮춘 뒤 원래 TTL만큼은 기다렸다가 주소를 바꿔야 옛 TTL로 받아 둔 답이 그사이에 모두 만료된다.

주소를 바꾼 뒤에도 옛 서버를 바로 끄지 않는다.
옛 답을 들고 있는 재귀 서버가 남아 있는 동안은 요청이 옛 서버로도 간다.
옛 서버로 오는 요청이 끊긴 것을 확인하고 내린다.

도메인과 인증서는 자동 갱신을 켜 둔다.
AWS의 인증서 서비스인 ACM에서 받은 인증서는 로드밸런서나 CloudFront에 연결돼 있고 DNS로 검증했다면 ACM의 관리형 갱신으로 자동 갱신된다.
다른 곳에서 가져와 넣은 인증서는 자동 갱신 대상이 아니어서 만료일을 따로 챙겨야 한다.