Foundations of Level 1 Support in Domain Registration & Shared Hosting Infrastructure Print

Core Knowledge Base for Level 1 Customer Support

Classification: Support Operations
Version: 1.0
Last Updated: 2026-02-19
Audience: Level 1 Technical Support Engineers

Table of Contents

1. Layer Separation Model
2. Domain Registration & Lifecycle
3. DNS Systems & Record Management
4. Shared Hosting Operations
5. Resource Limits & Server Constraints
6. Email Systems & Troubleshooting
7. Email Authentication: SPF, DKIM, DMARC
8. HTTP Errors & Web Diagnostics
9. SSL/TLS Certificates
10. Billing Workflows & Suspension Logic
11. Security Awareness for L1 Support
12. Escalation Framework
13. Diagnostic Checklists
14. Appendices & Quick Reference

1. Layer Separation Model

Every customer issue exists within one or more infrastructure layers. Misidentifying the layer leads to wasted time, incorrect fixes, and unnecessary escalations. Before any troubleshooting, determine which layer the problem belongs to.

The Five Layers

Why Layer Separation Matters

A customer reports: "My website is down."

This could be:

• Domain layer: Domain expired and registry has placed a hold on it.
• DNS layer: Nameservers changed or A record points to a decommissioned IP.
• Hosting layer: Account suspended, server down, or resource limit hit.
• Billing layer: Unpaid invoice triggered automatic suspension.

Rule: Always verify from the top layer downward. Domain → DNS → Hosting → Application.

Quick Layer Identification

Customer says "site is down" →
  1. Does the domain resolve? (dig/nslookup) → If NO → Domain or DNS layer
  2. Does it resolve to the correct IP? → If NO → DNS layer
  3. Does the server respond on that IP? → If NO → Hosting/Server layer
  4. Does the server return an error? → If YES → Application or Hosting layer
  5. Is the account active and paid? → If NO → Billing layer

2. Domain Registration & Lifecycle

Domain Lifecycle Stages

Every domain passes through a defined lifecycle. Understanding these stages is critical to answering renewal, expiry, and recovery questions accurately.

  AVAILABLE         ← Domain is unregistered, anyone can register
      |
      | Registration
      v
  ACTIVE            ← Domain is registered and functional (1-10 years)
      |
      | Expiry date passes
      v
  EXPIRED (Grace)   ← Grace period begins (typically 0-45 days, varies by TLD)
      |               Domain stops resolving or shows registrar parking page
      | Grace period ends
      v
  REDEMPTION /      ← Recovery possible but at a premium fee ($80-$200+)
  RESTORE PERIOD      depending on TLD and registrar
  (30 days typical)
      |
      | Redemption ends
      v
  PENDING DELETE    ← 5-day ICANN-mandated deletion queue
  (5 days)            Domain CANNOT be recovered during this phase
      |
      | Deletion
      v
  AVAILABLE         ← Domain returns to general availability
                      (or caught by drop-catch services)

Key Lifecycle Facts

• Auto-renewal: If enabled and a valid payment method is on file, the system attempts renewal before expiry. Auto-renewal typically triggers 1–30 days before the expiry date, depending on registrar policy.
• Grace period duration varies by TLD:
  • .com, .net: ~40 days
  • .in: ~30 days
  • .org: ~45 days
  • ccTLDs (.co.uk, .de, etc.): Varies widely; some have no grace period at all.
• Redemption fees are NOT refundable and are set by the registry, not the registrar. The registrar may add a margin on top.
• WHOIS expiry date vs actual resolution loss: WHOIS may still show the old expiry date during grace period, but the domain may already be non-functional.

Domain Statuses (EPP Status Codes)

Customers often ask why their domain is not working or cannot be transferred. The answer is usually in the EPP status codes visible in WHOIS.

Domain Transfers

Outbound Transfer (Customer leaving)

1. Domain must be unlocked (clientTransferProhibited removed).
2. Domain must have a valid authorization code (auth code / EPP code).
3. Domain must not have been registered or transferred within the last 60 days (ICANN 60-day lock).
4. WHOIS email must be accessible — transfer approval goes there.
5. Domain must not be expired (some registries block transfer of expired domains).

Inbound Transfer (Customer arriving)

1. Customer provides auth code from losing registrar.
2. Transfer initiated from our system.
3. Losing registrar sends confirmation; if no action, transfer auto-approves in 5 days.
4. Domain is added 1 year on top of the existing expiry date (not from the transfer date).

Common Transfer Failures

