운영 중인 서비스 무중단 이관

운영 중인 서비스의 도메인을 옮기면서 중단을 피하는 방법은 간단합니다. 전환 전에 TTL을 낮춰 두고, 새 DNS에 기존 레코드를 하나도 빠짐없이 복제한 뒤, 옛 존을 살려 둔 채로 네임서버를 바꾸는 것입니다. 이렇게 하면 전파가 끝나는 동안 옛 경로와 새 경로가 모두 정상 응답하므로 사용자 입장에서는 끊기는 순간이 없습니다.

기관이전(등록기관 변경) 자체는 중단을 만들지 않습니다. 위험한 것은 네임서버, 레코드 값, 서버 IP가 바뀌는 순간입니다. 그래서 이관은 "한 번에 다 바꾸기"가 아니라 "겹치게 만든 뒤 하나씩 바꾸기"로 설계합니다.

준비 기간

전환 예정일 기준 최소 2일 전부터 (기존 TTL이 길면 더 앞서)

전환 중 목표

옛 경로와 새 경로가 동시에 정상 응답

옛 존 유지

전환 뒤 최소 48시간, 권장 1주일

무중단 이관의 세 가지 원칙

1. 먼저 낮추고 나중에 바꾼다. TTL은 값을 바꾸기 전에 낮춰야 의미가 있습니다. 바꾼 뒤 낮추면 이미 퍼진 옛 값을 되돌릴 수 없습니다.
2. 새 경로를 먼저 완성한다. 새 네임서버에 레코드가 다 들어가 있고 그 자체로 정상 응답할 때만 전환합니다. 전환한 뒤에 레코드를 채우면 그 사이가 그대로 장애 시간입니다.
3. 옛 경로를 성급히 죽이지 않는다. 전환은 스위치가 아니라 겹침 구간입니다. 두 존의 값이 같으면 어느 쪽으로 질의가 가도 결과가 같습니다.

옮기는 대상을 먼저 구분하세요

한 번에 옮긴다고 말하는 작업 안에는 보통 세 가지가 섞여 있습니다. 각각 위험도와 순서가 다르므로 나누어 계획하세요.

세 가지를 같은 날에 몰면 문제가 생겼을 때 원인을 찾기 어렵습니다. 각 단계 사이에 최소 하루씩 두고, 앞 단계가 안정된 것을 확인한 뒤 다음으로 넘어가세요.

순서대로 진행하기

1. 현재 존 전체를 받아 적습니다

   현재 네임서버에 있는 레코드를 종류별로 전부 기록합니다. A, AAAA, CNAME, MX, TXT, SRV, NS, CAA까지 빠뜨리지 마세요. 특히 메일 인증(SPF, DKIM, DMARC), 각종 서비스 소유권 확인용 TXT, 서브도메인 CNAME은 평소에 보지 않아 잘 누락됩니다. 가능하면 DNS 콘솔의 존 파일 내보내기 기능을 쓰고, 없으면 dig 로 하나씩 확인해 표로 만듭니다. 기록한 목록에 CAA가 있으면 옮길 곳을 먼저 정해야 합니다. 레토 DNS는 CAA 레코드를 지원하지 않으므로, CAA를 계속 쓸 도메인은 존을 CAA를 지원하는 DNS 호스팅에 두고 레토에는 도메인 등록만 맡기는 구성이 맞습니다.

2. TTL을 낮춥니다

   옮길 레코드의 TTL을 300초로 내립니다. 이 변경이 전 세계에 퍼지려면 낮추기 전의 TTL만큼 기다려야 합니다. 기존 TTL이 86400초였다면 최소 24시간, 안전하게는 48시간 뒤에 다음 단계로 갑니다. 네임서버 자체를 바꿀 계획이면 상위 위임의 TTL은 레지스트리가 정하므로 우리가 낮출 수 없다는 점도 감안하세요.

3. 기관이전을 먼저 끝냅니다

   등록기관을 옮길 계획이라면 이 단계에서 처리합니다. 기관이전 절차에 따라 잠금 해제, 인증코드 발급, 신청과 결제를 진행합니다. 이전이 진행되는 동안에도 네임서버는 기존 값 그대로이므로 서비스에는 영향이 없습니다. 완료까지 최대 7일입니다.

4. 새 네임서버에 존을 복제합니다

   새 DNS 호스팅에 도메인을 추가하고 1단계에서 기록한 레코드를 그대로 넣습니다. 이때 네임서버는 아직 바꾸지 않습니다. 값이 하나라도 다르면 전환 순간에 그 부분만 끊기므로, 넣은 뒤 옛 존과 한 줄씩 대조하세요.

5. 새 네임서버에 직접 질의해 검증합니다

   아직 위임되지 않은 상태에서도 새 네임서버에 직접 물어볼 수 있습니다. 아래 dig 절의 방법으로 모든 레코드가 옛 존과 같은 답을 주는지 확인합니다. 여기서 통과하지 못하면 전환하지 않습니다.

