WHOIS 조회 가이드: 도메인 소유자 확인과 레코드 읽는 법

WHOIS 조회란 무엇인가?

WHOIS 조회는 도메인 이름의 공개 등록 데이터베이스에 질의하는 작업이며, 국내에서는 후이즈 조회라고 부르기도 합니다. .com, .net, .org 같은 일반 최상위 도메인(gTLD) 아래의 모든 도메인은 레지스트리와 등록대행자(레지스트라)가 보관하는 레코드를 가져야 하고, 그 레코드의 공개 부분은 누구나 읽을 수 있습니다. 조회하면 등록대행자가 어디인지, 도메인이 언제 생성되고 언제 만료되는지, 어떤 네임서버를 쓰는지, 그리고 잠겨 있는지·보류 중인지·삭제를 앞두고 있는지를 알려 주는 상태 코드가 돌아옵니다.

이름은 초창기 유닉스 명령어에서 왔습니다. 1982년 ARPANET 디렉터리는 whois 뒤에 이름을 붙여 입력하면 조회할 수 있었고, 이후 RFC 3912가 TCP 43번 포트를 쓰는 이 평문 프로토콜을 표준으로 정리했습니다. 아래에서 돌아가는 프로토콜은 바뀌었지만 이름은 그대로 남았습니다. 2025년 1월 28일부터 ICANN은 gTLD 레지스트리와 레지스트라에 포트 43 WHOIS 운영을 더 이상 요구하지 않으며, 같은 데이터가 JSON API인 RDAP으로 제공됩니다. DNS Robot의 WHOIS Lookup을 포함한 대부분의 도구는 RDAP을 먼저 질의하면서도 그 결과를 여전히 WHOIS 레코드라고 부릅니다.

요즘 WHOIS 조회가 대개 돌려주지 않는 것이 하나 있습니다. 바로 도메인 소유자의 이름, 주소, 이메일입니다. 2018년 5월 GDPR이 시행된 뒤로 전 세계 레지스트라는 기본적으로 개인 연락처 정보를 가립니다. 이 가이드의 나머지 부분에서는 그래도 남아 있는 정보가 무엇이고 어떻게 읽어야 하는지, 연락처 필드가 REDACTED FOR PRIVACY로 나올 때 소유자에게 닿는 방법은 무엇인지 다룹니다.

WHOIS 레코드에는 무엇이 담겨 있나

아래는 오늘 macOS에서 whois 명령어로 가져온 example.com의 실제 레지스트리 레코드입니다. 모든 gTLD 레코드는 같은 형태를 하고 있어서, 이 하나를 읽을 수 있으면 나머지도 전부 읽을 수 있습니다:

• 식별자 — Domain Name과 Registry Domain ID. ID는 레지스트리 내부 키로, 도메인 주인이 바뀌어도 절대 변하지 않습니다.

• 등록대행자 — 소유자가 비용을 지불하는 회사입니다. Registrar IANA ID는 IANA 레지스트라 목록에서 부여한 고유 번호이고, Registrar WHOIS Server는 연락처 필드가 저장된 곳입니다. .com과 .net은 레지스트리 자체가 연락처를 전혀 보관하지 않기 때문입니다.

• 날짜 — Creation Date, Updated Date, Registry Expiry Date. 세 값 모두 UTC 기준입니다. 생성일은 도메인 나이 확인 도구가 보여 주는 바로 그 값입니다.

• 상태 — 하나 이상의 EPP 상태 코드입니다. 레코드에서 가장 쓸모 있으면서 가장 많이 오해받는 부분이라 아래에 한 절을 따로 할애했습니다.

• 위임 — 네임서버와 DNSSEC 플래그입니다. WHOIS와 DNS를 잇는 다리로, 여기서 네임서버를 바꾸면 그 도메인의 모든 DNS 레코드가 함께 옮겨 갑니다.

Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.iana.org
Registrar URL: http://res-dom.iana.org
Updated Date: 2026-08-14T08:01:43Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2027-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: ELLIOTT.NS.CLOUDFLARE.COM
Name Server: HERA.NS.CLOUDFLARE.COM
DNSSEC: signedDelegation
DNSSEC DS Data: 2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1C83D245A
>>> Last update of whois database: 2026-09-18T01:28:30Z <<<

