FQDN Validator

The FQDN Validator verifies whether a domain name is a properly formatted Fully Qualified Domain Name with valid labels, a recognized top-level domain (TLD), and correct overall structure. Enter a value like mail.example.com or shop.example.co.uk to check if it qualifies as a valid FQDN, with detailed feedback on any structural or TLD issues found.

Understanding Fully Qualified Domain Names

A Fully Qualified Domain Name is the complete address of a host in the DNS hierarchy, from the specific machine all the way up to the root. When you type www.example.com into a browser, that is an FQDN because it specifies exactly where in the global DNS tree the server lives. Compare that with a relative name like www, which only makes sense if your system knows to append a search domain like example.com. FQDNs remove that ambiguity entirely, and that is why they are required in so many places: TLS certificates, mail server configuration, DNS zone files, and API endpoint definitions.

The distinction matters more than most administrators realize. A certificate issued for mail means nothing outside your local network, but a certificate for mail.example.com is globally unique and verifiable. When you configure an MX record, the target must be an FQDN because mail servers around the world need to resolve it without knowing your local DNS search domains. When BIND loads a zone file, any name without a trailing dot is treated as relative to the zone origin, and forgetting that trailing dot on what you intended as an FQDN is one of the most common DNS configuration mistakes.

This validator checks all the structural requirements of an FQDN: at least two labels (hostname plus TLD), each label following RFC 1123 syntax, a recognized TLD from the IANA registry or valid special-use TLD, total length within DNS limits, and correct Punycode encoding for internationalized domains. It catches problems before they cause certificate rejections, DNS resolution failures, or misconfigured services.

How to Validate a Fully Qualified Domain Name

1. Enter the domain name to validate (e.g., mail.example.com or shop.example.co.uk)
2. The tool checks label syntax, TLD validity, length limits, and overall FQDN structure
3. Review the result showing whether the input qualifies as a valid FQDN
4. If invalid, read the specific violation details to correct the domain name

FQDN Validation Examples

When to Use the FQDN Validator

• TLS certificate requests -- Certificate authorities require valid FQDNs in Common Name and SAN fields; invalid domains cause CSR rejection
• DNS zone configuration -- Verifying domain names before adding records prevents zone loading failures
• Email server setup -- MX records, SPF includes, and mail routing depend on valid FQDNs
• Security and threat analysis -- Validating domains from logs or threat feeds before performing reputation lookups
• Application configuration -- API endpoints, webhook URLs, and service discovery entries need properly formatted domains
• Domain registration checks -- Confirming name validity before attempting registration with a registrar

How FQDN Structure Works

A Fully Qualified Domain Name specifies an exact location in the DNS hierarchy, from a specific host all the way up to the root. Unlike relative names, FQDNs are unambiguous regardless of the DNS search domain configured on a client.

FQDN Components

For mail.staging.example.co.uk:

• Subdomain labels: mail, staging -- identify the specific host and environment
• Second-level domain: example -- the registered domain name
• Top-level domain: co.uk -- the public suffix under which the domain is registered
• Implicit root: The empty label at the end of the DNS tree (represented by a trailing dot)

Validation Checks Performed

1. Label count: At least two labels are required (hostname + TLD)
2. Label syntax: Each label follows RFC 1123 rules (alphanumeric + hyphens, 1-63 characters)
3. TLD recognition: The rightmost labels must match an IANA-registered public suffix or a known special-use TLD
4. Total length: The complete FQDN must not exceed 253 characters
5. Punycode validation: Labels starting with xn-- are checked for valid internationalized encoding

Internationalized Domain Names (IDNs)

Domains containing non-ASCII characters like munchen.de or unicode scripts are encoded using Punycode in DNS. The encoded form uses an xn-- prefix, for example xn--mnchen-3ya.de. The validator checks both the Punycode encoding and the decoded Unicode characters to ensure the IDN is valid.

FQDN Validation in Practice

