Thoughts from a power user

Connect with other users about what to run on your webhosting (and how to run it) here.
Post Reply
Bubka3
Compulsive poster
Compulsive poster
Posts: 70
https://www.youtube.com/channel/UC40BgXanDqOYoVCYFDSTfHA
Joined: Fri Feb 21, 2014 10:24 am

Thoughts from a power user

Post by Bubka3 »

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.
User avatar
Edge100x
Founder
Founder
Posts: 12945
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Re: Thoughts from a power user

Post by Edge100x »

Happy to clarify.
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.
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.

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.
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.
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.

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.
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...
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.).
Bubka3
Compulsive poster
Compulsive poster
Posts: 70
Joined: Fri Feb 21, 2014 10:24 am

Re: Thoughts from a power user

Post by Bubka3 »

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.
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 amPower users can use the workaround they described, if they wish.
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.
Edge100x wrote: Tue Jun 05, 2018 11:03 amPower users could also run their own VDS with a webhosting stack, possibly with mail and DNS servers, to get even more capabilities.
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.
Edge100x wrote: Tue Jun 05, 2018 11:03 amI 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.
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.
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.
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 amI 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 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.
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.).
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.
User avatar
Edge100x
Founder
Founder
Posts: 12945
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Re: Thoughts from a power user

Post by Edge100x »

Bubka3 wrote: Tue Jun 05, 2018 12:51 pm I'm not asking for support of external DNS servers. I'm asking for it not to get in the way when adding domains...
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.
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.
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.
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.
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.
viewtopic.php?f=106&t=14576 and the first bullet states that you must use NFO name servers.
This may be because of an initial plan to potentially use more flexible DNS-based activation. I will have to investigate that further.
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 can test further. It was very clearly broken before, with CloudFlare mangling the output of the test file -- adding script loads and such.
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 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.

(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.)
Post Reply