Just wanted to drop my thoughts here from the perspective of a power user. I'll start with my use case, or basically why I am not using a VDS. I need to host 2 static sites and a forums. All of the sites are low traffic so I've moved away from VDS hosting since there's a lot of overhead in managing your own that's just not worth it for 3 sites.
I previously used nfoservers so I decided to checkout the web hosting. Unfortunately, it seems the web hosting is setup in a way that purposefully prevents you from using anything but a "standard" setup. I couldn't find any good techincal explainations for some of the wild claims made by Support and the FAQ entries on this forum.
My first adventure was attempting to add a domain info the web hosting. I wanted to add in my domain and it errored out since I wasn't using nfo's DNS. I thought okay, no big deal! I will just contact support and let them know that I will use my own DNS setup and add the appropriate A records myself. I was met with this reply: "Due to the use of Apache vHosts for domain separation, an A record would not work properly." Uhm how do you think nfo's DNS works? Magic? I did something you should never do and decided to argue with the support rep. I changed the DNS on one of my domains to add it into the system. Then I changed it back, added the A record, and informed the agent to check for himself, it's all working fine. The next reply was even more amusing. The agent added a test subdomain and when it obviously wasn't working because he didn't ask me to setup an A record for it, I got this reply: "When you add a domain to our Domains tab, our system correctly sets up the vhost stub for that domain entry, allowing it to be forwarded correctly. Changing to another name server afterwards would still allow previously created domain entries to work correctly, but would fail for any newly created subdomains." Yeah that's not how Apache works at all. At this point I realized any further back and forth with this agent is useless. He clearly is not familar enough with Apache or how DNS works.
Then I came to the forums because I wanted to post this thread and maybe get some feedback from more senior NFO staff on why such quite frankly weird design choices where made. I'm not asking for anything that wouldn't work at your typical cPanel host -- they just might blame your setup at the lower support levels. While I was on the forums, what I found is a number of interesting statements and requirements about LetsEncrypt support. The requirement that you must use NFO's dns servers doesn't make any sense. No matter what DNS server you use, the ACME client will be able to validate everything in the well-known folder as long as the A records are correct and pointing to the NFO hosting server. Another interesting statement is that LetsEncrypt cannot be used on Cloudflare because it "mangles verification output". I dont have any technical information to refute this with but I have setup LetsEncyrpt with Cloudflare on cPanel hosts so I don't see why it would fail here.
Overall, I'm disappointed that NFO has these weird limitations and requirements on the web hosting. I consider NFO to be an industry leader due to the support and performance provided here which is why as I power use I would of felt comfortable hosting here. Unfortunately, it appears that will not be possible in the current situation.
Thoughts from a power user
-
- Compulsive poster
- Posts: 70
- https://www.youtube.com/channel/UC40BgXanDqOYoVCYFDSTfHA
- Joined: Fri Feb 21, 2014 10:24 am
Re: Thoughts from a power user
Happy to clarify.
Not supporting external DNS servers makes things simpler and significantly reduces the support burden of our webhosting in various ways, allowing us to keep prices lower than we otherwise could.
Power users can use the workaround they described, if they wish. Power users could also run their own VDS with a webhosting stack, possibly with mail and DNS servers, to get even more capabilities.
Having clients use us for DNS resolution does give us an additional option for ACME validation that we might use later. It would potentially work around customer site configurations that block access to the .well-known folder, such as through an .htaccess file restriction. So far, we haven't seen enough problems with the http validation method to make that necessary.
That is indeed how our system works. Our Domains page is set up to combine DNS and Apache vhost setup functionality. This is why it requires that the name server entries point to us before it allows for a domain to be added. It does not support use of an external DNS servers.Bubka3 wrote: ↑Tue Jun 05, 2018 10:07 am The agent added a test subdomain and when it obviously wasn't working because he didn't ask me to setup an A record for it, I got this reply: "When you add a domain to our Domains tab, our system correctly sets up the vhost stub for that domain entry, allowing it to be forwarded correctly. Changing to another name server afterwards would still allow previously created domain entries to work correctly, but would fail for any newly created subdomains." Yeah that's not how Apache works at all.
Not supporting external DNS servers makes things simpler and significantly reduces the support burden of our webhosting in various ways, allowing us to keep prices lower than we otherwise could.
Power users can use the workaround they described, if they wish. Power users could also run their own VDS with a webhosting stack, possibly with mail and DNS servers, to get even more capabilities.
I am not aware of where we made this claim in relation to LE, and you forgot the KB link. Please post the link so that I can read it and clarify there or here.The requirement that you must use NFO's dns servers doesn't make any sense. No matter what DNS server you use, the ACME client will be able to validate everything in the well-known folder as long as the A records are correct and pointing to the NFO hosting server.
Having clients use us for DNS resolution does give us an additional option for ACME validation that we might use later. It would potentially work around customer site configurations that block access to the .well-known folder, such as through an .htaccess file restriction. So far, we haven't seen enough problems with the http validation method to make that necessary.
I have not re-tested recently, but verification through CloudFlare did not work properly for that reason, per the certbot tool output. You can re-test if you wish. I really don't recommend using CloudFlare with https, though, because you lose end-to-end encryption -- CloudFlare has to decrypt the page so that it can cache and mangle it in its various ways, then serve it back to the client -- and having an active man in the middle like that is a pretty big deal from a security and privacy standpoint (e.g., if CloudFlare is compromised, your site will be too; their employees can view your data; they can be secretly told by the government to forward all of your communications with clients; etc.).Another interesting statement is that LetsEncrypt cannot be used on Cloudflare because it "mangles verification output". I dont have any technical information to refute this...
Re: Thoughts from a power user
I'm not asking for support of external DNS servers. I'm asking for it not to get in the way when adding domains. If I use my own DNS setup, and simply point an A record to the NFO server, this is not extra support. I am still using the web server in the same way as any other user. I could argue I'm using less resources because your DNS server isn't responsbile for serving my records. The page already states features won't work if you don't use NFO's DNS servers so its pretty clear to anyone who does this that support will not provide help to issues you caused by doing that.Edge100x wrote: ↑Tue Jun 05, 2018 11:03 amThat is indeed how our system works. Our Domains page is set up to combine DNS and Apache vhost setup functionality. This is why it requires that the name server entries point to us before it allows for a domain to be added. It does not support use of an external DNS servers.
Not supporting external DNS servers makes things simpler and significantly reduces the support burden of our webhosting in various ways, allowing us to keep prices lower than we otherwise could.
Just to clarify, all I want is the ability to bypass the DNS check on adding domains at your own risk. That's it.
To use the work around would disrupt other DNS records until the system accepts it and it's changed back.
As I stated in OP, for my use case, running my own webstack would be silly. It's two static websites and a forum that get barely any traffic.
Of course, the link is: viewtopic.php?f=106&t=14576 and the first bullet states that you must use NFO name servers.
The domain registration must continue to use our name servers.
HTTP validation should work regardless of what DNS servers you are using which is why I brought up the FAQ article in my original post. If a customer is not using NFO's DNS, then DNS vertification would simply not be available to them.Edge100x wrote: ↑Tue Jun 05, 2018 11:03 amHaving clients use us for DNS resolution does give us an additional option for ACME validation that we might use later. It would potentially work around customer site configurations that block access to the .well-known folder, such as through an .htaccess file restriction. So far, we haven't seen enough problems with the http validation method to make that necessary.
I mean I know it works. I'm currently moving from a host that I was able to set up all of this without a single ticket to support. It's just as you might know some hosts in the industry do not have good performance or support. Their SSH daemon has been down for days and after 3 days of the most basic troubleshooting in broken english they asked for my cpanel login. I saw the last login IP was from India. I realized I was wasting my time and they will never fix it. Not that they could. Pretty clear they don't have any access to the server since they needed my login.
CloudFlare is a powerful tool if you know how to configure it. I've been serving my FastDL through it for a couple of months and it's basically a free CDN. Some aggressive caching page rules on the FastDL subdomain and 75% of requests are served from CloudFlare's servers all over the world. That means faster downloads for foreign players and less bandwidth charges for me. I don't disagree with your analysis regarding security and privacy, I just think that for many webmasters the benefits out weigh the risk. Especially for hobby/gaming communities.Edge100x wrote: ↑Tue Jun 05, 2018 11:03 amI really don't recommend using CloudFlare with https, though, because you lose end-to-end encryption -- CloudFlare has to decrypt the page so that it can cache and mangle it in its various ways, then serve it back to the client -- and having an active man in the middle like that is a pretty big deal from a security and privacy standpoint (e.g., if CloudFlare is compromised, your site will be too; their employees can view your data; they can be secretly told by the government to forward all of your communications with clients; etc.).
Re: Thoughts from a power user
Unfortunately, in doing that, we would have to support them to some degree. For instance, with customers coming to us with questions on how to use the external DNS server, or having issues when the external DNS server doesn't work properly, or needing to update their external DNS entries if the IP address of the webhosting here changes.
If you wish to use external DNS, you can use the workaround. But, you have to keep in mind that because it is not officially supported, you have to maintain those entries yourself.
We can consider such requests further on an escalated case-by-case basis. Any such manually-approved addition will require separate verification of domain ownership, since that is a major reason for our system not allowing the addition of domains not already pointing to us.Just to clarify, all I want is the ability to bypass the DNS check on adding domains at your own risk. That's it.
To use the work around would disrupt other DNS records until the system accepts it and it's changed back.
Running a separate DNS service would also seem to be silly to me in that case, since it adds complication. But, you can still do it if you wish.As I stated in OP, for my use case, running my own webstack would be silly. It's two static websites and a forum that get barely any traffic.
This may be because of an initial plan to potentially use more flexible DNS-based activation. I will have to investigate that further.viewtopic.php?f=106&t=14576 and the first bullet states that you must use NFO name servers.
I can test further. It was very clearly broken before, with CloudFlare mangling the output of the test file -- adding script loads and such.I mean I know it works. I'm currently moving from a host that I was able to set up all of this without a single ticket to support.
I think that using it as a traditional CDN for static content on a separate subdomain can make some sense, although I still don't trust it, overall. Apart from the other concerns that I mention in various places, CloudFlare just controls too much of the market, does too much FUD-type marketing, and does too little to combat abuse from its clients, for me to recommend it.CloudFlare is a powerful tool if you know how to configure it. I've been serving my FastDL through it for a couple of months and it's basically a free CDN.
(I haven't looked at their DNS requirements recently, but it would be funny if they require that you use their DNS servers, as we do here. I imagine that must not be the case, for you to ask us to change our policy.)