6. 네임서버를 전환합니다

   레토 대시보드에서 네임서버를 새 값으로 바꿉니다. 절차는 네임서버 변경하기를 참고하세요. 레지스트리에는 보통 몇 분 안에 반영되지만, 리졸버 캐시 때문에 사용자에게 완전히 퍼지는 데는 수 시간에서 최대 48시간이 걸립니다.

7. 겹침 구간 동안 두 존을 모두 유지합니다

   전환 뒤 최소 48시간, 권장 일주일 동안 옛 존을 그대로 둡니다. 이 기간에 레코드를 바꿔야 한다면 양쪽에 똑같이 반영하세요. 한쪽만 바꾸면 사용자에 따라 다른 결과를 보게 됩니다.

8. 호스팅(서버 IP)을 옮깁니다

   DNS 전환이 안정된 것을 확인한 뒤 A, AAAA 레코드를 새 서버로 바꿉니다. 새 서버를 먼저 띄워 두고 옛 서버와 동시에 정상 응답하는지 확인한 다음 값을 바꾸면, 문제가 생겨도 TTL 300초 안에 되돌릴 수 있습니다.

9. TTL을 원래대로 올리고 마무리합니다

   모든 것이 안정되면 TTL을 3600초 이상으로 되돌립니다. 그 뒤에 옛 존과 옛 서버를 정리합니다.

dig로 확인하기

전환 전후로 확인해야 할 것은 두 가지입니다. 새 네임서버가 옛 네임서버와 같은 답을 주는가, 그리고 위임이 실제로 바뀌었는가.

새 네임서버에 직접 물어보려면 서버를 지정합니다. 위임 전에도 답을 받을 수 있습니다.

# 새 네임서버에 직접 질의 (위임 전에도 가능)
dig @ns1.new-dns.example A example.co.kr +noall +answer
dig @ns1.new-dns.example MX example.co.kr +noall +answer
dig @ns1.new-dns.example TXT example.co.kr +noall +answer

# 옛 네임서버와 답이 같은지 비교
dig @ns1.old-dns.example A example.co.kr +short
dig @ns1.new-dns.example A example.co.kr +short

위임(레지스트리에 등록된 네임서버)이 바뀌었는지는 상위 서버에 물어봅니다.

# 상위 존이 답하는 위임 정보
dig NS example.co.kr +trace | tail -20

# 일반 리졸버가 지금 무엇을 답하는지, 남은 캐시 시간(TTL)은 얼마인지
dig A example.co.kr @1.1.1.1
dig A example.co.kr @8.8.8.8

+trace 는 루트부터 따라 내려가며 어느 네임서버로 위임되어 있는지 보여 줍니다. 응답의 TTL 값은 그 리졸버가 그 답을 얼마나 더 들고 있을지를 뜻하므로, 값이 줄어들다가 0에 가까워지면 곧 새 값을 다시 조회한다는 의미입니다.

메일에서 특히 조심할 것

웹은 잠깐 끊겨도 사용자가 새로고침하면 됩니다. 메일은 다릅니다. 잘못 반송된 메일은 되돌릴 수 없습니다.

• MX는 절대 비는 순간이 없어야 합니다. 새 존에 MX를 먼저 넣고, 우선순위 값까지 옛 존과 똑같이 맞추세요.
• SPF, DKIM, DMARC TXT를 함께 복제합니다. MX만 옮기고 인증 레코드를 빠뜨리면 수신은 되지만 발신 메일이 스팸함으로 갑니다. 각 레코드의 역할과 값은 SPF, DKIM, DMARC 설정을 참고하세요.
• DKIM 선택자를 확인합니다. 선택자 이름의 CNAME 또는 TXT 레코드는 서브도메인 형태라 목록에서 빠지기 쉽습니다.
• 메일 서버 자체를 옮기는 경우에는 겹침 구간을 만듭니다. 옛 서버와 새 서버가 동시에 같은 도메인의 메일을 받을 수 있는 상태로 두고 MX를 바꾼 뒤, 전파가 끝날 때까지 옛 서버의 수신함도 계속 확인하세요.
• DMARC 정책은 이관 중에 올리지 마세요. 발신 경로가 바뀌는 시기에 정책을 강화하면 정상 메일까지 거부될 수 있습니다.

이관이 끝난 뒤

• TTL을 3600초 이상으로 되돌립니다. 낮은 TTL을 계속 두면 질의량과 지연이 늘어납니다.
• 도메인 잠금을 다시 켜고 자동 연장을 확인합니다.
• 옛 DNS 콘솔의 존을 삭제하기 전에 최종 스냅샷을 남겨 두세요. 나중에 "예전에 이런 TXT가 있었는데"를 확인할 유일한 근거가 됩니다.
• 새 존의 레코드 목록을 사내 문서에 정리해 두면 다음 담당자가 같은 조사를 반복하지 않아도 됩니다. 레코드 종류별 의미는 DNS 레코드 설정에 정리되어 있습니다.