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

WHOIS 조회란 무엇인가?

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

이름은 원조 Unix 명령어에서 왔습니다. 1982년 RFC 812는 ARPANET의 NICNAME/WHOIS 서비스를 TCP 43번 포트에서 whois 뒤에 이름을 입력하는 방식으로 설명했고, 이 평문 프로토콜의 현행 규격은 RFC 3912입니다. 밑바탕의 프로토콜이 바뀌었는데도 이름은 그대로 남았습니다. 2025년 1월 28일부터 ICANN은 gTLD 레지스트리와 레지스트라에게 포트 43 WHOIS 운영을 요구하지 않으며(.com, .name, .post는 예외), 같은 데이터가 JSON API인 RDAP으로 제공됩니다. DNS Robot의 WHOIS Lookup을 비롯한 대부분의 도구는 RDAP을 먼저 조회하고도 그 결과를 여전히 WHOIS 레코드라고 부릅니다.

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

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

다음은 2026년 10월 27일 macOS의 whois 명령어로 가져온 example.com의 실제 레지스트리 레코드입니다. 모든 gTLD 레코드는 형태가 같아서, 이 레코드를 읽을 수 있으면 어떤 레코드든 읽을 수 있습니다.

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-10-26T19:13:27Z <<<

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

• 식별자 — 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 레코드가 함께 옮겨 갑니다.

WHOIS 조회하는 방법

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

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

DNS Robot의 WHOIS Lookup을 열고 도메인을 입력한 뒤 Enter를 누르세요(URL이나 이메일 주소를 붙여 넣어도 등록 도메인으로 읽어 들입니다). 도구는 먼저 레지스트리 자체의 RDAP 서버에 묻고(IANA 목록에 있는 서버, 그리고 DENIC처럼 목록 밖에서 RDAP을 운영하는 레지스트리 포함), 연락처 필드는 레지스트라의 레코드에서 가져옵니다. RDAP이 없는 TLD, 즉 국가 코드 도메인의 약 3분의 2(.jp, .ru, .it, .eu 등)는 레지스트리의 포트 43 서버에 대신 묻습니다. 결과로는 신고용 연락처가 있는 레지스트라, 생성일·갱신일·만료일, 쉬운 말로 풀어 쓴 상태 코드, 네임서버, DNSSEC 상태, 도메인 나이가 나옵니다.

ICANN Lookup은 공식 대안입니다. 모든 gTLD에 대해 권위 있는 정보를 주지만, 레지스트리가 RDAP을 운영하는 국가 코드 도메인만 다루고, 이력도 일괄 조회도 DNS 데이터로의 연결도 없습니다. GoDaddy나 Namecheap 같은 레지스트라 사이트도 같은 공개 레코드를 읽는 WHOIS 페이지를 제공합니다. 잘 동작하지만, 도메인이 비어 있으면 그것을 판매하려는 목적으로 만들어진 페이지입니다.

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

macOS에는 whois 클라이언트가 기본 포함되어 있고, Linux 배포판도 패키지로 제공합니다. 포트 43 WHOIS로 통신하며 레지스트라로의 안내(referral)를 자동으로 따라가고, 레코드를 차례로 이어서 출력합니다(macOS는 IANA에서 시작하므로 세 개가 나옵니다).

# Basic lookup (follows registry -> registrar referral)
whois example.com

# Query one specific server and skip the referral
whois -h whois.verisign-grs.com example.com

# Only the lines you usually care about
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: install if missing
sudo apt install whois

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

Windows: Sysinternals whois 또는 curl

Sysinternals 모음에서 whois.exe를 내려받아 PATH에 넣으세요. -v는 레지스트라로의 안내를 따라가며, 특정 서버는 -h 뒤가 아니라 도메인 뒤에 적습니다(whois example.com whois.verisign-grs.com). 아무것도 설치하고 싶지 않다면 RDAP 서버에 직접 묻고 PowerShell이 JSON을 보기 좋게 정리하게 하면 됩니다.

