Does a Fully Qualified Domain Name Need a Period

Does a Fully Qualified Domain Name need a period?

How IT Works: Domain Name
System

All DNS records actually end with the period character (.) which
represents the root of the DNS hierarchy, but it's rarely printed and
is usually just assumed. A domain name that includes the trailing
period character is said to be a Fully Qualified Domain Name (FQDN).
However, domain names where the period character is implicit are also
commonly referred to as FQDNs.

^{Source: TechNet Magazine}

See also:

• Trailing Dots in Domain Names
• No, that dot in the domain name of the URL is not a mistake.

Fully qualified domain name validation

It's harder nowadays, with internationalized domain names and several thousand (!) new TLDs.

The easy part is that you can still split the components on ".".

You need a list of registerable TLDs. There's a site for that:

https://publicsuffix.org/list/effective_tld_names.dat

You only need to check the ICANN-recognized ones. Note that a registerable TLD can have more than one component, such as "co.uk".

Then there's IDN and punycode. Domains are Unicode now. For example,

"xn--nnx388a" is equivalent to "臺灣". Both of those are valid TLDs, incidentally.

For punycode conversion code, see "http://golang.org/src/pkg/net/http/cookiejar/punycode.go".

Checking the syntax of each domain component has new rules, too. See RFC5890 at
https://www.rfc-editor.org/rfc/rfc5890

Components can be either A-labels (ASCII only) or Unicode.
ASCII labels either follow the old syntax, or begin "xn--", in which case they are a punycode
version of a Unicode string.

The rules for Unicode are very complex, and are given in RFC5890. The rules are designed to prevent such things as mixing characters from left-to-right and right-to-left sets.

Sorry there's no easy answer.

Why do fully qualified domain names have to have an extension?

I am exapanding this as an answer because, perhaps, people really don't know what all that stuff means.

A URL is broken into two parts: Protocol and domain.

The protocol is so your browser (or other client) knows how to handle the transfer. And it's not just HTTP and HTTPS. There are many protocols like, FTP, SSH, etc...

The domain needs to be approved, usually by region. If your site exists in Turkey, you will not be able to get a domain with a .uk domain, because it's not in the UK. There may be ways around it, but that's the general idea.

The .COM, .NET, etc... Exist to help, in some way, determine what a site is. Network, government, education, country, etc... So, yes, they are absolutely still in use. And there is no reason that should change any time soon.

On top of that, attempting to use a bizarre formed domain like. site.comli.com, will have to be resolved by your server because that is not an actual approved domain name. And even though your server will serve it up, it will be flagged by most firewalls and security systems as suspicious.

The variations on domain names like .EDU, .ORG, .CO, etc... They are individually bought and owned. They could be the same person that owns them, or literally anyone else. You could own the .COM version of your domain, but not be able to buy .NET version because someone else already owns it. This has happened. This is also the reason that when you buy a domain, the seller normally asks if you want to buy all available variations at the same time. A few of my clients own 5 different versions of their domain that all redirect to the .COM for exactly this reason.

Why is `to.` a valid domain name?

The final dot is part of the fully qualified domain name. More information in this article. Specifically:

It's a little-known fact, but fully-qualified (unambiguous) DNS domain names have a dot at the end. People running DNS servers usually know this (if you miss the trailing dots out, your DNS configuration is unlikely to work) but the general public usually doesn't. A domain name that doesn't have a dot at the end is not fully-qualified and is potentially ambiguous.

What is a regular expression which will match a valid domain name without a subdomain?

Well, it's pretty straightforward a little sneakier than it looks (see comments), given your specific requirements:

/^[a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}$/

But note this will reject a lot of valid domains.

differences between hostname and fully qualified domain name(FQDN)

Regardless of the semantics of term FQDN we must see what Python's socket.getfqdn() does.

socket.getfqdn([name])

Return a fully qualified domain name for name. If name is omitted or
empty, it is interpreted as the local host. To find the fully
qualified name, the hostname returned by gethostbyaddr() is checked,
followed by aliases for the host, if available. The first name which
includes a period is selected. In case no fully qualified domain name
is available, the hostname as returned by gethostname() is returned.

