Talk:Fully qualified domain name

Correcting First Paragraph

This first paragraph used to look like this:

A fully qualified domain name (or FQDN) is the human-readable name corresponding to the TCP/IP address of a network interface, as found on a computer, router or other networked device. It includes both its host name and its domain name.

I changed it. Here is my reasoning.

The statements contained in the first paragraph are incorrect. A FQDN doesn't have to be human-readable, unless in the sense that it uses human readable characters. A FQDN could be rs3927-8H.as4823.net. Is that human-readable? My point is that it has dual purpose, both human and machine.

Secondly (and more importantly), an FQDN does not correspond to ANYTHING, not by definition. There are multiple resource record types that you can use with domain names. I will point to IN TXT as a valid, but non-TCP/IP address RR as an example of why this is not true.

What i have changed the paragraph to is more correct, and does not mislead the reader into a narrow view of what DNS is capable of.

- Fudoreaper 22:28, July 29, 2005 (UTC)

Canonical name

I am not sure if "canonical name" is the same as and should be directed to "FQDN". I read that if one uses /etc/hosts, the first hostname on the list is considered as the canonical name. So, if the first name is a unqualified name, the canonical name is the unqualified name. It seems canonical is as opposed to aliases, and FQDN is opposed to unqualified name - they are two different concepts. That is, all the canonical and aliased names can be fully qualified, and also can be all unqualified. I read that "canonical name" is defined in RFC103.

- Ming Kin Lai

—Preceding unsigned comment added by 128.195.10.233 (talk • contribs) 2006-09-27T19:21:35

I realize this is a very old comment, but a week or so ago, I finally fixed this so that canonical name now points to something more appropriate. Wrs1864 (talk) 10:12, 18 March 2009 (UTC)

Any binary string

"Any binary string can be used as the label of any resource record; a common misconception is that names are limited to a subset of ASCII characters." according to RFC1035 sec. 2.3.1, in order to be backward compatible, one should use the "let-dig-hyp" characters only.

- Yuval —Preceding unsigned comment added by 212.235.26.189 (talk) 09:45, 19 February 2008 (UTC)

Absolute domain name

I have never heard mention of an 'absolute domain name', which we say is an alternative to 'fully qualified domain name' in the opening paragraph. Can anyone say where they've heard this, or even better, cite a source? —fudoreaper (talk) 08:27, 18 March 2009 (UTC)

RFC 1035 discusses absolute vs relative domain names. Wrs1864 (talk) 10:06, 18 March 2009 (UTC)

The term FQDN is certainly the standard technical term, but absolute is not uncommon. What I do object to is the use of the notion of 'unambiguity' in terms of domain names when they are fully qualified, or of 'ambiguity' when they are not. A relative domain name is not 'ambiguous', it simply can't be interpreted in multiple ways, since the choices are not given or implicitly known. The 'absoluteness' is the technically correct term, just as in absoluteness (vs. relative) of path names. A relative (non-absolute) pathname also is not ambiguous, it's just not complete. Kbrose (talk) 17:10, 18 March 2009 (UTC)

PS: I think the notion of 'ambiguity' requires context, for example, if a host 'myhost' belongs to two domains for which it has, say, different SRV records. Only in this context would the local use of 'myhost' be ambiguous, but outside of these domains, where this context is unavailable, the name is simply incomplete and likely unresolvable. Kbrose (talk) 17:59, 18 March 2009 (UTC)

Being able to be interpreted several different ways seems to me to be the very definition of "ambiguous". Personally, I've heard seen far fewer references to "absolute" vs "relative" than I have FQDN vs unqualified. I don't have a problem with using abs/rel, but I can see how they might be confusing to some people. Wrs1864 (talk) 17:52, 18 March 2009 (UTC)

Yes, I would agree. See my PS addendum also Kbrose (talk) 18:02, 18 March 2009 (UTC)

