모두
모두콘텐츠
서버 이전을 도와달라는 연락을 받으면 저는 먼저 DNS 설정부터 확인합니다. 새 서버가 멀쩡한데도 일부 방문자만 예전 화면을 보거나 메일이 끊기는 경우가 꽤 있습니다. DNS레코드 하는법 자체는 어렵지 않습니다. 어느 관리 화면에서 바꿔야 하는지, 기존 기록 중 무엇을 남겨야 하는지가 더 중요합니다.
레코드를 바꾸기 전에 관리 위치부터 확인한다
도메인을 산 업체와 DNS를 운영하는 업체는 다를 수 있습니다. 도메인 등록 화면에 들어가 레코드를 수정했는데 아무 변화가 없다면, 실제로는 다른 업체의 네임서버를 사용 중일 가능성이 큽니다. 먼저 등록된 네임서버를 확인하고, 그 네임서버가 관리하는 DNS 영역에서 작업해야 합니다.
수정 전에는 현재 레코드 전체를 내보내거나 화면을 저장해 둡니다. 웹 연결만 보고 A 레코드 하나를 새 값으로 바꿨다가 메일용 MX와 TXT 기록을 지우는 사고가 흔합니다. 호스트 이름, 종류, 값, 우선순위, TTL을 함께 기록해야 되돌릴 때도 빠릅니다.
A와 CNAME은 연결할 대상을 보고 고른다
A 레코드는 이름을 IPv4 주소에 연결합니다. 관리 화면에서 루트 도메인을 뜻하는 이름으로 @를 쓰는 경우가 많습니다. 예를 들어 새 서버의 IPv4 주소가 192.0.2.10이라면, A 레코드의 이름을 @로 두고 값을 그 주소로 입력하는 식입니다. 이 숫자는 설명용 주소이므로 실제 설정에는 서버 업체가 제공한 주소를 써야 합니다. IPv6로 접속하게 하려면 AAAA 레코드에도 서버의 IPv6 주소를 넣습니다.
CNAME은 한 이름을 다른 이름으로 가리키는 별칭입니다. 블로그나 쇼핑몰처럼 별도 호스트를 외부 서비스에 연결할 때 자주 씁니다. 다만 같은 이름에 CNAME과 A, MX, TXT 같은 다른 레코드를 함께 둘 수는 없습니다. 루트 도메인에는 CNAME을 허용하지 않는 DNS 서비스도 있습니다. 외부 서비스가 루트 연결을 요구한다면 해당 DNS 업체가 별칭 처리 기능을 제공하는지 먼저 확인해야 합니다.
입력 칸의 형식도 확인할 필요가 있습니다. 어떤 관리 화면은 호스트 이름만 받지만, 어떤 곳은 전체 이름을 받습니다. 전체 이름을 넣었는데 업체가 도메인 이름을 다시 붙이면 의도하지 않은 이름이 만들어집니다. 저장 뒤 실제로 생성된 레코드 이름을 다시 읽어보는 이유입니다.
메일과 인증 기록은 웹 이전과 별개로 지킨다
MX 레코드는 메일을 받을 서버를 지정합니다. 값에는 메일 서비스가 안내한 서버 이름을 넣고, 우선순위 숫자가 작은 서버가 먼저 선택되도록 설정합니다. MX를 웹서버의 IP 주소로 적거나, 서버 이전과 관계없는 기존 MX를 지우면 수신 장애가 납니다.
TXT 레코드에는 발신 메일 인증을 위한 SPF, 도메인 소유 확인값 등이 들어갈 수 있습니다. SPF는 보통 한 도메인에 여러 개를 따로 만들지 않고 기존 정책에 필요한 발신 서비스를 반영합니다. DKIM과 DMARC도 사용 중이라면 함께 보존해야 합니다. 웹사이트만 옮기는 작업이라면 메일 레코드는 건드리지 않는 편이 안전합니다.
새 서버에서 인증서를 발급할 계획이라면 DNS가 새 서버를 가리키는지, 인증에 필요한 레코드가 있는지도 확인합니다. DNS가 맞아도 새 서버의 방화벽이나 웹서버 설정 때문에 접속이 실패할 수 있으니 두 문제를 구분해서 봐야 합니다.
전환 시간은 TTL과 검증 순서로 관리한다
TTL은 조회한 DNS 결과를 일정 시간 저장하도록 안내하는 값입니다. 평소 TTL이 3600초라면 전환 하루 전쯤 300초로 낮추는 방법을 씁니다. 기존 조회 결과는 예전 TTL이 끝날 때까지 남을 수 있어서, 바꾸기 직전에 TTL만 낮춰도 즉시 전환되지는 않습니다. DNS 업체의 최소 TTL 제한도 확인해야 합니다.
실제 이전에서는 새 서버에 파일과 데이터베이스를 먼저 복원하고, 내부 점검으로 화면과 로그인, 업로드 기능을 확인합니다. 그다음 DNS를 수정합니다. 데이터가 계속 바뀌는 사이트라면 최종 동기화나 쓰기 중단 시점도 정해야 합니다. DNS만 먼저 돌리면 방문자가 준비되지 않은 서버로 들어갑니다.
- 저장 직후에는 권한 있는 DNS 서버에서 새 값이 보이는지 확인합니다.
- 이어서 서로 다른 네트워크에서 웹 접속과 메일 송수신을 점검합니다.
- 예전 서버는 바로 끄지 말고, 기존 TTL과 실제 접속 기록을 보고 유지 시간을 정합니다.
- 문제가 생기면 저장해 둔 레코드와 비교해 변경값을 되돌리고 서버 로그를 확인합니다.
레코드를 저장했다고 모든 방문자가 같은 순간에 새 서버로 오는 것은 아닙니다. 각 DNS 서버와 이용자 환경에 남아 있는 조회 결과가 만료되는 시간이 다릅니다. 그래서 저는 서버 이전을 할 때 DNS 입력보다 기존 기록 보관, 새 서버 사전 점검, 전환 뒤 확인에 시간을 더 씁니다. 이 순서만 지켜도 값 한 줄을 잘못 바꿔 생기는 장애를 상당수 피할 수 있습니다.