• Auth code is incorrect or expired.
• Domain is locked at the losing registrar.
• 60-day transfer lock is active (recent registration, transfer, or WHOIS contact change).
• WHOIS email is invalid — approval email cannot be delivered.
• Domain is expired and in redemption — transfer blocked by registry.

ICANN WHOIS Verification

For gTLDs (.com, .net, .org, etc.), ICANN requires registrants to verify their email address within 15 days of registration or WHOIS contact change. If not verified:

• Domain is suspended (clientHold).
• Website and email stop working.
• Fix: Customer clicks the verification link in the email from the registrar. If lost, resend from the admin panel.

This is one of the most common causes of "my new domain isn't working" calls.

3. DNS Systems & Record Management

How DNS Resolution Works

User types example.com in browser
        |
        v
Browser cache → OS cache → Router cache → ISP Resolver
        | (if not cached)
        v
ISP Resolver queries Root servers
        | "Who handles .com?"
        v
Root servers respond: "Ask the .com TLD servers"
        |
        v
ISP Resolver queries .com TLD servers
        | "Who handles example.com?"
        v
TLD servers respond: "Ask ns1.hostingprovider.com"
        |
        v
ISP Resolver queries ns1.hostingprovider.com
        | "What is the A record for example.com?"
        v
Authoritative nameserver responds: "93.184.216.34"
        |
        v
Browser connects to 93.184.216.34

DNS Record Types

Critical DNS Concepts

TTL (Time To Live)

• Expressed in seconds. Tells resolvers how long to cache a record.
• TTL 3600 = Cache for 1 hour.
• TTL 86400 = Cache for 24 hours.
• Before migration: Lower TTL to 300 (5 min) at least 24–48 hours before the change, so old caches expire.
• After migration is confirmed stable: Raise TTL back to 3600–86400.
• Common mistake: Customer changes DNS and expects instant effect. If old TTL was 86400, it can take up to 24 hours for all resolvers worldwide to see the change.

Propagation

• DNS does not truly “propagate.” What happens is old cached entries expire based on TTL, and resolvers fetch fresh records.
• Typical visible change time: 5 minutes to 48 hours, depending on prior TTL.
• Use tools like dig, nslookup, or online propagation checkers to verify.

Zone Apex (Root Domain) Limitations

• Cannot use CNAME at zone apex (example.com). This is an RFC restriction.
• Some DNS providers offer ALIAS/ANAME records as a workaround (functionally similar to CNAME but resolved server-side).
• If a customer wants example.com to point to a CDN, they either need ALIAS/ANAME support or must use an A record pointing to the CDN's IP.

Common DNS Failure Scenarios

Scenario 1: Domain registered but not resolving

• Check: Are nameservers set at the registrar?
• Check: Do the nameservers actually have zone records for this domain?
• Common cause: Customer registered domain but never added it to the hosting account, so no DNS zone exists.

Scenario 2: Website works, email doesn't

• Check: MX records. Are they pointing to the correct mail server?
• Check: If using third-party email (Google Workspace, Microsoft 365), are the MX records correctly set per their documentation?
• Common cause: Customer set up website A record but forgot to configure MX records.

Scenario 3: DNS changed but still showing old site

• Check: What was the TTL of the old record?
• Check: Is the customer's local DNS cache stale? (ipconfig /flushdns on Windows, or test from a different network)
• Check: Is Cloudflare or another CDN caching content?
• Common cause: High TTL on previous record; resolver cache hasn't expired yet.

Scenario 4: Subdomain not working

• Check: Does the A/CNAME record for the subdomain exist?
• Check: Is the subdomain added as an addon domain or subdomain in the hosting control panel?
• Common cause: DNS record exists but hosting server doesn't have a virtualhost configured for it.

DNS Diagnostic Commands

# Query A record
dig example.com A +short

# Query MX record
dig example.com MX +short

# Query specific nameserver
dig @ns1.hostingprovider.com example.com A

# Query with full trace
dig example.com +trace

# Check nameserver delegation
dig example.com NS +short

# Check TXT records (SPF, DKIM, DMARC)
dig example.com TXT +short
dig default._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short

# Reverse DNS lookup
dig -x 192.168.1.1

# Windows equivalent
nslookup example.com
nslookup -type=MX example.com

4. Shared Hosting Operations

How Shared Hosting Works

Shared hosting places multiple customer accounts on a single physical or virtual server. All accounts share CPU cores, RAM, disk I/O bandwidth, network bandwidth, and IP address(es).

Each account is isolated via:

