What DNS does
Grade school
DNS is like the internet’s address book. When someone types your website name, DNS tells their computer where to go. It also says where your email should be delivered.
High school
Your domain’s DNS is a list of records. A and CNAME records send website visitors to your host. MX records send your email to your mailbox provider. TXT records hold proofs and policies such as SPF and DMARC. Each record does one job, so you can change one without touching the others.
College
Records live in a zone served by your domain’s authoritative nameservers. A maps a name to an IPv4 address, AAAA to IPv6, CNAME aliases one name to another (not allowed at the root alongside other records), MX designates inbound mail servers, and TXT carries arbitrary text used by SPF, DKIM, DMARC and verification tokens. Changes spread according to each record’s TTL.
Postgraduate
DNS is a delegated, cached system: the registrar records which nameservers are authoritative, those nameservers answer for the zone, and resolvers cache answers for the TTL. Operational risk comes from editing the wrong zone, conflicting records at one name, or unplanned delegation changes that silently drop records the new provider didn’t copy.
Developer
Inspect with dig NS brand.example, then query each authoritative server directly: dig @[ns] A brand.example, dig @[ns] CNAME www.brand.example, dig @[ns] MX brand.example, dig @[ns] TXT _dmarc.brand.example. Lower TTLs ahead of a planned change; don’t change them during an incident.
Who controls your DNS
Grade school
The company you bought your website name from isn’t always the one that keeps its address book. Find out who does before changing anything.
High school
Your registrar is where you bought the domain. Your DNS host is where its records actually live — it might be the registrar, Cloudflare, Hostinger or someone else. Only changes at the DNS host have any effect. If you’d like YPB to make changes, invite YPB’s support user with the narrowest DNS-only role your provider offers, for just this domain.
College
Find the DNS host by looking up the domain’s current nameservers. Editing records at a registrar that isn’t authoritative does nothing. For delegated help, Cloudflare supports a member scoped to a single domain with the Domain DNS role; other providers have similar delegate features. The domain stays in your account.
Postgraduate
Delegation should be least-privilege and revocable: scoped to one zone, a DNS-edit role rather than account ownership, and an identity you can remove. A registrar delegation and a DNS-host delegation are separate grants; one doesn’t imply the other.
Pointing your website
Grade school
To show your store at your web address, you change the two notes that say where the website lives. You leave the email notes alone.
High school
YPB storefronts are hosted on Hostinger. The usual way is to keep your DNS where it is and update just the website records:
- Replace the A record for your root domain (
@) with the address YPB gives you. - Point www the way YPB tells you — an A record to the same address, or a CNAME.
- Remove any old A/AAAA records for those names that point elsewhere.
Your email records stay unchanged. Timing depends on the old records’ TTL: often a few hours, sometimes up to 48.
College
Hostinger supports connecting a domain either by nameservers or by pointing records. Pointing records keeps your existing DNS provider and leaves MX and other records untouched, which is why YPB prefers it. Delete stale AAAA records too: if an old IPv6 address remains, some visitors will still reach the old site.
Postgraduate
Record-level cutover minimizes blast radius: only the web identity moves, and rollback is restoring the previous A/CNAME values. Pair the DNS change with TLS readiness on the new host (see HTTPS) so visitors don’t see certificate errors during propagation.
Developer
Symbolic shape: @ A [PRD-web-IPv4], www A [PRD-web-IPv4] or www CNAME [PRD-target]; remove conflicting AAAA. Values are per site and supplied privately. Source: Hostinger: point a domain.
Records for each environment
Grade school
Your store has a real version and two practice versions. Each has its own address.
High school
Every YPB storefront has three environments: DEV for building, UAT for testing and approval, and PRD — the live store. Each one has its own web address, usually a subdomain for DEV and UAT, and its own records. See environments.
College
DEV and UAT use approved subdomains (for example dev.brand.example and uat.brand.example, or names YPB assigns) with their own A or CNAME records. PRD uses your root and www. Lower environments aren’t for customers: they’re private, not indexed by search engines, and don’t send real customer mail or take real payments.
Postgraduate
Separate names give each environment its own certificate, cookies and crawl policy. Don’t reuse production DNS targets for lower environments, and don’t invent names such as www.dev: use the subdomains agreed for your site.
Developer
Symbolic only: [dev-host] A [DEV-web-IPv4], [uat-host] A [UAT-web-IPv4], @/www → [PRD]. Real values are per tenant and never published.
Moving nameservers
Grade school
Moving your whole address book to a new company is a big job. Only do it with a plan, so your email doesn’t get lost.
High school
Changing your domain’s nameservers moves all your DNS to a new provider. Any record not copied across first — especially email records — stops working. YPB doesn’t do this by default. If it’s ever needed, it’s planned with you as a separate job.
College
A nameserver change is a zone migration: rebuild every record at the new host (web, MX, SPF, DKIM selectors, DMARC, verification tokens), compare old and new zones, then switch delegation at the registrar and watch propagation. Hostinger notes that with its nameservers you must re-add your MX records if your mail is elsewhere.
Postgraduate
Migrations fail through omission. Export the full zone, diff it against the new zone before changing delegation, and keep the old zone intact for rollback until caches have expired.
Developer
Export via provider API or AXFR where allowed; compare with dig @old vs dig @new for every name; lower NS-related TTLs in advance; verify DNSSEC (remove or re-sign) before switching NS.