I don’t know what this means. What’s domain1 and domain2 got to do with anything?
The only thing that matters is that the system hostname is not a name you’re virtually hosting in Virtualmin (especially if mail is virtually hosted, but I would recommend avoiding it for everything). Everything else is just a name, and Virtualmin don’t care (Virtualmin don’t care about the system hostname either, but some services do, particularly Postfix when it comes to delivering mail).
Oh, wait are you saying that because the system hostname is subdomain1.domain1.net you shouldn’t host something in Virtualmin named domain1.net? No! I’m not saying anything of the sort! You can host domain1.net in Virtualmin and in the Postfix virtual map if the system hostname is something.domain1.net. That does not matter at all. Those are different names! And that’s all that matters.
To make this concrete: The server that hosts mail for virtualmin.com is called n1.virtualmin.com. That’s no problem. That’s two different names.
I understand what you’re saying, but if I may offer a constructive criticism, the term name in this context is ambiguous, and I think that this (in part) is causing unnecessary confusion
virtualmin.com and n1.virtualmin.com share the same domain name (namely, virtualmin.com), but whereas n1.virtualmin.com is an FQDN (with the hostname n1), virtualmin.com isn’t
The point seems to be that the Virtualmin system name should be an FQDN and that the name of a created virtual server should be a non-FQDN domain name that may but need not share its domain name with the domain name of the Virtualmin system name
Examples of encouraged/permitted naming:
hostname1.domain1.netdomain1.nethostname1.domain1.netdomain2.orgExamples of discouraged/prohibited naming:
hostname1.domain1.nethostname1.domain1.nethostname1.domain1.nethostname2.domain1.netWould you agree with this?
In this connection, on Automated Installation | Virtualmin — Open Source Web Hosting Control Panel , I find the following statement a bit confusing:
A fully qualified domain name is one of the form host1.example.com, or simply example.com (but do not use a name you’ll be hosting in Virtualmin).
I wouldn’t have considered example.com to be an FQDN
In addition, “but do not use a name you’ll be hosting in Virtualmin” suffers from the ambiguity of name in this context, because the domain name may be the same
That is also a FQDN. It’s just not what I should use to name my server, if I want to virtually host mail for virtualmin.com on that server.
You would consider wrong. It is an FQDN.
To be clear, example or virtualmin is not fully qualified. host1.example is also not fully qualified. But, example.com? Definitely fully qualified, all the way up to the root name servers.
Fully qualified is about ambiguity, or the lack thereof, and has nothing to do with the number of dots in the name. example.com can only ever resolve one way. Top-level server delegates name service to the example.com zone name servers, and they respond with A records for that host, if any. example on the other hand, is ambiguous. What zone is it in? Depends on local resolver configuration. People on the internet can’t find you with just example.
Joe, just to clarify, my main point (in my post above) concerned the ambiguity of name in this context (given the technical terms FQDN, hostname, and domain name) and a corresponding suggestion on how to make the documentation clearer (with encouraged and discouraged examples)
Naturally, if you feel that the documentation on this point is already sufficiently clear, then my main point may appear misplaced or unnecessary
Regarding the scope of the term FQDN – which wasn’t my main point – I’m happy to stand corrected (thanks), but I would only point out that as far as I can tell, in practice, if one is asked to provide or to specify a FQDN, one is expected to give an explicit hostname + a domain name and not simply a domain name. (I say “as far as I can tell” – my personal experience and what I’ve read may be misleading in this respect)
In closing, I’ll quote RFC 1594 - FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions , which certainly suggests that a FQDN contains a hostname (but admittedly doesn’t say that a domain name without an explicit hostname isn’t a FQDN, so it doesn’t contradict what you say):
5.2 What is a Fully Qualified Domain Name?
A Fully Qualified Domain Name (FQDN) is a domain name that includes all higher level domains relevant to the entity named. 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. For example, for a host, a FQDN would include the string that identifies the particular host, plus all domains of which the host is a part up to and including the top-level domain (the root domain is always null). For example, atlas.arc.nasa.gov is a Fully Qualified Domain Name for the host at 128.102.128.50. In addition, arc.nasa.gov is the FQDN for the Ames Research Center (ARC) domain under nasa.gov.
(By the way, a random search query for What is a FQDN? will invariably show examples with an explicit hostname + a domain name)
An FQDN is just a name under any TLD; the TLD is what matters in this context. Joe pointed it out here.
Yes, I know – this was in part what I was reacting to (if you read what I wrote two posts above)
I wasn’t disputing what Joe said – I was just pointing out how (it seems to me) a FQDN is understood in practice
Out of 36 Postfix email servers I maintain, only 4 of them are setup to use the hostname for abuse email contact.
35 of the servers have nothing to do with Virtualmin (or any other control panel) and 1 of them is my personal website and email server using Virtualmin GPL.
The only reason the 4 servers (that includes my Virtualmin Server) use the hostname for contacts are due to the DATA Centers Policy and TOS. They only allow rDNS/PTR if your domain.tld is hosted on the same server as the host.domain.tld, and in my case they don’t. So, their policy is to have at least a landing page for the hostname with an abuse email contact directly on that IP address.
As far as Postfix goes? Going on 20 years now and never had an issue with the hostname receiving and sending out emails. Only the occasional warnings that can easily be ignored.
I think the problem is people want to take advantage of Let’s Encrypt Certs for their email servers and Virtualmin allows them to do just that with ease. Thus the reason why we are seeing a lot people setting up their hostnames with email, even if they are not going to use it for email. Back in the day we had to purchase an SSL for our email servers and manually set them up with Postfix, which I still do to this day.
So as I just pointed out, there are times when you have no choice in the matter and forced to setup an email account for the hostname. While I believe Postfix does not recommend it? It’s still allowed an still issues a warning about it.
How do you go about suppressing the warning? Don’t setup an email account for the hostname unless the Data Centers Policy requires you to do so.
Thanks for sharing this!
The +1 was I agree with this
do you mind if we completely remove the mail feature for the host default domain, making it impossible for users to enable it and potentially break things?
The insert fluff comment was because this forum needed x amount of key strokes to allow me to post my reply
After the new Virtualmin release, this will happen. However, a user can still re-activate it using the Virtualmin CLI with the --skip-warnings flag or disable this block completely by adding the nocheck_forbidden_domain_features=1 option to the /etc/webmin/virtual-server/config file.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.