• CageFS / CloudLinux: Jails each user into their own virtual filesystem. User A cannot see User B's files.
• PHP Selector: Per-account PHP version selection (7.4, 8.0, 8.1, 8.2, 8.3).
• Resource limits (LVE): Per-account CPU, memory, I/O, inode, and entry process limits enforced by CloudLinux.
• cPanel/WHM: Account-level control panel providing file management, database management, email, DNS zone editing, and application installation.

Control Panel Structure

WHM (Web Host Manager)
├── Server-level administration (L2/L3 only)
├── Account creation/suspension/termination
├── Server-wide PHP/Apache/Nginx configuration
├── DNS cluster management
└── Resource limit configuration

cPanel (Customer-facing)
├── File Manager / FTP Accounts
├── MySQL Databases / phpMyAdmin
├── Email Accounts / Forwarders / Autoresponders
├── DNS Zone Editor (if enabled)
├── SSL/TLS Management
├── Backup / Restore
├── Error Logs
├── Resource Usage (CPU, Memory, I/O stats)
├── Cron Jobs
├── PHP Version Selector
└── Softaculous (Application Installer)

Common Hosting Issues

“My website is showing a blank page”

1. Check error logs: cPanel → Error Logs (or ~/public_html/error_log in File Manager).
2. Common causes:
   • PHP fatal error (usually missing function, class, or extension).
   • PHP version mismatch (code requires 8.1 but account is on 7.4).
   • .htaccess syntax error.
   • memory_limit exceeded during page load.
3. Quick test: Create a phpinfo.php file with <?php phpinfo(); ?> — if this loads, PHP is working and the problem is in the customer's code.

“My website is very slow”

1. Check resource usage in cPanel → Resource Usage.
2. Look for: CPU limit hits, memory limit hits, I/O throttling, entry process (EP) limit.
3. Check if the slow response is server-side (TTFB > 2s) or client-side (large images, unoptimized JS).
4. Common causes:
   • Unoptimized WordPress with 30+ plugins.
   • No caching plugin active.
   • Database queries running without indexes.
   • Cron jobs running too frequently.
   • Bot traffic (check access logs for crawler IPs).

“I can't upload files via FTP”

1. Verify FTP credentials (username is usually [email protected] or just cpanel_username).
2. Check FTP server is running (port 21, or SFTP on port given by system).
3. Check if disk quota is full — uploads fail silently when disk is at 100%.
4. Check passive FTP port range if customer is behind a firewall.
5. Verify the customer is connecting to the correct server hostname.

“Database connection error”

1. Verify database name, username, and password in the application's config file.
2. Verify the database user is assigned to the database in cPanel → MySQL Databases → “Add User to Database.”
3. Check if the database user has sufficient privileges.
4. In cPanel, database names and usernames are prefixed with the cPanel username (e.g., cpuser_dbname). Customers often forget the prefix.
5. Check if the MySQL server is running (if multiple customers report the same issue, escalate — server-level problem).

File System Layout (cPanel)

/home/cpaneluser/
├── public_html/           ← Document root (main website)
│   ├── .htaccess          ← Apache rewrite rules, redirects, security
│   ├── index.php          ← Default landing page
│   ├── wp-config.php      ← WordPress configuration (if WP installed)
│   └── subdomain_folder/  ← Subdomain document root (configurable)
├── mail/                  ← Email data (Maildir format)
│   └── domain.com/
│       └── user/
│           ├── cur/       ← Read messages
│           ├── new/       ← Unread messages
│           └── tmp/       ← Messages being delivered
├── logs/                  ← Access and error logs
├── tmp/                   ← Temporary files, PHP sessions
├── .trash/                ← cPanel File Manager trash
├── etc/                   ← Account-level configuration
└── ssl/                   ← SSL certificate storage

.htaccess — Common Problems and Patterns

The .htaccess file is one of the most common sources of 500 errors and unexpected behavior on shared hosting.

Common issues:

• Syntax error → immediate 500 Internal Server Error.
• Infinite redirect loop → ERR_TOO_MANY_REDIRECTS.
• Overly aggressive rewrite rules → wrong pages loading.
• php_value / php_flag directives when server uses PHP-FPM (not mod_php) → 500 error.

Quick diagnosis: Rename .htaccess to .htaccess.bak. If the site loads, the problem is in .htaccess.

Common .htaccess patterns:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force www
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# WordPress default
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# Custom PHP settings (mod_php only - causes 500 on PHP-FPM)
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300

5. Resource Limits & Server Constraints

