모두
모두콘텐츠
얼마 전 사이트가 열리지 않는다는 연락을 받고 서버부터 확인했는데, 서버는 멀쩡했습니다. 도메인 갱신이 빠져 접속이 끊긴 경우였죠. 이런 일이 생각보다 많습니다. 도메인확인은 단순히 이름이 등록돼 있는지 보는 작업이 아닙니다. 누가 관리하는지, 이름이 어느 서버를 가리키는지, 접속할 때 인증서까지 맞는지를 차례로 봐야 원인을 빨리 찾을 수 있습니다.
먼저 등록 상태와 관리 권한을 확인합니다
도메인이 갑자기 안 열리면 등록대행업체의 관리자 화면에서 만료일과 갱신 상태를 먼저 봅니다. 자동 갱신을 켜 두었더라도 결제 카드가 만료됐거나 결제가 실패하면 갱신이 되지 않을 수 있습니다. 운영 중인 도메인이라면 만료 30일 전부터 알림을 받고, 결제 수단도 함께 확인하는 편이 안전합니다.
그다음에는 실제로 관리자 계정에 들어가 DNS 설정과 네임서버를 바꿀 권한이 있는지 확인합니다. 외주 제작사가 도메인을 대신 등록한 사이트에서 자주 막히는 부분입니다. 사이트를 운영하는 사람이 서버 접속 권한은 갖고 있는데 도메인 관리 권한은 없는 식이죠. 이런 상태에서는 서버를 새로 마련해도 이전 작업을 끝낼 수 없습니다.
등록 정보 조회 화면에 소유자 이름이 보이지 않아도 곧바로 문제라고 판단할 필요는 없습니다. 개인정보 보호 설정 때문에 가려질 수 있습니다. 더 중요한 증거는 등록대행업체 계정에서 갱신과 네임서버 변경이 가능한지, 도메인 관련 안내 메일을 받을 수 있는지입니다. 회사 사이트라면 담당자 개인 메일에만 갱신 알림이 가지 않도록 운영용 연락처도 확인합니다.
네임서버와 DNS 기록은 따로 봅니다
네임서버는 도메인의 DNS 기록을 어디에서 관리하는지 알려줍니다. 실제 접속 주소는 그곳에 저장된 A 또는 AAAA 기록을 통해 결정됩니다. 그래서 등록대행업체 화면에서 새 서버 주소를 입력했더라도, 도메인이 다른 업체의 네임서버를 사용 중이면 접속 결과가 바뀌지 않을 수 있습니다. 먼저 현재 지정된 네임서버를 확인하고, 그 네임서버가 관리하는 기록을 봐야 합니다.
웹 접속이라면 A 기록은 IPv4, AAAA 기록은 IPv6 주소를 가리킵니다. 별칭을 쓰는 경우에는 CNAME이 최종적으로 어디를 가리키는지도 확인합니다. 새 서버로 옮길 때 A 기록만 고쳤는데 오래된 AAAA 기록이 남아 있으면, IPv6로 접속하는 이용자에게만 이전 서버가 보일 수 있습니다. 일부 이용자에게만 장애가 나타날 때 확인할 만한 지점입니다.
메일은 웹과 별개입니다. MX 기록이 메일을 받는 서버를 지정하고, TXT 기록에는 발신 인증에 쓰는 SPF 같은 설정이 들어갈 수 있습니다. 웹사이트 이전 중 네임서버 전체를 바꾸면 메일 기록까지 함께 옮겨야 합니다. 이전 화면에서 웹 접속만 확인하고 작업을 끝냈다가 메일 수신이 끊기는 사고가 여기서 납니다.
변경 직후에는 캐시 시간을 계산합니다
DNS 기록에는 TTL이라는 캐시 유지 시간이 있습니다. 예를 들어 TTL이 3600초라면 조회 결과가 최대 1시간가량 재사용될 수 있습니다. 값을 300초로 낮추면 이후 변경에 빠르게 반응하도록 준비할 수 있지만, 변경 직전에 낮춘다고 이미 저장된 오래된 값이 즉시 사라지지는 않습니다. 서버 이전을 예정했다면 기존 TTL이 지나갈 시간을 두고 미리 낮추는 이유입니다.
변경 후에는 내 컴퓨터 한 곳에서만 확인하지 않습니다. 다른 네트워크에서도 새 서버가 열리는지 보고, 가능하면 DNS 조회 도구로 현재 네임서버가 돌려주는 값과 일반 DNS 서버가 돌려주는 값을 나눠 확인합니다. 현재 네임서버는 새 주소를 주는데 일부 환경에서 옛 주소가 나온다면 캐시를 의심할 수 있습니다. 반대로 현재 네임서버 자체가 옛 주소를 준다면 기록을 수정한 위치부터 다시 봐야 합니다.
이전할 때는 기존 서버를 바로 지우지 않는 편이 좋습니다. 캐시가 남은 이용자는 한동안 이전 서버로 들어올 수 있기 때문입니다. 특히 주문이나 게시글을 받는 사이트라면 두 서버에 데이터가 갈라지지 않도록 쓰기 작업을 제한하거나 동기화 방안을 먼저 마련해야 합니다. 접속 화면이 뜨는지만 보고 이전을 끝내면 데이터 문제가 뒤늦게 드러납니다.
접속이 된다면 인증서와 응답까지 확인합니다
DNS가 새 서버를 가리켜도 브라우저에 보안 경고가 뜰 수 있습니다. 이때는 SSL 인증서의 유효 기간과 인증서에 포함된 도메인 이름을 확인합니다. 서버에 인증서가 설치돼 있어도 지금 접속한 이름이 인증서에 빠져 있으면 경고가 납니다. 대표 주소와 별칭 주소를 함께 운영한다면 각각 접속해 보는 게 정확합니다.
화면이 정상으로 보여도 새 서버가 응답한 것인지 확인해야 합니다. 이전 서버와 새 서버의 접속 로그에서 요청 시각을 비교하면 구분이 쉽습니다. 오류가 난다면 순서는 단순합니다. 등록과 갱신 상태, 네임서버, DNS 기록, 서버의 웹 서비스, 인증서 순으로 좁혀 갑니다. 서버 사양을 올리기 전에 이 순서만 지켜도 불필요한 작업을 꽤 줄일 수 있습니다.
저는 도메인 이전 작업을 할 때 만료일, 관리자 계정, 네임서버, 웹과 메일 기록, 인증서 만료일을 한 장에 적어 둡니다. 장애가 났을 때 필요한 건 더 비싼 서버보다 지금 어떤 설정이 실제로 적용돼 있는지 확인할 수 있는 기록인 경우가 많았습니다.
