DNS로 "이 도메인 팝니다"를 알린다 — _for-sale 레코드의 실무적 의미

도메인을 팔고 싶어도 그 의사를 외부에 전달할 마땅한 채널이 없다는 것은 오래된 문제였다. 관심 있는 매수자가 소유자에게 접근하는 유일한 통로는 WHOIS에 등록된 연락처로 보내는 콜드 이메일 정도인데, 개인정보 보호를 위한 마스킹(privacy redaction)이 그 연락처마저 대부분 가려 버린다. 그 결과 환영받았을 문의는 도착하지 못하고, 어쩌다 도착한 문의는 스팸과 구분되지 않는다. 최근 IANA에 등록되고 RFC 10023(Informational, 2026년 7월)으로 정의된 _for-sale 규약은 바로 이 공백을 겨냥한다. 판매 의사가 있는 도메인이라면 그 사실을 DNS에 직접 적어 두자는 발상이다.

동작 방식은 단순하다. 판매하려는 존(zone)의 _for-sale 리프 노드에 TXT 레코드를 하나 게시한다. 예를 들어 example.com을 판다면 _for-sale.example.com에 레코드를 둔다. 이 레코드는 필수 버전 태그로 시작하고, 그 뒤에 최대 한 개의 tag=value 쌍만 붙일 수 있다. 즉 형식 자체가 극도로 절제되어 있어 오남용이나 자유 서식으로 인한 파싱 문제를 줄인다. 레코드는 원할 때 추가하고 원할 때 제거할 수 있으며, 진심으로 팔 의사가 있을 때에만 게시하는 것이 규약의 전제다.

파킹과는 거의 정반대다

가장 먼저 걷어내야 할 오해는 이것이 도메인 파킹(parking)의 한 방식이라는 생각이다. 실제로는 그 반대에 가깝다. 파킹은 원래 사이트를 판매 안내 페이지로 대체해 버리기 때문에, 도메인이 여전히 붙들고 있던 방문자를 매번 잃는다. 반면 _for-sale 레코드는 살아 있는 사이트 옆 DNS에 조용히 놓여 브라우저에는 아무 말도 하지 않는다. 홈페이지는 그대로 서비스되고 메일도 계속 흐른다. RFC 10023은 이 규약이 도메인이 여전히 활발히 사용되는 상태에서 작동하도록 설계되었음을 명시한다. 사이트를 내리지 않고도 판매 신호만 얹는다는 점이 핵심이다.

등록 정보와도 다른 층위

또한 이 신호는 WHOIS나 RDAP 같은 등록 데이터와도 성격이 다르다. WHOIS와 RDAP는 "이 이름이 등록되어 있는가?"에 답한다. 그러나 등록된 이름이라도 구매 가능할 수 있고, 미등록 이름이라도 가질 가치가 없을 수 있다. 바로 이 간극, 즉 "등록 여부"와 "판매 의사" 사이의 빈틈이 규약이 존재하는 이유다. 그래서 이 신호의 대상 독자는 사람이 아니라 브로커와 자동화된 가용성(availability) 서비스다. 이들은 이름을 조회하는 것이 이미 일상 업무이므로, 조회 과정에 룩업 한 번을 더하는 것만으로 렌더링된 페이지가 결코 알려줄 수 없는 정보를 얻는다.

신호를 페이지가 아니라 DNS에 두는 선택이 실무적으로 유용한 이유가 여기에 있다. 정상 작동하는 홈페이지의 그 어떤 요소도 "이 도메인은 협상 가능하다"고 말해 주지 않는다. 사람이 눈으로 페이지를 봐서는 알 수 없는 사실을, 외부에서 기계적으로 검증할 수 있는 형태로 노출하는 것이다. 비용은 레코드 하나뿐이고, 브라우저는 그 레코드를 결코 보지 않으므로 사이트 자체에는 아무런 위험이 없다. 판매 의사를 행동으로 옮길 수 있는 당사자에게만 정확히 닿는 구조라는 점이 이 방식의 설계 의도다.

다만 도입 시 반드시 챙겨야 할 지점이 있다. 가능하다면 존에 DNSSEC 서명을 적용하는 것이 강력히 권고된다. 서명되지 않은 TXT 레코드는, 그것이 판매 사실과 가격, 연락처 URI까지 담고 있을 경우 제3자가 위조하기에 지나치게 편안한 표적이 된다. 누군가가 남의 도메인에 대해 "팝니다, 얼마에, 여기로 연락"이라는 가짜 신호를 심어 두는 상황을 막으려면 서명이 사실상 전제 조건에 가깝다. 신호가 외부에서 검증 가능하다는 장점은, 그 검증이 위변조를 걸러낼 수 있을 때에만 온전히 성립한다.

한국의 실무자 관점에서 이 규약의 매력은 운영 부담이 거의 없다는 점이다. 기존 서비스를 중단하거나 트래픽을 희생하지 않고, TXT 레코드 하나를 넣고 빼는 것만으로 매각 채널을 열고 닫을 수 있다. 반면 한계도 분명하다. 이는 Informational 등급의 관례일 뿐 강제력이 없고, 실제 가치는 브로커와 가용성 서비스가 이 리프 노드를 실제로 조회하고 존중하도록 생태계가 형성되느냐에 달려 있다. 채널을 표준화했다는 것과 그 채널이 시장에서 실제로 조회된다는 것은 별개의 문제이며, 도입을 검토한다면 DNSSEC 적용과 함께 판매 의사가 사라진 순간 레코드를 즉시 제거하는 운영 규율을 함께 세워 두는 편이 안전하다.