원활한 DNS 마이그레이션 방법

새 집으로 이사하면 전입신고부터 해야 합니다. 전입신고가 아주 복잡한 일은 아니지만 신고를 하지 않으면 중요한 우편물이 예전 집으로 발송될 수 있고, 보내는 사람과 받는 사람 모두 우편물을 받지 못했다는 사실조차 모르고 넘어갈 수도 있습니다.

DNS 마이그레이션도 비슷합니다. 제대로 하지 않으면 사용자가 웹 사이트에 액세스할 수 없고, 이메일에 장애가 발생하여 클라이언트와의 통신 문제가 생길 수 있으며, 통합이 중단되는 등의 문제도 생길 수 있습니다. 고객이 정확한 주소로 기업에 문의를 하지 못하면서 다양한 부정적 결과가 초래될 수 있습니다.

DNS(도메인 이름 시스템)는 인터넷의 전화번호부 또는 디렉토리와 같습니다. 사용자는 숫자 문자열(이 경우 184.85.75.7) 대신 ibm.com과 같이 기억하기 쉬운 도메인 이름을 사용하여 웹사이트에 접속할 수 있습니다.

그러나 DNS는 단순한 번역 이상의 역할을 하며 관리형 DNS 공급자의 서비스 품질은 성능, 안정성, 지연 시간, 보안, 개인 정보 보호 등에 영향을 미칠 수 있습니다. 공급자의 DNS 서비스가 기대나 요건을 충족하지 못하면 기업은 새로운 공급자를 찾을 수 있습니다. 이 경우 DNS 마이그레이션을 계획해야 합니다.

조직이 도메인의 DNS 레코드와 설정을 한 업체에서 다른 업체에게로 이전하는 DNS 마이그레이션은 그렇게 힘든 활동이 아닐 때가 많습니다. 그러나 제대로 실시하지 않으면 위험하고 앞으로 골칫거리가 생길 수 있습니다. DNS 마이그레이션 오류는 서버 다운타임, 네트워크 취약성을 유발할 수 있으며 이를 예방하는 방법은 다음과 같습니다.

DNS 조회 프로세스에 대한 자세한 내용은 여기에서 확인하세요.

간단하게 답하자면, 모든 DNS 제공업체가 동일한 서비스 또는 서비스 품질을 제공하는 것은 아닙니다. 성능이 핵심 기능이지만 유일한 관심사는 아닙니다.

예를 들어 DNS 제공자는 DNS 스푸핑을 방지하고, 알려졌거나 의심되는 악성 도메인에 대한 액세스를 차단하는 보안 기능을 제공할 수도 있습니다. 모니터링과 로깅 기능도 공급업체마다 다릅니다. 일부 DNS 공급자는 장애 조치를 위한 로드 밸런싱을 제공하며, 이 경우 여러 중복 웹 서버가 DNS 쿼리를 처리하여 한 서버에 과부하가 걸리지 않도록 하거나 콘텐츠를 사용자에게 더 가깝게 캐시하는 데 도움이 되는 글로벌 콘텐츠 전송 네트워크(CDN)를 제공합니다. 물론 비용도 DNS 제공업체 변경에 영향을 미칠 수 있습니다.

비즈니스 리더는 비즈니스 요구 사항에 가장 적합한 서비스를 선택해야 합니다. 요구 사항은 진화하는 경우가 많으며 DNS 요구 사항도 마찬가지입니다. 현재 이용하는 DNS 공급자의 서비스가 더 이상 비즈니스 요구 사항을 충족하지 못하는 경우, 비즈니스 리더는 DNS 레코드와 관리를 새 공급자로 마이그레이션하는 것을 고려할 수 있습니다.

일반적으로 많은 기업이 마이그레이션을 미루는 주된 이유는 이것이 너무 어려운 작업이고 다운타임이 생길 것 같기 때문입니다. 이는 타당한 걱정이지만 신중하게 계획을 세우고 실행하면 위험을 완화할 수 있습니다.

DNS 마이그레이션의 첫 단계는 마이그레이션하는 이유를 기술하는 것입니다. 비즈니스가 현재 누리지 못하고 있는 혜택은 무엇인가요? 해결해야 할 문제는 무엇인가요? 예를 들어 소규모 인터넷 서비스 제공업체(ISP)의 DNS를 사용하는 기업이라면 해결 시간이 세 자릿수 밀리초로 늘어난 것을 보고 속도 향상을 우선 순위로 삼을 수 있습니다.

경영진이 마이그레이션이 필요한 이유를 파악한 다음에는 IT 팀이 다양한 업체를 비교해서 적절한 기능, 서비스 및 비용의 조합을 찾습니다. 업체마다 마이그레이션 온보딩에 대한 세부 사항은 다르지만 일반적인 가이드라인도 있습니다.

