도메인이 스스로 팔린다고 말하는 방법 — DNS는 언제부터 주장을 싣는 채널이 되었나

• 잘 뜨는 도메인이 사실은 팔린다는 것
• DNS는 오래전부터 이름 해석 이상의 일을 해 왔습니다
• 밑줄 이름이 하는 일
• RFC 10023이 정의한 레코드
• 태그 네 개와 제약들
• 이 방식이 싼 이유
• 그리고 이 방식이 신뢰를 주지 못하는 이유
• 우리 도메인에 붙인다면
• 정리와 출처

잘 뜨는 도메인이 사실은 팔린다는 것

찾던 도메인이 이미 등록되어 있습니다. 열어 보니 사이트도 멀쩡히 뜹니다. 여기서 보통은 포기합니다. 그런데 그중 상당수는 사실 팔 의사가 있습니다.

문제는 그 사실을 알아낼 방법이 기계에게 없다는 것입니다. 사람이라면 사이트에 적힌 연락처를 찾아 메일을 보내 볼 수 있지만, 도메인 검색 도구나 등록 대행사가 수백만 개의 도메인에 대해 그 일을 할 수는 없습니다. 등록 정보에도 팔 의사는 적혀 있지 않습니다. 등록되어 있다는 사실과 팔 의사가 있다는 사실은 서로 다른 층위의 정보인데, 후자를 담을 자리가 없었던 겁니다.

DNS는 오래전부터 이름 해석 이상의 일을 해 왔습니다

이 문제에 대한 답이 최근 RFC로 나왔는데, 답 자체보다 답이 놓인 자리가 흥미롭습니다. DNS입니다.

우리는 DNS를 이름을 주소로 바꾸는 시스템이라고 배웁니다. 그런데 실제 운영에서 우리가 DNS에 넣는 것 중 상당수는 주소가 아닙니다. 어떤 서버가 이 도메인 이름으로 메일을 보내도 되는지를 적고, 서명 검증에 쓸 공개 키를 적고, 인증서를 어느 기관이 발급해도 되는지를 적고, 인증서를 받기 위해 이 도메인을 통제하고 있다는 증거를 잠깐 올려 둡니다.

이것들의 공통점은 전부 이 도메인에 관한 주장이라는 점입니다. 그리고 그 주장을 도메인 소유자만 쓸 수 있는 자리에 올려 둔다는 점입니다. DNS가 진짜로 제공하는 것은 이름 해석이라기보다, 도메인 소유자만 쓸 수 있고 누구나 읽을 수 있는 전 세계 공개 게시판에 가깝습니다.

밑줄 이름이 하는 일

이 게시판이 서로 충돌하지 않고 굴러가는 이유가 밑줄입니다.

TXT 레코드는 아무 내용이나 담을 수 있어서, 한 도메인에 여러 용도의 TXT가 섞이면 읽는 쪽이 내용을 뜯어봐야 자기 것을 골라낼 수 있습니다. 이 문제를 정리한 것이 2019년의 RFC 8552입니다. 이 문서는 용도별로 밑줄로 시작하는 하위 노드를 두고, 그 아래의 레코드만 해당 용도로 해석하도록 규칙을 세웠습니다. 그리고 IANA에 밑줄 노드 이름 등록부를 만들어 서로 겹치지 않게 관리하도록 했습니다.

밑줄을 쓴 이유가 핵심입니다. 호스트 이름 규칙은 밑줄을 허용하지 않습니다. 그래서 밑줄로 시작하는 이름은 어떤 실제 호스트와도 절대 충돌하지 않습니다. 이미 널리 쓰이던 _dmarc, _domainkey, _acme-challenge 같은 이름들이 이 규칙 아래로 들어왔습니다.

RFC 10023이 정의한 레코드

이번에 추가된 것이 RFC 10023입니다. SIDN Labs의 Marco Davids가 쓴 정보성 문서이고 2026년 7월에 나왔습니다. 이름은 _for-sale입니다.

동작은 이렇습니다. example.com을 팔 의사가 있다면 _for-sale.example.com에 TXT 레코드를 하나 둡니다. 원래 도메인은 그대로 잘 동작합니다. 사이트도 그대로 뜨고 메일도 그대로 갑니다. 신호만 옆에 붙는 겁니다.

레코드의 내용은 255옥텟짜리 문자열 조각 하나이고, 반드시 버전 태그로 시작합니다. 그 뒤에 태그-값 쌍을 최대 하나만 붙일 수 있습니다.

_for-sale IN TXT "v=FORSALE1;"
_for-sale IN TXT "v=FORSALE1;ftxt=Call for info."
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/foo%20bar"
_for-sale IN TXT "v=FORSALE1;fval=EUR999"
_for-sale IN TXT "v=FORSALE1;fval=BTC0.000010"

첫 줄처럼 태그 없이 버전만 있는 것도 유효합니다. 팔 의사가 있다는 사실만 알리고 나머지는 말하지 않는 형태입니다.

태그 네 개와 제약들

정의된 태그는 넷입니다.

제약도 명세에 분명히 적혀 있습니다. 한 레코드에 태그-값 쌍은 하나를 넘을 수 없습니다. 와일드카드 형태는 규격에 맞지 않습니다. 캐시 유효 시간은 3600초 이하가 권장됩니다. 그리고 팔 의사가 없다는 취지의 내용을 적는 것은 유효하지 않은 사용으로 간주됩니다.