Shared Hosting Resource Model (CloudLinux LVE)

Each shared hosting account operates within enforced resource limits. When a limit is hit, the system throttles or blocks that account rather than allowing it to affect other users on the server.

Inodes: The Hidden Limit

Inodes are one of the least understood limits by customers and the most common cause of “everything broke at once.”

What counts as an inode: Every file, every directory, every email message, every cache file, every session file.

Common inode bloat causes:

• WordPress cache plugins creating thousands of static HTML files.
• Maildir email storage (each email is one file).
• Session files not being cleaned up (/home/user/tmp/).
• Backup files sitting in the account.
• node_modules directories (easily 50,000+ inodes for one project).
• File manager trash not emptied.

Symptoms when inode limit is hit:

• Cannot send or receive email (Maildir cannot create new files).
• Cannot upload files.
• cPanel shows errors when trying to create anything.
• WordPress/CMS may show white screen if it tries to write cache.
• Database operations fail if they need to create temp tables on disk.

Diagnostic approach:

1. Check inode usage in cPanel → Disk Usage or via Disk and Resource Usage.
2. Identify top directories consuming inodes.
3. Common cleanup: clear cache directories, empty trash, remove old backups, archive old emails.

Resource Usage Indicators — Reading the Graphs

cPanel's Resource Usage section (powered by CloudLinux LVE Stats) shows:

• Faults: Number of times the account hit its limit. Any fault count > 0 means the account is being throttled.
• Graph colors: Green = within limits. Yellow = approaching limits. Red = hitting limits.
• Timeframes: Check both “current usage” and “historical” (24h, 7d, 30d) to identify patterns.

Decision Framework for Resource Limit Issues

Account hitting CPU/Memory limits →
  ├── Occasional spikes?
  │     → Likely legitimate traffic spikes or cron jobs
  │     → Advise: optimize code, enable caching, review cron frequency
  ├── Constant hits?
  │     → Account has outgrown shared hosting
  │     → Advise: upgrade to higher plan or VPS
  └── Sudden onset?
        → Possible attack, compromised site, or broken script
        → Check access logs for unusual traffic
        → Check for suspicious files (shells, miners)
        → Escalate if compromise is suspected

6. Email Systems & Troubleshooting

Email Protocols

Important port notes:

• Port 25 is blocked by many ISPs and cloud providers for end users. Always use 587 or 465 for mail client configuration.
• Port 587 requires STARTTLS (upgrade from plain to encrypted). Port 465 is implicit SSL (encrypted from the start).
• Always configure customer mail clients with SSL/TLS. Never configure plaintext connections.

Email Flow: Sending

Sender's Mail Client (Outlook/Thunderbird/Gmail)
        |
        | SMTP (port 587/465) with authentication
        v
Sender's Mail Server (outbound)
        |
        | Looks up recipient's MX record via DNS
        v
DNS returns MX: mail.recipient.com (priority 10)
        |
        | SMTP connection to recipient's mail server (port 25)
        v
Recipient's Mail Server (inbound)
        |
        | Checks: SPF, DKIM, DMARC, spam filters, blacklists
        | Checks: Recipient exists? Mailbox full?
        v
Delivered to recipient's mailbox (or rejected/spam-flagged)

Common Email Failures

“I can't send email”

Diagnostic checklist:

1. Is authentication configured in the mail client? (Username = full email address, password = email account password)
2. Is the correct SMTP port being used? (587 with STARTTLS or 465 with SSL)
3. Is the password correct? (Reset from cPanel → Email Accounts to verify)
4. Is the sending IP blacklisted? (Check if the server IP is on any RBLs)
5. Is the account suspended? (Check billing status)
6. Is the recipient's server rejecting us? (Check the bounce-back message / NDR for exact error codes)
7. Is the outbound mail queue backed up? (Server-level issue — escalate)

“I can't receive email”

Diagnostic checklist:

