ドメイン名バリデーター（RFC準拠チェック）
ドメイン名がRFC 1035/1123の構文ルールに準拠しているかチェックします。ラベル長・全体の長さ・使用可能文字・ハイフンの位置などをルールごとに検証し、違反があれば具体的な理由を表示します。
使い方のヒント
- このツールはRFC 1035/1123が定める構文ルールに沿って検証するもので、実際にそのドメインが登録・使用可能か（DNS上に存在するか）までは確認しません。
- フォームのバリデーションルール（正規表現）を自作する前に、まずこのツールで境界値（63文字ちょうど・ハイフンの位置など）の挙動を確認しておくと、実装時の考慮漏れを防げます。
- 日本語ドメインなど非ASCII文字を含む入力は、文字種チェックのみ判定不能として扱われます。正確に検証したい場合はPunycode変換ツールで `xn--` 表記に変換してから入力してください。
- TLDが数字のみになるケースは実務ではほぼ発生しませんが、ユーザー入力のバリデーションで「IPアドレスとの誤認」を防ぐ目的で意図的にチェック項目に含めています。
- メールアドレスの `@` より後ろの部分（ドメイン部）にもそのまま同じルールを適用できるため、メールアドレスの簡易チェックにも流用できます。
よくある質問
RFC 1035により、ラベル（`.`で区切られた各部分）は1〜63文字、ドメイン全体では253文字（ワイヤーフォーマットでの255オクテット制限に由来）までと定められています。ただし実際に取得可能な文字数は各レジストリのポリシーによってさらに制限されている場合があります。
RFC 1035/1123上、ホスト名として使えるのは英数字とハイフンのみで、アンダースコアは許可されていません。ただしDNSのTXTレコードやSRVレコードのラベル（例: `_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アドレスとして扱う」という判定を行っています。