---
title: DNS (Domain Name System)
description: The system that turns domain names into IP addresses. In hosting, DNS points your domain at the right server — separate from the site files themselves.
canonical: https://penasihathosting.com/en/hosting-wiki/dns-domain-name-system
type: wiki
locale: en
updated: 2026-07-15
author: Willya Randika
---

# DNS (Domain Name System)

## Overview

- **Summary:** The system that turns domain names into IP addresses. In hosting, DNS points your domain at the right server — separate from the site files themselves.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

**DNS** (Domain Name System) translates human-friendly domain names — like `example.com` — into [IP addresses](/en/hosting-wiki/ip-address) machines use on the internet. Without DNS, you would type raw server numbers every time you open a site.

In hosting, DNS decides **which server** your domain points to. Your site files still live on the host; DNS is only the map.

## A Simple Analogy

DNS is like a phone book. You look up a name (“Budi’s Shop”) and get a number to dial (the IP address). Change the number in the book, and calls go somewhere new — the shop inventory does not move unless you also move the goods (the files on the hosting account).

## How It Works (Short Version)

When someone types your domain:

1. The browser asks DNS: “What IP belongs to this name?”  
2. The answer comes from the domain’s authoritative **nameservers** (often after checking a cache first)  
3. The browser connects to that IP on your hosting server  
4. Only then does the server send HTML, images, and other assets  

This usually takes a fraction of a second. “DNS errors” are more often bad records, nameservers not updated, or ongoing [propagation](/en/hosting-wiki/domain-propagation).

## Records You Will Touch Most

| Record | Practical job |
| --- | --- |
| **A** | Domain → IPv4 server address |
| **AAAA** | Domain → IPv6 address (when used) |
| **CNAME** | Alias: one name points at another name |
| **MX** | Where domain email should be delivered |
| **TXT** | Verification text (Google, SPF, DKIM, and similar) |
| **NS** | Which nameservers are authoritative for the domain |

A typical site needs a correct A record (or the CNAME pattern your host documents) plus MX/TXT if you use domain email. Email authentication almost always lives in TXT records and ties into [SMTP](/en/hosting-wiki/smtp) deliverability.

## DNS Is Not Hosting

Easy to mix up:

- **Hosting** stores and runs the site files  
- **DNS** points the domain name at the right server or service  
- You can buy a domain at A, run DNS at B (for example Cloudflare), and host files at C — as long as the records stay consistent  

Wrong DNS means the site is “not found” even when files are fine. Hosting downtime can happen with perfect DNS if the server itself is offline.

## Nameservers vs Records in the Panel

Two layers people confuse:

1. **Domain nameservers** (at the registrar) — who controls the DNS zone  
2. **Records in that zone** (A, MX, …) — the actual directions  

If nameservers still point at an old provider while you edit A records on a new host panel, the public internet will ignore those edits. Align “who owns DNS” first, then change records.

## What to Watch For

- **TTL** — higher cache times make changes feel slower to spread  
- **Do not casually edit MX** during a web-only migration — mail can break while the site already works  
- **CDN / proxy** setups often show a proxy IP to visitors, not the raw origin IP  
- **Subdomains need their own records** — `www`, `mail`, and `staging` do not inherit automatically from the root alone  
- DNS affects the initial lookup; it is **not** a substitute for app performance work or a [CDN](/en/hosting-wiki/cdn) for static assets  

<Callout type="info">
  After changing nameservers or A records, wait for propagation and test from more than one network. Deeper detail: [Domain Propagation](/en/hosting-wiki/domain-propagation). To inspect records, use the [DNS Lookup](/en/tools/dns-lookup) tool.
</Callout>

## FAQ

<Accordion>
  <AccordionItem title="Why is my site unreachable after I moved hosts?">
    DNS often still points at the old server, nameservers were not updated, or propagation is incomplete. Confirm A/AAAA (or the host’s CNAME instructions), then check propagation before blaming the new hosting stack.
  </AccordionItem>
  <AccordionItem title="Does DNS make a site faster?">
    A healthy DNS lookup is only a small slice of total load time. Server work, page weight, database queries, and CDN delivery usually matter more. Broken DNS, though, can make the site unreachable entirely.
  </AccordionItem>
  <AccordionItem title="Where do I edit DNS?">
    At whoever holds the domain’s nameservers: registrar, hosting DNS, or a dedicated DNS host. Edits in a non-authoritative panel will not change what the internet sees.
  </AccordionItem>
  <AccordionItem title="How long do DNS changes take?">
    Anywhere from minutes to roughly 24–48 hours, depending on TTL and resolver caches. See [domain propagation](/en/hosting-wiki/domain-propagation) for the full picture.
  </AccordionItem>
  <AccordionItem title="Does email depend on DNS too?">
    Yes. MX records (and usually TXT for SPF/DKIM) control delivery and authentication. A website migration should leave mail records intentional — not accidental collateral damage.
  </AccordionItem>
</Accordion>