가격 표기가 통화 기호가 아니라 통화 코드라는 점도 눈여겨볼 만합니다. 기호는 나라마다 겹치고 문자 집합 문제를 일으키지만 코드는 그렇지 않습니다. 작은 결정처럼 보여도 자동 처리 쪽에서는 큰 차이입니다.

이 방식이 싼 이유

이 설계가 매력적인 이유는 아무것도 건드리지 않는다는 데 있습니다.

새 레코드 타입을 만들지 않았습니다. 만들었다면 해석기와 권한 서버와 관리 도구가 전부 대응해야 했을 겁니다. 대신 이미 어디서나 동작하는 TXT를 그대로 씁니다. 프로토콜도 바꾸지 않습니다. 그리고 원래 도메인의 운영에 영향이 없습니다. 살아 있는 사이트 옆에 조용히 붙었다가, 팔 생각이 없어지면 지우면 그만입니다.

이것이 밑줄 채널이 계속 쓰이는 이유이기도 합니다. 새 기능을 배포하는 가장 싼 방법이 이미 모두가 배포해 둔 것 위에 얹는 것이기 때문입니다. 메일 인증도, 인증서 발급 검증도 같은 경로로 퍼졌습니다.

그리고 이 방식이 신뢰를 주지 못하는 이유

싼 데는 이유가 있습니다. 이 채널에 실리는 것은 전부 검증되지 않은 자기 주장입니다. 도메인을 통제한다는 것 외에는 아무것도 보증하지 않습니다.

RFC 10023은 이 점에 대해 놀랄 만큼 솔직합니다. 보안 절에서 짚는 위험만 봐도 그렇습니다. 값을 그대로 화면에 뿌리면 스크립트 삽입이나 질의 삽입이 될 수 있고, 동형 이의 문자나 양방향 텍스트를 이용해 사람이 읽는 값을 속일 수 있으며, furi가 가리키는 곳이 악성 사이트일 수 있고, 터무니없이 낮은 가격을 적어 구매자를 유인할 수 있습니다. 그래서 문서는 처리하는 쪽이 값을 반드시 정제하고 URI의 평판을 확인하며, 가격은 참고용이며 판매자에게 확인해야 한다는 취지의 안내를 함께 보여 주라고 권고합니다.

가장 분명한 금지 사항도 있습니다. furi의 내용을 만나더라도 사용자의 명시적 확인 없이 자동으로 이동시켜서는 안 된다는 것입니다. DNS 레코드에 적힌 주소로 사용자를 그냥 보내는 순간, 도메인을 잠깐 손에 넣은 사람이 그 링크의 도착지를 정할 수 있게 됩니다.

사생활 쪽 위험도 문서가 직접 적습니다. 판다는 의사를 공개하는 것 자체가 정보의 노출이고, 적어 둔 연락처는 수집되어 스팸의 대상이 됩니다.

우리 도메인에 붙인다면

정리하면 체크리스트는 이렇습니다.

1. 정말 팔 생각이 있을 때만 붙입니다. 명세가 그렇게 정하고 있습니다.
2. 캐시 유효 시간을 짧게 잡습니다. 3600초 이하가 권장입니다. 마음이 바뀌었는데 하루 내내 팔린다고 광고되는 상황을 피하려면 필요합니다.
3. 연락 수단을 새로 만듭니다. 기존 업무용 주소를 적지 마시기 바랍니다. 공개 레코드에 적힌 주소는 수집됩니다.
4. 가격을 적을지 신중히 정합니다. 정보성 RFC는 형식만 정하고 협상 전략을 정해 주지 않습니다. 적어 둔 숫자가 상한이 됩니다.
5. 읽는 쪽을 만든다면 자동 신뢰를 금지합니다. 값을 그대로 렌더링하지 말고, 자동 이동을 넣지 말고, 이 정보가 판매자의 주장일 뿐이라는 점을 화면에 표시합니다.
6. 팔 생각이 없어지면 지웁니다. 레코드를 지우는 것만으로 신호가 사라진다는 점이 이 방식의 가장 큰 장점입니다.

정리와 출처

이 RFC를 도메인 거래에 관한 문서로만 읽으면 작아 보입니다. 더 값이 나가는 부분은 패턴입니다. 배포된 인프라 위에 밑줄 이름 하나를 얹어 새 의미를 싣는 방식이 얼마나 싸고, 그 대가로 신뢰가 얼마나 없는지를 한 문서 안에서 다 보여 줍니다. 사내 시스템에서 같은 유혹을 느낄 때 이 두 면을 함께 보시기 바랍니다.

• RFC 10023 — The _for-sale Underscored and Globally Scoped DNS Node Name — Marco Davids, SIDN Labs, 정보성, 2026년 7월. 레코드 문법, 태그 네 개와 길이 제한, 예시, 캐시 유효 시간 권고, 자동 이동 금지, 보안과 사생활 고려사항을 모두 이 문서에서 확인했습니다.
• RFC 8552 — Scoped Interpretation of DNS Resource Records through Underscored Naming of Attribute Leaves — 2019년 3월, BCP 222. 밑줄 이름 등록부와 밑줄을 쓰는 이유를 확인했습니다.
• 본문 마지막의 체크리스트는 위 두 문서의 규정과 권고를 실무 형태로 옮긴 것이며, 그 자체가 명세에 실려 있는 목록은 아닙니다.