도메인 이름 검증기 (RFC 준수 여부 확인)
도메인 이름이 RFC 1035/1123 구문 규칙을 준수하는지 확인합니다. 라벨 길이, 전체 길이, 사용 가능한 문자, 하이픈 위치를 개별적으로 검증하고, 위반 사항이 있으면 구체적인 이유를 표시합니다.
사용 팁
- 이 도구는 RFC 1035/1123에서 정한 구문 규칙에 따라 검증하는 것으로, 해당 도메인이 실제로 등록되어 있는지 또는 DNS로 확인 가능한지까지는 확인하지 않습니다.
- 폼(form)의 검증용 정규식을 직접 작성하기 전에, 이 도구로 경계값(정확히 63자, 하이픈 위치 등)의 판정 결과를 먼저 확인해 두면 구현 누락을 방지할 수 있습니다.
- 일본어 도메인 등 비ASCII 문자가 포함된 입력은 문자 종류 검사만 판정 불가로 처리됩니다. 정확히 검증하려면 Punycode 변환 도구로 `xn--` 표기로 변환한 뒤 입력해 주세요.
- TLD가 숫자로만 구성되는 경우는 실무에서 거의 발생하지 않지만, 폼 검증 시 IP 주소와의 혼동을 방지할 목적으로 검사 항목에 의도적으로 포함했습니다.
- 이메일 주소의 `@` 뒤 부분(도메인 부분)에도 동일한 규칙을 그대로 적용할 수 있어, 이메일 주소의 간단한 검증에도 활용할 수 있습니다.
자주 묻는 질문
RFC 1035에 따르면 라벨(`.`로 구분된 각 부분)은 1〜63자, 도메인 전체는 253자(전송 형식에서의 255옥텟 제한에서 유래)까지 허용됩니다. 다만 실제로 등록 가능한 문자 수는 각 레지스트리의 정책에 따라 추가로 제한될 수 있습니다.
RFC 1035/1123에 따르면 호스트 이름에는 영숫자와 하이픈만 사용할 수 있으며 밑줄은 허용되지 않습니다. 다만 TXT나 SRV 레코드 등 호스트 이름이 아닌 용도의 DNS 라벨(예: `_dmarc.example.com`)에서는 밑줄이 사용되기도 합니다.
RFC 1123에서는 각 라벨이 영숫자 문자로 시작하고 끝나야 한다고 규정합니다. 하이픈을 처음이나 끝에 두면 구문 분석이 모호해지기 쉽고, 오래된 DNS 구현과의 호환성 문제가 발생할 위험이 있어 이를 방지하기 위한 규정입니다.
일본어 등을 포함하는 국제화 도메인 이름(IDN)은 DNS에 등록되기 전에 반드시 Punycode(`xn--`로 시작하는 ASCII 표기)로 변환되어야 합니다. 이 도구는 Punycode로 변환된 문자열을 검증하도록 설계되어 있으므로, 비ASCII 도메인은 먼저 Punycode 변환 도구로 변환한 뒤 이곳에서 구문 검사를 진행하는 것을 권장합니다.
여담이지만 ― "도메인 이름 검증"이 계속해서 재발명되는 이유
도메인 이름의 구문 검사는 언뜻 보면 정규식 하나로 간단히 해결될 것 같지만, 실제로는 많은 개발자가 직접 구현하다가 어려움을 겪어 온 영역이다. 폼의 이메일 검증, 설정 파일의 호스트 이름 파싱, 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 주소로 처리한다"는 판단을 내리고 있다.