1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
.. .............................................................................
.. AMAZING REFERENCES
.. .............................................................................
.. |Python Versions| image:: https://img.shields.io/pypi/pyversions/fqdn.svg
:target: https://pypi.org/project/fqdn/
.. |Build Status| image:: https://github.com/ypcrts/fqdn/actions/workflows/unit-tests.yml/badge.svg?branch=develop
:target: https://github.com/ypcrts/fqdn/actions/workflows/unit-tests.tml?query=branch%3Adevelop
.. |Coverage Status| image:: https://codecov.io/gh/ypcrts/fqdn/branch/develop/graph/badge.svg?token=cavArywW2X
:target: https://codecov.io/gh/ypcrts/fqdn
.. |Latest PyPI Version| image:: https://img.shields.io/pypi/v/fqdn.svg
:target: https://pypi.python.org/pypi/fqdn
.. |Downloads| image:: https://pepy.tech/badge/fqdn
:target: https://pepy.tech/project/fqdn
.. |Monthly Downloads| image:: https://pepy.tech/badge/fqdn/month
:target: https://pepy.tech/project/fqdn/month
.. |License Status| image:: https://app.fossa.com/api/projects/git%2Bgithub.com%2Fypcrts%2Ffqdn.svg?type=shield
:target: https://app.fossa.com/projects/git%2Bgithub.com%2Fypcrts%2Ffqdn?ref=badge_shield
.. |License Status Shield| image:: https://app.fossa.com/api/projects/git%2Bgithub.com%2Fypcrts%2Ffqdn.svg?type=large
:target: https://app.fossa.com/projects/git%2Bgithub.com%2Fypcrts%2Ffqdn
================================================================================
Python FQDN Fully-Qualified Domain Names
================================================================================
|License Status| |Build Status| |Coverage Status| |Latest PyPI Version|
|Downloads| |Monthly Downloads| |Python Versions|
This package validates Fully Qualified Domain Names (FQDNs) conforming to the
Internet Engineering Task Force specification [#spec]_. 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
make a DNS lookup [#letsencrypt]_. 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 [#browsers]_ .
>>> 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 to the IETF
specification [#equality].
>>> FQDN('BBC.CO.UK.') == FQDN('BbC.Co.uK')
True
>>> hash(FQDN('BBC.CO.UK.')) == hash(FQDN('BbC.Co.uK'))
True
.. [#spec] See `IETF Specification`_.
.. [#letsencrypt] 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 login. `Boulder's code
<https://github.com/letsencrypt/boulder/blob/8139c8fe28d873c2f772827be30426d075103002/policy/pa.go#L218>`_
is starkly different from Chromium's, as outlined in `Issue #14
<https://github.com/ypcrts/fqdn/issues/14#issuecomment-688604160>`_.
.. [#browsers] See `Issue #14
<https://github.com/ypcrts/fqdn/issues/14#issuecomment-688604160>`_.
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 <https://tools.ietf.org/html/rfc1123>`_: 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 <https://tools.ietf.org/html/rfc952>`_: DoD Internet host table
specification, October 1985
This RFC is the official specification of the format of the Internet Host Table.
..
.. code:: text
<hname> ::= <name>*["."<name>]
<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
Commentary
--------------------------------------------------------------------------------
`RFC-1034 <https://tools.ietf.org/html/rfc1035>`_: 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 <https://tools.ietf.org/html/rfc1035>`_: Domain Names
- Implementation and Specification, November 1987
- Section 2.3.1 repeats the "preferred name syntax" proposal from RFC-1034.
`RFC-2181 <https://tools.ietf.org/html/rfc2181>`_: 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 <https://tools.ietf.org/html/rfc3696>`_: 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
================================================================================
|License Status Shield|
|