Back before I did a rewrite (see here), this article claimed: "Notice that there is a dot at the very end of the domain name, i.e. it ends ".com." and not ".com" — this indicates that the name is an FQDN. For example "myhost.bar.com" could be ambiguous, because it could be the prefix of a longer domain name such as "myhost.bar.com.au", whereas "myhost.bar.com." is a fully qualified domain name." I found this kind of bogus due to the ndot rule, but the whole article stressed the "requirement" that a FQDN must have a dot at the end. I'm not sure how much this is a "common misunderstanding" in the general population, but there was a little more text that addressed the issue. Wrs1864 (talk) 18:00, 18 March 2009 (UTC)

I think this perceived 'requirement' of the final dot was introduced by people coming from the DNS only perspective, and indeed in DNS it is a requirement due the definition of structure in the 'standard' zone files, most notably implemented in BIND. Not all DNS implementations have this requirement, however. But for other protocols, such as SMTP, that by definition always use FQDNs, this is not true. Such ignorance leads to the confusion, caused primarily by the assertion that a FQDN always end in a dot in order to be technically correct. Again, the context of application is important. This notion has been copied from WP to many other 'definition' sources, it appears, without discrimination (or the early versions of WP were copied from somewhere else). Kbrose (talk) 18:13, 18 March 2009 (UTC)

The article clearly needs more work to dispel the myths around this issue. Perhaps sections can be added for more detailed discussion of FQDNs vs. unqualified ones (UQDN?) in some prominent applications and protocols. Kbrose (talk) 18:32, 18 March 2009 (UTC)

partially qualified domain

A full does imply a partial. Is there a partial?

Which are the phrases to describe the distinction, please, between, with www. verus without? Such as [ my examples include en., nothing, then www.. ]:

http://en.wikipedia.org/wiki

http://wikipedia.org/wiki

http://www.wikipedia.org/wiki

http://en.wiktionary.org/wiki

http://wiktionary.org/wiki

http://www.wiktionary.org/wiki

[[ hopiakutaPlease do sign your communiqué.~~Thank You, DonFphrnqTaub Persina.]] 10:00, 4 September 2009 (UTC)

Please, help?

Anyone home?

[[ hopiakutaPlease do sign your communiqué.~~Thank You, DonFphrnqTaub Persina.]] 22:15, 8 September 2009 (UTC)

First, your examples are of URLs, not domain names. Strip http:// and everything following the / at the end. So your examples actually are:

* en.wikipedia.org

* www.wikipedia.org

* en.wikionary.org

All of these are fully qualified, as they contain the top-level domain (.org). A partially qualified domain name might be something like "en.wikipedia" or "www.wiktionary". An unqualified domain name might be "en" or "www". All these can be used, but require specific setup of DNS on the host you are using to do the lookup. Hope that helps, —fudoreaper (talk) 05:35, 10 September 2009 (UTC)

Unique device name

The third paragraph states that "The FQDN therefore uniquely identifies the device". For this example, this is true, but it is not universally true. The FQDN may refer to a round-robin set of machines or even a name that has no specific machine associated with it; the key is that within the complete domain name system, it points to a specific node within the tree. Corydon76 (talk) 18:17, 6 November 2009 (UTC)

This was already stated, and the statement is clearly within the context of the example. The formatting was poor, however, being spread out with too much whitespace. Kbrose (talk) 19:05, 6 November 2009 (UTC)

Trailing Dot

If there is to be a trailing dot at the end of a sentence, that must be clearly defined by another method than only one dot. Either use two, or use a separate box to display the example; ie.

somehost.example.com.

Was this what was actually meant? - KitchM (talk) 20:46, 10 November 2009 (UTC)

Yes, I tried to implement your suggestion in a way so that the domain name with the trailing dot does not occur at the end of a sentence, which makes it difficult in any case for good typesetting. Kbrose (talk) 22:21, 10 November 2009 (UTC)

Example

How about an FQDN example? scope_creep (talk) 16:01, 23 August 2010 (UTC)

Perhaps you should read the article, it has an example. Kbrose (talk) 15:10, 23 August 2010 (UTC)

Information given in this article does not conform to relevant RFCs

