Point Your Domain to Getwebup: Nameservers vs A Record

You bought a domain from one company and hosting from another, and now you just want the website to load. Two roads get you there - nameservers or an A record - and picking the wrong one, or mixing both by accident, is the number one reason a "simple" domain setup turns into two days of a broken site.

The short answer

If you want us to manage all your DNS (mail records, subdomains, SSL, the works) from cPanel, change your nameservers at your domain registrar. If you only want the domain to point somewhere while everything else (email, other subdomains) stays managed at the registrar or another DNS provider, add an A record instead and leave nameservers alone. You almost never need to do both.

What each option actually changes

Nameservers

Nameservers tell the internet which company's DNS servers are authoritative for your domain. When you point your domain's nameservers to Getwebup, you're handing over the entire DNS zone - A records, MX records, CNAME records, TXT records, all of it - to be managed inside your cPanel > Zone Editor.

ns1.getwebup.in
ns2.getwebup.in

You set these two values at your registrar (GoDaddy, Namecheap, BigRock, wherever you bought the domain), not at your host. It's a one-time change per domain.

A Record

An A record is a single DNS entry that says "this hostname maps to this IPv4 address." It doesn't touch anything else in your zone. You'd add something like:

Type: A
Host: @
Value: 203.0.113.45  (your server's IP)
TTL: 3600

Do this at whichever DNS provider currently controls your domain - that could be your registrar's default DNS, Cloudflare, or a previous host. Everything else in that zone (MX records for email, other subdomains) is untouched.

How to choose

Symptom → Cause → Fix

Symptom: Site loads sometimes, email stops working after changing nameservers

Cause: Changing nameservers moves your entire DNS zone. If your old zone had MX records for Google Workspace and you didn't recreate them in the new zone, mail routing breaks the moment the change propagates.

Fix: Before switching nameservers, export or screenshot every existing DNS record - MX, TXT (SPF/DKIM), CNAME. Once nameservers point to Getwebup, go to cPanel > Zone Editor and re-add those same MX and TXT records so mail keeps flowing.

Symptom: Added an A record, but the site still shows the old host

Cause: Either the A record was added on the wrong DNS provider (the domain's nameservers still point elsewhere), or you're hitting a cached DNS result.

Fix: Run dig NS yourdomain.com or check on whatsmydns.net to confirm which provider is actually authoritative. Edit the A record there, not at the registrar's "DNS" tab if that's not the active nameserver set. Then flush local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on Mac) and test again.

Symptom: "www" version of the site doesn't load, only the bare domain does

Cause: Only an A record for @ (root) was added; there's no CNAME or A record for www.

Fix: Add a second record - either a CNAME www → yourdomain.com, or a duplicate A record for host www pointing at the same server IP.

Step-by-step: switching nameservers to Getwebup

1. Log in to cPanel and note your account's assigned nameservers (Server Information widget, or ask support).
2. Log in to your domain registrar and find the nameserver / DNS management section.
3. Back up any existing MX, TXT, and CNAME records if email or subdomains currently work elsewhere.
4. Replace the existing nameservers with ns1.getwebup.in and ns2.getwebup.in.
5. Save, then wait for propagation (usually 1-4 hours, up to 24-48 in rare cases).
6. Once propagated, go to cPanel > Zone Editor and re-add any email or subdomain records you backed up.

Step-by-step: pointing an A record instead

1. Get your server's IP address from your Getwebup welcome email or cPanel > Server Information.
2. Log in to wherever your domain's DNS is currently managed.
3. Add or edit the A record for @ (root domain) to point to that IP.
4. Add a matching A record or CNAME for www.
5. Leave MX, TXT, and other records exactly as they are.
6. Wait for the TTL to expire (usually under an hour if TTL is set to 3600 or less).

Prevention

• Never change nameservers and add conflicting A records for the same host at the same time - pick one method.
• Lower your TTL to 300-600 seconds a day before a planned migration, so any mistake resolves quickly instead of sitting cached for 24 hours.
• Always keep a written copy of your DNS zone before touching nameservers. It takes two minutes and saves hours of guessing what the old MX records were.
• If email matters to your business, test mail flow immediately after any DNS change - don't wait for a customer to tell you their message bounced.