도메인 소유자·만료일 확인하는 법

문제

도메인을 누가 갖고 있는지, 어느 등록대행사에 있는지, 언제 만료되는지 알아야 합니다 — 갖고 싶은 도메인을 쫓는 중이거나, 내 포트폴리오를 점검하거나, 어떤 이름이 곧 풀리는지 확인하려는 거죠. 그래서 후이즈 사이트에 쳐 넣으면 돌아오는 건 REDACTED FOR PRIVACY 벽과 “등록대행사에 문의” 링크뿐. 쓸 게 없습니다. 예전엔 이렇지 않았고, 지금 이렇게 된 이유는 대부분 못 들어본 변화 때문입니다: 낡은 후이즈 배관이 꺼지는 중이고, 아직 거기에 기대는 도구들은 그 유령을 보여주는 겁니다.

무엇이 바뀌었나

몇 년 간격으로 두 가지가 일어났고, 합치면 요즘 본 빈 조회가 전부 설명됩니다.

첫째, 프라이버시. EU의 GDPR이 2018년 5월 시행되자 등록대행사는 등록자 이름·이메일·주소·전화번호를 전 세계가 긁게 내버려 둘 수 없었습니다. 그래서 안 했습니다. 대부분 도메인에서 그 필드는 기본으로 가려집니다 — 프라이버시 표시나 중계 폼으로 대체되죠. 조회 도구의 버그가 아니라 법이 의도대로 작동하는 겁니다.

둘째, 프로토콜 자체. WHOIS는 RFC 3912로 확정된 1980년대 설계입니다: 포트 43 위의 순수 텍스트 스트림, 구조도 표준 필드도 없고 레지스트리마다 출력이 제각각이라 모든 파서가 특수 케이스 덩어리입니다. 그 대체재 RDAP — Registration Data Access Protocol — 는 깔끔한 구조화 JSON을 반환하고, 2021년 6월 인터넷 표준(STD 95, RFC 9082/9083)이 됐습니다. 2025년 1월 28일, ICANN은 낡은 WHOIS 의무를 종료했습니다: 레지스트리·등록대행사는 더 이상 포트 43에서 WHOIS를 운영할 계약 의무가 없고, RDAP가 gTLD 등록 데이터의 권위 있는 출처입니다. WHOIS는 여전히 많은 곳에서 — 당분간 자발적으로 — 응답하지만, 죽어가는 건 데이터가 아니라 그 형식입니다.

실무적 결론: 조회가 고장 나 보이면, 해법은 대개 더 나은 후이즈 사이트가 아닙니다. RDAP에 물어보는 겁니다.

실제로 읽을 수 있는 것

가려진 연락처 블록을 걷어내도 등록 레코드엔 신호가 많이 남습니다. 공개로 유지되고 중요한 필드:

• 등록대행사(Registrar) — 도메인이 등록된 경유 회사. 갱신·이전·신고·복구, 모든 일의 연락처입니다.
• 생성일·만료일 — 도메인이 처음 등록된 시점과 현재 등록 기간의 끝. RDAP는 이를 자유 텍스트가 아니라 구조화된 events(등록·만료·최종변경)로 노출합니다.
• 상태 플래그 — EPP 상태 코드. 레코드에서 가장 유용하면서 가장 무시되는 부분입니다(아래 참조).
• 네임서버 — 레지스트리에 등록된 위임. 실제 DNS와 비교할 가치가 있습니다: 레지스트리가 등록한 네임서버와 도메인이 실제로 응답하는 곳이 다르면 변경 중이거나 잘못 설정된 겁니다.

중요한 상태 플래그

EPP 상태 코드는 도메인의 상태 기계입니다. 읽을 줄 알면 “사이트가 죽었는데 이유를 모름”이 정밀 진단으로 바뀝니다. 외워둘 만한 것:

• clientHold / serverHold — 등록대행사나 레지스트리가 도메인을 DNS에서 뺐습니다. 갱신 완료된 도메인이 갑자기 응답을 멈추는 이유가 이겁니다: DNS 버그가 아니라 홀드, 보통 결제나 인증 문제 때문. 홀드가 풀리기 전엔 존을 아무리 바꿔도 안 고쳐집니다.
• autoRenewPeriod — 도메인이 만료일을 지나 레지스트리가 유예 창으로 자동 갱신했습니다. 만료됐지만 지금 싸게 복구 가능한 상태.
• redemptionPeriod — 도메인이 삭제돼 ~30일 상환 유예 기간(RGP)에 있습니다. 원 등록자만, 그것도 일부러 비싸게 매긴 복원 수수료로만 되찾을 수 있습니다. 등록이 아니라 복원입니다.
• pendingDelete — 마지막 5일. 상환은 끝났고 아무도 못 살리며, 끝나면 공개 풀로 떨어집니다. 이름을 노리고 기다린다면 이 플래그가 카운트다운입니다.
• clientTransferProhibited — 대부분 등록대행사가 무단 이전을 막으려 걸어두는 정상적이고 건강한 잠금. 문제 아니라 도메인 이전 전에 풀면 되는 것뿐입니다.

만료된 도메인은 이분법이 아닙니다. 자동갱신 → 상환 → pendingDelete → 해제를 차례로 걷고, 상태 플래그가 지금 어느 문 앞에 서 있는지 정확히 알려줍니다.

DechoNet으로 진단

• RDAP 조회는 도메인의 권위 있는 RDAP 서비스를 질의해 등록대행사, 생성/만료/변경 이벤트, 현재 상태 플래그, 레지스트리 네임서버를 — 해독할 텍스트 덩어리가 아니라 구조화해서 — 보여줍니다. 공개 후이즈 사이트가 아무것도 안 보여줄 때, 아직 공개된 데이터가 실제로 사는 곳입니다.
• DNS 조회는 도메인의 실제 네임서버와 레코드를 읽어, 레지스트리가 등록한 것과 도메인이 실제 서빙하는 것을 비교하게 해줍니다 — 이전 중이거나 엉뚱한 곳을 가리키는 도메인을 잡는 가장 빠른 방법.

해결 체크리스트

• 먼저 도메인을 RDAP로 돌리세요. 구조화 데이터가 나오면 그게 권위 있는 출처 — 긁어온 어떤 후이즈 페이지보다 그걸 믿으세요.
• “곧 만료”가 아니라 만료 이벤트를 읽으세요. 정확한 날짜와 그 날짜를 넘겼는지 확인하세요.
• 상태 플래그를 읽으세요. redemptionPeriod나 pendingDelete면 시계가 거의 다 됐고, clientHold면 등록은 됐지만 일부러 DNS에서 뺀 상태입니다.
• 등록대행사를 확인하세요 — 갱신·복구·이전·신고의 유일한 실제 연락처입니다. 우회로는 거의 없습니다.
• 연락처가 가려져 있으면(대개 그렇습니다) 싸우지 마세요. 등록대행사 채널이나 비공개 데이터용 ICANN 요청 경로를 쓰세요.
• 레지스트리 네임서버를 실제 DNS와 비교하세요. 불일치는 변경 진행 중이거나 오설정을 뜻합니다.

에스컬레이션 시점

• 분명히 존재하는 gTLD인데 RDAP가 빈 응답이나 오류를 내면, 그 레지스트리의 RDAP 서비스가 일시적으로 나쁜 날일 수 있습니다 — 재시도하고, 도메인이 사라졌다고 단정하기보다 WHOIS를 교차 확인용으로 쓰세요.
• .kr와 일부 ccTLD는 등록 데이터가 국가 레지스트리(.kr는 KISA/KRNIC)에 그들만의 규칙과 RDAP/WHOIS 서비스로 존재합니다; gTLD 조회는 .kr 사정을 말해주지 않습니다.
• 내 도메인에 예상 못 한 clientHold·redemptionPeriod나 틀린 만료일이 보이면, 오늘 당장 등록대행사와 나눌 대화입니다 — 그 상태들은 되돌릴 수 있습니다, 되돌릴 수 없어지기 직전까지는.