Article 10
From a domain name to a server: how DNS, name servers and records work
Follow siscorp.co.th from the browser to an IP address and server, with plain-language explanations of DNS records, caching, HTTPS and domain security.
What happens in seconds
Start with the people using the system
A website name is not the server address; DNS translates it
People remember siscorp.co.th more easily than an IP address, but the browser needs a destination. DNS acts as a distributed directory, often answering through several caches. The browser then connects, validates HTTPS and sends the host name before receiving the page. Each layer has a distinct responsibility, and a bad change can disrupt the website, email or the whole domain.
Terms before you begin
Technical language, explained by what each part does
You do not need to memorize every term. Use this section as a map while reading the detailed explanation.
- Domain Name
- A registered, renewable name such as siscorp.co.th that identifies online services.
- Registrar
- The company managing domain registration, ownership, renewal and name-server delegation.
- DNS Resolver
- A service that receives the device's query and resolves it through cache or authoritative DNS.
- Authoritative DNS
- The DNS service holding the source records for a zone and authorized to answer for it.
- Name Server (NS)
- The servers delegated as authoritative for a domain, normally listed redundantly.
- Record
- A DNS entry describing where a name or service points.
- TTL
- The number of seconds a resolver may cache an answer before asking again.
- TLS / HTTPS
- Encryption plus certificate validation that binds the connection to the requested domain.
Summary for business and everyday users
From a domain name to a server: how DNS, name servers and records work
A registrar controls domain ownership; DNS hosting stores records and answers where names point.
Name servers identify the authoritative DNS service, not the website IP itself.
MX routes email; A, AAAA and CNAME resolve names; TXT publishes verification and policy data.
Protect domains with MFA, registrar lock, restricted access, appropriate DNSSEC and change records.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 06
01 / Ownership
Ownership begins at the registrar, then DNS is delegated to name servers
Registering siscorp.co.th grants renewable rights to a name, not a server. The registrar account is highly privileged because changing name servers can redirect all web and email traffic. The registrar delegates to a name-server set; records must be edited in that authoritative DNS service.
Evidence to inspect
- Enable registrar MFA
- Use a company-owned account
- Enable transfer lock
- Monitor expiry and auto-renew
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Ownership
01Ownership begins at the registrar, then DNS is delegated to name servers
Registering siscorp.co.th grants renewable rights to a name, not a server. The registrar account is highly privileged because changing name servers can redirect all web and email traffic. The registrar delegates to a name-server set; records must be edited in that authoritative DNS service.
- Enable registrar MFA
- Use a company-owned account
- Enable transfer lock
- Monitor expiry and auto-renew
- Record current name servers
02 / Resolution path
02The browser does not ask the web server first; it resolves the destination
The browser checks local caches, then asks a recursive resolver. If uncached, the resolver follows referrals from root to the relevant top-level and authoritative name servers. The answer is cached for its TTL, so users may temporarily receive different answers during a migration.
Simplified path
Opening siscorp.co.th
Browser → Recursive Resolver → Root/TLD → Authoritative DNS → A/AAAA/Alias → IP → TLS → Web Server
03 / Read records
03Each record answers a different question, and MX does not open a website
A maps to IPv4, AAAA to IPv6, and CNAME aliases another host name. Cloud DNS may provide alias-style records for changing endpoints. MX identifies mail receivers by priority. TXT carries verification and email policies such as SPF, DKIM and DMARC. CAA limits certificate authorities. Edit records by purpose and never delete an unfamiliar record without tracing ownership.
A CNAME normally cannot coexist with other data at the same owner name or be used at the zone apex; cloud alias/flattening records are provider-specific solutions.
04 / Email DNS
04MX routes mail; SPF, DKIM and DMARC establish sending trust
A sender looks up the domain's MX records and connects by priority. SPF lists permitted senders, DKIM signs messages for integrity, and DMARC defines handling and reporting when alignment fails. Incorrect configuration can send legitimate mail to spam or make impersonation easier.
05 / Change safely
05DNS propagation is usually old cache expiring, not a file slowly travelling
Before migration, lower TTL at least one old-TTL period in advance, validate the new destination and HTTPS, then change records while keeping the old service available. Observe users and logs before restoring TTL. Permanently low TTL does not speed the site and cannot force every non-compliant cache to refresh.
06 / Protect the name
06The domain anchors trust for the website, email and certificates
A compromised registrar or DNS account can redirect the website, change mail routing and undermine certificate trust. Use strong MFA, least privilege, approvals, audit logs and protected recovery access. DNSSEC signs DNS data against forged responses, but requires disciplined key rotation and migration because a broken trust chain can make the domain unresolvable.
Checklist before action
Identify registrar and account owner
Enable MFA and registrar lock
Record authoritative name servers
Inventory records with owners
Separate web, mail and verification records
Validate SPF, DKIM and DMARC
Plan TTL before migration
Test through multiple resolvers
Verify TLS after changes
Keep audit and recovery procedures
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Infrastructure & Security
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.