All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Educate me, please: Shared web hosting provider unexpectedly tells me to change DNS
Turbo_Pascal
Member
Two years ago, I signed up for shared web hosting (with a LET provider I don't need to name yet). I set an A record for the root domain names. The hosting worked perfectly until last month, when DNS for my domain names terminally failed to resolve. Specifically, a Chrome browser still gives the following error:
ERR_CONNECTION_REFUSED
I did not take any troubleshooting steps. I also did not alter my DNS in any way. Overall, I took no actions that would create the problem or resolve the problem. This leads me to believe the hosting provider changed something on their end.
Eventually I communicated with the provider and received the following message:
DNS of your website is wrong. Please use our name servers not IP.
While I don't consider myself a newbie, I am puzzled by this instruction. Is anyone here willing to help me walk through the logic?
I didn't reply yet, for instance to ask if there's a reason why it worked before and then stopped working.
My domain names are registered where they are because I like the free DNS hosting the registrar provides with registration. Is the shared web hosting provider telling me to abandon my favorite DNS hosting just so that a web browser will display a web page?
Comments
They probably change their IPs every so often, or at least this is what happened now. Without using their nameservers, there is no way for you to know the shared IP of your server. Well, there is, you have to login to the panel and see it, what I mean is there is no automated way for your domain to update it.
So either point your domain to the new IP manually or use their servers.
If you use shared hosting, you are probably better with option 2.
After all my experience with shared hosting, should I be surprised I never encountered this problem before?
Is this considered standard practice?
That highly depends on multiple factors, including your neighbors.
If some idiot hosted phishing/scam pages on that shared IP, and it became flagged
by all kinds of security tools, you'd probably want to have that IP changed right?
Same goes for sending spam.
Or it could simply be that the leasing block contract has ended and they bought another from a different provider. This can happen even on VPS, just a recent example:
https://lowendtalk.com/discussion/217810/avs-isp-netherlands-ip-changes
It's very common for shared hosts to ask you to use their nameservers, yes. Multiple shared hosting providers I've used over the last couple decades all required this, or at least presumed it.
For the vast majority of shared hosting customers, this isn't an issue. Heck, a lot of them buy their domains from their shared hosting provider anyway.
I'm not saying using other nameservers couldn't work, but ultimately it can require manual reconfig if the provider's IP changes, as you've seen.
Using a CNAME for their NS might avoid this
What does that mean?
Sorry I don't understand.
Cloudflare
Type: CNAME
Name: @ and www
Destination: ns1.provider.com
It will probably work and prevent IPs from breaking when they change.
They renumbered for whatever reason and your hosting/website is on a different ip now.
Maybe they set up a new box and moved your site, whatever, irrelevant.
If you were using their nameservers you wouldn't have noticed the change.
They're just giving you the easiest answer because support costs.
It probably gives you the new ip someplace in their panel, or that could be your response to them "I'd rather use external ns, what's the new ip thanks!"
It's not a huge deal, not particularly unusual (though if it was happening often I'd probably wonder what the fuck they're doing), and they probably don't really care if you use their ns or not but if you use an external set you have to manage changes.
Presumably you got an onboarding letter when you signed up for services with the hosting provider.
This letter would contain instructions on how to setup your hosting account with the service. Presumably it gave you a set of nameservers to point your domain to, to have your domain work with that web hosting service.
The implication here is just like with any other service or product. If you don't follow the instructions on how to use the service or product, then you can't expect the provider or manufacturer to support your means of using the service/product.
In regards to hosting, a hosting provider can't force you to use their nameservers. BUT... you shouldn't be shocked if by not using them you eventually run into issues. It's the price that is paid from deviating from the given instructions.
Assuming this method delivers the desired result, does it have any disadvantage?
Yes,but neglectable.
You should very much consider yourself a newbie. You can do what you want for personal sites, but if you said your job was as an admin for this server, you'd get tons of shit for being grossly unprepared.
in the shared hosting panel dns section you can find the new ip address the host use for your domain
update it at the 3rd party dns provider you used
problem solved
it's very rare for shared hosting provider to change ip address tho
if they really need and don't have choice, at least email the customer. that's what good provider do.
yea i thought it odd they didn't communicate about it. even just a banner in the panel or something.
What if that user's domain registered with Cloudflare? Cloudflare didn't allow domain owners to change from their DNS to third parties.
Any half-decent shared hosting provider uses a panel that supports the Cloudflare API.
And every half-decent panel supports Cloudflare and some other DNS APIs.
If yours don't - they are stuck in 2010.
never had happen, why do they change ip often? rented ip ?
Only if the provider is running their hosting on the same server as their DNS server.
And also, RFC 1034 explicitly forbids using a CNAME for the zone apex (@).
I'll go on record and say that I'm not a fan of Cloudflare, so take from this what you want.
I'm not a fan of Cloudflare begging hosts to "whitelist their IPs" so that website flooding can go on unchecked at the hosting provider's expense.
As a hosting provider, you're left with two chooses when it comes to Cloudflare. You can either do what Cloudflare tells you to do, whitelist their IPs, and when your servers get flooded with traffic that Cloudflare is not stopping - you hope their your customers will log into their Cloudflare account and click the "I'm under attack" button to limit inbound flooding or you just suffer through the flood because there's nothing you can do. Or, you can ignore what Cloudflare tells you to do and not whitelist their IPs and when a flood of traffic comes into your server for a website that is hiding behind Cloudflare, you block the Cloudflare based IPs and then everyone on the server that is using Cloudflare also gets blocked.
If the instructions for onboarding accounts tells the account owner to use the web hosting based nameservers, then those accounts that are being blocked because they are using Cloudflare... did they follow instructions?
I'm sure Cloudflare is great if you are someone that is invested in the state of your website and the performance of the underlying server. And this likely describes a fair amount of the citizens of this forum. But expand that to look at typical shared hosting accounts. They often don't share that same zeal for watching server performance. They often use a set-it-and-forget-it strategy and Cloudflare can often be a detriment in those situations.
Thanks for letting me know. I didn't know such things existed directly from the control panel of the shared hosting, as I never use shared hosting much. Learn something new every day.
A surprising conclusion of this thread is that shared hosting customers are expected to not use premium DNS hosting.
i don't think it's really surprising if you consider the typical shared hosting customer and even if they know how shit works using shared hosting is probably to minimize effort so pointing everything at the hoster just makes sense.
i have limitlesshost $5 promo shared hosting since 2022, they never change the ip address, and i'm using bunny as dns as long as they not charge me lol.
it's provider issue. they should communicate more efficiently.
You might want to educate yourself first!, there is no reason absolutely no reason to “White-list” cloudflare providers entirely.
Cloudflare includes a free IP Forwarded header and a variety of various information for you to be able to rate-limit as you would any other client.
Your magical no solution scenarios don’t exist, and you’d have every shared web-host iexposed to the most basic of attacks which they are not.
The actual connection comes from a Cloudflare IP.
The CF-Connecting-IP header only gets exposed once you reach Layer 7 of the OSI model.
By the time a connection has reached Layer 7 your server has already done a fair amount of processing.
If you really want to stop flooding or attacks, you have to do that earlier in the OSI model. iptables/ipset/nft operate at Layer 4 of the OSI model. But CF-Connecting-IP is not exposed at this point. The only thing that is available is the Cloudflare connecting IP (i.e. 103.21.244.34). So if you really want to stop attacks or flooding, you want to do that at Layer 4.
IF the owner of a website is also closely involved with the performance of the server they are being hosted on, then Cloudflare might be useful for them. If you're posting here on lowendtalk, there's a good chance that this describes you.
But it doesn't, at least in my experience, describe typical shared hosting users. Ask any shared hosting customer what the server load is for the server hosting their website, you're going to get a lot of "What's a server load?" And that's OK, I'm not bashing them for not knowing. But you can't really use Cloudflare unless you are really involved in the operation of the underlying server.
If you're using Cloudflare and your website comes under attack or gets flooding with bot traffic and if you don't want to do a Layer 4 block, then you have to block it at Cloudflare. And typical shared hosting customers are not going to know that their website is being flooded and won't be logging into their Cloudflare account to block the attack.
Someone mentioned linking your Cloudflare account to your hosting using control panel features. And that would be great... if customers would use it. Experience has taught me that customers that are going to use Cloudflare are going to sign up for Cloudflare directly on their website. They are not going to take the time to link it to their web hosting account.
No, you don't. Because the idea is that you only allow Cloudflare IPs at layer 4.
No other IPs as a rule of good security practice, if you use Cloudflare.
They will handle all the bots at all layers.
That's good enough, Cloudflare will only pass you valid layer 7 traffic.
This assumes that EVERY account on a shared hosting server is using Cloudflare nameservers. Again... this may be true for you and for a lot of lowendtalk users. But it's not going to work with common shared hosting customers.
I'm glad that's been your experience. It has not been my experience.
Cloudflare needs to configured correctly and maintained to be effective.
Of course not. What "premium" DNS hosting would that be in your case, anyway?
If it is premium it is not free with your registrar as you said. Also it is not premium if it is hosted by your registrar, period. Most registrar dns is ass.
Regarding this questionable suggestion:
@vinhais said:
And then the follow-up:
Please fucking don't do this and no the risks are not negligible. The !genius upthread suggests you CNAME your apex domain to the
ns1hostname of the shared vendor. This is wrong on so many levels that I don't know where to start.Firstly, cloudflare has absolutely defiled most users by using what they call "CNAME flattening". Cloudflare CNAMEs are not real CNAMEs (as in, they don't conform to the RFC). Cloudflare CNAMEs are effectively ALIAS/virtual records that internally map hostnames. If you try to do what Cloudflare does with any other DNS provider your domain will break.
The RFC clearly states that a CNAME record is incompatible with all other record types. So when a certified !genius uses a non-Cloudflare DNS provider and CNAMEs the apex domain, he can no longer deploy TXT records to prove domain ownership for email, to use SPF policy to prevent email spoofing, to use Google Search Console, etc.
Secondly, there is no guarantee that the shared hosting provider nameservers share a node with where your website is hosted. This has certainly never been the case on the shared hosting providers I used (for my sins) in my youth.
And no manual configuration is not necessary. You can just use any of the conventional tools for detecting your outbound IP address and use that to programmatically update your DNS to point at your shared hosting node (but that defeats the purpose of using shared hosting IMO you're effectively doing dyndns like on a residential toaster).
But the best solution is to abandon the cancer that is shard hosting.
To answer the original practice - is using the provider's nameservers common for shared hosting? Yes. Because shared hosting is designed for certain individuals whose intellect I would dearly like to criticize in various and inventive ways. Shared Hosting is the Apple of the internet community: designed to be seamless and flashy because the user is presumed to be a dunce.