마이그레이션 팀에서 공급자를 선정하고 나면, 기존 DNS 업체에서 모든 레코드와 관련 정보를 수집해야 합니다. 이때 수집할 레코드는 다음과 같습니다.

이러한 레코드는 도메인 이름에서 IP 주소로의 직접 변환을 제공합니다. A 레코드는 IPv4 주소에 매핑되고 AAAA 레코드는 IPv6 주소에 매핑됩니다. 훨씬 많은 수의 고유 IP 주소를 제공하며 몇 가지 기본적인 보안 및 속도 향상 기능이 들어있는 IPv6가 점점 더 보편화되고 있습니다.

정식 이름 레코드 또는 CNAME 레코드는 별칭 도메인을 정식 도메인으로 연결합니다. 즉, 이 유형의 레코드는 하위 도메인을 도메인 A 또는 AAAA 레코드에 연결하는 데 사용됩니다.

위임 이름 레코드 또는 DNAME 레코드는 하나의 레코드로 여러 하위 도메인을 리디렉션하고 다른 도메인을 가리키는 데 사용됩니다.

인증 기관 권한 부여 레코드 또는 CAA 레코드를 사용하면 도메인 소유자가 도메인에 대한 인증서를 발급할 수 있는 인증 기관(CA)을 지정할 수 있습니다. CA는 웹사이트의 ID를 검증하고 디지털 인증서를 발급하여 웹사이트를 암호화 키에 연결하는 조직입니다.

텍스트 또는 TXT 레코드는 도메인 및 하위 도메인과 관련된 텍스트 정보를 저장합니다. 텍스트 레코드를 사용하면 SPF(발신자 정책 프레임워크) 레코드와 이메일 확인 레코드를 보관할 수 있습니다. TXT 레코드에 저장된 DKIM 및 DMARC 레코드는 이메일 서버가 메일이 신뢰할 수 있는 출처에서 온 것인지 확인하는 데 도움이 됩니다.

권한 시작 또는 SOA 레코드는 도메인에 대한 중요한 관리 정보를 저장합니다. 이 정보에는 도메인 관리자의 이메일 주소, 도메인 업데이트 정보 및 서버가 해당 정보를 새로 고쳐야 하는 시기가 포함될 수 있습니다.

이름서버, 즉 NS 레코드는 도메인의 권한 있는 이름서버 역할을 하는 DNS 서버를 보여줍니다. 권한 있는 이름서버에는 특정 도메인과 해당 IP 주소에 대한 최종 정보가 포함되어 있습니다. NS 레코드는 도메인이 보유한 다양한 레코드를 모두 가리킵니다. NS 레코드가 없으면 사용자는 웹사이트에 액세스할 수 없습니다.

DNS 영역은 DNS 네임스페이스 안에 있는 구역입니다. ibm.com을 예로 들면 research.ibm.com에 별도의 DNS 영역이 있습니다. 이러한 하위 도메인은 개별 관리 및 모니터링의 이점을 누릴 수 있을 만큼 충분히 큽니다. DNS 영역 파일에는 SOA 레코드, A 및 AAAA 레코드 등 앞서 언급한 파일 형식이 대부분 포함됩니다.

다른 DNS 레코드 유형과 자세한 정보를 이 가이드에서 읽어보세요.

일부 공급자는 DNS 레코드 수집, 내보내기, 가져오기 자동화 기능을 제공하지만 레코드가 누락되면 심각한 문제가 발생할 수 있으므로 수동 백업을 하는 것이 현명한 경우가 많습니다. 이렇게 백업한 파일 사본은 안전한 곳에 보관하는 것이 좋습니다.

이 프로세스에서는 DNSSEC, 즉 도메인 이름 시스템 보안 확장 문제가 생길 수 있습니다. DNSSEC는 서명 확인을 사용하여 정확성을 보장하고 DNS 스푸핑을 비롯한 공격을 방지하는 데 도움이 되는 귀중한 보안 보호 제품군을 제공합니다.

그러나 DNS 마이그레이션 프로세스에 다양한 서명 알고리즘이 도입되면서 연결이 끊어지고 중단이 발생할 수 있습니다. 이 문제에는 다양한 해결책이 있습니다. 해당 보안을 유지하는 DNSSEC 전용 마이그레이션 도구를 제공하는 업체도 있고, 마이그레이션하기 전에 DNSSEC를 사용하지 않도록 설정해 두고, 마이그레이션이 완료되면 다시 사용하도록 설정하는 업체도 있습니다.