My edit has been reverted by user tbhotch within several seconds (so he/she has not read the RFCs but just disliked the edit). Text of my edit was: It seems that a significant part of this article is PLAIN WRONG. See RFC 1594 (Section 5.2) for Fully Qualified Domain Name (FQDN). This RFC is cited by several other RFCs using the term FQDN. See RFC 1034 and RFC 1035 for absolute domain names (sometimes called complete domain names). The terms FQDN and absolute domain name are NOT synonyms. Maybe someone with Wikipedia formatting skills can add a hint to the article. People rely on Wikipedia but information given in the article is PLAIN WRONG. I am a UNIX admin for nearly 20 years and I do read RFCs (which are the relevant source for internet related things by definition). (I had added some asterisks to my original edit as I do not know how to format Wikipedia articles to emphasize that important information.) — Preceding unsigned comment added by 84.128.50.110 (talk) 22:45, 30 September 2012 (UTC)

Proposed merge with PQDN

Googling suggests that PQDN is often discussed alongside FQDN, and there is a competent article at FQDN as compared to the totally unsourced dictionary definition at PQDN: it looks as if it would be better to add some description of PQDN to the FQDN article and redirect. PamD 22:47, 20 May 2014 (UTC)

AGAINST, I know what a PQDN is, I came here to see what a FQDN is INSTEAD of a PQDN merging them would remove the usefulness of that this article to that end.

--74.93.100.211 (talk) 00:25, 18 November 2014 (UTC)

• Support A casual perusal of Google Books Search supports that PQDN is rarely separated from FQDN. @IP: Merging here probably means that we will add a section on PQDN here and redirect the name too, and the other content originally in FQDN would normally not be touched from this. In fact let's add that section right now to show you how things will not be compromised. 野狼院ひさし u/t/c 06:03, 23 March 2015 (UTC)

Support PQDN is very related to FQDN, and does not meet notability requirements for a article. Qjokj6567 (talk) 19:03, 19 May 2015 (UTC)

I ended this absurdity by a redirect. It simply is not a separate topic. Kbrose (talk) 02:09, 20 May 2015 (UTC)

Copyright infringement

Not sure the correct policy for this but wanted to let you know: https://www.youtube.com/watch?v=qHAb3Foa1Nw – I can't report the video because it doesn't infringe my rights, as I haven't contributed to the article. There are many other videos like this in that channel. — Preceding unsigned comment added by 77.20.177.141 (talk) 17:51, 14 December 2014 (UTC)

Trailing dot is not part of FQDN

Hi all. It seems this article still contains misinformation. Rather than take up tons of space here, I have written up a lengthy explanation of why the trailing dot is not part of a FQDN.

In a nutshell, and as has been pointed out by other users on this very talk page, the dot is a lexical convention only used in DNS resource records and (rarely) to control the behavior of a resolver; it is not an inherent component of a FQDN. On my side are numerous quotations from RFCs 882, 1035, 1123, 1594, 1983, 2181, 2821, 2822, and 4703. Some of these same quotations have been taken out of context by previous editors of this Wikipedia article to support conflicting assertions about the trailing dot.

I also take issue with the references for "PQDN" and "relative domain name"; see my writeup for explanation.

Before I hack away at the article, I'd like to hear your comments/criticisms, either here or in my inbox. Thanks. —mjb (talk) 16:56, 23 December 2015 (UTC)

Inaccuracies in the current version of the article

I have never edited a Wikipedia page. With my inexperience, I'd like to start by submitting in "talk" and learning more about how to proceed.

"including at least a second-level domain and a top-level domain"

A second-level domain is not required. "ai." is an FQDN. Https://ai. is a valid website and is live. It has an MX record. It is distinct from "ai" because it lacks the terminating dot. It is ambiguous, sometimes meant as an unqualified domain/host (in DNS, though not necessarily in SMTP email addresses). In network configurations with domain suffix searches, ai could be an unqualified name that resolves to ai.something, ai.something.something, and so on.