# Sysinternals whois (after download)
whois -v example.com

# No install: query RDAP and pretty-print the JSON
curl.exe -sL -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 부트스트랩 파일에서 알맞은 서버를 찾아 리디렉션해 줍니다:

# Registry record for a .com, straight from Verisign
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Any TLD: let rdap.org find the authoritative server
curl -sL https://rdap.org/domain/example.org | jq '.events'

# Output of the first command (trimmed: Verisign also returns a "last update of RDAP database" event)
{
  "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 서버에도 그대로 적용됩니다.

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

WHOIS 조회를 하는 이유는 대개 네 가지 질문 중 하나입니다. 답이 레코드의 어디에 있는지 알아봅시다.

도메인이 이미 등록되어 있나요? 레코드가 돌아오면 등록된 것입니다. 등록된 도메인에는 항상 Creation Date가 있습니다. 레지스트리가 No match for domain을 돌려주거나 RDAP이 HTTP 404를 돌려주면, 등록되지 않았거나 레지스트리가 예약해 둔 이름입니다. 짧은 단어나 사전 단어에서 흔한 경우입니다. 둘을 구별하려면 DNS로도 확인하는 도메인 등록 가능 여부 조회기를 쓰세요.

언제 만료되고, 삭제될까요? 만료일을 읽은 다음 상태 코드를 보세요. autoRenewPeriod나 redemptionPeriod 상태의 도메인은 풀려난 것이 아니며, 소유자가 여전히 갱신하거나 복구할 수 있습니다. 풀려난다는 뜻은 pendingDelete뿐이고, 보통 5일 더 걸립니다. 아래 만료 수명주기 섹션에서 전체 타임라인을 다룹니다. 레지스트리의 날짜만 보고 판단하지 마세요. gTLD 도메인이 만료되면 레지스트리가 자동으로 1년 갱신하므로, Registry Expiry Date는 이미 내년으로 표시되는데 레지스트라 자체 레코드(Registrar Registration Expiration Date)에는 소유자가 결제를 멈춘 그날이 그대로 남아 있을 수 있습니다. 둘이 다를 때는 상태 코드가 삭제 여부를 결정합니다.

누가 관리하나요? Registrar가 연락할 회사이고, Registrar Abuse Contact Email과 전화번호는 다른 모든 정보가 가려져 있어도 공개됩니다. 의도된 설계로, ICANN의 Registration Data Policy가 이 필드들을 공개로 유지하도록 요구합니다.

최근에 바뀌었나요? 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이 일주일 전에 채택한 임시 사양과 같은 날입니다), 레지스트라들은 누가 적용 대상인지 가리는 대신 모든 사람의 개인정보를 가리기 시작했습니다. 그 임시 규정은 ICANN의 Registration Data Policy로 대체되어 2025년 8월 21일부터 완전히 시행되고 있습니다. 개인정보보호법이 요구하는 곳에서는 레지스트라가 개인정보를 가려야 하고, 그 밖의 사람에 대해서도 가릴 수 있습니다.

다음은 cloudflare.com의 레지스트라 단계 RDAP 레코드가 오늘 등록자에 대해 돌려주는 내용입니다(일부 생략).

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {"type": "work"}, "text", "DATA REDACTED"],
    ["adr", {"cc": "US", "type": "work"}, "text",
      ["", "", ["DATA REDACTED", "DATA REDACTED"], "DATA REDACTED", "CA", "DATA REDACTED", ""]],
    ["contact-uri", {}, "uri", "https://domaincontact.registrar.cloudflare.com/cloudflare.com"]
  ]],
  "remarks": [{ "title": "REDACTED FOR PRIVACY",
                "description": ["Some of the data in this object has been removed"] }]
}

