일반적인 도메인 등록 방식과 달리, 최상위 도메인(TLD) 자체를 웹사이트로 활용하는 사례를 소개함
과거 `.ai` 도메인에서 웹 서버가 운영되었던 흥미로운 기록을 웨이백 머신(Wayback Machine) 스냅샷으로 제시함
레지스트리 운영자가 TLD 최상위에 직접 DNS 레코드(A 레코드)를 설정하여 TLD 기반 웹사이트 구현이 가능함을 설명함
일반적으로 사용자가 도메인(`example.com`)의 최상위(`apex`)에 A 레코드를 설정하는 것과 동일한 원리로, TLD 레지스트리 운영자는 `.uz`와 같은 최상위 도메인 존(Zone)의 최상위에 직접 DNS 레코드를 설정할 수 있다.
DNS 최상위 레코드(Apex DNS Record): 도메인 이름 없이 최상위 레벨에서 직접 관리되는 레코드 집합을 의미함
레지스트리 운영자 권한: TLD의 DNS 존 파일에 대한 직접적인 수정 권한을 통해 특정 IP 주소로의 매핑(Mapping) 설정 가능
이러한 설정은 일반적인 웹사이트 구성 방식은 아니지만, DNS 인프라의 유연성(DNS Infrastructure Flexibility)을 보여주는 기술적 사례로 볼 수 있다.
본문에서는 과거 `.ai` 최상위 도메인(TLD)에서 실제 웹 서버가 운영되었던 사례를 언급하며, 이는 DNS 설정의 비전통적 활용을 보여준다.
웨이백 머신(Wayback Machine) 스냅샷: 해당 시점의 웹사이트 상태를 기록으로 보존하여 기술적 흥미를 유발함
서버 중단 및 A 레코드 제거: 현재는 해당 IP 주소로의 연결이 끊어져 접근이 불가능하지만, 과거에는 유효한 웹사이트로 기능했음을 시사함
이러한 사례는 TLD 자체를 네임스페이스(Namespace)의 최상단 엔드포인트(Endpoint)로 활용할 수 있는 가능성을 탐구하게 한다.
발견된 `.uz` 도메인 기반 웹사이트 접속 시, TLS 인증서의 일반 이름(Common Name) 불일치로 인해 브라우저에서 경고가 발생한다. 사용자는 이를 무시하고 강제로 접속해야 하는 상황이 발생한다.
TLS 인증서 검증: 브라우저는 보안을 위해 인증서의 도메인 이름과 접속하려는 도메인 이름이 일치하는지 확인함
강제 접속(Force Entry): 인증서 오류를 무시하고 접속하는 것은 보안 위험을 수반하므로, 신뢰할 수 없는 환경에서는 권장되지 않음
이 문제는 TLD 자체를 웹사이트로 운영할 때 발생할 수 있는 보안 구성(Security Configuration)의 복잡성을 드러낸다.