1. Are MX records correct? (dig domain.com MX)
2. Is the mailbox full? (Check quota in cPanel → Email Accounts)
3. Is the email account actually created? (A domain existing doesn't mean email accounts exist)
4. Is the email going to spam? (Check Spam/Junk folder)
5. Is greylisting enabled? (First-time senders are temporarily rejected; email arrives on retry, usually 5–15 minutes later)
6. Is there a mail routing issue? (cPanel → Email Routing — should be “Local Mail Exchanger” if hosting email on this server)
7. Is the sender's server blacklisted? (Our server may reject incoming from blacklisted IPs)

“Emails are going to spam”

This is one of the most common and most complex issues. Contributing factors:

1. Missing or incorrect SPF record — recipient server cannot verify that our server is authorized to send for this domain.
2. Missing DKIM signature — no cryptographic proof that the email is authentic.
3. No DMARC policy — recipient server has no guidance on how to handle SPF/DKIM failures.
4. Server IP reputation — the shared hosting IP may be blacklisted because another user on the same server sent spam.
5. Email content — spam-like subject lines, excessive links, large attachments, HTML-only messages without text part.
6. New domain — domains less than 30 days old have no sending reputation.
7. No reverse DNS (PTR record) — the sending IP has no PTR record, or PTR doesn't match the HELO/EHLO hostname.
8. Sending volume spike — suddenly sending hundreds of emails from an account that normally sends 5/day.

Common Bounce Codes

IMAP vs POP3 — When to Recommend What

Critical POP3 issue: If a customer uses POP3 on their phone and then asks “where are my emails on the computer?”, the phone downloaded and deleted them from the server. This is not a server issue — it's how POP3 works. Enable “Leave a copy on the server” in POP3 settings to prevent this.

7. Email Authentication: SPF, DKIM, DMARC

These three mechanisms work together to authenticate email and prevent spoofing. Every L1 agent must understand them because they directly affect deliverability.

SPF (Sender Policy Framework)

What it does: Declares which mail servers are authorized to send email on behalf of a domain.

How it works: The receiving server checks the SPF TXT record of the sender's domain. If the sending server's IP is listed, SPF passes.

Record format (TXT record on the domain's DNS zone):

v=spf1 [mechanisms] [qualifier]

Common SPF records:

# Basic: Only this server can send
v=spf1 ip4:192.168.1.1 -all

# Shared hosting: Include the hosting provider's SPF
v=spf1 include:_spf.hostingprovider.com -all

# Google Workspace
v=spf1 include:_spf.google.com -all

# Microsoft 365
v=spf1 include:spf.protection.outlook.com -all

# Multiple services (hosting + Google Workspace)
v=spf1 include:_spf.hostingprovider.com include:_spf.google.com -all

Qualifiers:

SPF Lookup Limit: SPF processing is limited to 10 DNS lookups. Each include: directive counts as one lookup, and each included record may contain further lookups. Exceeding 10 causes SPF to permanently fail (permerror), which is worse than having no SPF at all.

Common SPF mistakes:

• Multiple SPF records on the same domain. There must be exactly ONE v=spf1 TXT record. If multiple exist, SPF fails.
• Missing include: for a third-party sender (e.g., transactional email service, CRM).
• Using +all — this authorizes the entire internet to send as your domain.

DKIM (DomainKeys Identified Mail)

What it does: Adds a cryptographic signature to outgoing emails. The receiving server verifies this signature against a public key published in DNS.

How it works:

1. The sending server signs the email headers and body with a private key.
2. The signature is added as a DKIM-Signature header in the email.
3. The receiving server looks up the public key via DNS: selector._domainkey.domain.com TXT record.
4. The receiving server verifies the signature.

DNS record (TXT):

Name:  default._domainkey.example.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCA... (public key)

Key points for L1:

• DKIM is typically configured at the server level and enabled per-domain in cPanel → Email → Authentication (or Email Deliverability).
• The “selector” (e.g., default) is chosen by the mail server admin. Different services use different selectors (Google uses google, Microsoft uses selector1 and selector2).
• If a customer uses a third-party email service (Google Workspace, Microsoft 365), they need to add the DKIM TXT records provided by that service.
• DKIM records are long (2048-bit keys). Some DNS providers have a 255-character TXT record limit per string. The record must be split into multiple strings within the same TXT record.

Checking DKIM:

dig default._domainkey.example.com TXT +short

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it does: Tells receiving servers what to do when SPF and/or DKIM fail, and where to send reports about authentication results.

DNS record (TXT):

Name:  _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:[email protected]

DMARC Policies:

DMARC Alignment:

• For DMARC to pass, either SPF or DKIM must pass and align with the “From” domain.
• SPF alignment: The Return-Path (envelope sender) domain matches the From header domain.
• DKIM alignment: The d= domain in the DKIM signature matches the From header domain.

Recommended starting DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

fo=1 = Generate failure reports when any authentication mechanism fails (useful for debugging).

Email Authentication Diagnostic Framework

Customer reports "email going to spam" or "email rejected":

1. CHECK SPF
   dig domain.com TXT | grep spf
   ├── No SPF record             → Add one
   ├── Multiple SPF records      → Merge into one
   ├── Missing include for service → Add it
   └── SPF passes                → Move to step 2

2. CHECK DKIM
   Look at email headers for DKIM-Signature
   dig selector._domainkey.domain.com TXT
   ├── No DKIM record            → Enable in cPanel or add record
   ├── DKIM fails                → Key mismatch, regenerate
   └── DKIM passes               → Move to step 3

3. CHECK DMARC
   dig _dmarc.domain.com TXT
   ├── No DMARC record           → Add basic p=none record
   ├── p=reject but mail failing → Relax to p=none, investigate
   └── DMARC passes              → Move to step 4

4. CHECK IP REPUTATION
   Look up server IP on mxtoolbox.com/blacklists
   ├── IP blacklisted            → Escalate to L2 for delisting
   └── IP clean                  → Move to step 5

5. CHECK EMAIL CONTENT AND SENDING PATTERNS
   ├── Spammy content?           → Advise on content best practices
   ├── New domain?               → Reputation needs time
   └── Volume spike?             → Advise gradual ramp-up

8. HTTP Errors & Web Diagnostics

HTTP Status Code Reference

2xx / 3xx — Success & Redirects

4xx — Client Errors

5xx — Server Errors

The 403 Diagnostic Tree

403 Forbidden →
├── File permissions wrong?
│   Files should be 644 (rw-r--r--)
│   Directories should be 755 (rwxr-xr-x)
│   Fix: cPanel → File Manager → Permissions
│
├── No index file?
│   Directory listing is disabled and there's no index.html/index.php
│   Fix: Add an index file or enable DirectoryIndex
│
├── .htaccess blocking access?
│   "Deny from all" or IP restriction
│   Fix: Review .htaccess rules
│
├── ModSecurity rule triggered?
│   WAF blocked the request as potentially malicious
│   Check: cPanel → Error Logs or ModSecurity log
│   Fix: If false positive, escalate to L2 to whitelist rule ID
│
├── Hotlink protection blocking?
│   cPanel Hotlink Protection may block direct access
│   Fix: Review Hotlink Protection settings
│
└── IP blocked by firewall?
    Customer's IP blocked by CSF/LFD after failed logins
    Check: Error for everyone or just this customer?
    Fix: Escalate to L2 to check and whitelist IP

The 500 Diagnostic Tree

500 Internal Server Error →
├── Check error log FIRST (cPanel → Error Logs)
│   The log will usually tell you exactly what went wrong
│
├── .htaccess error?
│   Rename .htaccess to .htaccess.bak
│   Site loads? → .htaccess was the problem
│
├── PHP version mismatch?
│   Check: cPanel → MultiPHP Manager
│   Try changing PHP version
│
├── File permission error?
│   Check ownership and permissions
│
├── PHP memory limit?
│   Check error log for "Allowed memory size exhausted"
│   Increase memory_limit in PHP settings
│
├── Broken plugin/theme? (WordPress)
│   Rename wp-content/plugins/ to plugins_disabled/
│   Site loads? → Plugin caused it; disable one by one
│
└── Server-level issue?
    Multiple customers affected?
    → Escalate to L2/L3

Key HTTP Headers for Diagnostics

9. SSL/TLS Certificates

Types of SSL Certificates

Let's Encrypt & AutoSSL

Most shared hosting providers offer Let's Encrypt (or similar free DV SSL) via AutoSSL in cPanel.

How AutoSSL works:

1. Runs automatically every few hours (or on-demand).
2. Validates domain ownership via HTTP challenge (places a file at /.well-known/acme-challenge/).
3. Issues or renews certificate.
4. Installs certificate automatically.

Common AutoSSL failures:

Mixed Content Errors

After installing SSL, the site loads over HTTPS but browser shows “Not Secure” or broken padlock.

Cause: The HTML page loaded over HTTPS contains resources (images, scripts, CSS) loaded over HTTP.

Diagnosis: Browser Developer Tools → Console → Look for “Mixed Content” warnings.

Fix:

• Update hardcoded http:// URLs in the CMS/database to https://.
• WordPress: Use “Really Simple SSL” plugin or run a search-replace on the database.
• General: Search the codebase for http://domain.com and replace with https://domain.com or //domain.com.

Certificate Chain Issues

Sometimes SSL is installed but browsers show “Your connection is not private” or “Certificate not trusted.”

Common causes:

• Missing intermediate certificate (CA bundle). The server must send the full chain.
• Certificate expired. Check expiry date.
• Certificate doesn't match domain. Cert was issued for www.example.com but visiting example.com.
• Self-signed certificate. Not trusted by any browser.

10. Billing Workflows & Suspension Logic

Billing Lifecycle

Invoice Generated (due date set, e.g., 14 days before service renewal)
        |
        ├── Auto-payment succeeds → PAID → Service continues
        |
        ├── Auto-payment fails → UNPAID
        |       |
        |       ├── Reminder emails sent (1st, 2nd, 3rd at intervals)
        |       |
        |       ├── Grace period (e.g., 3-7 days after due date)
        |       |
        |       ├── Service SUSPENDED
        |       |       Customer can still log in to billing panel
        |       |       Customer can still pay the invoice
        |       |
        |       ├── Overdue period (e.g., 14-30 days after suspension)
        |       |
        |       └── Service TERMINATED (data deleted)
        |               DATA LOSS IS PERMANENT
        |
        └── Customer pays manually → PAID → Service continues/unsuspended

Suspension Types and Their Causes

Key Billing Rules for L1

1. Never manually unsuspend an abuse-suspended account. Always escalate to the abuse team.
2. Verify payment before unsuspending. Check that the invoice is actually marked as PAID in the billing system, not just that the customer says they paid.
3. Payment received ≠ Payment cleared. Bank transfers, cheques, and some online payments may take time to clear. If the billing system shows “pending,” do not unsuspend.
4. Refund authority. L1 typically does not have authority to issue refunds. Escalate refund requests to billing team or L2.
5. Terminated accounts. Data deletion after termination is generally irreversible. If a customer contacts about a recently terminated account, escalate immediately — there may be a narrow window for recovery from server backups (not guaranteed).
6. Service downgrade timing. Downgrades take effect at the next billing cycle, not immediately. Upgrades are typically immediate.

Common Billing Scenarios

“I paid but my site is still down”

1. Verify invoice payment status in billing system.
2. If payment shows as “Pending” or “Processing,” explain the clearing time.
3. If payment is confirmed “Paid,” check if the unsuspension automation ran.
4. If automation didn't trigger, manually unsuspend (if billing suspension and within L1 authority).
5. Verify site is back up after unsuspension.

“I'm being charged for a service I cancelled”

1. Check if a cancellation request exists in the system.
2. Check if the cancellation was processed.
3. If no cancellation was submitted, walk them through the cancellation process.
4. If cancellation was submitted but not processed, escalate to billing team.
5. Never promise refunds without billing team approval.

“I want to transfer my domain but my account is suspended”

• A billing suspension does not necessarily prevent domain transfers, but the domain itself must be unlocked and active.
• If the domain is paid but hosting is unpaid, the domain can potentially still be transferred.
• If the domain itself is unpaid and expired, it's in the domain lifecycle stages — refer to Section 2.

11. Security Awareness for L1 Support

Identity Verification

Before making ANY account changes (password resets, contact info updates, domain unlocks, authorization code release), verify the customer's identity.

Minimum verification requirements:

• Registered email address on the account.
• Account holder's full name.
• Last 4 digits of the payment method on file (if applicable).
• Security PIN / secret question (if configured).

Never:

• Give auth codes, passwords, or account information via chat/phone without verification.
• Accept “I'm the owner” as sufficient verification.
• Share account information with someone who “says they are authorized” but isn't on the account.
• Send sensitive information to an email address not associated with the account.

Social Engineering Red Flags

Watch for these patterns:

• Urgency pressure: “I need this RIGHT NOW or I'll lose a deal.”
• Authority claims: “I'm the CEO's assistant, just give me the auth code.”
• Email mismatch: Customer contacts from a different email than what's on the account.
• Knowledge gaps: Customer doesn't know basic account details but insists they own it.
• Transfer requests for recently changed WHOIS: Could indicate a hijacked account.

When in doubt, escalate to L2 or the security team. It is always better to delay a legitimate customer's request than to facilitate an account theft.

Common Security Issues in Shared Hosting

Compromised Websites

• Signs: Defaced pages, unknown files in public_html, unexplained email sending (spam), redirects to malicious sites, Google Safe Browsing warnings.
• L1 Action: Do NOT attempt to clean the site. Document the symptoms and escalate to the security/malware team.
• Inform the customer: Change all passwords (cPanel, FTP, email, CMS admin, database). This is urgent.

Brute Force Attacks

• Signs: Customer locked out of cPanel/email, many failed login attempts in logs, IP blocked by firewall (CSF/LFD).
• L1 Action: If customer's IP is blocked, verify identity and escalate to L2 for IP whitelist. Never whitelist without proper verification.

Phishing Pages

• This is an abuse case. The customer's account may be compromised, or the customer may be the bad actor.
• L1 Action: Report to abuse team immediately. Do not inform the account holder before the abuse team reviews.

Password Reset Protocols

12. Escalation Framework

Escalation Boundaries — What L1 Can and Cannot Do

L1 CAN:

• Verify DNS records and advise on correct configuration.
• Reset cPanel, email, and FTP passwords (after identity verification).
• Check and communicate resource usage information.
• Guide customers through cPanel operations.
• Unsuspend billing-suspended accounts after confirming payment.
• Troubleshoot email client configuration (ports, SSL, credentials).
• Diagnose common HTTP errors using error logs and .htaccess.
• Guide SSL/AutoSSL troubleshooting for standard cases.
• Process standard domain operations (renewal, lock/unlock, WHOIS privacy).
• Release auth codes (after strict identity verification).
• Resend ICANN verification emails.
• Create, modify, and delete DNS records as directed by the customer.
• Restart PHP processes for a customer's account (if tooling allows).

L1 CANNOT (must escalate):

• Modify server-level configurations (Apache, PHP global, MySQL server, firewall rules).
• Access WHM for server-wide changes.
• Unsuspend abuse-suspended or fraud-suspended accounts.
• Issue refunds or account credits.
• Perform server migrations.
• Delist IP addresses from blacklists (RBLs).
• Modify ModSecurity rules.
• Restore backups from server-level backup systems.
• Access root or perform any operation requiring root privileges.
• Make changes to other customers' accounts.
• Investigate or clean compromised/hacked websites.
• Handle legal or compliance matters (DMCA, court orders, LEA requests).
• Override domain registry-level holds (serverHold, serverTransferProhibited).

Escalation Decision Framework

Can I resolve this with the tools and access I have?
├── YES → Resolve it
├── MAYBE →
│   ├── Try the standard diagnostic steps first
│   ├── Document what you've tried
│   └── If still unresolved → Escalate
└── NO →
    ├── Security issue?    → Escalate IMMEDIATELY
    ├── Server-level?      → Escalate to L2 Infrastructure
    ├── Abuse/legal?       → Escalate to Abuse/Compliance team
    ├── Billing dispute?   → Escalate to Billing team
    └── Beyond knowledge?  → Escalate to L2 with full documentation

How to Write an Effective Escalation

Every escalation must include:

1. Customer Information: Account username, domain(s) affected, contact email.
2. Problem Summary: One-sentence description of the issue.
3. Impact: What is broken? Completely down or partially affected?
4. Steps Already Taken: Every diagnostic step performed and its result.
5. Relevant Evidence: Error log entries, DNS lookup results, HTTP status codes, screenshots.
6. Your Assessment: What you think the problem is (even if unsure).

Example of a GOOD escalation:

Account: johndoe ([email protected])
Domain: example.com
Server: shared-web-14.hostingprovider.com

Issue: Customer's WordPress site returns 503 for all pages since
approximately 14:00 UTC today.

Steps Taken:
1. Verified domain resolves correctly to 198.51.100.14 (correct server IP). OK
2. Billing status: Active, no outstanding invoices. OK
3. Account not suspended. OK
4. Resource Usage: Entry Processes showing 47 faults in last hour.
   CPU at 98%.
5. Error log shows: "mod_lsapi: connect to lsphp timed out"
   repeated hundreds of times.
6. Customer confirmed no recent changes to site.
7. Checked access logs: Large volume of POST requests to /xmlrpc.php
   from multiple IPs starting ~14:00 UTC.

Assessment: Likely brute-force attack via WordPress XML-RPC endpoint
exhausting entry processes. Recommend blocking xmlrpc.php at server
level or via ModSecurity and clearing the LVE fault counter.

Example of a BAD escalation:
Customer says site is down. Please check.

Escalation Priority Levels

13. Diagnostic Checklists

Checklist A: Website Not Loading

Checklist B: Email Not Working

Checklist C: Domain Transfer Issues

Checklist D: SSL Certificate Issues

Appendices & Quick Reference

Appendix A: Port Numbers

Appendix B: File Permissions

Never set files to 777. This is a security vulnerability that allows any user on the server to read, write, and execute the file.

Appendix C: Common DNS TTL Values

Appendix D: Glossary

End of Document — Core Knowledge Base for Level 1 Customer Support v1.0