도메인과 DNS, 웹사이트 연결이 안 될 때 보는 순서

등록과 이름 해석과 웹 응답을 나눕니다

도메인을 샀는데 사이트가 열리지 않는다면 등록 상태, DNS 이름 해석, 웹 서버 응답을 나누어 점검합니다. 도메인 등록기관은 이름의 등록을 관리하고, 네임서버는 그 이름의 DNS 정보를 응답하며, 호스팅은 실제 사이트를 제공합니다. 같은 업체에서 모두 제공해도 역할은 다릅니다. 1단계는 도메인이 정상 등록되어 있는지와 어느 네임서버가 권한을 갖는지 확인하는 것입니다. 현재 권한이 없는 DNS 관리 화면에서 레코드를 바꾸면 실제 응답에는 반영되지 않을 수 있습니다. 따라서 관리 화면이 편하다는 이유만으로 수정을 반복하지 말고 어떤 네임서버가 응답하는지부터 추적해야 문제 구간을 줄일 수 있습니다.

웹과 메일의 레코드를 구분해 보존합니다

2단계에서는 웹 연결에 사용하는 레코드와 메일 및 소유권 확인용 레코드를 나눕니다. A와 AAAA는 주소 연결에, CNAME은 다른 이름을 가리키는 데 사용됩니다. MX와 여러 TXT 항목은 메일 흐름과 인증에 관여할 수 있습니다. 호스팅을 옮긴다고 기존 레코드를 모두 지우면 사이트는 열려도 메일이 멈출 수 있습니다. 변경 전 현재 값을 내보내거나 기록하고, 실제로 바꿔야 하는 항목만 수정합니다. 프록시를 사용하는 경우 DNS에서 보이는 주소와 원본 서버 주소가 다를 수 있으므로 응답 주소만 보고 잘못 연결되었다고 단정하지 않습니다. 해당 서비스의 프록시 설정과 원본 연결 상태를 함께 확인합니다.

캐시 시간을 전환 보장으로 해석하지 않습니다

TTL 설명용 가정으로 레코드의 캐시 유지 시간을 300초로 설정했다고 놓겠습니다. 300÷60=5분이지만 이것이 변경 버튼을 누른 뒤 전 세계가 정확히 5분 만에 새 주소를 쓰게 된다는 보장은 아닙니다. 기존 캐시의 만료 시점, 재귀 DNS의 동작, 클라이언트 캐시와 다른 레코드의 조건이 영향을 줄 수 있습니다. 이 계산의 최종값은 설정한 TTL의 분 단위 환산일 뿐 전체 전환 시간은 아닙니다. 독자는 권한 있는 네임서버 응답과 실제 사용 중인 네트워크의 응답을 나누어 비교합니다. 변경 직후 결과가 다를 때 같은 설정을 계속 덮어쓰기보다 어느 계층에 이전 값이 남았는지 확인하는 것이 다음 행동입니다.

DNS가 맞으면 인증서와 서버 설정으로 넘어갑니다

3단계에서 이름이 기대한 대상으로 해석된다면 HTTPS 인증서, 웹 서버의 호스트 설정, 리디렉션과 방화벽을 점검합니다. DNS가 정상이어도 서버가 해당 도메인을 처리하도록 구성되지 않았다면 기본 페이지나 인증서 오류가 나타날 수 있습니다. 대표 도메인과 하위 도메인, www 유무를 각각 시험합니다. 외부에서 접속되는지와 서버 내부에서만 되는지도 구분합니다. 문제 해결 기록에는 수정 시각과 이전 값, 새 값, 관찰한 응답을 남깁니다. 여러 항목을 동시에 바꾸면 무엇이 원인이었는지 알기 어려우므로 한 계층씩 검증합니다. 최종적으로 웹 페이지뿐 아니라 메일과 소유권 확인 기능도 다시 시험해야 도메인 연결이 완성됩니다.

웹호스팅 실행 전 점검표

• 권한 있는 네임서버를 확인했다
• 메일과 인증 레코드를 보존했다
• TTL과 전체 전환 시간을 구분했다
• HTTPS와 대표 주소를 각각 시험했다