DNS서버를 바꿀 때 접속 장애를 피하는 방법

얼마 전 서버를 옮긴 뒤 새 서버는 멀쩡한데 일부 방문자만 옛 화면을 본다는 연락을 받았다. 웹서버 로그에는 그 방문자의 요청이 없었다. 확인해 보니 새 IP를 등록한 DNS서버와 실제로 도메인이 가리키는 DNS서버가 달랐다. 서버 이전에서는 이런 일이 꽤 흔하다. DNS서버를 바꾼다면 웹서버 설정만큼 DNS 기록과 변경 순서를 챙겨야 한다.

DNS서버 변경 전에 두 역할부터 구분한다

브라우저가 사이트에 접속할 때 쓰는 DNS에는 크게 두 역할이 있다. 방문자 쪽의 재귀 DNS서버는 도메인의 주소를 찾아 임시로 기억한다. 도메인에 등록된 권한 DNS서버는 그 도메인의 실제 기록을 답한다. 호스팅 업체가 제공하는 DNS 관리 화면에서 A 레코드를 바꿨더라도, 도메인 등록기관에 설정된 권한 DNS서버가 다른 곳이면 방문자에게는 변화가 없다.

먼저 도메인 등록기관의 네임서버 설정과 현재 권한 DNS서버를 확인한다. 같은 서비스에서 DNS 기록만 수정할지, 권한 DNS서버 자체를 옮길지에 따라 작업량이 달라진다. A 레코드의 IP만 바꾸는 작업은 비교적 단순하다. 네임서버를 옮기면 웹뿐 아니라 메일, 인증, 다른 하위 도메인의 기록까지 새 DNS서버에 옮겨야 한다.

웹 접속 기록만 복사하고 끝내면 메일이 먼저 끊기기도 한다. MX는 메일 수신 경로를, TXT는 메일 발송 인증이나 서비스 소유 확인에 쓰일 수 있다. AAAA는 IPv6 주소를 가리킨다. 새 서버가 IPv6로 응답하지 못하는데 예전 AAAA 기록을 남겨 두면 IPv6를 쓰는 방문자에게만 접속 장애가 날 수 있다. CNAME도 별칭으로 쓰는 위치를 확인해야 한다. 화면에 보이는 레코드를 종류별로 저장하고, 각 기록이 아직 필요한지 담당 서비스와 대조한다.

서버 이전은 DNS 변경보다 먼저 준비한다

DNS를 먼저 바꾸고 새 서버를 준비하면 새 주소를 받은 방문자부터 오류를 본다. 나는 이전할 때 새 서버에 파일과 데이터베이스를 복원한 뒤, 운영 도메인을 바꾸기 전에 접속과 로그인을 확인한다. SSL 인증서, 리디렉션, 관리자 페이지, 예약 작업도 이때 본다. 데이터베이스를 쓰는 사이트라면 마지막 데이터 동기화 시점과 쓰기 중단 시간을 따로 잡아야 한다. DNS는 접속 위치를 알려줄 뿐, 두 서버의 게시물이나 주문 데이터를 맞춰 주지는 않는다.

기존 DNS 기록의 TTL은 변경 전에 낮춘다. TTL은 재귀 DNS서버가 답을 보관할 수 있는 시간이다. 예를 들어 기존 TTL이 24시간이라면 작업 직전에 300초로 바꿔도 이미 저장된 답이 즉시 사라지지는 않는다. 적어도 기존 TTL만큼 앞서 낮춰 두고, 이전하는 동안에는 구 서버도 응답하게 유지하는 편이 안전하다. TTL이 300초여도 모든 방문자가 정확히 5분 뒤 새 서버로 오는 것은 아니다. 방문자의 기기와 네트워크에도 캐시가 남을 수 있다.

권한 DNS서버까지 바꿀 계획이라면 새 DNS서버에 기존 레코드를 먼저 만들어 둔다. 그다음 새 서버가 웹과 메일에 대해 올바른 답을 내는지 확인하고 등록기관의 네임서버 설정을 변경한다. DNSSEC을 사용 중인 도메인은 DS 기록도 함께 확인해야 한다. 새 DNS서버의 서명 설정과 예전 DS 기록이 맞지 않으면 일부 재귀 DNS서버가 도메인의 답을 거부할 수 있다. 설정을 확신할 수 없다면 이전 절차와 서명 전환 방법을 먼저 확인한 뒤 변경 시간을 잡는다.

접속이 안 될 때는 답을 주는 위치를 찾는다

DNS 장애가 의심되면 브라우저의 오류 화면만 반복해서 보지 않는다. 먼저 여러 네트워크에서 같은 증상인지 확인한다. 휴대전화의 이동통신망에서는 열리고 사무실 회선에서만 안 열린다면 캐시나 해당 회선의 재귀 DNS서버를 의심할 수 있다. 어느 곳에서도 열리지 않는다면 권한 DNS서버의 응답과 등록기관의 네임서버 설정부터 확인한다.

다음으로 재귀 DNS서버가 주는 답과 권한 DNS서버가 직접 주는 답을 비교한다. 권한 DNS서버는 새 IP를 주는데 재귀 DNS서버만 옛 IP를 준다면 캐시가 남은 상황일 수 있다. 둘 다 옛 IP를 준다면 레코드를 수정한 위치가 잘못됐거나 변경이 저장되지 않았을 가능성이 크다. 올바른 IP가 나오는데도 접속이 안 된다면 그때부터 웹서버, 방화벽, SSL 인증서, 애플리케이션 로그를 본다. 주소 조회가 정상인 장애를 DNS 문제로 붙잡고 있으면 복구만 늦어진다.

‘도메인이 없다’는 응답도 주의해야 한다. 새 DNS서버에 하위 도메인을 만들기 전에 누군가 조회했다면, 존재하지 않는다는 답이 일정 시간 저장될 수 있다. 레코드를 추가한 직후에도 일부 환경에서 계속 실패하는 이유다. 이런 경우에는 같은 이름을 여러 재귀 DNS서버와 권한 DNS서버에 물어보고 응답 차이를 확인한다.

변경 뒤에는 구 서버와 DNS 기록을 함께 지킨다

새 IP로 접속되는 것을 한 번 확인했다고 구 서버를 바로 끄지 않는다. 구 서버의 접속 로그에 요청이 남는지 보고, 메일을 쓰는 도메인이라면 송수신도 따로 점검한다. 쇼핑몰이나 회원 사이트는 구 서버에 새 데이터가 쌓이지 않도록 읽기 전용 전환이나 짧은 점검 시간을 고려해야 한다. 방문자가 두 서버로 나뉘어 들어오는 동안 양쪽에서 주문을 받으면 DNS보다 데이터 복구가 더 어려워진다.

작업 전에는 DNS 기록을 파일이나 관리 화면의 내보내기 기능으로 보관하고, 기존 네임서버와 TTL도 적어 둔다. 되돌릴 때 필요한 값이 없으면 장애 중에 기억에 의존해 기록을 다시 만들어야 한다. DNS 기록 백업은 비용이 거의 들지 않지만, 빠진 MX나 TXT 하나를 찾는 시간을 크게 줄여 준다.

작은 사이트라면 DNS를 위해 비싼 서버 요금제로 올릴 이유는 거의 없다. 기존 호스팅의 DNS 기능으로 필요한 기록을 안정적으로 관리할 수 있다면 그것으로 충분하다. 내가 더 신경 쓰는 것은 변경 전 기록 사본, 새 서버의 사전 점검, 구 서버를 유지할 시간이다. 이 세 가지가 준비돼 있으면 DNS서버를 바꾸는 작업도 훨씬 예측 가능해진다.