레코드는 다섯 묶음으로 나뉘고, 각 묶음은 서로 다른 질문에 답합니다:

WHOIS 조회하는 방법

후이즈 조회를 실행하는 방법은 세 가지이고, 어느 쪽이든 바탕이 되는 데이터는 같습니다. 얼마나 자주 조회하는지, 가공되지 않은 원본 출력이 필요한지에 따라 고르면 됩니다.

방법 1: 온라인 WHOIS 도구 사용하기

DNS Robot의 WHOIS Lookup을 열고 도메인만 입력한 뒤(https://www.example.com/page가 아니라 example.com) Enter를 누르면 됩니다. 이 도구는 주요 TLD의 경우 레지스트리 RDAP 서버에 직접 질의하고 나머지는 rdap.org 부트스트랩으로 넘겨 처리한 다음, 파싱된 레코드를 보여 줍니다. 남용 신고 연락처가 포함된 등록대행자, 생성일·갱신일·만료일, 쉬운 말로 풀어 쓴 상태 코드, 네임서버, DNSSEC 상태, 도메인 나이까지 한 화면에 나옵니다. 테스트에서 dnsrobot.net 조회는 387ms 만에 결과가 돌아왔습니다.

ICANN Lookup은 공식 대안입니다. 모든 gTLD에 대해 권위 있는 답을 주지만 대부분의 국가 코드 도메인에서는 쓸 만한 결과가 나오지 않고, 이력 조회도 대량 조회도 DNS 데이터로 이어지는 링크도 없습니다. 등록대행자 사이트(GoDaddy, Namecheap, Cloudflare)도 WHOIS 페이지를 제공합니다. 동작에는 문제가 없지만, 도메인이 비어 있으면 곧바로 판매로 이어지도록 설계된 화면이라는 점은 감안해야 합니다.

방법 2: whois 명령어 (macOS, Linux, Windows)

macOS와 거의 모든 리눅스 배포판에는 whois 클라이언트가 기본으로 들어 있습니다. 포트 43 WHOIS로 통신하고, 레지스트리에서 레지스트라로 이어지는 리퍼럴을 자동으로 따라가며, 두 레코드를 연달아 출력합니다:

# 기본 조회 (레지스트리 -> 레지스트라 리퍼럴을 따라감)
whois example.com

# 특정 서버 하나만 질의하고 리퍼럴은 건너뛰기
whois -h whois.verisign-grs.com example.com

# 보통 확인하는 줄만 뽑아 보기
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: 설치되어 있지 않다면
sudo apt install whois

Windows에는 기본 whois가 없습니다. 깔끔한 선택지는 두 가지입니다. 마이크로소프트가 직접 배포하는 Sysinternals 도구를 쓰거나, Windows 10·11에 기본 포함된 curl로 RDAP을 질의하는 것입니다:

Windows: Sysinternals whois 또는 curl

Sysinternals 제품군에서 whois.exe를 내려받아 PATH에 넣으면 유닉스와 동일한 문법으로 쓸 수 있습니다. 아무것도 설치하고 싶지 않다면 RDAP 서버에 직접 물어보고 PowerShell로 JSON을 정리해 출력하면 됩니다:

# Sysinternals whois (내려받은 뒤)
whois -v example.com

# 설치 없이: RDAP을 질의해 JSON을 보기 좋게 출력
curl.exe -s -H "Accept: application/rdap+json" https://rdap.org/domain/example.com | ConvertFrom-Json | Select-Object ldhName, status, events, nameservers

방법 3: RDAP 직접 질의하기 (스크립트용)

스크립트에서 WHOIS 데이터가 필요하다면 텍스트 형식은 건너뛰고 RDAP을 호출하세요. 응답이 스키마가 고정된 JSON이라 정규식 없이도 필드를 뽑아낼 수 있습니다. .com 레지스트리는 rdap.verisign.com에서 응답하고, 그 밖의 TLD는 rdap.org가 IANA 부트스트랩 파일에서 알맞은 서버를 찾아 리디렉션해 줍니다:

# .com 레지스트리 레코드를 Verisign에서 바로 가져오기
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# 모든 TLD: rdap.org가 권한 있는 서버를 찾아 줍니다
curl -sL https://rdap.org/domain/example.org | jq '.events'

# 출력 예시
{
  "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" }
  ],
  "nameservers": ["ELLIOTT.NS.CLOUDFLARE.COM", "HERA.NS.CLOUDFLARE.COM"]
}