이 정책은 무엇이 공개로 남는지 정확히 정해 둡니다. gTLD 도메인에서는 도메인 이름, 레지스트라 이름과 IANA ID, 레지스트라 URL, 레지스트라의 신고용 이메일과 전화번호, 생성일, 만료일, 네임서버, 상태 코드를 항상 공개해야 합니다. 가리기도 완전하지 않습니다. 정책은 등록자의 시/도와 국가를 공개하도록 요구하고, 등록자가 공개에 동의했다면 조직 이름도 공개하도록 하므로, 가려진 레코드에서도 소유자가 캘리포니아나 바이에른에 있다는 것은 알 수 있습니다. 위 레코드에서는 CA와 US, 그리고 Cloudflare 문의 양식으로 연결되는 contact-uri 링크가 그것입니다.

개인정보 보호와 가림 처리의 실질적인 차이는 이렇습니다. 유료 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월 이전의 레코드는 공개였고 여러 상용 서비스가 보관해 두었습니다. 그보다 몇 년 전에 등록한 도메인이라면, 그때도 개인정보 보호 서비스를 쓰지 않았다면 최초 등록자가 나오는 가려지지 않은 과거 레코드가 있는 경우가 많습니다.
• 역방향 WHOIS. 회사 이름이나 남아 있는 이메일처럼 알려진 정보가 하나 있다면, 역방향 WHOIS 서비스가 그 정보를 등록한 적이 있는 모든 도메인을 검색해 줍니다. 비싸지만 브랜드 보호 팀이 도메인 선점꾼의 포트폴리오를 파악하는 방법이 이것입니다.
• 요청을 제출하세요. 상표 분쟁, 피싱, 사기 같은 법적 필요가 있다면 ICANN의 Registration Data Request Service(RDRS)가 공식 공개 요청을 레지스트라에 전달합니다. gTLD에서, 그리고 참여한 레지스트라에서만 동작합니다. 2년간의 시범 운영(2023년 11월 28일~2025년 11월 30일) 동안 3,700건이 넘는 요청이 접수되었고, 그중 26%가 승인, 55%가 거부되었습니다(ICANN). 커뮤니티가 다음 단계를 결정하는 동안 ICANN은 서비스를 계속 운영하고 있습니다.

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

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

실질적인 결과가 둘 있습니다. 첫째, whois 텍스트 출력을 긁어 오는 스크립트가 있다면 시한부입니다. .com, .name, .post를 제외하면 레지스트리와 레지스트라는 언제든 포트 43 서비스를 끌 수 있고, 이미 끈 곳도 있습니다. .app과 .dev를 서비스하던 Google Registry의 whois.nic.google은 이제 이름 해석조차 되지 않고, GoDaddy의 레지스트라 서버는 모든 질의에 "This WHOIS server is being retired. Please use our RDAP service instead."라고 답합니다(둘 다 2026년 10월 27일에 확인).

둘째, RDAP 부트스트랩은 WHOIS가 해결하지 못한 문제를 풉니다. example.museum이 주어지면 클라이언트는 data.iana.org/rdap/dns.json을 한 번 내려받아 museum 항목을 찾고, 미리 하드코딩해 둔 지식 없이 권위 서버에 질의합니다. 전환은 트래픽에서도 보입니다. ICANN의 월간 보고서에 따르면 gTLD RDAP 질의는 2025년 1월 월 약 70억 건에서 2025년 8월 650억 건으로 늘었고, 2025년 6월에 포트 43 WHOIS를 앞질렀습니다(APNIC).

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

ICANN의 정책은 gTLD에만 적용됩니다. 국가 코드 TLD(.de, .uk, .br, .jp 등 약 300개)는 자체 규칙을 정하므로, ccTLD에 대한 WHOIS 조회는 검증된 신원 전체부터 거의 아무것도 없는 것까지 무엇이든 돌려줄 수 있습니다. 다음은 2026년 10월 27일 레지스트리 여덟 곳에서 공개 조회로 얻은 결과입니다.

스펙트럼의 끝에서는 example.de에 대한 DENIC의 포트 43 응답이 전부 이렇습니다.

