Skip to main content

Python FQDN — Fully-Qualified Domain Names

CI CodeQL OSSAR codecov OpenSSF Scorecard PyPI version PyPI downloads License: MPL-2.0 Python versions Snyk FOSSA Status Ruff mypy pre-commit Read the Docs

This package validates Fully Qualified Domain Names (FQDNs) conforming to the Internet Engineering Task Force specification (see IETF Specification). The design intent is to validate that a string would be traditionally acceptable as a public Internet hostname to RFC-conforming software, which is a strict subset of the logic in modern web browsers like Mozilla Firefox and Chromium that determines whether to make a DNS lookup. Configuration options can relax constraints so that short hostnames without periods or others with underscores will be valid. These relaxations are closer to how modern web browsers work (see Notes).

>>> from fqdn import FQDN
>>> domain = 'bbc.co.uk'
>>> bbc_fqdn = FQDN(domain)
>>> bbc_fqdn.is_valid
True
>>> bbc_fqdn.absolute
'bbc.co.uk.'
>>> bbc_fqdn.relative
'bbc.co.uk'

Equality checks are implemented case insensitive conforming to the IETF specification:

>>> FQDN('BBC.CO.UK.') == FQDN('BbC.Co.uK')
True
>>> hash(FQDN('BBC.CO.UK.')) == hash(FQDN('BbC.Co.uK'))
True

Notes

  • Certificate authorities. Certificate authorities like Let's Encrypt run a narrower set of string validation logic to determine validity for issuance. This package is not intended to achieve functional parity with CA issuance, because they may have proprietary or custom logic. boulder's code is starkly different from Chromium's, as outlined in issue #14.
  • Browsers. See issue #14.

Standards Conformance

In the default configuration, this package adds only one additional constraint to the IETF specification, requiring a minimum of two labels, separated by periods. This extra restriction can be disabled. It is enabled by default to prevent breaking backwards compatibility. Review the tests for examples of the impact of this.

IETF Specification

The IETF specification restricts domain names to alphanumeric ASCII characters and hyphens as described below.

RFC 1123: Requirements for Internet Hosts - Application and Support, October 1989

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts.

2.1  Host Names and Numbers

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4].  One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit.  Host software MUST support this more liberal
syntax.

Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.

Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.

RFC 952: DoD Internet host table specification, October 1985

This RFC is the official specification of the format of the Internet Host Table.

<hname> ::= <name>*["."<name>]
<name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]

Commentary

RFC 1034: Domain Name Concepts and Facilities, November 1987

  • Section 3.5 specifies a "preferred name syntax", which is non-compulsory.

    3.5. Preferred name syntax
    
    The DNS specifications attempt to be as general as possible in the rules
    for constructing domain names.  The idea is that the name of any
    existing object can be expressed as a domain name with minimal changes.
    However, when assigning a domain name for an object, the prudent user
    will select a name which satisfies both the rules of the domain system
    and any existing rules for the object, whether these rules are published
    or implied by existing programs.
    
    For example, when naming a mail domain, the user should satisfy both the
    rules of this memo and those in RFC-822.  When creating a new host name,
    the old rules for HOSTS.TXT should be followed.  This avoids problems
    when old software is converted to use domain names.
    

RFC 1035: Domain Names - Implementation and Specification, November 1987

  • Section 2.3.1 repeats the "preferred name syntax" proposal from RFC 1034.

RFC 2181: Clarification to the DNS Specification, July 1997

  • Section 11 comments that RFC 1035 does not restrict domain names to the preferred name syntax set out in it. Instead Internet hostnames are restricted more or less by a combination of tradition and RFC 2181, where this package finds itself.

RFC 3696: Application Techniques for Checking and Transformation of Names, February 2004

  • This memo provides fascinating commentary of the history of string validation for domain names.

Licenses

FOSSA Status

Metadata

Release files for fqdn 1.6.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for fqdn 1.6.0
File Size Uploaded
fqdn-1.6.0.tar.gz 130.7 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for fqdn 1.6.0
File Interpreter ABI Platform
fqdn-1.6.0-py3-none-any.whl Python 3 none any Details

Total release size: 143.3 kB

Release files / fqdn-1.6.0.tar.gz

Download URL fqdn-1.6.0.tar.gz
Size 130.7 kB
Tags Source
SHA-256 checksum
How to use checksums
e39bf62e2a9481aa2cb780554fdfd944dd8ee5f230eb831684d539cbafed8de2
BLAKE2b-256 checksum
How to use checksums
0201248d44fbda9e78fa1a7b5a475194bef4c4a3e285db286419f3bb42f2efdf
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 28, 2026.

Transparency log

Release files / fqdn-1.6.0-py3-none-any.whl

Download URL fqdn-1.6.0-py3-none-any.whl
Size 12.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
6c793c312ccfa29981e1135b3ef5e1277ebe639731a6b0f7350d90e96e63f0b4
BLAKE2b-256 checksum
How to use checksums
15d5a8f9149b97cced9e1f4bff92ff0b6206120e2c853ae774d7020d6ecd8fa8
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 28, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

1.6.0 This release

2 release files

1.5.1

2 release files

1.5.0

2 release files

1.4.0

2 release files

1.3.1

2 release files

1.3.0

3 release files

1.2.0

2 release files

1.1.0

1 release file

1.0.2

1 release file

1.0.1

1 release file

1.0.0

1 release file

0.0.1

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page