레지스트리 응답의 links 배열에는 레지스트라 자체 RDAP 서버로 연결되는 related 링크가 들어 있습니다. 이를 따라가면 가려졌든 아니든 연락처 객체를 받을 수 있습니다. 잘 만들어진 웹 도구는 이 과정을 요청 한 번으로 대신 처리해 줍니다. 이 데이터를 바탕으로 무언가를 만들 생각이라면, 공개 API 엔드포인트 테스트 방법에서 소개한 6단계 절차가 다른 JSON API와 마찬가지로 RDAP 서버에도 그대로 적용됩니다.

결과 읽는 법 (필드별 해설)

대부분의 사람은 네 가지 질문 중 하나에 답하려고 후이즈 조회를 실행합니다. 각 답이 레코드의 어디에 있는지 정리했습니다.

이 도메인은 이미 등록되어 있나? 레코드가 돌아왔다면 등록된 것입니다. 등록된 도메인에는 반드시 Creation Date가 있습니다. 레지스트리가 No match for domain을 반환하거나 RDAP이 HTTP 404를 돌려주면 그 이름은 미등록 상태이거나, 레지스트리가 예약해 둔 이름입니다. 짧은 단어나 사전에 있는 단어는 예약된 경우가 흔합니다. 둘을 구분하려면 도메인 등록 가능 여부 확인 도구를 쓰세요. DNS로도 함께 검증하기 때문입니다.

언제 만료되고, 정말 풀릴까? Registry Expiry Date를 보고 이어서 상태 코드를 읽으세요. 만료일이 지났어도 상태가 autoRenewPeriod나 redemptionPeriod이면 아직 풀린 것이 아닙니다. 소유자가 여전히 갱신할 수 있습니다. 풀린다는 뜻을 가진 상태는 pendingDelete 하나뿐이고, 거기서도 보통 5일이 더 걸립니다. 아래 만료 수명주기 절에서 전체 타임라인을 다룹니다.

누가 관리하나? 연락할 곳은 Registrar이고, Registrar Abuse Contact Email과 전화번호는 다른 정보가 전부 가려져도 공개됩니다. 의도된 설계입니다. ICANN의 등록 데이터 정책이 이 필드들을 공개로 유지하도록 요구합니다.

최근에 바뀐 적이 있나? Updated Date는 레지스트라가 변경을 반영할 때마다 움직입니다. 갱신, 네임서버 교체, 잠금 추가나 해제가 모두 여기에 해당합니다. 지난주에 네임서버가 바뀌고 다음 달에 만료되는 도메인은 2015년 이후 손대지 않은 도메인과 위험도가 전혀 다릅니다. 네임서버가 바뀌었다면 NS 조회로 DNS가 지금 어디에 있는지 확인하세요.

도메인 상태 코드(EPP) 완전 정리

상태 코드는 WHOIS 레코드에서 가장 값진 한 줄이자 가장 많이 오해받는 줄입니다. EPP 프로토콜에 정의되어 있고 각 코드의 의미는 ICANN이 고정해 공개합니다. client로 시작하는 코드는 레지스트라가 대개 소유자의 요청에 따라 설정한 것이고, server로 시작하는 코드는 레지스트리가 설정하며 레지스트리만 해제할 수 있습니다.

