서버 주소를 바꿨는데 왜 어떤 사람은 아직 옛 서버로 갈까?

예를 들어 서비스를 새 서버로 옮겼다. 도메인 설정도 새 주소로 바꿨다. 내 컴퓨터에서는 새 화면이 열리는데 다른 사람은 한동안 옛 화면을 본다. 설정이 저장되지 않은 걸까?

도메인 이름 시스템(Domain Name System, DNS)은 사람이 쓰는 이름에 연결된 주소 같은 정보를 여러 서버에 나눠 보관하고 찾는 체계다. 사용자가 매번 원본 서버에 물어보지 않도록 중간에 얻은 답을 저장한다. 도메인 설정을 바꾼 시각과 모든 사용자가 새 주소를 받는 시각이 같지 않은 이유가 여기에 있다.

주소를 누가 기억하고 있을까

www.example.com의 주소를 찾는 요청은 브라우저와 운영체제의 기록을 먼저 확인할 수 있다. 거기에 답이 없으면 인터넷 서비스 제공업체나 회사에서 설정한 재귀 리졸버(recursive resolver)에 묻는다. 재귀 리졸버는 사용자 대신 권한 있는 서버의 답을 찾아 돌려주는 프로그램이다. 권한 서버(authoritative server)는 자신이 맡은 도메인 영역의 원본 답을 제공한다.

브라우저·운영체제의 저장된 답
        ↓ 없으면
재귀 리졸버의 저장된 답
        ↓ 없으면
도메인을 맡은 권한 서버의 답

권한 서버의 주소가 바뀌어도 재귀 리졸버가 이전 답을 저장해 두었다면 그 리졸버를 쓰는 사용자는 옛 주소를 받는다. 서로 다른 재귀 리졸버를 쓰는 두 사람에게 다른 결과가 나오는 일도 가능하다. 브라우저나 응용 프로그램이 자체적으로 주소 또는 연결을 재사용한다면 재귀 리졸버의 답이 새로워진 뒤에도 이전 서버와 통신할 수 있다.

유효 시간이 끝나기 전에는 이전 답이 남는다

유효 시간(Time To Live, TTL)은 저장한 주소를 다시 조회하지 않고 쓸 수 있는 시간을 나타낸다. 권한 서버가 주소의 유효 시간을 300초로 보냈다고 하자. 한 리졸버가 12시에 옛 주소를 받아 저장했고, 운영자가 12시 2분에 새 주소로 바꿨다. 리졸버는 자신의 기록이 살아 있는 동안 계속 옛 주소로 답할 수 있다.

12:00  리졸버가 옛 주소를 300초 동안 저장
12:02  권한 서버의 주소를 새 주소로 변경
12:04  그 리졸버를 쓰는 사용자는 옛 주소를 받을 수 있음
12:05  저장한 답이 만료된 뒤 다시 찾으면 새 주소를 받을 수 있음

이 예는 재귀 리졸버 한 곳만 단순화한 것이다. 실제로는 여러 층에서 저장 기간을 다르게 적용할 수 있다. 주소를 바꾸는 바로 그 순간 유효 시간을 30초로 줄여도 이미 300초로 저장된 답의 남은 수명은 줄어들지 않는다. 계획된 서버 이전이라면 기존 유효 시간을 먼저 낮추고, 옛 답이 만료될 시간을 기다린 다음 주소를 바꿔야 한다.

‘없는 주소’라는 답도 남을 수 있다

새 도메인을 만들었는데 일부 사람에게 계속 ‘찾을 수 없음’이 보일 때도 있다. 부정 캐시(negative cache)는 이름이 없거나 요청한 종류의 주소가 없다는 응답을 일정 시간 저장하는 방식이다. 존재하지 않는 이름이라는 응답인 NXDOMAIN과, 이름은 있지만 요청한 주소 종류가 없다는 응답은 범위가 다르다.

새 레코드를 만든 뒤에도 재귀 리졸버가 이전의 ‘없음’ 응답을 보관하고 있으면 다시 물어보기 전까지 같은 실패를 돌려줄 수 있다. 이때 권한 서버를 직접 조회한 결과만 보고 ‘모든 사용자에게 보일 것’이라고 말할 수 없다. 실제 사용자가 쓰는 재귀 리졸버의 답과 저장 기간도 봐야 한다.

새 주소를 받았는데도 옛 화면이라면

이 문제를 전부 DNS 탓으로 돌리면 엉뚱한 곳을 고치게 된다. 먼저 사용자가 실제로 받은 주소를 확인한다. 주소가 옛것이면 캐시와 유효 시간을 살펴본다. 주소가 새것인데 화면이 옛것이면 웹 캐시, 프록시, 새 서버의 배포 상태, 브라우저가 유지한 연결을 확인한다. 새 서버가 이전 내용을 그대로 제공하고 있을 수도 있다.

서버를 옮길 때는 옛 서버를 곧바로 끄지 않는 편이 안전하다. 아직 옛 주소를 가진 사용자의 요청을 새 서버로 넘기거나, 이전 기간 동안 같은 서비스를 제공해야 할 수 있다. 다만 옛 서버와 새 서버가 둘 다 주문이나 결제를 처리한다면 데이터가 갈라지지 않도록 쓰기 경로도 함께 정해야 한다. 도메인 주소만 바꾸면 업무 상태까지 자동으로 옮겨지는 것은 아니다.

도메인을 바꾼 뒤 결과가 엇갈린다면 권한 서버의 현재 답, 사용자가 쓰는 리졸버의 답, 브라우저가 연결한 주소, 그 주소의 실제 화면을 차례로 비교해 보자. 어느 단계에서 옛 정보가 남았는지 알면 기다려야 할 일과 고쳐야 할 일을 구분할 수 있다.

참고 자료

• RFC 1034: DNS의 이름 공간과 캐시
• RFC 2308: DNS의 부정 캐시