네임서버 변경방법을 실수 없이 진행하려면

얼마 전 서버 이전을 마친 사이트가 새 서버에서는 잘 열리는데, 일부 방문자에게만 예전 화면이 보인다는 연락을 받았다. 서버나 호스팅 요금제 문제가 아니었다. 새 네임서버에 빠진 DNS 레코드가 있었고, 예전 네임서버의 응답도 아직 일부 이용자에게 남아 있었다. 네임서버를 바꾸는 작업은 등록업체 화면에서 주소 몇 개를 입력하면 끝나지만, 장애를 막는 일은 그 전후에 있다.

네임서버를 바꾸기 전에 현재 DNS부터 복사한다

네임서버는 도메인의 DNS 정보를 어디에 물어볼지 알려주는 역할을 한다. 변경 후에는 새 DNS 업체에 등록된 레코드가 기준이 된다. 서버 파일을 옮겼다고 DNS 레코드까지 따라오는 것은 아니다. 그래서 기존 설정을 먼저 내보내거나 화면을 기록하고, 새 DNS 영역에 같은 내용을 만들어야 한다.

웹사이트만 생각하면 A 레코드 하나를 옮기고 끝내기 쉽다. 실제 운영에서는 IPv6용 AAAA, 메일 수신용 MX, 발신 인증에 쓰는 TXT, 인증서 발급에 필요한 CAA, 서비스 확인용 CNAME이나 SRV가 같이 걸려 있을 수 있다. 하위 도메인과 와일드카드 레코드도 확인한다. 특히 메일 레코드가 빠지면 사이트는 정상인데 주문 알림이나 문의 메일만 끊긴다.

• 기존 네임서버 주소와 DNS 레코드 전체를 기록한다.
• 새 DNS 업체에 웹, 메일, 인증, 하위 도메인 레코드를 먼저 입력한다.
• 레코드의 이름, 값, 우선순위, TTL을 기존 설정과 대조한다.
• 서버 이전을 함께 한다면 새 서버에서 웹과 메일 동작을 별도로 확인한다.

TTL은 DNS 응답을 얼마나 오래 보관할지 나타내는 값이다. 서버 주소도 함께 바꾼다면 기존 A·AAAA 레코드의 TTL을 하루나 이틀 전에 300초 정도로 낮춰 두면 전환 중 오래된 서버 주소가 남는 시간을 줄일 수 있다. 다만 이미 저장된 응답의 유효기간을 거꾸로 줄일 수는 없다. 또 이 설정만으로 네임서버 위임 정보의 보관 시간까지 제어할 수 있는 것은 아니다.

DNSSEC를 쓰고 있다면 변경 순서를 따로 잡는다

도메인 등록업체 화면에 DS 레코드가 등록돼 있다면 DNSSEC가 켜져 있을 가능성이 높다. 이 상태에서 서명 체계가 다른 네임서버로 곧바로 바꾸면 일부 이용자에게 사이트 전체가 열리지 않을 수 있다. 서버가 멀쩡한데 웹과 메일이 함께 실패하는 식이라 발견도 늦다.

가장 단순한 절차는 등록업체에서 기존 DS 레코드를 제거하고, 그 변경이 DNS 캐시에서 충분히 반영된 뒤 네임서버를 바꾸는 것이다. 새 DNS 업체에서 DNSSEC 설정을 마친 다음 새 DS 정보를 등록한다. 보안상 DNSSEC를 끄는 시간을 허용할 수 없다면 기존 업체와 새 업체의 서명 정보를 함께 유지하는 전환 절차가 필요하다. 이 경우에는 두 업체가 지원하는 방식과 등록업체의 DS 등록 기능을 먼저 확인해야 한다.

DNSSEC를 사용하지 않는 도메인이라도 등록업체 화면에서 DS 레코드가 남아 있지 않은지 확인하는 편이 안전하다. 예전 설정의 흔적 하나가 이전 후 장애의 원인이 될 수 있다.

등록업체에서 네임서버를 바꾸는 방법

준비가 끝나면 도메인을 구매했거나 관리하는 등록업체에 로그인해 해당 도메인의 네임서버 관리 메뉴를 연다. 새 DNS 업체가 안내한 네임서버 주소를 정확히 입력하고 저장한다. 두 개 이상이 제공된다면 안내된 개수를 모두 등록한다. 등록업체마다 메뉴 이름은 다르지만, 바꾸는 대상은 웹호스팅의 서버 주소가 아니라 도메인의 위임 대상이다.

저장 직후 화면에 새 주소가 보인다고 전 세계에서 동시에 새 DNS를 쓰는 것은 아니다. DNS 조회 결과가 중간 서버와 이용자 기기에 남아 있기 때문이다. 몇 분 만에 바뀐 곳도 있고 하루 이상 예전 응답을 보는 곳도 있다. 흔히 말하는 24~48시간은 여유를 잡는 운영 기준에 가깝고, 모든 환경에 적용되는 완료 시각은 아니다.

이 기간에는 기존 DNS 영역을 바로 삭제하지 않는다. 새 네임서버와 기존 네임서버가 각각 응답하더라도 웹과 메일에 필요한 값이 맞아야 한다. 서버 주소까지 바뀌었다면 두 서버가 잠시 요청을 받을 수 있도록 유지하는 편이 안전하다. 쇼핑몰처럼 주문이나 회원 데이터가 계속 쌓이는 사이트는 웹 화면만 유지해서는 부족하다. 전환 시간 동안 데이터가 어느 서버에 기록되는지도 계획해야 한다.

변경 후에는 웹보다 DNS 응답을 먼저 확인한다

확인은 등록업체에 입력한 네임서버가 실제 위임 정보에 반영됐는지 보는 것부터 시작한다. 이어 새 네임서버가 A·AAAA, MX, TXT 등 필요한 레코드를 응답하는지 확인한다. 운영체제의 DNS 조회 명령이나 DNS 점검 도구를 쓰면 된다. 브라우저에서 사이트가 한 번 열리는 것만으로는 부족하다. 기기에 남은 캐시나 다른 DNS 경로로 우연히 접속했을 수 있다.

그다음 웹의 첫 화면과 로그인, 관리 화면, 파일 업로드를 확인한다. 메일은 외부에서 받는 시험과 외부로 보내는 시험을 나눠 본다. 인증서 오류가 생기면 서버의 인증서 설정과 DNS 인증 레코드, CAA 설정을 함께 확인한다. IPv4에서는 정상인데 일부 이용자만 실패한다면 AAAA 레코드가 이전 서버를 가리키는지도 본다.

문제가 생겼을 때 곧바로 네임서버를 다시 되돌리면 캐시가 한 번 더 갈라져 원인 파악이 어려워질 수 있다. 먼저 누락되거나 틀린 레코드가 있는지 확인하고 새 DNS에서 고칠 수 있다면 그쪽에서 수정한다. 새 DNS 자체가 응답하지 않는다면 기록해 둔 기존 설정을 기준으로 복구하고, 이후 웹과 메일을 다시 시험한다.

제가 이전 작업에서 가장 오래 붙잡는 부분은 등록업체의 저장 버튼이 아니라 레코드 대조표다. 무료 DNS나 저렴한 호스팅으로도 충분한 규모의 사이트가 많다. 네임서버 변경 때문에 더 비싼 서버가 필요한 경우는 드물고, 빠진 레코드 하나를 찾아내는 편이 훨씬 자주 일을 해결한다.