# net.hostname-validate
Checks that a text is a usable host name and returns its normal form:
lower-case, with one trailing dot (the DNS root, as in a fully qualified
`www.example.com.`) removed. It never throws; an invalid name comes back with
`valid: false`, a `reason`, and how many labels it had.
## Rules, in the order they are checked
The first rule that fails is the reason.
1. Not empty (`""` and `"."` are `empty`).
2. Only ASCII letters, digits, hyphens and dots. No underscores (allowed in
some DNS record names such as `_sip._tcp`, never in a host name), no
spaces, no trailing newline, nothing non-ASCII: an internationalised name
must be converted to its `xn--` punycode form first.
3. At most 253 characters, not counting the trailing dot (RFC 1035 section
2.3.4 allows 255 octets on the wire, which is 253 characters of text).
4. Every label is 1 to 63 characters (RFC 1035 2.3.4) and does not start or
end with a hyphen (RFC 952). A label may start with a digit: RFC 1123
section 2.1 relaxed RFC 952 on that point, so `3com.example` is fine.
5. The last label is not all digits (RFC 3696 section 2). This keeps
`192.168.1.1` an address, not a name, so a caller can try the IP parsers
first and fall back to this without ambiguity.
## Not checked
Whether the name resolves, whether its top-level domain exists, and the rules
for other DNS record names (underscores, wildcards). `labels` is counted even
when the name is invalid, from the text with one trailing dot removed.
Sources: RFC 952 (DoD Internet Host Table Specification), RFC 1123 section 2.1
(Requirements for Internet Hosts), RFC 1035 section 2.3.4 (size limits),
RFC 3696 section 2 (Application Techniques for Checking and Transformation of
Names).