Binding your own domain — a DNS walkthrough
This guide is the practical half of domain setup. The email coexistence guide explains how a website and a mailbox share one domain without breaking each other. Here we walk through the web side only: the records that make www.yourcompany.com resolve to your site, and how to confirm they’re right.
If you’ve never touched DNS, the short version is: your domain’s zone is a list of records published by a nameserver you control (usually at your registrar or DNS host). Pointing a domain at Nodipe means changing a small number of records in that zone — nothing about your registration, your email or your other services needs to move.
The records that matter for a website
Three record types do the work of “make this domain serve a site”:
- A record maps a hostname to an IPv4 address. Your apex (
yourcompany.com) andwwwusually need one each. - AAAA record is the IPv6 equivalent — many hosts publish both.
- CNAME record maps a hostname to another hostname instead of an address. It’s commonly used so
wwwfollows the apex (or vice-versa).
What you should not need to touch is anything mail-related: the MX records and SPF/DKIM TXT records stay with your email provider, exactly as covered in the email coexistence guide. The clean rule of thumb — move the web records, leave the mail records — keeps every risk on one side of the line.
Who sets the nameservers matters
Every domain has authoritative nameservers — the servers that answer “what are this domain’s records?” for the whole internet. Nodipe can bind your domain in one of two ways:
- Your DNS host stays authoritative. You already control a zone (often at your registrar or hosting panel) that can hold A/CNAME records. We give you the exact target values; you add or update them. Mail records stay exactly where they are. Least disruptive, and the path we recommend for most operators.
- Nodipe hosts the zone. If your current host can’t set custom records, the domain’s nameservers are pointed at Nodipe and we publish your site’s web records there. The one extra step is carrying your email provider’s MX/SPF/DKIM records across at their existing values so mail keeps resolving — that mirror is exactly what the email coexistence guide walks through. Your registrar stays yours; only the “who answers DNS questions” setting changes.
Whichever path, the outcome is identical: web records resolve to your site, mail records resolve to your email provider, and the two never collide.
What Nodipe provisions on the web side
Once the domain resolves to us, three things are handled automatically rather than left as homework:
- Edge CDN — the site is served from a global edge network, so a buyer in Frankfurt, São Paulo or Singapore pulls from a nearby point of presence instead of a single origin.
- Automatic HTTPS — a TLS certificate is issued for your domain and its
wwwform, and is renewed automatically. There is no certificate you buy, upload or chase when it expires. - Permanent URLs —
yourcompany.comandwww.yourcompany.comboth resolve, so a buyer who types either form reaches the same site over a valid certificate.
None of this changes who owns the domain. Registration stays in your name at your registrar; you can point the domain elsewhere at any time by changing records or nameservers back.
Verification checklist
After records are in place (allow up to a couple of hours for propagation), confirm the web side with four checks:
dig +short A yourcompany.com # → an edge address (IPv4)
dig +short AAAA yourcompany.com # → an edge address (IPv6)
dig +short CNAME www.yourcompany.com # → resolves to the same target as the apex
dig +short MX yourcompany.com # → still your mail provider's servers
Then in a browser: open https://www.yourcompany.com, confirm the padlock is valid (no certificate warning), and open the apex form too. If the site loads over HTTPS on both and mail still arrives, the handover is done.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
dig shows no A record for the apex | Your DNS host parks the apex and won’t let you set A records | Use path 2 above — move the zone to Nodipe, which can host the apex |
| Site returns a 522 or 523-style edge error | The web record points at a target that isn’t answering, or is mid-propagating | Confirm the target value matches what your onboarding notes said; wait, then retry; if it persists, send us the dig output |
| HTTPS warning in the browser | Certificate still provisioning, or you’re testing a record that points elsewhere | Wait a short while — certificates issue on first successful resolution; check you’re not on a cached redirect |
www loads but apex doesn’t (or vice-versa) | Only one form has a record | Ensure both the apex A/AAAA and the www CNAME resolve to the same target |
| Site works, but mail stopped after you changed records | The zone edit touched or omitted mail records | Re-add the exact MX/SPF/DKIM values from your provider — see the email coexistence guide troubleshooting table |
If a check above shows something unexpected and the fix isn’t obvious, write to us with the output of the dig commands. The four answers tell us in seconds whether the issue is your zone, our edge, or a record that points at neither.