네임서버 변경 버튼을 누른 뒤에는 사이트가 곧바로 새 호스팅으로 연결될 거라고 생각했다.
설정 화면에는 정상적으로 저장됐다는 문구가 떴다. 그런데 도메인을 입력해 보니 이전 사이트가 그대로 나오거나, 어떤 때는 접속 오류가 나타났다. 휴대폰에서는 열리는 것 같은데 컴퓨터에서는 열리지 않는 경우도 있었다.
저장이 제대로 안 된 것 같아 네임서버를 다시 입력할까 고민했지만, 조금 더 기다리고 확인해 보니 설정 실패가 아니라 DNS 정보가 인터넷 환경마다 서로 다른 시점에 갱신되고 있는 상태였다.
네임서버는 도메인의 DNS 기록을 어느 서버에서 관리할지 알려주는 역할을 한다. 새로운 네임서버로 변경하면 이후 DNS 조회는 새 관리 서버를 향하게 되지만, 이미 이전 정보를 저장해 둔 DNS 서버와 기기에서는 한동안 과거 결과가 나올 수 있다.
저장 완료와 전체 반영 완료는 달랐다
도메인 관리 화면에서 ‘변경 완료’라고 표시되는 것은 등록한 네임서버 정보가 접수됐다는 뜻에 가깝다.
그 순간 전 세계의 모든 인터넷 회선과 기기가 동시에 새 정보를 받아 가는 것은 아니다. 인터넷 사업자의 DNS 서버, 공용 DNS, 공유기와 컴퓨터는 이전에 조회한 결과를 일정 시간 저장해 두고 재사용한다.
이 저장 시간을 결정하는 값이 TTL이다.
TTL은 DNS 기록을 캐시에 얼마나 오래 보관할지 정하는 값이다. TTL이 길수록 이전 결과가 오래 남을 수 있고, 그만큼 변경 사항이 사용자에게 나타나는 데 시간이 더 걸릴 수 있다.
그래서 같은 시간에 같은 도메인을 열어도 다음처럼 결과가 다를 수 있다.
- 집 와이파이에서는 이전 사이트가 나옴
- 휴대폰 데이터에서는 새 사이트가 열림
- 한 브라우저에서는 오류가 나지만 다른 브라우저에서는 열림
- 기본 도메인은 열리는데
www주소는 아직 안 열림
처음에는 설정이 불안정하다고 생각했지만, 네임서버와 DNS 기록이 갱신되는 중에는 충분히 나타날 수 있는 차이였다.
기다리기만 하면 되는 상황과 수정해야 하는 상황
네임서버를 바꾼 뒤 사이트가 안 열린다고 무조건 기다리는 것도 맞지는 않는다.
새 DNS 관리 화면에 필요한 기록이 빠져 있다면 아무리 기다려도 사이트가 정상적으로 열리지 않는다.
네임서버를 변경하기 전에는 이전 DNS 업체에 있던 기록을 새 업체에도 옮겨야 한다. 네임서버에는 도메인의 A, CNAME, MX 등 여러 DNS 기록이 저장되기 때문이다.
예를 들어 워드프레스 사이트를 연결하려면 새 DNS 관리 화면에 다음 정보가 필요할 수 있다.
- 기본 도메인을 웹 서버로 보내는 A레코드
www주소를 연결하는 CNAME 또는 A레코드- 이메일을 사용한다면 MX와 관련 TXT 기록
- 도메인 인증에 사용되는 TXT 기록
네임서버만 새 업체로 변경하고 A레코드를 만들지 않았다면 도메인이 워드프레스 서버를 찾을 수 없다.
따라서 확인 기준을 두 가지로 나누는 것이 편했다.
새 DNS에 필요한 기록이 모두 들어 있다
이 경우에는 변경 직후 접속 결과가 다르더라도 일정 시간 기다리며 확인할 수 있다.
새 DNS에 A레코드나 필요한 기록이 없다
이 경우에는 반영 시간이 아니라 설정 누락 문제이므로 새 DNS 관리 화면에서 기록을 먼저 등록해야 한다.
네임서버를 여러 번 바꾸지 않은 이유
변경 직후 사이트가 열리지 않으면 기존 네임서버로 되돌렸다가 다시 새 네임서버를 입력하고 싶어진다.
하지만 반영 중인 상황에서 설정을 반복해서 바꾸면 어느 정보가 현재 조회되고 있는지 더 판단하기 어려워진다. 이전 네임서버와 새 네임서버가 번갈아 등록되면서 확인 시간도 다시 길어질 수 있다.
나는 네임서버 이름의 철자가 정확하고 새 DNS에 필요한 기록이 들어 있는 것을 확인한 뒤에는 추가 변경을 하지 않았다.
그 대신 접속 환경을 바꿔 확인했다.
컴퓨터에서는 기존 화면이 보였지만 휴대폰의 와이파이를 끄고 모바일 데이터로 접속하니 새 사이트가 먼저 나타났다. 이 차이를 보고 서버 자체가 꺼진 것이 아니라 기존 DNS 정보가 일부 환경에 남아 있다고 판단할 수 있었다.
브라우저 새로고침만으로 해결되지 않았던 이유
브라우저에서 새로고침을 누르면 웹페이지 파일은 다시 불러올 수 있다.
하지만 접속 전에 도메인을 어느 서버로 보낼지 결정하는 DNS 정보는 브라우저 외에도 운영체제, 공유기, 통신사 DNS 등에 저장될 수 있다. 따라서 일반 새로고침만 반복해도 이전 서버로 계속 연결될 수 있다.
확인할 때는 다음 방식이 더 구분하기 쉬웠다.
- 시크릿 모드로 접속
- 다른 브라우저에서 접속
- 휴대폰 모바일 데이터로 접속
- 다른 와이파이에서 접속
- 공용 DNS 조회 화면에서 네임서버 확인
Google Public DNS는 도메인의 DNS 호스팅이나 등록기관이 최근 변경된 경우 캐시에 남은 결과가 영향을 줄 수 있다고 설명하며, 별도의 캐시 삭제 기능도 제공한다.
다만 일반 사용자가 캐시를 무조건 지워야 하는 것은 아니다. 서로 다른 네트워크에서 새 네임서버가 확인된다면 반영이 진행 중인지 판단하는 용도로 충분했다.
이전 사이트와 새 사이트가 번갈아 보인 이유
가장 당황스러운 상황은 새 워드프레스와 이전 사이트가 번갈아 나타나는 경우였다.
이 현상은 방문할 때마다 사이트가 실제로 이동하는 것이 아니라, 사용한 DNS 해석 경로에 따라 이전 정보와 새 정보 중 하나가 반환되면서 생길 수 있다.
예를 들어 집의 인터넷 사업자 DNS에는 이전 네임서버 정보가 남아 있고, 휴대폰 통신사의 DNS에는 새 정보가 반영됐다면 기기와 연결 방식에 따라 서로 다른 사이트가 나온다.
이때 워드프레스 설정이나 글을 반복해서 수정해도 해결되지 않는다. 문제는 사이트 본문이 아니라 도메인이 어느 DNS 서버와 웹 서버를 바라보고 있는지에 있기 때문이다.
네임서버는 바뀌었는데 사이트가 계속 안 열릴 때
시간이 지난 뒤에도 모든 환경에서 사이트가 열리지 않는다면 단순 전파 지연으로만 보기 어렵다.
나는 다음 내용을 다시 확인했다.
네임서버 철자
호스팅 업체가 안내한 네임서버를 복사하면서 숫자나 도메인 일부가 빠지지 않았는지 확인한다.
새 DNS의 A레코드
기본 도메인이 실제 워드프레스 호스팅 서버 IP를 향하는지 확인한다.
호스팅의 도메인 등록
호스팅 관리 화면에도 해당 도메인이 연결 도메인이나 대표 도메인으로 추가돼 있어야 할 수 있다.
www 기록
기본 주소와 www 주소는 별도 기록이 필요할 수 있다.
DNSSEC 상태
기존 DNSSEC 설정이 새 DNS 구성과 맞지 않으면 조회 오류가 생길 수 있으므로, DNSSEC을 사용했던 도메인은 새 제공업체의 이전 안내를 확인해야 한다.
SSL 인증서
DNS 연결은 됐지만 HTTPS 인증서가 아직 발급되지 않아 보안 오류가 나타나는 경우도 있다.
이 가운데 한 항목이라도 빠져 있으면 기다리는 시간과 상관없이 접속 문제가 계속될 수 있다.
실제 반영 시간을 단정하기 어려운 이유
네임서버 변경은 “정확히 몇 시간이면 완료된다”고 한 가지 숫자로 말하기 어렵다.
도메인 종류, 등록기관의 갱신 처리, 기존 TTL, 사용자가 이용하는 DNS 서버와 캐시 상태가 모두 다르기 때문이다. DNS 변경은 TTL에 따라 캐시가 갱신되며, TTL이 길면 변경 사항이 최종 사용자에게 도달하는 시간이 더 늦어질 수 있다.
그래서 나는 특정 시간이 지나기만 기다리기보다 아래 두 상태를 구분했다.
새 네임서버와 DNS 기록이 정확하지만 일부 네트워크에만 이전 정보가 보임
새 네임서버는 등록됐지만 새 DNS에 필요한 웹사이트 기록이 없음
첫 번째는 기다릴 수 있는 상태이고, 두 번째는 설정을 추가해야 하는 상태다.
변경 전에 했으면 좋았을 준비
네임서버를 변경하고 나서야 이전 DNS 기록을 미리 복사해 둘 걸 알았다.
네임서버를 옮길 예정이라면 변경 전에 기존 DNS 관리 화면을 캡처해 두는 편이 좋다.
특히 웹사이트뿐 아니라 도메인 이메일을 사용한다면 MX, TXT와 인증 관련 기록을 놓치지 않아야 한다. 웹사이트는 정상적으로 열려도 이메일만 수신되지 않는 문제가 생길 수 있기 때문이다.
또한 계획된 이전이라면 DNS 기록의 TTL을 미리 낮춰 캐시 갱신 시간을 줄이는 방법이 있다. Google은 사이트 이전 전에 DNS TTL을 낮추면 인터넷 사업자의 캐시가 더 빨리 새 설정을 확인하는 데 도움이 될 수 있다고 설명한다.
단, 변경 직전에 TTL을 낮춰도 이전 값이 이미 캐시돼 있다면 즉시 효과가 나타나는 것은 아니다. 미리 준비할 때 의미가 있다.
네임서버 변경 후 내가 판단한 기준
사이트가 당장 열리지 않는다는 사실만으로 실패라고 판단하지 않았다.
새 DNS 관리 화면에 필요한 기록이 있고, 일부 외부 네트워크에서 새 사이트가 보이기 시작했다면 설정이 전달되는 중이라고 봤다.
반대로 어느 환경에서도 새 사이트가 보이지 않고 DNS 조회 결과에도 웹 서버 기록이 없다면 기다리는 대신 설정 누락을 확인했다.
결국 중요한 것은 ‘얼마나 오래 기다렸는지’보다 새 네임서버가 정확한 DNS 답변을 제공하고 있는지였다.
네임서버 변경 뒤 바로 사이트가 열리지 않았던 이유는 저장이 실패해서가 아니라, 기존 DNS 정보가 여러 위치의 캐시에 남아 있었기 때문이다. 다만 새 DNS에 A레코드와 필요한 기록을 먼저 준비하지 않았다면 이것은 반영 지연이 아니라 설정 문제다.
두 상황을 구분하고 나니 사이트가 안 열린다고 네임서버를 계속 변경하는 실수를 피할 수 있었다.
답글 남기기