socket.gethostbyaddr(ip_address)

Return a triple (hostname, aliaslist, ipaddrlist) where hostname is
the primary host name responding to the given ip_address, aliaslist is
a (possibly empty) list of alternative host names for the same
address, and ipaddrlist is a list of IPv4/v6 addresses for the same
interface on the same host (most likely containing only a single
address).

In other words, getfqdn() looks for reverse PTR record first, regardless of what A or CNAME record has pointed to it in the first place. It looks for a fully qualified domain name (FQDN) and simply gives you the first suitable one i.e. the first one that ends with ., the root.

So, FQDN : sa-in-f93.1e100.net comes from the PTR record for IP 74.125.200.93.

93.200.125.74.in-addr.arpa. 86400 IN    PTR     sa-in-f93.1e100.net.

Here, the FQDN for this hostname www having domain youtube.com is actually by definition www.youtube.com., including the dot. Likewise, the sa-in-f93.1e100.net is not a FQDN, as it should actually be sa-in-f93.1e100.net.:

• hostname sa-in-f93 as subdomain for 1e100
• sa-in-f93.1e100 as subdomain for net
• sa-in-f93.1e100.net as subdomain for the root, ..

Why sa-in-f93.1e100.net. is chosen over www.youtube.com. simply comes from how the socket.getfqdn() is designed to determine the FQDN of a given name.

On the other hand, the Canonical Name CNAME record SHOULD by design (RFC 1035, 3.2.2) point to the canonical name, but it's commonly used like it was just an alias, because it works like one. Also, the PTR record SHOULD (RFC 1912, 2.1) give the same result, as it should represent the canonical name for the given IP.

If only that was obeyed, the method socket.getfqdn() uses would have been completely appropriate. Here, the CNAME youtube-ui.l.google.com. without the corresponding PTR record (93.200.125.74.in-addr.arpa. IN PTR youtube-ui.l.google.com.) made this assumption false.

X.509 certificate: Is it a good idea (or bad) to add localhost in Subject Alternative Name?

Is it a good idea (or bad) to add localhost in Subject Alternative Name?

It depends on the standards you follow and your security posture.

---

First things first (for the discussion below). A Fully Qualified Domain Name (FQDN) must be defined. That definition is taken from W. Richard Steven's TCP/IP Illustrated Volume I: The Protocols (p. 189):

A domain name that ends with a period is called an absolute domain name or a fully qualified domain name. If the domain name does not end in a period, it is assumed that name needs to be completed. How the name is completed depends upon the DNS software being used.

That means we can change localhost into a fully qualified domain name by appending a period:

localhost.

Here's a little experiment:

$ hostname
debian-q500

$ hostname --fqdn
debian-q500

$ dnsdomainname 
$

$ ping debian-q500.
ping: unknown host debian-q500.
$ ping debian-q500.local
PING debian-q500.local (172.16.1.26) 56(84) bytes of data.
64 bytes from debian-q500.home.pvt (172.16.1.26): icmp_req=1 ttl=64 time=0.040 ms
64 bytes from debian-q500.home.pvt (172.16.1.26): icmp_req=2 ttl=64 time=0.035 ms
...

$ ping localhost.
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.037 ms
...
$ ping localhost.local
ping: unknown host localhost.local
$ ping localhost.localdomain
ping: unknown host localhost.localdomain

---

Next is standards. One of the most popular is the guides published by the CAs ad Browsers. The CAs ad Browsers publish their operations guides at the CA/B Forums. They two guides of interest are:

• Baseline Requirements for the Issuance and Management of Trusted Certificates
• Guidelines For The Issuance And Management Of Extended Validation Certificates

There's another popular one, but it generally defers CA/B guides in hosts listed in the certificates. That standard is RFC 5280 from the IETF:

• Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

RFC 5280 will call out other items, like how to validate a certificate chain and how to list email addresses in the subjectAltName.

Baseline Guide

The Baseline guide has this to say about names:

9.2.1 Subject Alternative Name Extension    
Certificate Field: extensions:subjectAltName
Required/Optional: Required