% 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 레코드는 그 블록을 어느 조직이 보유하고 있는지, 블록 크기는 얼마인지, 할당 국가는 어디인지, 남용 신고 연락처는 무엇인지 알려 줍니다. 어떤 주소가 서버를 공격하거나 스팸을 보낼 때 정확히 필요한 정보입니다.

# Port-43 WHOIS: the client finds the right RIR automatically
whois 1.1.1.1

# RDAP: rdap.org redirects to the right RIR (APNIC here)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# Output
{
  "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일 동안(더 빨리 삭제하면 만료 시점부터) 도메인이 해석되지 않도록 해야 하므로 사이트가 멈춥니다. 많은 레지스트라는 도메인이 만료되었다고 알리는 페이지로 연결합니다.
• 1~45일차(레지스트라 유예) — 소유자가 여전히 갱신할 수 있습니다. ICANN이 보장하는 것은 도메인이 중단된 동안뿐이고(ERRP), 그 이후 얼마나 허용하고 가격이 얼마인지는 레지스트라의 정책이며, 만료 후 수수료는 웹사이트에 공개해야 합니다.
• 삭제 → redemptionPeriod(30일) — 레지스트라가 삭제했습니다. 소유자는 여전히 복구할 수 있고, 갱신 비용에 더해 레지스트라가 웹사이트에 표시해야 하는 복구 수수료를 냅니다. 다른 사람은 등록할 수 없습니다.
• pendingDelete(5일) — 더 이상 복구할 수 없습니다. 이 기간이 끝나면 레지스트리가 알리지 않는 시각에 이름이 삭제되어 등록 가능해집니다.
• 드롭 — 도메인이 등록 가능해지고, 레지스트리를 계속 폴링해 온 드롭캐치 서비스들이 밀리초 단위로 경쟁합니다.

그래서 레지스트라 레코드의 만료일이 2주 전인 도메인도 실제로 등록 가능해지기까지는 약 35일에서 66일이 남아 있을 수 있고, 영영 등록 가능해지지 않을 수도 있습니다. 소유자는 pendingDelete 전까지 언제든 되찾을 수 있기 때문입니다. 만료일이 아니라 상태 줄을 감시하세요. 하루에 한 번 WHOIS 조회를 하고 상태 전환을 기록하는 것으로 충분합니다.

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

"이 이름이 비어 있나"를 넘어, 지원 문의와 보안 팀에서 반복해서 나오는 용도가 몇 가지 있습니다.

믿기 전에 웹사이트 검증하기. 10년 운영을 내세우는 쇼핑몰의 도메인이 3주 전에 만들어졌다면 그 자체가 말해 주는 바가 있습니다. 생성일, 레지스트라, 네임서버는 확인하는 데 10초밖에 안 걸리고, 레지스트리 레코드에서는 위조가 불가능합니다.

해석되지 않게 된 사이트 문제 해결하기. DNS를 건드리기 전에 도메인이 만료되었거나 clientHold 상태가 아닌지 확인하세요. 그렇다면 어떤 DNS 변경도 소용이 없습니다. 네임서버 이전 후에는 WHOIS의 Name Server 줄이 레지스트라가 실제로 변경을 반영했는지 확인해 줍니다. 리졸버는 이전 네임서버를 최대 48시간, 즉 .com 위임 레코드의 TTL 동안 캐시할 수 있습니다. NS 조회로 지금 세상이 보는 값을 확인하세요.

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

피싱이나 악용 조사하기. Registrar Abuse Contact Email은 악성 도메인을 정지시킬 수 있는 곳에 신고하라고 공개되어 있습니다. 호스팅 업체에 대해서는 IP WHOIS의 신고용 연락처와 함께 쓰세요.

내 도메인 포트폴리오 점검하기. 도메인은 해커뿐 아니라 만료된 신용카드 때문에도 사라집니다. 소유한 모든 도메인을 분기마다 WHOIS로 훑어 만료일과 잠금 상태를 확인하는 것은 저렴한 보험입니다.

WHOIS 필드 레퍼런스

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

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