• RFC 10023은 운영 중인 도메인도
  _for-sale

TXT 레코드로 구매 가능 상태임을 브로커와 자동화 서비스에 알리는 규약을 정의함

• 도메인 파킹과 달리 기존
  웹·메일 서비스를 그대로 유지할 수 있으며, 판매 신호도 브라우저에 노출되지 않음
• 레코드는 필수 버전
  v=FORSALE1;

과 최대 1개의 tag=value

쌍으로 구성되며, 설명·연락처 URI·희망 가격·독점 코드를 전달할 수 있음

• 레코드마다 태그 하나와 255옥텟 이하의 문자열 하나만 사용하고,
  TTL은 3,600초 이하로 설정하며 판매 의사가 사라지면 삭제해야 함
• 공개된 가격은 판매 약속이 아니며 텍스트와 URI가 조작될 수 있으므로, 처리기는 내용을 정제하고 사용자 확인 없이 링크로 자동 이동해서는 안 됨

_for-sale

이 보내는 판매 신호

_for-sale

은 2026년 7월 Informational 문서인 RFC 10023이 정의하고 IANA에 등록한 예약 DNS 리프 노드 이름임
_for-sale.example.com

에 TXT

레코드를 게시하면 example.com

이 등록되어 정상 작동하는 동안에도 구매 가능하다는 신호를 보낼 수 있음

_for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale";

• 필수 버전 태그 뒤에는 최대 하나의 값을 추가함
  ftxt=

: 사람이 읽을 수 있는 자유 형식 텍스트
furi=

: 연락처 또는 정보 URI
fval=

: 통화 코드와 금액으로 구성된 희망 가격
fcod=

: 사전 합의에 따라 해석하는 독점 코드

도메인 파킹·등록 정보와의 차이

도메인 파킹은 기존 사이트를 판매 페이지로 교체해 방문자를 잃지만, _for-sale

은 운영 중인 사이트와 함께 존재하는 DNS 레코드이므로 홈페이지와 메일이 계속 작동함

• 필요할 때 레코드를 추가하거나 제거할 수 있고 브라우저에는 아무것도 표시되지 않으며, RFC도 활성 사용 중인 도메인을 대상으로 설계됨

• WHOIS와 RDAP는 도메인의
  등록 여부만 알려주며 구매 가능 여부는 나타내지 않음

• 등록된 이름도 판매 대상일 수 있음

• 미등록 이름이라고 반드시 가치가 있거나 구매할 만한 것은 아님

• 주요 이용자는 일반 방문자가 아니라
  브로커와 자동 가용성 확인 서비스임

DNS 판매 신호가 필요한 이유

• 판매 의사가 있어도 개인정보가 제거된 WHOIS 연락처로 콜드 이메일을 보내는 것 외에는 구매자가 이를 알아낼 방법이 부족함
• 환영할 만한 문의가 도착하지 않거나, 도착한 문의도
  스팸과 구분하기 어려움
• 브로커나 가용성 서비스는 도메인을 확인할 때 DNS를 조회하므로, 한 번의 추가 조회만으로 판매 여부를 확인할 수 있음
• 정상 운영 중인 홈페이지에는 기반 도메인의 가격 협상 가능 여부가 나타나지 않지만, DNS 레코드는 외부에서 검증할 수 있고 사이트 자체에는 영향을 주지 않음

게시 형식과 지원 값

• 판매하려는 존의
  _for-sale

리프에 판매 의사가 유지되는 동안 단일 TXT

레코드를 게시함

; 자유 형식 텍스트
_for-sale IN TXT "v=FORSALE1;ftxt=Serious offers only"
; 협상용 URI
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6";
; 희망 가격
_for-sale IN TXT "v=FORSALE1;fval=USD12500"

furi=

에서 사용할 수 있는 URI 스킴은 https

·mailto

·tel

임
fval=

은 대문자 통화 코드 뒤에 금액을 붙이는 형식임

레코드 작성 규칙

• 모든 레코드는 대소문자를 구분하는
  v=FORSALE1;

으로 시작해야 함

• DNS 와일드카드가
  _for-sale

이름으로 확장한 무관한 TXT

레코드와 실제 판매 레코드를 처리기가 구분하기 위한 장치임

• 레코드 하나에는
  tag=value

쌍을 하나만 넣어야 함

• 가격과 연락처 URI를 함께 제공하려면 같은 RRset에 레코드 두 개를 게시함

• SPF처럼 여러 쌍을 이어 붙이지 않으며, 처리기가 이해하는 레코드를 선택함

• 레코드마다
  문자열 하나만 허용되며 최대 길이는 255옥텟이므로 파싱할 때 재조립할 필요가 없음

• TTL은
  3,600초 이하로 유지해야 함

• 철회한 가격이나 이미 판매된 도메인을 알리는 오래된 캐시는 레코드가 없는 것보다 나쁨

_for-sale.example.com

은 DNS 트리의 어느 수준에서도 유효하지만 xyz._for-sale.example.com

은 유효하지 않음
.arpa

아래의 레코드는 주소 공간 판매가 범위 밖이므로 무시해야 함

• 더 이상 판매 대상이 아니면 레코드를 제거해야 함

• 별도의 “판매하지 않음” 값이 없으므로
  레코드 부재만이 이를 나타냄

• 가능하면 DNSSEC로 존을 서명해야 함

• 서명되지 않은 가격 및 연락처 레코드는 제3자가 위조할 수 있음

specification.website

자체에는 _for-sale

레코드가 없으며 판매 대상도 아님

구현 오류와 보안 주의점

"v=FORSALE1;fval=EUR2500;furi=https://…";

처럼 여러 쌍을 한 레코드에 넣으면 형식에 어긋남

• 태그마다 별도 레코드를 만들어 동일한 RRset에 배치해야 함

• 실제로 판매 가능하지 않은 도메인에 문의 유도용으로 게시해서는 안 됨

• 이 신호는 마케팅 배너가 아니며 RFC는 이런 사용을
  남용으로 규정함

• 레코드 공개가 소유자에게 판매 의무를 부과하지는 않음
  fval=

가격은 참고용이며 구매 약속이 아님

• 처리기는 면책 문구를 표시하고 이를 구매 확약으로 취급해서는 안 됨

_for-sale.*.example.com

은 유효한 와일드카드가 아니므로, 하나의 레코드로 TLD 아래 모든 도메인을 판매 대상으로 만들 수 없음

• 읽는 쪽에서는
  ftxt=

텍스트와 furi=

URI를 공격자가 통제하는 입력으로 취급해야 함

• 표시하기 전에 내용을 정제해야 하며 RFC 예시에도
  <script>...</script>

가 사용됨

• 명시적인 확인 없이 사용자를
  furi=

대상으로 자동 이동시켜서는 안 됨

레코드 검증 방법

dig +short TXT _for-sale.example.com

• 응답이
  v=FORSALE1;

으로 시작하고 문자열마다 tag=value

쌍이 최대 하나인지 확인함

• 다음 명령으로 TTL이 3,600 이하인지 확인함

dig TXT _for-sale.example.com | grep _for-sale

• 서명된 존에서는 다음 명령이 검증 가능한
  RRSIG

를 반환해야 함

dig +dnssec TXT _for-sale.example.com

• 도메인이 redemption 또는
  pendingDelete

상태이거나 DNSSEC 검증이 bogus이면 이름이 해석되지 않아 판매 신호도 조용히 사라짐

관련 규격과 참고 자료