Contents: This extension MUST contain at least one entry. Each
entry MUST be either a dNSName containing the Fully-Qualified
Domain Name or an iPAddress containing the IP address of a
server. The CA MUST confirm that the Applicant controls the
Fully-Qualified Domain Name or IP address or has been granted
the right to use it by the Domain Name Registrant or IP address
assignee, as appropriate.

Wildcard FQDNs are permitted.
...

And

9.2.2 Subject Common Name Field 
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or
Fully-Qualified Domain Name that is one of the values contained in
the Certificate’s subjectAltName extension (see Section 9.2.1).

Finally,

11.1.3 Wildcard Domain Validation   

Before issuing a certificate with a wildcard character (*) in a
CN or subjectAltName of type DNS-ID, the CA MUST establish and
follow a documented procedure† that determines if the wildcard
character occurs in the first label position to the left of a
“registry-controlled” label or “public suffix” (e.g. “*.com”,
“*.co.uk”, see RFC 6454 Section 8.2 for further explanation).

If a wildcard would fall within the label immediately to the left
of a registry-controlled† or public suffix, CAs MUST refuse
issuance unless the applicant proves its rightful control of the
entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or
“*.local”, but MAY issue “*.example.com” to Example Co.).

So localhost is fine as long as its a fully qualified domain name. In fact, localhost not even mentioned in the guide.

Extended Validation

9.2.2 Subject Alternative Name Extension
Certificate field: subjectAltName:dNSName
Required/Optional: Required

Contents: This extension MUST contain one or more host Domain
Name(s) owned or controlled by the Subject and to be associated
with the Subject’s server. Such server MAY be owned and operated
by the Subject or another entity (e.g., a hosting service).
Wildcard certificates are not allowed for EV Certificates.

9.2.3 Subject Common Name Field
Certificate field: subject:commonName (OID: 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single Domain
Name(s) owned or controlled by the Subject and to be associated
with the Subject’s server. Such server MAY be owned and operated
by the Subject or another entity (e.g., a hosting service).
Wildcard certificates are not allowed for EV Certificates.

So localhost is fine as long as its a fully qualified domain name. In fact, localhost not even mentioned in the guide.

---

Microsoft encourages the practice in KB315588, HOW TO: Secure an ASP.NET Application Using Client-Side Certificates:

• On the Your Site's Common Name page, type localhost, and then click Next.

---

littleblackbox is a database of private SSL/TLS and SSH keys for embedded devices. It comes with a SQlite3 database in bin/.

The certificates are in PEM format (i.e.,-----BEGIN CERTIFICATE----- and friends). You can dump all the certificates with:

$ sqlite3 lbb.db 
SQLite version 3.8.3 2013-12-17 16:32:56
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .mode line
sqlite> .out certificates.txt
sqlite> SELECT certificate FROM certificates;
sqlite> .q

Next, remove the certificate = from the file:

$ sed -e "s|certificate = ||g" certificates.txt > temp.txt
$ mv temp.txt certificates.txt

Now use nawk and openssl to decode each certificate:

nawk '
v{v=v"\n"$0}
/----BEGIN/ {v=$0}
/----END/&&v{
  print v > "tmp.cert"
  close("tmp.cert")
  system("openssl x509 -in tmp.cert -inform PEM -text -noout")
  v=x}' certificates.txt

If we know about them, the bad guys surely know about them.

---

Finally, its security posture. With all of that said above, here's why its a bad idea. This is where the security posture comes in. From Peter Gutmann's Engineering Security (p. 45):

In practice CAs seem to issue certificates under more or less any
name to pretty much anybody, ranging from small-scale issues like
users buying certificates for the wonderfully open-ended mail [237]
through to the six thousand sites that commercial CAs like Comodo,
Cybertrust, Digicert, Entrust, Equifax, GlobalSign, GoDaddy,
Microsoft, Starfield and Verisign have certified for localhost,
with no apparent limit on how many times a CA will issue a
certificate for the same name [238].

The problem here is, "is it my localhost, or is it your localhost". So its not so much a question of issuing certficate for and trusting your localhost - its more a problem of inadvertently trusting a foreign localhost.

Once your software (such as a browser) trusts the certificate issued to localhost, its game over.

---

Related Topics