New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
easyDNS offers a range of DNS hosting from quite expensive to gratis with registration.
I also observed that according to most of this thread, a shared hosting customer is expected to not use DNS hosting from IncogNET or any other premium DNS host. (Maybe Cloudflare is in the same category, but I haven't digested the Cloudflare discussion in this thread.) This feels awfully limiting. Maybe a good option for some is to go ahead and use DNS of choice, and simply wait for an outage before inquiring about why the outage is happening. That strategy works unless an outage hurts one's business.
Ok, so you have lots of services outside the shared hosting where it's easier to change a dozen DNS records for the shared hosting services and want them reachable when the shared hosting is down longer than caching periods. Yes, that's the minority for shared hosting and then it's on you to maintain the external DNS records.
But it's standard practice for the hosting provider to announce IP changes for this reason. If they don't, switch providers.
The point about selecting a new host ultimately answers the question of this thread. Thank you.
To anyone who wants to belabor the subject with me, does the following scenario sound reasonable?
A domain name is used mostly for mail. The owner considers the mail to be important enough to justify being a just a bit selective about DNS hosting. Meanwhile, the owner wants to the name to resolve to a basic web site that does nothing important. She prefers this outcome over a blank, spinning wheel that visitors would see if a web site does not exist. Therefore, she selects an inexpensive shared web host and finds out the host wants her to change DNS, which would undo her previous efforts to find DNS that handles mail to her satisfaction.
Sounds absolutely fine for shared hosting. It's not normal for a host to routinely change the IP associated with a server.
In the unlikely event it's required (perhaps due to upgrades or migrations) you should be notified in advance (probably multiple notifications) and provided with ample time, as well as window in which you should make the changes.
Absolutely crazy to assume everyone is using their nameservers.
Then nobody should give two fucks if the nonexistent webhost goes offline.
The MX records use names, not IP. Even in the spf, you can use a hostname, iirc. And even so, if you really cared about mail and premium DNS, you'd have spf and DKIM monitoring setup.
Anyway, you're shenanigans up and down (free DNS from registrar becomes Premium and intentional). A lot of mental gymnastics for you to feel better about not knowing something you maybe should have.
Anyway, you bought shared hosting of multiple services, not a single one, so the expectation and easiest management is for the server to handle DNS. Full. Stop.
The other thing is, you're responsible for basic troubleshooting. You should have a managed service if you need advice and hand holding support.
Lots of noise.... So...
In short:
They changed the shared hosting IP. It doesn't happen much but when it does...
When using their DNS, as advised by them:
Ip gets auto updated in the dns records, you might not even have noticed.
When not using their DNS:
You should do it yourself. If they didn't notify of the ip change, or you missed it... Tough luck.
Had a similar issue when hostslim changed the shared hosting IP and didn't notify me. Monitor picked up the issue though, changed A records within minutes.
We are talking about the very same host.
You seem to feel a bit more strongly about the matter than I do. Or there is more emotion going on at your end. I'd like to learn from you (if there is something to learn) and I'm wondering if there is a reason for a tone of anger.
I don't have the time or patience to deal with your sensitive ass. You ask to be educated and then argue the entire time.
@beanman109 ahh solution
you're trying too hard to be funny
You’re seemingly not trying at all
jbiloh isn't paying me enough to drive traffic here anymore
If this thread bothers you, please feel free to ignore it. I don't know what prompted the emotion. Anyway, I look forward to reading back through this thread and learning what I can.
The main conclusion I see so far is that hosts are responsible for communicating a change to an IP address.
By choosing HostSlim and not hosting DNS there, one must accept the risk.
It's not 2014 anymore bro everyone supports this shit now
https://support.bunny.net/hc/en-us/articles/24872742824220-Do-you-support-CNAME-flattening
https://docs.gcore.com/dns/dns-records/specify-cname-at-root
https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains-route53.html
https://docs.cloud.google.com/dns/docs/cnamechasing
https://doc.powerdns.com/authoritative/guides/alias.html
https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/subsect_1547053319.html
That's not emotional. You're just sensitive.
If you haven't already in the last 5 weeks, I doubt it.
No, the main conclusion is that the shared hosting provider expects their nameserver to be used and you're on your own to update IP's. Secondarily, it's ideal and expected for providers to inform users but not guaranteed.
That's true for any shared hosting. It's not risk, it's just assuming the administration of, which you're kind of responsible for anyway.
I see two ways. One is to get knowledgeable with DNS and to run your own NS - which I advise against for anyone with just one or two domains and relatively basic needs.
The other one I didn't see yet in this thread and so I mention it: Use scripting (if you know how to, pretty much any scripting language will do) and use some free and reasonably flexible NS service (like the one you mentioned)
.
Reason: maximal independence.
How?
Have a script (you need to create) run on some server to which you have SSH access. Have said script check entries for your domain's IP at your hosting provider (like, in a shell
host -t A *yourdomain*) frequently within reason, i.e. not every 50 ms but maybe in between once a minute and once every 15 min, depending on how critical whatever happens to be on your server is (in other words: check somewhat more often than "perceived downtime" acceptable for your users/visitors).Keep a 'lastIP' variable and check whether the newest IP obtained in above request is the same (i.e. not changed). If it changed however adapt the 'A' record on the name server for your domain. Don't forget to change the lastIP variable to the new one.
Done. No more dependence on your shared hoster, full control over your NS records, next to no downtime/switch-over time (keep in mind that changed name server entries have some propagation delay anyway).
Yes no maybe. It is not 2014 anymore but the DNS RFC is the DNS RFC and a standards-compliant CNAME is incompatible with other RRTypes. Providers offering various virtual records (ANAME/ALIAS/faux CNAME) does not negate the standards issue. In some cases it makes things even worse when you, for instance, export a cloudflare zone with fake CNAME records and try to import that zone in a BIND-compatible resolver.
Do I, personally, think we should have an official standard for ANAME/ALIAS? Yes, very much so. As you said it is no longer 2014 nor 1994, the computational load of dynamically calculating ALIAS references when a zone is built is not that great. Personally I run Stackoverflow's
dnscontrolto transparently create zonefiles based on templates to achieve the same thing.But none of this detracts from the standards compliance issue.
Alt f4 this provider