기억할 패턴은 이렇습니다. clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibited 조합은 건강하고 심심한 상태입니다. 갑자기 아무 데도 연결되지 않으면서 clientHold가 보이는 도메인은 DNS가 아니라 소유자의 받은편지함을 확인해야 합니다. 그리고 남이 놓친 도메인을 노리고 기다리는 중이라면, pendingDelete 이전 단계는 지켜볼 가치가 없습니다.

WHOIS에 "REDACTED FOR PRIVACY"가 뜨는 이유

2018년까지만 해도 .com 도메인의 WHOIS 레코드에는 도메인 소유자의 실명, 주소, 전화번호, 이메일이 그대로 적혀 있는 것이 보통이었습니다. 레지스트라는 그 필드를 대행 서비스 정보로 바꿔 주는 부가 상품으로 WHOIS 프라이버시를 팔았습니다. 그러다 2018년 5월 25일 EU의 GDPR이 시행되자 ICANN은 며칠 만에 임시 규정(Temporary Specification)을 내놓았고, 레지스트라들은 누가 적용 대상인지 따지는 대신 모든 등록자의 개인정보를 가리기 시작했습니다. 이 임시 규정은 ICANN의 등록 데이터 정책(Registration Data Policy)으로 대체되었고, 이 정책이 2025년 8월 21일 전면 시행되면서 비공개 처리가 영구화되었습니다.

지금 cloudflare.com의 레지스트라 단 RDAP 레코드가 도메인 소유자 항목으로 돌려주는 내용은 다음과 같습니다:

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {}, "text", "DATA REDACTED"],
    ["adr", {}, "text", ["DATA REDACTED", "DATA REDACTED", "DATA REDACTED"]]
  ]],
  "remarks": [{ "title": "REDACTED FOR PRIVACY",
                "description": ["Some of the data in this object has been removed."] }]
}

이 정책은 무엇을 공개로 남길지 명확히 정해 두었습니다. gTLD 도메인이라면 도메인 이름, 레지스트라 이름과 IANA ID, 레지스트라 URL, 레지스트라의 남용 신고 이메일과 전화번호, 생성일, 만료일, 네임서버, 상태 코드는 언제나 공개되어야 합니다. 비공개 처리가 늘 완전한 것도 아닙니다. 상당수 레지스트라는 회사 명의로 등록된 도메인의 조직(organisation) 이름을 여전히 공개하고(법인은 GDPR 보호 대상이 아닙니다) 소유자의 주/도와 국가도 남겨 둡니다. 그래서 가려진 레코드만으로도 소유자가 델라웨어의 회사인지, 바이에른의 개인인지 정도는 알 수 있습니다.

프라이버시 서비스와 비공개 처리의 실질적인 차이는 이렇습니다. 유료 WHOIS 프라이버시 서비스는 대행 주소로 온 메일을 소유자에게 전달해 주지만, 단순한 비공개 처리는 이메일을 아예 지우고 레지스트라에 따라 문의 양식 링크나 익명 전달 주소로 바꿔 놓습니다. 어느 쪽이든 외부인은 소유자가 누구인지 모른 채로 연락할 방법은 갖게 됩니다.

WHOIS가 가려졌을 때 도메인 소유자 확인하는 방법

비공개 처리가 정문을 닫았을 뿐, 도메인은 다른 곳에 흔적을 잔뜩 남깁니다. 아래 순서대로 진행하세요. 각 단계는 1분이면 끝나고, 대부분은 세 번째 단계에서 소유자가 드러납니다.

• 가려지지 않은 부분부터 읽으세요. 조직, 주/도, 국가 필드는 남아 있는 경우가 많습니다. 레지스트라 자체도 단서입니다. MarkMonitor나 CSC에 맡겨진 도메인은 대기업 소유이고, Cloudflare Registrar에 있는 도메인은 개발자나 스타트업일 가능성이 높습니다.

