도메인 이름 검증기 (RFC 준수 여부 확인)
도메인 이름이 RFC 1035/1123 구문 규칙을 준수하는지 확인합니다. 라벨 길이, 전체 길이, 사용 가능한 문자, 하이픈 위치를 개별적으로 검증하고, 위반 사항이 있으면 구체적인 이유를 표시합니다.
도메인 이름 검증기란
도메인 이름 검증기는 입력한 문자열이 RFC 1035(1987년 제정)와 RFC 1123(1989년 제정)이 정한 도메인 이름 구문 규칙을 준수하는지 각 규칙별로 나누어 판정하는 도구입니다. "유효한지 아닌지"라는 한마디 결론만 보여주는 것이 아니라, 어떤 규칙을 위반했는지, 위반했다면 어느 라벨(`.`로 구분된 각 부분)이 원인인지를 개별적으로 표시하기 때문에, 왜 거부되는지 알 수 없어 곤란한 상황의 원인을 파악하는 데 적합합니다.
이 도구가 검증하는 것은 어디까지나 구문(문자열로서의 형식)이며, 해당 도메인이 실제로 DNS에 등록되어 있는지, 웹사이트가 운영되고 있는지, 등록 가능한 상태인지와 같은 실재 여부는 확인하지 않습니다. 다시 말해, 아직 등록하지 않은 새 도메인 이름 후보나 개발 중인 호스트 이름이 "구문상 올바른지"를 실제로 DNS에 등록하기 전에 미리 확인하는 용도에 적합합니다.
도메인 이름 검증기 사용 방법
- 도메인 이름을 입력한다 입력란에 확인하고 싶은 도메인 이름(예: example.com)을 입력합니다. 앞부분의 프로토콜(`https://` 등)이나 경로(`/path` 등)는 제거하고 도메인 부분만 입력해 주세요.
- 판정 결과를 확인한다 입력하면 실시간으로 6가지 규칙이 평가되어 각각 "통과", "위반", "참고" 중 하나로 표시됩니다.
- 위반 이유를 읽는다 "위반"으로 표시된 항목에는 해당 라벨이나 글자 수 등 구체적인 이유가 함께 표시됩니다. 어느 부분을 고쳐야 하는지 여기서 판단할 수 있습니다.
- 예시 버튼으로 동작을 확인한다 "유효한 예시", "유효하지 않은 예시" 버튼을 누르면 경계값을 포함한 예시 문자열이 입력되어 각 규칙의 판정 동작을 빠르게 확인할 수 있습니다.
더 잘 활용하기 위한 팁
- 이 도구는 RFC 1035/1123에서 정한 구문 규칙에 따라 검증하는 것으로, 해당 도메인이 실제로 등록되어 있는지 또는 DNS로 확인 가능한지까지는 확인하지 않습니다.
- 폼(form)의 검증용 정규식을 직접 작성하기 전에, 이 도구로 경계값(정확히 63자, 하이픈 위치 등)의 판정 결과를 먼저 확인해 두면 구현 누락을 방지할 수 있습니다.
- 일본어 도메인 등 비ASCII 문자가 포함된 입력은 문자 종류 검사만 판정 불가로 처리됩니다. 정확히 검증하려면 Punycode 변환 도구로 `xn--` 표기로 변환한 뒤 입력해 주세요.
- TLD가 숫자로만 구성되는 경우는 실무에서 거의 발생하지 않지만, 폼 검증 시 IP 주소와의 혼동을 방지할 목적으로 검사 항목에 의도적으로 포함했습니다.
- 이메일 주소의 `@` 뒤 부분(도메인 부분)에도 동일한 규칙을 그대로 적용할 수 있어, 이메일 주소의 간단한 검증에도 활용할 수 있습니다.
이런 상황에서 활용할 수 있습니다
폼 입력 검증 구현 전 사전 확인
직접 만든 정규식으로 도메인 입력란의 검증 로직을 구현하기 전에, 정확히 63자인 라벨이나 하이픈 위치 같은 경계값을 이 도구로 미리 확인해 두면 구현 시 놓치는 부분을 줄일 수 있습니다.
새 도메인 이름 후보 사전 점검
서비스명이나 서브도메인 후보를 정할 때, 레지스트라에서 검색하기 전에 구문상 문제가 없는지 먼저 확인할 수 있습니다.
이메일 주소 도메인 부분의 간단한 검증
이메일 주소의 `@` 뒷부분은 기본적으로 동일한 호스트 이름 규칙을 따르므로, 이메일 주소 검증 로직의 보조 확인 수단으로도 활용할 수 있습니다.
오류 원인 조사
시스템에서 "유효하지 않은 도메인 이름입니다"라며 거부된 문자열이 왜 거부되는지 알 수 없을 때, 이곳에 붙여넣어 원인이 되는 규칙을 특정할 수 있습니다.
용어집
- 라벨
- 도메인 이름을 `.`(마침표)으로 구분한 각 부분을 말합니다. www.example.com이라면 "www", "example", "com" 세 개가 라벨입니다. RFC 1035는 도메인 전체가 아니라 라벨 단위로 길이와 사용 가능한 문자를 제한합니다.
- TLD(최상위 도메인)
- 도메인 이름 끝에 있는 가장 오른쪽 라벨을 말합니다. .com이나 .kr처럼 DNS 계층 구조에서 가장 위에 위치하는 부분을 가리킵니다.
- FQDN(완전 정규화 도메인 이름)
- 호스트 이름부터 TLD까지 모든 계층을 생략 없이 기술한 도메인 이름을 말합니다. 끝에 루트를 나타내는 마침표(예: example.com.)를 붙인 표기가 본래의 FQDN이지만, 실무에서는 생략되는 경우가 많습니다.
- IDN(국제화 도메인 이름)
- 한국어·일본어·중국어·아랍어 등 ASCII가 아닌 문자를 포함하는 도메인 이름을 말합니다. DNS는 원래 ASCII 문자만 다룰 수 있기 때문에, 실제 등록 및 통신 시에는 Punycode로 변환됩니다.
- Punycode
- IDN의 ASCII가 아닌 문자 부분을 DNS가 다룰 수 있는 ASCII 문자열(`xn--`로 시작하는 표기)로 변환하는 인코딩 방식입니다. 브라우저 주소창에서는 일반적으로 원래 문자 표기로 되돌려 표시됩니다.
- 와이어 포맷
- DNS 질의와 응답이 실제로 네트워크상에서 주고받아질 때 사용되는 이진 형식을 말합니다. 각 라벨 앞에 길이를 나타내는 1바이트가 놓이는 구조로 되어 있으며, 이것이 라벨 길이 63자 제한의 기술적 근거가 됩니다.
- 호스트 이름
- 네트워크상의 기기를 식별하는 이름을 말합니다. 도메인 이름의 한 종류이지만, RFC 1123은 호스트 이름에 사용할 수 있는 문자를 영숫자와 하이픈만으로 제한하고 있으며, 이 도구는 이 호스트 이름 규칙에 따라 검증합니다.
자주 묻는 질문
여담이지만 ― "도메인 이름 검증"이 계속해서 재발명되는 이유
도메인 이름의 구문 검사는 언뜻 보면 정규식 하나로 간단히 해결될 것 같지만, 실제로는 많은 개발자가 직접 구현하다가 어려움을 겪어 온 영역입니다. 폼의 이메일 검증, 설정 파일의 호스트 이름 파싱, API의 URL 검증 등 온갖 상황에서 "도메인처럼 보이는 문자열"을 다뤄야 하지만, RFC 1035(1987년)와 RFC 1123(1989년)이 정한 공식 규칙을 정확하게 반영한 구현은 의외로 많지 않습니다.
예를 들어 "라벨은 63자 이내", "전체는 253자 이내"라는 2단계 길이 제한은 DNS의 와이어 포맷(실제로 네트워크상에서 주고받는 이진 형식) 설계에서 비롯된 것입니다. 각 라벨 앞에는 길이를 나타내는 1바이트가 붙는데, 그 값이 0〜63(6비트로 표현 가능한 최댓값)으로 제한되어 있다는 점이 라벨 길이 제한의 직접적인 이유가 됩니다.
TLD가 숫자로만 구성되어서는 안 된다는 관례에도 흥미로운 역사가 있습니다. 이는 RFC에 명문화된 필수 규칙이 아니라, IPv4 주소(숫자와 점으로 이루어진 나열)와 도메인 이름을 구별하기 위한 구현상의 지혜로 널리 채택되어 온 것입니다. 많은 DNS 리졸버와 브라우저는 이 관례를 이용해 "192.168.1.1과 같은 문자열은 도메인 이름이 아니라 IP 주소로 처리한다"는 판단을 내리고 있습니다.