ドメイン名バリデーター（RFC準拠チェック）
ドメイン名がRFC 1035/1123の構文ルールに準拠しているかチェックします。ラベル長・全体の長さ・使用可能文字・ハイフンの位置などをルールごとに検証し、違反があれば具体的な理由を表示します。
ドメイン名バリデーターとは
ドメイン名バリデーターは、入力した文字列がRFC 1035（1987年制定）およびRFC 1123（1989年制定）が定めるドメイン名の構文ルールに準拠しているかを、ルールごとに分解して判定するツールです。「有効か無効か」という一言の結論だけでなく、どのルールに違反しているのか・違反しているとすればどのラベル（`.`で区切られた各部分）が原因なのかを個別に表示するため、なぜ弾かれるのかが分からず困っているケースの原因特定に向いています。
このツールが検証するのはあくまで構文（文字列としての形式）であり、そのドメインが実際にDNS上に登録されている・Webサイトが稼働している・取得可能である、といった実在性は確認しません。逆に言えば、まだ取得していない新規ドメイン名の候補や、開発中のホスト名が「構文として正しいか」を、実際にDNS登録する前に確認する用途に適しています。
ドメイン名バリデーターの使い方
- ドメイン名を入力する 入力欄にチェックしたいドメイン名（例: example.com）を入力します。先頭のプロトコル（`https://`等）やパス（`/path`等）は取り除いてドメイン部分だけを入力してください。
- 判定結果を確認する 入力するとリアルタイムで6つのルールが評価され、それぞれ「合格」「違反」「参考」のいずれかで表示されます。
- 違反理由を読む 「違反」と表示された行には、該当するラベルや文字数など具体的な理由が添えられます。どの部分を直せばよいかはここで判断できます。
- サンプルボタンで挙動を確かめる 「有効な例」「無効な例」ボタンを押すと、境界値を含むサンプル文字列が入力され、各ルールの判定挙動を素早く確認できます。
使いこなすためのヒント
- このツールはRFC 1035/1123が定める構文ルールに沿って検証するもので、実際にそのドメインが登録・使用可能か（DNS上に存在するか）までは確認しません。
- フォームのバリデーションルール（正規表現）を自作する前に、まずこのツールで境界値（63文字ちょうど・ハイフンの位置など）の挙動を確認しておくと、実装時の考慮漏れを防げます。
- 日本語ドメインなど非ASCII文字を含む入力は、文字種チェックのみ判定不能として扱われます。正確に検証したい場合はPunycode変換ツールで `xn--` 表記に変換してから入力してください。
- TLDが数字のみになるケースは実務ではほぼ発生しませんが、ユーザー入力のバリデーションで「IPアドレスとの誤認」を防ぐ目的で意図的にチェック項目に含めています。
- メールアドレスの `@` より後ろの部分（ドメイン部）にもそのまま同じルールを適用できるため、メールアドレスの簡易チェックにも流用できます。
こんな場面で使えます
フォームの入力チェックの実装前確認
自作の正規表現でドメイン入力欄のバリデーションを実装する前に、63文字ちょうどのラベルやハイフンの位置といった境界値をこのツールで確認しておくと、実装時の考慮漏れに気付けます。
新規ドメイン名候補の事前チェック
サービス名やサブドメインの候補を決める際、レジストラで検索する前に構文上問題がないかをまず確認できます。
メールアドレスのドメイン部の簡易検証
メールアドレスの`@`より後ろの部分は基本的に同じホスト名ルールに従うため、メールアドレス検証ロジックの副検証としても利用できます。
エラーの原因調査
システムで「無効なドメイン名です」と弾かれた文字列がなぜ弾かれるのか分からないとき、貼り付けて原因のルールを特定できます。
用語集
- ラベル
- ドメイン名を`.`（ドット）で区切った各部分のこと。`www.example.com`であれば「www」「example」「com」の3つがラベルです。RFC 1035はラベル単位で長さや使用可能文字を制限しています。
- TLD（トップレベルドメイン）
- ドメイン名の末尾にある最も右側のラベルのこと。`.com`や`.jp`など、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アドレスとして扱う」という判定を行っています。