• 레지스트라의 연락 중계를 이용하세요. 모든 레지스트라는 도메인 소유자에게 닿을 수단을 제공해야 합니다. abc123@contact.gandi.net 같은 익명 이메일이거나 WHOIS 출력에 링크된 웹 양식입니다. 정상적인 메시지는 소유자에게 전달됩니다.

• SSL 인증서를 확인하세요. 조직 검증(OV)과 확장 검증(EV) 인증서에는 Subject 필드에 법인명이 들어갑니다. SSL 검사 도구로 도메인을 조회해 인증서 체인을 읽어 보세요. 조직 정보가 어디에 들어가는지는 SSL 인증서 체인 가이드에 정리되어 있습니다.

• DNS를 보세요. SOA 레코드의 RNAME 필드는 존 관리자의 이메일에서 @를 점으로 바꾼 값입니다. TXT 레코드는 메일 제공업체, Google·Microsoft·Facebook 인증 토큰, 때로는 회사 이름까지 그대로 드러냅니다. SOA와 TXT에 대한 DNS 조회는 몇 초면 끝나고, 서브도메인 검색을 돌리면 mail., crm., jira. 같은 호스트명이 그 회사가 어떤 도구를 쓰는지 알려 줍니다.

• WHOIS 이력을 확인하세요. 2018년 5월 이전 레코드는 공개였고 여러 상용 서비스가 그때 데이터를 보관하고 있습니다. 2012년에 등록된 도메인이라면 최초 소유자가 그대로 적힌 과거 레코드가 거의 확실히 남아 있습니다.

• 역방향 WHOIS를 쓰세요. 회사 이름이나 살아남은 이메일처럼 확인된 정보가 하나라도 있다면, 역방향 WHOIS 서비스로 그 값을 등록 정보에 썼던 모든 도메인을 찾아낼 수 있습니다. 비싸지만 브랜드 보호 팀이 도메인 스쿼터의 보유 목록을 그려 내는 방법이 바로 이것입니다.

• 정식으로 요청하세요. 상표권 분쟁, 피싱, 사기처럼 법적 필요가 있다면 ICANN의 등록 데이터 요청 서비스(RDRS)가 정식 공개 요청을 레지스트라에 전달해 줍니다. 2023년 11월 28일에 시작했고 gTLD에만 적용되며, 대부분의 ccTLD에는 이에 해당하는 수단이 없습니다.

WHOIS와 RDAP 비교: 2025년에 무엇이 바뀌었나

RDAP(Registration Data Access Protocol)은 포트 43 WHOIS의 고장난 부분을 전부 고치려고 IETF가 설계한 프로토콜이고, 오늘날 여러분이 쓰는 조회 도구가 실제로 호출하는 것도 이쪽입니다. 이 데이터를 바탕으로 무언가를 만든다면 차이를 알아 둘 필요가 있습니다:

실무적으로 두 가지 결론이 나옵니다. 첫째, whois 텍스트 출력을 긁어 쓰는 스크립트가 있다면 시한부입니다. 레지스트리는 언제든 포트 43 서비스를 끌 수 있고 이미 끈 곳도 있습니다. .app과 .dev를 담당하던 Google Registry의 whois.nic.google은 이제 이름 해석조차 되지 않습니다. 둘째, RDAP 부트스트랩은 WHOIS가 끝내 풀지 못한 문제를 해결합니다. example.museum이 주어지면 클라이언트는 data.iana.org/rdap/dns.json을 한 번 내려받아 museum 항목을 찾고, 하드코딩된 목록 없이 권한 있는 서버에 질의합니다. ICANN은 2024년 12월 기준 RDAP이 월 100억 건이 넘는 질의를 처리하고 있다고 밝혔습니다.

국가 코드 도메인: 레지스트리마다 방식이 다릅니다

ICANN의 정책은 gTLD에만 적용됩니다. 국가 코드 최상위 도메인(.de, .uk, .br, .jp 등 약 300개)은 각자 규칙을 정하며, 국내에서 쓰는 .kr는 KISA(한국인터넷진흥원) 산하 KRNIC이 관리합니다. 그래서 ccTLD에 대한 WHOIS 조회 결과는 검증까지 마친 완전한 신원 정보부터 거의 아무것도 없는 수준까지 천차만별입니다. 다음은 .de 레지스트리인 DENIC의 43번 포트 서버가 오늘 example.de에 대해 돌려준 응답입니다:

% The DENIC whois service on port 43 doesn't disclose any information concerning
% the domain holder, general request and abuse contact.
% This information can be obtained through use of our web-based whois service
% available at the DENIC website:
% https://webwhois.denic.de/?lang=en

Domain: example.de
Nserver: ns1078.ui-dns.biz
Nserver: ns1078.ui-dns.com
Nserver: ns1078.ui-dns.de
Nserver: ns1078.ui-dns.org
Status: connect
Changed: 2018-08-10T05:24:12+02:00

레지스트라도, 날짜도, 소유자도 없고 상태 어휘(connect)조차 EPP가 아닌 DENIC 고유의 것입니다. 다른 레지스트리들은 이 스펙트럼의 서로 다른 지점에 놓여 있습니다:

IP WHOIS 조회: 이 IP 주소는 누구 것인가

같은 whois 명령어는 IP 주소에도 통하지만, 답은 다른 데이터베이스에서 옵니다. 도메인 이름은 레지스트리와 레지스트라가 관리하고, IP 주소 블록은 5개 지역 인터넷 레지스트리(RIR)가 할당합니다. 북미는 ARIN, 유럽과 중동은 RIPE NCC, 아시아·태평양은 APNIC, 중남미는 LACNIC, 아프리카는 AFRINIC입니다. IP WHOIS 레코드는 그 블록을 어느 조직이 보유하고 있는지, 블록 크기는 얼마인지, 할당 국가는 어디인지, 남용 신고 연락처는 무엇인지 알려 줍니다. 어떤 주소가 서버를 공격하거나 스팸을 보낼 때 정확히 필요한 정보입니다.

# 포트 43 WHOIS: 클라이언트가 알맞은 RIR을 자동으로 찾습니다
whois 1.1.1.1

# RDAP: rdap.org가 알맞은 RIR로 리디렉션합니다 (여기서는 APNIC)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# 출력
{
  "name": "APNIC-LABS",
  "handle": "1.1.1.0 - 1.1.1.255",
  "startAddress": "1.1.1.0",
  "endAddress": "1.1.1.255",
  "country": "AU",
  "type": "ASSIGNED PORTABLE"
}

IP 레코드는 그 주소에서 어떤 웹사이트가 돌아가는지는 알려 주지 않습니다. 클라우드 IP 하나가 수천 개 도메인의 앞단 역할을 할 수 있기 때문입니다. 사용자의 실제 위치도 알 수 없고, 블록이 등록된 지역만 알 수 있습니다. 명령줄 없이 빠르게 확인하려면 IP 조회가 RIR 데이터와 위치 정보를 함께 보여 주고, ASN 조회는 그 블록이 어느 네트워크에서 광고되는지 알려 줍니다. IP에서 호스트명을 거꾸로 찾으려면 WHOIS가 아니라 PTR 레코드를 읽는 역방향 DNS를 쓰세요.

만료일 읽기: 도메인 수명주기

상태 코드는 소유자가 비용 지불을 멈춘 뒤 gTLD 도메인이 밟는 타임라인 위에 놓고 봐야 의미가 통합니다. ICANN의 만료 등록 회복 정책(Expired Registration Recovery Policy)이 최소 기준을 정하고 레지스트리와 레지스트라가 각자 여유를 더하다 보니, 대부분이 생각하는 것보다 훨씬 긴 길이 됩니다:

• 만료 약 30일 전과 다시 약 7일 전 — 레지스트라는 소유자에게 메일을 보내야 합니다. 만료 후 5일 이내에 세 번째 안내가 이어집니다.

