여러 홈페이지를 운영하다 보니 같은 사이트에도 Pages 주소, 대표 주소, www 주소, 현장별 한글 주소가 함께 남았다. 어느 주소가 무엇을 가리키는지 묻는 일이 반복됐다.

검색 서비스의 소유권 확인에서는 도메인 문자열이 중복된 TXT 레코드가 대화에 등장했다. 그 기록이 모든 실패의 원인을 증명하지는 않는다. 다만 내가 더 이상 화면의 이름만 보고 연결이 끝났다고 판단하지 않게 된 계기였다.

내가 주소를 맡기는 입장에서

내가 광고에 넣은 주소와 방문자가 실제로 보는 주소는 같아야 한다. 주소가 맞더라도 다른 현장이나 오래된 화면으로 연결되면 고객의 신뢰가 먼저 손상된다. 그래서 나는 주소의 이름보다 방문자가 도착한 결과를 확인한다.

하나의 연결을 다섯 질문으로 나눈다

  1. 등록기관의 이름서버가 의도한 DNS 운영자를 가리키는가?
  2. DNS 레코드의 이름과 대상은 각각 정확한가?
  3. Pages 프로젝트의 Custom domains에 그 호스트가 등록돼 있는가?
  4. HTTPS 인증서 상태는 준비됐는가?
  5. 접속 후 최종 주소와 canonical은 같은 대표 주소 정책을 따르는가?

CNAME과 사이트 등록을 함께 확인한다

Pages에서는 DNS 대상만 적는 것과 사용자 도메인을 프로젝트에 연결하는 것을 구별해야 한다. 공식 문서는 프로젝트에 연결하지 않은 수동 CNAME이 522로 이어질 수 있다고 설명한다. 루트 도메인과 서브도메인의 연결 조건도 같다고 가정하지 않는다.

한글 주소를 비교할 때

사람이 보는 한글 이름과 DNS에서 비교하는 ASCII 이름을 함께 적는다. 다른 주소처럼 보인다고 두 사이트로 세거나, 같은 한글 이름이라고 세부 호스트까지 같다고 판단하지 않는다. 국제화 도메인 자체를 피할 이유는 없지만, 운영 문서에는 비교 가능한 형태가 필요하다.

코드와 구현 살펴보기

자기 소유 주소 변수를 사용하는 읽기 전용 예시

Resolve-DnsName $siteAlias -Type CNAME
Resolve-DnsName $siteHost -Type TXT
curl.exe -I $siteUrl
curl.exe -IL $siteAliasUrl

수정 전에 남기는 연결표

호스트마다 DNS 대상, Pages 프로젝트, 인증서 상태, 리다이렉트 목적지, 확인일을 한 행에 적는다. 바꿀 레코드의 이전 값을 보존하고 그 호스트만 먼저 확인한다. 전체 영역을 정리하거나 관계없는 레코드를 삭제할 필요는 없다.

이 절차의 성공은 DNS 응답 하나로 결정되지 않는다. HTTP 최종 주소, 실제 페이지 내용, HTTPS, 대표 주소가 모두 맞아야 한다. 오래된 인증 문자열을 그대로 재사용하지 않고 해당 서비스가 지금 요구한 이름과 값을 대조한다.