The most important thing to understand about FQDN validation is that it is a structural check, not a liveness check. A domain can be perfectly valid as an FQDN and still not exist in DNS. The validator tells you whether the name is well-formed and would be accepted by DNS software, certificate authorities, and other systems that require FQDNs. Whether someone has actually registered the domain and set up DNS records for it is a separate question.

One common source of confusion is the difference between TLD validation and domain existence. The validator checks whether the TLD is recognized by IANA, which means it has been delegated in the root zone. But having a valid TLD does not mean the second-level domain is registered. totally-fake-domain-12345.com has a valid TLD (.com) and passes FQDN structural validation, but it almost certainly does not exist in DNS. If you need to check whether a domain actually resolves, you need a DNS lookup tool, not just an FQDN validator.

Another area where administrators get tripped up is the handling of special-use TLDs. Names like server.local, host.internal, and router.home.arpa use TLDs that are reserved for special purposes and are not part of the global DNS. The validator recognizes these as valid FQDNs because they are legitimate in their intended contexts (mDNS, private networks, etc.), but they will never resolve on the public internet. If you are validating domains for public-facing services like TLS certificates or MX records, you should also verify that the TLD is a publicly resolvable one, not just structurally valid.

Watch out for the trailing dot distinction. In DNS protocol and BIND zone files, the trailing dot marks a name as absolute. In nearly every other context (browsers, application configs, certificate requests), the trailing dot is omitted. Both example.com and example.com. are valid FQDNs, but using the wrong form in the wrong context causes problems. Zone files without trailing dots on external targets are one of the most frequent sources of DNS misconfiguration.

Frequently Asked Questions

What makes a domain "fully qualified" versus just a hostname?

A fully qualified domain name includes all labels from the host to the top-level domain, providing an absolute path in the DNS hierarchy. The hostname mail is relative and depends on the local DNS search domain, but mail.example.com is fully qualified and resolves the same way everywhere. In BIND configuration, an FQDN is indicated by a trailing dot (mail.example.com.), but in most other contexts the trailing dot is optional.

Does the FQDN validator perform live DNS lookups?

No. The validator checks the structural correctness of the domain name without performing DNS resolution. A domain can be syntactically valid as an FQDN but not actually exist in DNS. This offline validation is useful for checking names before they are registered or configured.

How does the validator handle new generic TLDs like .app or .dev?

The validator uses the IANA TLD registry, which includes all delegated top-level domains. New gTLDs like .app, .dev, .io, and hundreds of others added through ICANN's new gTLD program are recognized as valid. The registry is periodically updated to include newly delegated TLDs.

Can an IP address be an FQDN?

No. An FQDN is a domain name in the DNS hierarchy, composed of labels separated by dots. While an IPv4 address like 192.168.1.1 superficially resembles a dotted name, it is not a domain name and does not pass FQDN validation. IP addresses and domain names are fundamentally different identifiers, even though they are related through DNS resolution.

What is the difference between this tool and the Hostname Validator?

The Hostname Validator checks RFC 1123 syntax rules for individual hostnames, including single-label names like localhost. The FQDN Validator goes further by requiring at least two labels and verifying that the TLD is recognized by IANA. Use the Hostname Validator for general hostname syntax checking; use the FQDN Validator when you need to confirm a name is globally unique and complete.

How are .local and other special-use TLDs handled?

Special-use TLDs like .local (mDNS), .onion (Tor), .test, and .home.arpa are recognized as valid because they are formally reserved by IANA for specific purposes. The validator accepts them as structurally valid FQDNs, though they will not resolve on the public internet.

Related Tools

• Hostname Validator - Validate hostnames per RFC 1123 standards
• Root Domain Extractor - Extract the registrable domain using the Public Suffix List
• URL → Hostname Extractor - Extract hostnames from URLs in bulk
• Subdomain Extractor - Extract subdomains from hostnames in bulk
• BIND Zone A/AAAA Generator - Generate BIND zone A and AAAA records from CSV