There is nothing in the footnoted source (or that source's source); RFCs 1594 and 3696; or logic that indicates an FQDN must have at least two labels (one being the TDL and one below that). In fact, logic proves otherwise. If a TLD couldn't, on its own, be an FQDN, there would be no such thing as a fully-qualified TLD.

The paraphrasing of RFC 1594 in the author's source states, "If you think of the DNS as a tree-structure with each node having its own label, a fully qualified domain name for a specific node would be its label followed by the labels of all the other nodes between it and the root of the tree." It is an accurate paraphrase; but neither it nor the original content rule out a node having no nodes and labels between it and the root of the tree. If a TLD has no nodes between it and the root, then none are possible to omit. In other words, the FQDN of a TLD includes all of the labels when it includes only itself, because there are no other labels to include.

There are sources that claim things like "Domain name consists of two parts, a second level domain (SLD) and a top level domain (TLD)." That particular quote is fallacious, not least because it contradicts every website that has "www" as its third-level label.

"The DNS root domain is unnamed which is expressed by having an empty label in the DNS hierarchy, resulting in a fully qualified domain name ending with the top-level domain."

There is some supporting documentation for stating the root domain's label is empty. For example, RFC 4702 states,

"To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label."

In other documentation, it is referred to as having a null name. See RFCs 2929, 5395, and 6195 all of which include, "the null or ROOT label can not the null label is usable only as root...." — Preceding unsigned comment added by Sophware (talk • contribs) 18:40, 17 January 2019 (UTC)

Working on some cleanup here. I agree that the technical details in this article contain a number of errors; looking at both this and the previous comment by User:mjb I've made a list of the things identified, including some I noticed; feel free to comment and sanity check me here. I'm otherwise going to use this as a cleanup checklist.

Technical errors:

• Agreed that there's no requirement for a FQDN to have a second-level domain, nor does it end at a third level as implied by the article. The only requirement is that an FQDN unambiguously identifies a DNS entry. Even com. is a FQDN (the presence of A records or a CNAME is not required for something to be an FQDN either).
• A trailing dot is definitely not required for most FQDNs (per mjb's excellent analysis). I don't agree a trailing dot to indicate the root label necessarily makes something not an FQDN though. I also think one is required for disambiguation to indicate any FQDN represntation of a TLD (such as User:Sophware's ai. example), since most systems will otherwise treat that as a hostname on the same domain as the system doing the lookup.
• Finally on the topic of dots, `.` as a label separator is a conventional standard for writing it out, not a special character within labels themselves. In fact, a DNS label can contain a `.` (while I'm being way too detailed, it goes further: a DNS label can contain any octets and those octets "should not be treated as standard ASCII" but like, no human should do that, no registrar allows it in practice, why would you do that). Most systems that read ASCII written labels support escaping (some don't! A period in a label notably breaks the default Verizon DNS resolver for my home ISP! I should stop testing weird DNS edge cases on them!). IDK if this merits mention, it's a weird edge case.
• The article has some confusing language describing the root zone. Most notably, alternate root zones are still defined with an empty root label; that's a hard requirement of RFC 1035. I think we should just link to the appropriate articles for each term and not redescribe them here.
• I think PQDN is a far less commonly used term than "relative host" or "relative domain name" or similar, though it's used in Kubernetes (at least in Windows-specific documentation and specifically non-Windows tests), so I guess it has some traction. I'm inclined to rename the section to "Relative domain names."

Other cleanup tasks:

• Lead section has numerous errors: it's too long, contains information not anywhere else in the article, and not a particularly good summary of the topic
• I don't think we need external links to every RFC that mentions FQDNs (and RFC 2826 doesn't even mention FQDNs).
• Though it's fine to mention technical terms like octets, I think it's possible to clean this up a bit to be accessible to someone who understands the basics of DNS but not like, character encoding.

Dylnuge ^{(Talk • Edits)} 22:24, 12 October 2022 (UTC)

Thanks to both of you for taking up the charge. Life has taken me far away from most tech-y things, so I won't be doing any edits here anytime soon. You have my moral support. Good luck! —mjb (talk) 17:44, 21 October 2022 (UTC)

Thank you! Your analysis was extremely well written and useful here; I think the page is already in a better state and I'm hoping to clean it up some more this weekend! Hope things are going well for you! Dylnuge ^{(Talk • Edits)} 18:41, 21 October 2022 (UTC)