도메인 이름 시스템(DNS), 이름이 주소가 되는 길

낯선 동네에서 느티나무 서점을 찾아간다고 해 볼게요. 이름은 외우기 쉽지만 그것만으로는 문 앞에 설 수 없어요. 이름과 위치는 늘 따로 있고, 둘을 잇는 안내가 어딘가에 필요해요.

인터넷도 같아요. 사람은 짧은 이름을 기억하고 기계는 숫자 주소로 연결해요. 그 사이를 중개하는 것이 DNS(Domain Name System), 도메인 이름 시스템이에요. 여기까지는 널리 알려진 설명인데, 운영에서 실제로 문제를 만드는 것은 이 중개가 한 곳에서 일어나지 않는다는 점이에요.

한 파일로 버티다 권한을 나눈 설계

초기 인터넷은 연결된 컴퓨터 전체의 이름과 주소를 적은 파일 하나를 중앙에서 관리하고 각 기관이 주기적으로 내려받는 방식이었어요. 참가자가 수십 곳일 때는 충분했지만, 이름 하나가 바뀔 때마다 전원이 파일을 다시 받아야 했고 새 이름을 등록하려면 중앙의 손을 거쳐야 했어요. 참가자 수에 비례해 중앙이 병목이 되는 구조였어요.

1983년 11월 Paul Mockapetris는 RFC 882와 RFC 883에서 다른 길을 제안했어요. 이름을 마디로 끊고 마디마다 답할 권한을 나누자는 것이었어요. 어떤 이름의 답을 최종적으로 책임지는 서버가 정해지고, 그 위 마디는 그 서버가 어디인지만 알려 줘요. 이 넘겨주기를 위임(delegation)이라고 해요. 새 이름을 만들 때 중앙에 알릴 필요가 사라진 것이 이 설계의 핵심이고, 그래서 이름 공간이 인터넷과 함께 커질 수 있었어요. 이 구조는 1987년 RFC 1034와 RFC 1035로 다시 정리됐어요.

실제 조회는 두 종류의 서버가 나눠 맡아요. 하나는 최종 답을 가진 권한 서버이고, 다른 하나는 사용자 대신 위에서부터 물어 내려가 답을 모아 오는 재귀 서버예요. 우리가 인터넷 제공자나 공용 DNS라고 부르며 설정하는 주소는 뒤쪽이에요.

TTL이 실제로 정하는 것

재귀 서버가 매번 처음부터 물으면 위쪽 서버들이 견디지 못해요. 그래서 받은 답에는 얼마 동안 기억해도 되는지를 알려 주는 값이 함께 붙어요. 이 값을 TTL이라고 불러요.

TTL은 Time to Live의 약자로, 받은 답을 다시 확인하기 전까지 보관할 수 있는 시간이에요. 예를 들어 한 시간짜리 답을 막 받은 재귀 서버는 원본의 주소가 바뀌어도 한동안 예전 답을 줄 수 있어요. 이전부터 TTL을 낮춰 두는 이유죠. 지금 낮춘 값이 이미 보관된 답의 시간을 소급해서 줄여 주지는 않아요.

다만 TTL을 ‘변경이 전 세계에 퍼지는 시간의 상한’으로 외우면 틀려요. 캐시를 받은 시각도 서로 다르고, RFC 8767은 원본에 다시 물을 수 없을 때 만료된 답을 제한적으로 쓰는 방식도 정의해요. 이름이 없다는 답도 캐시될 수 있어요. 주소 변경은 한 곳의 스위치를 동시에 내리는 작업과 달라요.

받은 시각이 다른 캐시 두 곳에서 주소 변경을 따라가 보세요.

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

캐시 A

옛 주소

남은 1분

캐시 B

옛 주소

남은 3분

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

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

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

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

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

B도 옛 답이 만료된 뒤 조회해 새 주소를 받았어요. 두 곳 모두 새 주소를 알아요.

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

도메인을 산다는 말도 정확히는 빌린다는 뜻이에요. 등록 기간이 끝나면 이름은 다른 사람이 가져갈 수 있고, 그 이름을 신뢰의 근거로 삼던 모든 것이 함께 넘어가요. 잘 쓰던 서비스의 주소가 어느 날 전혀 다른 화면이 되는 사고는 대개 여기서 시작해요.

이름이 맞아도 남는 질문

주소를 찾고 나면 두 가지가 남아요. 내가 요청한 이름의 서버와 연결했는지 확인하고, 중간에서 내용을 읽거나 바꾸기 어렵게 하는 일이에요. HTTPS는 웹 통신을 암호화된 연결 위로 보내 이 일을 도와요. 다만 연결이 암호화됐다고 그 사이트의 상품이나 운영자까지 믿을 수 있다는 뜻은 아니에요.

그 이름에 대한 확인에는 인증서가 쓰여요. 도메인 검증 인증서를 받을 때는 신청자가 이름을 통제한다는 것을 보여 줘야 해요. Let’s Encrypt의 인증 방식에는 특정 웹 경로에 값을 올리거나 DNS에 정해진 레코드를 넣는 방법이 있어요. DNS를 바꿀 권한을 빼앗기면 인증서 발급에도 영향을 줄 수 있는 이유예요.

예전에는 인증서가 돈이 들고 갱신이 번거로워 로그인이나 결제 화면에만 자물쇠를 다는 사이트가 많았어요. 2015년 12월 3일 Let’s Encrypt가 공개 베타를 시작하면서 이 계산이 바뀌었어요. 무료라는 점보다 발급과 갱신이 자동화됐다는 점이 컸어요. 사람이 만료일을 기억해야 하는 일이 사라지자 전 구간 암호화가 기본이 됐고, 지금 브라우저는 자물쇠가 없는 쪽에 경고를 붙여요.

무엇이	무엇을 보장하나	이것만 잘못되면
도메인 등록	그 이름을 쓸 권한	기간이 끝나면 이름째 남에게 넘어간다
DNS 레코드	이름이 가리키는 목적지	옮겨도 TTL이 지나기 전까지 옛 곳으로 간다
인증서	도착한 곳이 그 이름의 주인임	만료되면 브라우저가 연결을 막는다

저는 이 이름을 어떻게 정리했나

이 블로그를 열면서 뜻밖에 시간을 쓴 일이 주소를 하나로 모으는 것이었어요. 아무것도 정하지 않으면 같은 글이 여러 주소로 존재해요. www가 붙은 쪽과 붙지 않은 쪽, 자물쇠가 있는 쪽과 없는 쪽이 각각 열리므로 사람 눈에는 하나여도 기계에게는 네 곳이에요.

그래서 자물쇠 없는 요청은 전부 있는 쪽으로 넘기고 www는 루트 도메인으로 모았어요. 기술적으로 어려운 일은 아니었지만, 정하고 나서야 왜 이 정리가 먼저인지 알았어요. 링크를 나눠 준 사람이 가진 주소와 검색 결과에 실린 주소가 갈라지면 나중에는 되돌리기 어려워요. 주소는 한 번 밖으로 나가면 회수할 수 없는 종류의 결정이에요.