• 0일 차(만료) — 레지스트리가 도메인을 자동 갱신하고 autoRenewPeriod를 설정합니다. 레지스트라는 최대 45일 안에 유지할지 삭제할지 정해야 합니다. 삭제 전 최소 8일 동안은 DNS 응답을 끊어야 하므로 사이트는 내려갑니다. 많은 레지스트라가 만료 안내 페이지를 대신 띄웁니다.

• 1~45일 차(레지스트라 유예 기간) — 소유자는 정상 가격으로 갱신할 수 있습니다. 대부분의 레지스트라는 이 기간을 30일 이하로 줄여 둡니다.

• 삭제 → `redemptionPeriod`(30일) — 레지스트라가 삭제한 상태입니다. 소유자는 갱신 비용에 더해 보통 80~200달러의 수수료를 내고 복구할 수 있습니다. 그동안 다른 사람은 등록할 수 없습니다.

• `pendingDelete`(5일) — 복구가 더 이상 불가능합니다. 이 기간이 끝나면 레지스트리가 따로 공지하지 않는 시점에 이름이 완전히 삭제되어 등록 가능해집니다.

• 드롭 — 도메인이 누구나 등록할 수 있는 상태가 되고, 레지스트리를 계속 폴링하던 드롭 캐칭 서비스들이 밀리초 단위로 경쟁합니다.

그래서 WHOIS 만료일이 2주 전으로 찍힌 도메인은 실제로 등록 가능해지기까지 보통 60~75일이 남아 있고, 끝내 풀리지 않을 수도 있습니다. pendingDelete가 되기 전까지는 소유자가 언제든 되찾을 수 있기 때문입니다. 만료일이 아니라 상태 줄을 지켜보세요. 하루에 한 번 WHOIS 조회를 돌리고 상태 전환을 기록하는 것으로 충분합니다.

사람들이 실제로 WHOIS 조회를 쓰는 곳

"이 이름이 비어 있나" 말고도, 고객 지원 창구와 보안 팀에서 반복해서 등장하는 용도가 몇 가지 있습니다.

믿어도 되는 사이트인지 확인할 때. 10년 업력을 내세우는 쇼핑몰의 도메인이 3주 전에 생성됐다면 그 자체가 답입니다. 생성일, 레지스트라, 네임서버를 확인하는 데 10초면 충분하고, 레지스트리 레코드에 남은 값은 위조할 수도 없습니다.

접속이 끊긴 사이트를 점검할 때. DNS를 건드리기 전에 도메인이 만료됐는지, clientHold에 걸려 있는지부터 확인하세요. 둘 중 하나라면 DNS를 아무리 바꿔도 소용없습니다. 네임서버를 옮긴 뒤라면 WHOIS의 Name Server 줄로 레지스트라가 변경을 실제로 반영했는지 확인할 수 있습니다. 전파에는 최대 48시간이 걸리기도 합니다.

이미 등록된 도메인을 사려 할 때. WHOIS는 레지스트라(대개 중개 서비스를 함께 운영합니다), 도메인의 잠금 여부, 현재 소유자가 얼마나 오래 보유했는지, 만료 쪽으로 흘러가고 있는지를 알려 줍니다.

피싱이나 남용을 신고할 때. Registrar Abuse Contact Email이 공개되는 이유가 바로 악성 도메인을 정지시킬 수 있는 당사자에게 신고하라는 것입니다. 호스팅 업체의 IP WHOIS 남용 신고 연락처와 함께 쓰세요.

보유 도메인을 점검할 때. 기업이 도메인을 잃는 원인은 해커보다 만료된 신용카드인 경우가 더 많습니다. 분기에 한 번 보유 도메인 전체의 만료일과 잠금 상태를 WHOIS로 훑어보는 것은 값싼 보험입니다.

WHOIS 필드 레퍼런스

gTLD 레코드에서 만나게 될 모든 필드를 정리했습니다. JSON을 직접 파싱하는 분들을 위해 RDAP에서의 위치도 함께 적었습니다:

지금 보고 있는 레코드가 이 표와 맞지 않는다면 거의 틀림없이 ccTLD입니다. 그때는 해당 레지스트리의 자체 문서가 기준이 됩니다.