또 다른 권장 방법은 TTL(수명) 값을 낮추는 것입니다. 이는 재귀 확인자 또는 DNS 쿼리에서의 첫 번째 정거장인 재귀 서버가 최근에 방문한 웹 사이트의 IP 주소를 캐시에 저장하는 시간입니다. 캐싱을 사용하면 IP 주소를 다시 조회할 필요가 없으며 연결 속도를 높이는 데 도움이 됩니다.

가령 TTL이 24시간으로 설정되어 있다면, 사용자가 해당 기간에 DNS 서버를 마이그레이션한 사이트를 방문하려고 할 때 브라우저가 이전 IP 주소로 이동하려고 하면서 오류가 발생할 수 있습니다. TTL을 몇 분 길이 정도로 아주 낮게 설정하면 이 문제를 방지하는 데 도움이 될 수 있습니다.

마이그레이션은 한 번에 끝내지 말고 단계적으로 수행하는 것이 좋습니다. 스테이징을 사용하면 마이그레이션 팀이 작업 전체에서 무엇이 잘못되었는지 힘들게 파악하지 않고, 기능 각각의 오류를 개별적으로 확인할 수 있습니다.

팀이 기존 DNS 문서를 내보내고 새 DNS 공급자의 서비스와 함께 가져오고 나면, 문서가 손실되지 않았는지 확인해야 합니다. [dig] 같은 도구가 검증에 도움이 될 수 있습니다. [Dig] 또는 도메인 정보 그루퍼는 사용자가 기본 IP 주소에서 TXT, SOA 같은 DNS 문서를 확인하기 위한 명령줄 도구입니다. Nslookup은 [dig]보다 간단하지만 결과가 덜 자세하게 나오는 다른 명령줄 도구입니다.

이제 팀은 웹 호스팅, 이메일 서비스, API 및 기타 타사 서비스를 단계별로 이전할 수 있습니다. 담당자를 정해두고 마이그레이션 진행 과정에서 각 단계를 확인하며 문제를 해결하게 하는 것이 좋습니다. DNSSEC 활성화와 같은 고급 설정을 구성합니다. 테스트 서버에서 모든 테스트를 마치면 등록 기관과 함께 정보 업데이트를 진행할 수 있습니다.

DNS에 IBM® NS1 CONNECT를 사용하고 도메인 등록에는 GoDaddy를 사용하는 등, 하나의 조직에서 도메인 등록 기관과 DNS 업체를 따로 이용하고 있다면 도메인 등록 서비스에 로그인하여 네임 서버 레코드를 업데이트해야 합니다. 같은 업체에서 DNS 및 레지스트리 서비스를 모두 이용 중이면 이 작업은 자동으로 처리되는 경우가 많습니다. 호스팅 업체도 변경하지 않는다면 웹 호스트 자체에서 아무것도 변경할 필요가 없습니다. 

중요한 점은 아직 이전 DNS를 삭제하지 마세요. 이는 DNS 전파 때문입니다. DNS 레코드는 인터넷 전체에서 즉시 변경되지 않습니다. 흩어져 있는 도메인 서버가 레코드를 검색하고 업데이트하는 데 시간이 걸리기 때문입니다. 팀은 WhatsMyDNS.net 같은 온라인 도구를 사용해서 레코드 상태를 주기적으로 확인할 수 있습니다. 보통 하루나 이틀이면 충분하지만, 해당 도메인 서버가 레코드를 업데이트하는 동안에는 이전 DNS 서비스와 새 DNS 서비스를 모두 실행해야 사용자가 불편을 겪지 않습니다.

전파가 완료되면 마이그레이션이 완료되었다고 볼 수 있습니다. 이제 다음과 같은 가벼운 마무리 작업만 남았습니다.

TTL을 정상으로 복원: 사용자에게 캐싱을 사용하도록 설정하기 위해 TTL을 최대 24시간 또는 이전으로 다시 늘립니다.

내부 문서 업데이트: 혼란이 생기지 않도록 조직 레코드에서 DNS 정보(계정 번호, 청구 주기 등)를 업데이트합니다.

모니터링: 마이그레이션 후 성능과 기타 지표를 검토합니다. IT 팀은 DNS 로그에서 오류나 시간 초과를 검토하고, 새로운 응답 시간을 추적하고, 다운타임에 대한 알림을 설정하고, 정기적으로 전파 여부를 확인할 수 있습니다. DNS 업체가 내부 모니터링 툴을 보유한 경우가 많으며 타사 도구도 사용할 수 있습니다.

여기에서 관리형 DNS 서비스에 대해 자세히 알아보세요.