AlexHost Nameservers: A Complete Technical Reference for DNS Configuration

Nameservers (NS records) are the authoritative DNS pointers that tell the global DNS infrastructure which servers hold the definitive zone file for your domain. Without correctly configured NS records, your domain cannot resolve — regardless of how well-configured your web server, mail system, or SSL certificates are.

This guide covers AlexHost's specific nameserver infrastructure, explains how NS records function at a protocol level, and provides actionable configuration guidance for both cPanel with LiteSpeed and standard shared hosting environments.

What Are Nameservers and Why They Are the Foundation of DNS

A nameserver is a specialized DNS server that stores and serves the authoritative DNS zone for one or more domains. When a recursive resolver needs to find the IP address behind example.com, it does not guess — it follows a strict delegation chain:

1. The resolver queries a root nameserver, which returns a referral to the appropriate TLD nameserver (e.g., .com, .net, .md).
2. The TLD nameserver returns the NS records registered at the domain registrar, pointing to the domain's authoritative nameservers.
3. The authoritative nameserver — the one you configure at your registrar — responds with the actual DNS records: A, AAAA, MX, CNAME, TXT, and so on.

This means NS records are not just a technical formality. They are the delegation mechanism that gives your hosting provider's DNS servers the authority to answer queries for your domain. If the NS records point to the wrong servers, or if those servers are unreachable, your domain goes dark — for every service that depends on it.

Every domain must have at least two NS records pointing to distinct, independently operated servers. This is not a recommendation; it is a requirement enforced by ICANN policy and the DNS protocol itself (RFC 1034/1035).

How the DNS Resolution Chain Works in Practice

Understanding the full resolution path helps you diagnose propagation delays and misconfiguration issues with precision.

When a visitor types your domain into a browser, the following sequence occurs:

• Local cache check: The operating system and browser check their local DNS cache. If a valid cached record exists (within its TTL), resolution stops here.
• Recursive resolver query: If no cache hit, the query goes to the ISP's or user's configured recursive resolver (e.g., 8.8.8.8, 1.1.1.1).
• Root server referral: The resolver contacts one of the 13 root server clusters, which returns the authoritative TLD nameserver address.
• TLD nameserver response: The TLD server (operated by Verisign for .com, for example) returns the NS records you registered at your domain registrar.
• Authoritative answer: The resolver queries AlexHost's nameservers directly, which return the A record, MX record, or whatever record was requested.
• Response delivered: The resolver caches the result for the duration of the record's TTL and returns the answer to the client.

The critical insight here is that NS records live in two places: at your domain registrar (as a delegation) and within the zone file on the authoritative nameserver itself. Both must be consistent. A mismatch between the two — known as a lame delegation — causes intermittent resolution failures that are notoriously difficult to diagnose.

AlexHost Nameserver Infrastructure

AlexHost operates separate nameserver pairs for different hosting environments. Using the correct pair for your specific hosting plan is essential for proper DNS resolution.

Nameservers for cPanel Hosting with LiteSpeed

These nameservers serve domains hosted on AlexHost's VPS with cPanel and LiteSpeed-powered infrastructure:

ns5.alexhost.md (176.123.0.83) acts as the primary DNS authority for domains on the LiteSpeed cPanel stack. All zone file changes — A records, MX records, subdomains — are authored here and synchronized to the secondary.

ns6.alexhost.md (176.123.0.84) serves as the secondary nameserver. In a properly configured BIND or PowerDNS setup, the secondary performs zone transfers (AXFR/IXFR) from the primary and can answer queries independently if the primary becomes temporarily unreachable.

Nameservers for cPanel Shared Hosting

Domains hosted on AlexHost's Shared Web Hosting platform use a dedicated nameserver pair:

ns3.alexhost.md (176.123.0.55) is the primary authoritative server for shared hosting zones. It holds the master zone files and is the source of truth for DNS propagation.

ns4.alexhost.md (176.123.0.60) provides geographic and operational redundancy. If ns3 is unreachable due to network issues or maintenance, ns4 continues to serve DNS responses without interruption.

Why Separate Nameserver Pairs Matter

Running distinct nameserver pairs per hosting environment is an architectural decision with real operational benefits:

• Blast radius isolation: A configuration error or DDoS attack targeting the shared hosting nameservers does not affect LiteSpeed VPS customers, and vice versa.
• Independent TTL and zone management: Each environment can tune propagation behavior independently.
• Capacity planning: Traffic growth on one platform does not degrade DNS response times on another.

Comparison: AlexHost Nameserver Environments

How to Point Your Domain to AlexHost Nameservers

Changing nameservers is done at your domain registrar — not at your hosting provider. This is a common source of confusion.

Step-by-Step Configuration

1. Log in to your domain registrar's control panel (e.g., GoDaddy, Namecheap, or wherever you registered the domain — or directly through AlexHost Domain Registration if registered with AlexHost).
2. Navigate to the DNS or Nameserver settings for the specific domain you want to configure.
3. Remove any existing nameserver entries. Default registrar nameservers (e.g., ns1.registrar.com) must be cleared before adding new ones.
4. Enter the AlexHost nameservers corresponding to your hosting plan:

• For LiteSpeed VPS: ns5.alexhost.md and ns6.alexhost.md
• For Shared Hosting: ns3.alexhost.md and ns4.alexhost.md

1. Save the changes. The registrar will update the delegation at the TLD level.
2. Wait for propagation. DNS propagation typically completes within 24 to 48 hours, though most resolvers pick up changes within 1 to 4 hours. TTL values on the old NS records determine how long caches hold stale data.

Verifying Nameserver Propagation

After making changes, verify propagation using command-line tools or online checkers:

Using dig (Linux/macOS):

dig NS yourdomain.com +short

Using nslookup (Windows/Linux):

nslookup -type=NS yourdomain.com 8.8.8.8

Using whois to check registrar delegation:

whois yourdomain.com | grep -i "name server"

If the output shows AlexHost's nameservers, delegation is complete. If you still see old nameservers, either propagation is still in progress or the registrar change was not saved correctly.

To test whether the authoritative nameserver itself is responding correctly:

dig A yourdomain.com @ns3.alexhost.md

This queries AlexHost's nameserver directly, bypassing any cached responses from recursive resolvers.

Critical Technical Pitfalls and Edge Cases

These are the failure modes that experienced administrators encounter — and that most documentation omits entirely.

Glue Records and the Circular Dependency Problem

If your domain name is the same as or a subdomain of the nameserver's domain, a circular dependency arises. For example, if you own alexhost.md and your nameservers are ns3.alexhost.md, a resolver cannot find the IP of ns3.alexhost.md without first resolving alexhost.md — which requires querying ns3.alexhost.md.

The solution is glue records: A records registered directly at the TLD registry alongside the NS delegation, providing the IP addresses of the nameservers without requiring a separate lookup. AlexHost handles this internally for its own nameserver domain. If you ever set up custom nameservers using your own domain (e.g., ns1.yourdomain.com), you must register glue records at your registrar.

Lame Delegations

A lame delegation occurs when the NS records at the registrar point to a nameserver that either does not exist, does not respond, or does not hold an authoritative zone for the domain. This causes resolution failures or severe latency as resolvers time out waiting for responses. Always verify that both NS records are reachable and authoritative before finalizing a migration.

TTL Strategy During Migrations

Before migrating a domain to AlexHost, lower the TTL on your existing DNS records to 300 seconds (5 minutes) at least 24 to 48 hours in advance. This minimizes the window during which resolvers serve stale data after you switch nameservers. After migration is confirmed stable, raise the TTL back to a standard value (3600 seconds or higher) to reduce query load on the nameservers.

NS Record Propagation vs. DNS Record Propagation

These are two distinct propagation events that are frequently conflated:

• NS record propagation: The time it takes for the TLD registry to publish your new nameserver delegation globally. This is controlled by the TLD's SOA TTL, typically 24–48 hours.
• DNS record propagation: The time it takes for individual A, MX, CNAME records within your zone to be picked up by recursive resolvers. This is controlled by the TTL you set on each record.

Changing nameservers triggers both events simultaneously, which is why full propagation can take up to 48 hours even when individual record TTLs are short.

Email Continuity During DNS Migration

