docs: port still-relevant WHMCS KB articles to the dedicated KB
First step of retiring the WHMCS knowledgebase in favour of kb.anhonesthost.com. Ports the four articles that are still accurate and product-agnostic, into three new top-level sections: - domains/ — transferring a domain, flushing a local DNS cache - email/ — why we filter outbound mail - support/ — remote support via RustDesk Content was refreshed rather than copied verbatim: - RustDesk download links were pinned to 1.3.8; now point at /releases/latest (current is 1.4.9). API server switched to https, which the relay serves. - macOS DNS flush gained the killall mDNSResponder step, without which the documented command usually appears to do nothing. - The nameserver list was deliberately not ported — this KB points customers at Dashboard → Server Information instead of hardcoding per-server values. - Added an anti-social-engineering warning to the remote-support page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
AnHonestHost Dev
co-authored by
Claude Opus 5
Claude Opus 5
parent
f0ec3395ab
commit
ee6b6af107
@@ -19,6 +19,9 @@ export default defineConfig({
|
||||
'/whp/reference/': '/whp/reference/service-hostnames/',
|
||||
'/whp/add-ons/': '/whp/add-ons/overview/',
|
||||
'/whp/admin/': '/whp/admin/overview/',
|
||||
'/domains/': '/domains/transferring-a-domain-to-us/',
|
||||
'/email/': '/email/outbound-spam-filtering/',
|
||||
'/support/': '/support/remote-support/',
|
||||
},
|
||||
vite: {
|
||||
resolve: {
|
||||
@@ -85,6 +88,18 @@ export default defineConfig({
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Domains',
|
||||
items: [{ autogenerate: { directory: 'domains' } }],
|
||||
},
|
||||
{
|
||||
label: 'Email',
|
||||
items: [{ autogenerate: { directory: 'email' } }],
|
||||
},
|
||||
{
|
||||
label: 'Support',
|
||||
items: [{ autogenerate: { directory: 'support' } }],
|
||||
},
|
||||
// Future products only appear once they have content.
|
||||
],
|
||||
pagefind: true,
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: Flush your DNS cache
|
||||
description: Your site moved or its DNS changed, but your computer still loads the old version? Clear the DNS cache your device has saved locally.
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
When you visit a site, your computer saves ("caches") the answer to *which server is this domain on?* so it doesn't have to ask again every time. That's normally invisible and helpful — but right after a domain moves to a new server or its DNS records change, your device can keep using the old answer and show you the old site.
|
||||
|
||||
Devices are supposed to re-check after a short while, but some record lifetimes stretch to hours or even days. Clearing the cache by hand skips the wait.
|
||||
|
||||
## First, confirm it's actually your computer
|
||||
|
||||
Before changing anything locally, check whether the new DNS has actually gone out to the world. Look your domain up at [whatsmydns.net](https://www.whatsmydns.net/) — it queries servers in many countries at once.
|
||||
|
||||
- **Most locations show the new value** — the change has propagated, and a stale local cache is the likely culprit. Continue below.
|
||||
- **Most locations still show the old value** — the change hasn't propagated yet. Flushing your own cache won't help; give it time.
|
||||
|
||||
<Aside type="tip">
|
||||
A quick sanity check: open the site in a **private / incognito window**, or on your phone using mobile data instead of Wi-Fi. If it looks correct there, the problem is local to your computer.
|
||||
</Aside>
|
||||
|
||||
## Windows
|
||||
|
||||
<Steps>
|
||||
|
||||
1. Press the **Windows key**, type `Command Prompt`, and open it.
|
||||
|
||||
2. Type this and press **Enter**:
|
||||
|
||||
```text
|
||||
ipconfig /flushdns
|
||||
```
|
||||
|
||||
3. You should see *"Successfully flushed the DNS Resolver Cache."*
|
||||
|
||||
</Steps>
|
||||
|
||||
## macOS
|
||||
|
||||
<Steps>
|
||||
|
||||
1. Open **Terminal** (in **Applications → Utilities**, or press `Cmd` + `Space` and search for "Terminal").
|
||||
|
||||
2. Type this and press **Enter**:
|
||||
|
||||
```bash
|
||||
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
|
||||
```
|
||||
|
||||
3. Enter your administrator password when prompted, then press **Enter**. Nothing is printed when it works — no news is good news.
|
||||
|
||||
</Steps>
|
||||
|
||||
<Aside type="note">
|
||||
Both commands matter on macOS: the first clears the lookup cache, the second restarts the service that answers DNS queries. Running only the first often appears to do nothing.
|
||||
</Aside>
|
||||
|
||||
## Still seeing the old site?
|
||||
|
||||
Your computer isn't the only thing that caches DNS. Work outward:
|
||||
|
||||
- **Your browser** keeps its own cache. Do a hard refresh (`Ctrl` + `Shift` + `R`, or `Cmd` + `Shift` + `R` on a Mac) or try a private window.
|
||||
- **Your router** caches DNS too. Restarting it clears that.
|
||||
- **Your internet provider's resolvers** cache as well, and you can't clear those — they expire on their own schedule. If everything else is clean, this is usually what's left. It typically resolves within a few hours.
|
||||
|
||||
If it's still wrong well after the record's lifetime should have expired, it may not be a caching problem at all — get in touch and we'll look at the actual DNS records.
|
||||
|
||||
## Related
|
||||
|
||||
- [Manage DNS records](/whp/how-to/manage-dns-records/)
|
||||
- [Add a domain](/whp/how-to/add-a-domain/)
|
||||
- [Clear your site's cache](/whp/how-to/clear-your-cache/) — for when *content* is stale rather than DNS.
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Transferring a domain to us
|
||||
description: What happens after you start a domain transfer — the confirmation emails, how long it takes, and the nameserver check to do afterwards.
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
You've started a domain transfer to us — here's what happens next, and the one thing worth checking once it lands.
|
||||
|
||||
## Before the transfer will go through
|
||||
|
||||
Your current registrar has to let the domain go first. At the registrar you're leaving, make sure you've:
|
||||
|
||||
- **Unlocked the domain.** Registrars set a transfer lock by default to prevent unauthorised moves.
|
||||
- **Turned off WHOIS / domain privacy.** Privacy services can hide the administrative address the confirmation email needs to reach.
|
||||
- **Got the EPP code** (sometimes called the auth code or transfer key). Your registrar provides this, usually by email or in the domain's settings.
|
||||
|
||||
<Aside type="caution">
|
||||
Domains can't be transferred within **60 days** of being registered, or within 60 days of a previous transfer. That's an ICANN rule, not a registrar policy — nobody can waive it.
|
||||
</Aside>
|
||||
|
||||
## Confirming the transfer
|
||||
|
||||
<Steps>
|
||||
|
||||
1. **Watch for confirmation emails.** You'll get one or both of:
|
||||
|
||||
- a message from **your previous registrar**, confirming the domain is moving away from them;
|
||||
- a message from **NameCheap**, who we use to resell domains, confirming it's moving to our account.
|
||||
|
||||
They go to the domain's registered contact address — which may not be the address you use with us. If nothing arrives, check that address and its spam folder.
|
||||
|
||||
2. **Click the confirmation link** in the email. Nothing moves until you do; an unconfirmed transfer just sits until it expires.
|
||||
|
||||
3. **Wait for it to complete.** Once confirmed, the transfer usually finishes in **1 to 12 hours**, depending on how quickly the losing registrar releases it. Your account page updates to reflect the domain once it's done.
|
||||
|
||||
</Steps>
|
||||
|
||||
## After it completes: check your nameservers
|
||||
|
||||
This is the step people miss. Some registrars — **GoDaddy** most notably — reset a domain's nameservers when they release it. If that happens, the domain transfers to us successfully but still points at the old host, so your site or email can appear to break for no obvious reason.
|
||||
|
||||
Once the transfer shows as complete, confirm the domain's nameservers match the ones for your hosting. If you're on WHP, your server's nameservers are listed on the **Dashboard** page under **Server Information** — see [Add a domain](/whp/how-to/add-a-domain/) for where to set them.
|
||||
|
||||
<Aside type="tip">
|
||||
A transfer moves *registration*, not *hosting*. Your site's files and email stay wherever they already live. If you're also moving hosting to us, that's a separate step — ask us and we'll help sequence the two so nothing goes dark.
|
||||
</Aside>
|
||||
|
||||
## Related
|
||||
|
||||
- [Add a domain](/whp/how-to/add-a-domain/)
|
||||
- [Manage DNS records](/whp/how-to/manage-dns-records/)
|
||||
- [Flush your DNS cache](/domains/flush-your-dns-cache/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Why we filter outbound email
|
||||
description: We scan mail leaving our servers, not just mail arriving. Here's why, and what to do if a legitimate message gets held.
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
Most hosts filter the mail arriving at your inbox. We also filter the mail **leaving** our servers — which occasionally surprises people, so here's the reasoning.
|
||||
|
||||
## Why outbound filtering exists
|
||||
|
||||
Large mail providers — Gmail, Outlook / Hotmail, Yahoo and others — judge mail by the **server it came from**, not by who wrote it. If spam leaves our servers, we're recorded as the sender, and our server's address can land on a blocklist.
|
||||
|
||||
That matters even when the spam isn't ours to begin with. A forwarder is the classic case: someone sends spam to an address on our server that forwards to a Gmail account. We didn't originate it, but as far as Gmail is concerned, we handed it over — so it counts against us.
|
||||
|
||||
Once a server is blocklisted, the consequences land on everyone hosted there. Most lists delist within a few days, but some take **up to a year**, and repeated or severe listings can attract longer penalties or a refusal to delist at all. During that time, mail from every customer on the server is at risk of being rejected or sent to spam.
|
||||
|
||||
Outbound filtering is how we keep that from happening. It's not a common feature among hosting providers, and we think it should be.
|
||||
|
||||
## When legitimate mail gets caught
|
||||
|
||||
No filter is perfect. Marketing and bulk mail is the most likely to be held, since it shares many characteristics with the mail the filter is built to stop.
|
||||
|
||||
If a message you sent didn't arrive, [open a ticket](https://secure.anhonesthost.com/submitticket.php) with:
|
||||
|
||||
- the **subject line** of the message;
|
||||
- the **from** address;
|
||||
- the **destination** address;
|
||||
- roughly **when** you sent it.
|
||||
|
||||
That's enough for us to find it in the logs, release it if it's legitimate, and tune the filter so similar messages pass in future.
|
||||
|
||||
<Aside type="tip">
|
||||
Sending genuine bulk or marketing email? Tell us before you start. We can make sure your sending domain is set up so it isn't mistaken for spam — and we'll go over the authentication records and consent rules that keep it landing in inboxes.
|
||||
</Aside>
|
||||
|
||||
## Helping your mail get delivered
|
||||
|
||||
Filtering aside, most delivery problems come down to authentication. Mail from your domain should have **SPF** and **DKIM** records in DNS so receiving servers can verify it really came from you.
|
||||
|
||||
If your domain uses our nameservers, we add an SPF record automatically when you add the domain, and your DKIM records are listed in WHP under **Email → Email Domains (DNS)**. If your DNS lives elsewhere, you'll need to copy those records to your DNS provider yourself — see [Create an email account](/whp/how-to/create-an-email-account/).
|
||||
|
||||
## Related
|
||||
|
||||
- [Create an email account](/whp/how-to/create-an-email-account/)
|
||||
- [Manage DNS records](/whp/how-to/manage-dns-records/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Remote support with RustDesk
|
||||
description: Install and configure the RustDesk client so our support team can connect to your device and help directly.
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
Sometimes the fastest way to sort something out is for us to see your screen — configuring an email client, reproducing an error we can't recreate from our side, or walking through a setting together.
|
||||
|
||||
We use **RustDesk**, an open-source remote-desktop tool, running on our own relay server rather than a third-party service. Nothing is installed permanently and nothing runs in the background: you start it when you want help and close it when you're done.
|
||||
|
||||
<Aside type="caution">
|
||||
We will never ask you to install remote-support software out of the blue. If someone contacts you claiming to be from AnHonestHost and asks for remote access to your computer — especially about a payment, a refund, or a "problem with your account" — stop and [open a ticket](https://secure.anhonesthost.com/submitticket.php) to check it's really us. Only ever run this at the end of a conversation *you* started with us.
|
||||
</Aside>
|
||||
|
||||
## Install the client
|
||||
|
||||
Download RustDesk for your device from the official releases:
|
||||
|
||||
- **Windows, macOS, and Android** — [github.com/rustdesk/rustdesk/releases/latest](https://github.com/rustdesk/rustdesk/releases/latest). Pick the `.msi` for Windows, the `.dmg` for macOS, or the signed `.apk` for Android.
|
||||
- **iOS / iPadOS** — [RustDesk on the App Store](https://apps.apple.com/us/app/rustdesk-remote-desktop/id1581225015).
|
||||
|
||||
## Point it at our server
|
||||
|
||||
We run our own ID and relay server, which is faster and keeps your session off shared public infrastructure. You only need to do this once.
|
||||
|
||||
<Steps>
|
||||
|
||||
1. Open **Settings**. On desktop that's the **three dots** next to your ID; on mobile it's the settings icon.
|
||||
|
||||
2. On desktop, choose **Network**. (On mobile, skip straight to the next step.)
|
||||
|
||||
3. Choose **ID/Relay server** and enter:
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| **ID server** | `rustdesk.cloud-hosting.io` |
|
||||
| **Relay server** | `rustdesk.cloud-hosting.io` |
|
||||
| **API server** | `https://rustdesk.cloud-hosting.io` |
|
||||
| **Key** | `UmpkeFe76AKt8vw8Pj0YCSbxIcYLsqqfPGYzLRl+PgA=` |
|
||||
|
||||
4. **Save**, then go back to the **Home** screen.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Starting a session
|
||||
|
||||
The support operator needs two things from the Home screen:
|
||||
|
||||
- **Your ID** — a nine-digit number that stays the same for your device.
|
||||
- **Your one-time password** — shown beneath the ID, and regenerated each time.
|
||||
|
||||
Give both to your support operator over the phone, or in your ticket.
|
||||
|
||||
<Aside type="tip">
|
||||
If you send them in a ticket rather than over the phone, **leave your computer on with RustDesk running** — the one-time password only works while the client is open, and we can't connect to a sleeping machine.
|
||||
</Aside>
|
||||
|
||||
## Ending a session
|
||||
|
||||
Close the RustDesk window when you're finished. With it closed, no connection is possible — the one-time password from your session is already spent, and a new one is generated next time you open it. You can uninstall the client entirely if you'd rather.
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -28,6 +28,21 @@ const PRODUCT_META: Record<string, { title: string; blurb: string; firstSection:
|
||||
blurb: 'Configure Outlook, Apple Mail, Thunderbird, and mobile clients.',
|
||||
firstSection: 'index',
|
||||
},
|
||||
domains: {
|
||||
title: 'Domains',
|
||||
blurb: 'Transfer a domain to us, point it at your hosting, and sort out DNS problems.',
|
||||
firstSection: 'transferring-a-domain-to-us',
|
||||
},
|
||||
email: {
|
||||
title: 'Email',
|
||||
blurb: 'How our mail filtering works and what to do when a message does not arrive.',
|
||||
firstSection: 'outbound-spam-filtering',
|
||||
},
|
||||
support: {
|
||||
title: 'Support',
|
||||
blurb: 'Working with our support team, including remote-assistance sessions.',
|
||||
firstSection: 'remote-support',
|
||||
},
|
||||
};
|
||||
|
||||
const docs = await getCollection('docs');
|
||||
|
||||
Reference in New Issue
Block a user