If your domain has active Email Hosting or MX records pointing to a third-party mail provider, ensure those MX records are recreated in AlexHost's DNS zone before switching nameservers. Failing to do so results in mail delivery failures during the propagation window — a problem that is invisible until someone reports a bounced email.

DNS Records Managed Through AlexHost Nameservers

Once your domain delegates to AlexHost's nameservers, the following record types are managed within the cPanel DNS Zone Editor:

For domains requiring HTTPS, ensure an SSL Certificate is provisioned after DNS propagation completes — Let's Encrypt and other CA validation methods depend on correct DNS resolution.

Operational Best Practices for AlexHost DNS Configuration

• Always configure both NS records. A single nameserver is a single point of failure. Use both the primary and secondary for every domain.
• Monitor nameserver reachability. Use tools like dig, dnschecker.org, or automated uptime monitors to verify that both NS IP addresses (176.123.0.83/84 or 176.123.0.55/60) remain reachable. IP addresses associated with infrastructure can change during major migrations; always verify against current AlexHost documentation.
• Do not mix nameserver pairs. Do not combine ns3 (shared) with ns5 (LiteSpeed VPS) for a single domain. Each pair is designed to serve zones within its own hosting environment.
• Audit your zone file after migration. After switching nameservers, use dig ANY yourdomain.com @ns3.alexhost.md to retrieve all records and confirm that A, MX, TXT, and CNAME entries transferred correctly.
• Document your TTL changes. Keep a record of when you lowered TTLs and when you switched nameservers. This creates an audit trail that is invaluable during incident response.
• Use DNSSEC where supported. DNS Security Extensions add cryptographic signatures to DNS records, preventing cache poisoning attacks. Check whether your registrar and AlexHost's nameservers support DNSSEC for your TLD.

Decision Matrix: Which Nameservers to Use

Key Technical Takeaways

• Use ns3.alexhost.md / ns4.alexhost.md for shared hosting; use ns5.alexhost.md / ns6.alexhost.md for LiteSpeed VPS environments.
• Always configure both nameservers in every domain registration — never rely on a single NS record.
• Lower record TTLs to 300 seconds at least 24 hours before any planned nameserver migration.
• Verify propagation using dig NS yourdomain.com +short and direct queries to AlexHost's nameserver IPs.
• Recreate all MX and TXT records (SPF, DKIM, DMARC) in the new zone before switching nameservers to avoid mail delivery interruptions.
• Check for glue record requirements if you are configuring custom nameserver hostnames under your own domain.
• After DNS propagation, provision or revalidate SSL certificates — domain validation depends on correct DNS resolution.
• Monitor both nameserver IPs periodically; infrastructure changes can alter IP assignments.

Frequently Asked Questions

What is the difference between ns3/ns4 and ns5/ns6 on AlexHost?

ns3.alexhost.md and ns4.alexhost.md serve domains on AlexHost's shared hosting platform. ns5.alexhost.md and ns6.alexhost.md are dedicated to the LiteSpeed-powered cPanel VPS environment. Using the wrong pair will result in DNS resolution failures because the zone files for your domain reside only on the correct nameserver pair.

How long does it take for AlexHost nameserver changes to propagate?

Full global propagation typically takes between 24 and 48 hours, though most recursive resolvers pick up the change within 1 to 4 hours. The actual duration depends on the TTL set on your previous NS records and the caching behavior of individual resolvers worldwide.

Can I use only one of AlexHost's nameservers instead of both?

No. Using a single nameserver creates a single point of failure. If that server is unreachable for any reason — maintenance, network partition, or hardware failure — your domain becomes unresolvable. ICANN policy and DNS protocol standards require a minimum of two nameservers per domain.

What happens to my email if I switch nameservers without recreating MX records?

Incoming mail delivery will fail for any domain whose MX records are not present in the new zone. Senders will receive bounce messages or experience deferred delivery. Always audit and recreate MX, SPF, DKIM, and DMARC records in AlexHost's DNS zone editor before completing the nameserver switch.

How do I verify that AlexHost's nameservers are correctly authoritative for my domain?

Run dig NS yourdomain.com +short to confirm the registered delegation, then run dig A yourdomain.com @ns3.alexhost.md (or the appropriate nameserver) to confirm the authoritative server is responding with the correct records. If both commands return expected results, your DNS configuration is functioning correctly.