DNS System

The DNS system (Domain Name System) is a hierarchical, distributed system that translates website names into IP addresses. Without it no website, email or domain-based service would work. This article explains what the DNS system is, how it works step by step, its server and query types, what DNS records look like, and how DNSSEC secures it. We write from the perspective of a company that administers servers and maintains client DNS zones every day.

What is the DNS system and what is it for?

The DNS system (Domain Name System) translates human-readable website names such as nodea.pl into IP addresses like 188.116.34.251 that computers actually use. It is a distributed naming system operating at the application layer of the TCP/IP model, communicating mainly over the UDP protocol on port 53.

The simplest analogy is a phone book: each name maps to a "number", which here is an IP address. You type a domain name, the DNS system finds the number assigned to it and routes the connection to the right place. Without this mechanism every user would have to memorise strings of digits instead of readable names, and every server change would mean broadcasting a new IP address to every visitor.

Global institutions keep the whole system consistent: IANA and ICANN oversee the name and address space, and in Poland the .pl domain is managed by NASK. Thanks to this hierarchy a single domain name is unique worldwide and always leads to the same resource.

How does the DNS system work?

How does the DNS system work? It translates a domain name into an IP address in a few steps: from your browser, through one of the 13 root servers, to the domain's authoritative server. The whole process takes fractions of a second and is invisible to the user.

Name resolution runs as follows:

1. The browser asks the local DNS server (your ISP's resolver) for the IP address of a domain, e.g. nodea.pl.
2. If the resolver does not know the answer, it asks one of the 13 root servers which servers handle the top-level domain — here .pl.
3. The root server points to the servers responsible for .pl, and those point to the domain's authoritative servers (for Nodea: ns1.nodea.net.pl and ns2.nodea.net.pl).
4. The authoritative server returns the correct IP address, and the browser opens a connection to the destination server.

Caching plays a key role here. Once a resolver learns an IP address, it stores it for the time set by the TTL value, so a repeat query for the same domain is instant and never touches the root servers. Alongside DNS, Windows systems also use local name-resolution mechanisms such as NetBIOS and LLMNR, which work only inside a single local network and have nothing to do with the global DNS hierarchy.

What types of DNS servers are there?

DNS servers split into root servers, authoritative servers and master and slave servers — worldwide there are 13 root server sets. Each type plays a different role in the domain name hierarchy.

• Root servers — 13 server sets labelled a through m (a.root-servers.net to m.root-servers.net), spread across the world in hundreds of copies via anycast. They indicate where to look for top-level domains such as .pl, .com or .net.
• Authoritative servers — store a specific domain's data and give binding answers from their own database. This is where your domain's actual DNS records live.
• Master and slave servers — the master holds the primary DNS zone configuration, and the slave pulls a copy after every change and acts as a backup server. This split provides redundancy.

Every domain should have at least 2 DNS servers. At Nodea these are ns1.nodea.net.pl and ns2.nodea.net.pl — pointing your domain's NS records at these servers is the condition for traffic to reach our hosting. It is also the first practical step when you want to point a domain to your hosting.

What types of DNS queries are there?

DNS queries split into recursive (the server must find the full answer) and iterative (the server only returns the best hint it knows). On top of that, answers are either authoritative or non-authoritative.

• Recursive query — forces the server to find the full answer (an IP address) or return an error. It is sent by the user's program, the resolver, which takes on the whole job of querying successive servers.
• Iterative query — the server returns the best answer it knows, i.e. the address of another server, and does not connect further itself. These queries travel between DNS servers during name resolution.

Answers also come in two kinds. An authoritative answer comes straight from the database of the server responsible for the domain. A non-authoritative answer comes from another server's cache and is valid only for the TTL duration — after it expires the server has to query again for current data.

DNS records

A DNS record is a single entry in a DNS zone that assigns a specific value to a name — most often an IP address, a mail server name or an alias. All of a domain's records live in its DNS zone and decide where web traffic and email go.

The most important record types and their uses:

• A — assigns an IPv4 address to a domain, e.g. 188.116.34.251. Directs web traffic to the right server.
• AAAA — assigns an IPv6 address, the newer addressing standard.
• CNAME — a domain alias, pointing one name to another (e.g. www to the root domain).
• MX — points to the mail server handling the domain's email and its priority.
• NS — points to the domain's authoritative (name) servers.
• SOA — the zone's start-of-authority record with parameters including the master server and timing values.
• TXT — arbitrary text, used among others by SPF, DKIM and DMARC records.
• SRV — points to the host and port of a specific service (e.g. a messenger).
• PTR — reverse mapping of an IP address to a name, important for verifying email senders.

In practice A, CNAME and MX records are edited most often — they decide where a site runs and where email is sent from. Together these records make up a domain's DNS zone.

SPF, DKIM and DMARC records — email security

SPF, DKIM and DMARC records are DNS zone entries that protect a domain from spoofing and decide whether your email lands in the inbox or in spam. All three are stored as TXT records in the domain's DNS zone.

SPF (Sender Policy Framework) defines which servers are allowed to send email on behalf of the domain. A sample SPF record for Nodea hosting looks like this:

v=spf1 a mx include:spf.nodea.net.pl ~all

The individual elements mean:

• v=spf1 — the SPF mechanism version.
• a — allows the server named in the domain's A record to send mail.
• mx — allows servers from the domain's MX records to send.
• include:spf.nodea.net.pl — adds Nodea's sending servers.
• ~all — the softfail qualifier: remaining mail is flagged as suspicious rather than rejected outright.

DKIM (DomainKeys Identified Mail) adds a digital signature to every message, which the recipient's server verifies with a public key published in DNS — confirming the content was not altered in transit. DMARC ties SPF and DKIM into a single policy: it tells recipient servers what to do with mail that fails verification (accept, mark as spam or reject) and lets you collect reports on spoofing attempts. Configuring these three records correctly is the foundation of business email deliverability.

What does DNS system security look like?

The DNS system is protected by the DNSSEC extension, which adds cryptographic signatures to the data — without it DNS is vulnerable to spoofing, cache poisoning and DDoS attacks. The vulnerability stems from DNS relying on the connectionless UDP protocol on port 53 and originally having no mechanism to authorise answers.

The main threats to the DNS system:

• DNS cache poisoning — injecting a false answer into a server's cache, which then directs users to a fake IP address for the TTL duration.
• DNS spoofing — impersonating a DNS server and returning forged answers that send the victim to the attacker's site.
• DNS amplification DDoS attacks — using open DNS servers to multiply the traffic aimed at an attack target.
• Man-in-the-middle attack — intercepting and swapping DNS queries between client and server.

DNSSEC (Domain Name System Security Extensions) is an extension that adds digital signatures and cryptographic validation to DNS data. With it, a resolver checks whether an answer truly comes from an authoritative server and was not swapped — which effectively protects against spoofing and cache poisoning. You can read more about the mechanism itself in the DNSSEC glossary entry.

What is a DNS zone and how does caching work?

A DNS zone is a file holding all the records of a domain and its subdomains — DNS servers keep its answers in cache for the time set by the TTL value. It is in the DNS zone that you manage A, MX, CNAME and TXT records, controlled by the master server.

A few concepts worth distinguishing:

• DNS zone — the set of records for one domain together with its subdomains, stored on the authoritative server. The master server manages the original, and the slave holds a copy.
• DNS cache — servers store learned answers for the TTL duration, so repeat queries for the same name are faster and do not load the authoritative servers.
• Subdomain — an extension of the root domain, e.g. blog.example.com, defined as separate records within the same DNS zone.

The TTL value is a trade-off between speed and freshness: a high TTL relieves servers but slows how fast changes spread; a low TTL speeds propagation but generates more queries. Before a planned domain migration you lower the TTL in advance. We cover managing records in more detail in our article on the DNS zone.

What to do when the DNS server is not responding?

'DNS server not responding' means your computer cannot reach the server that translates domain names into IP addresses — a router restart or switching the DNS server usually helps. This message appears when your ISP's resolver is overloaded, misconfigured or temporarily down.

The most common quick steps that restore the connection:

• Restart the router and network adapter — this clears most transient errors.
• Switch the DNS server to a public one, e.g. 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google).
• Flush the local DNS cache, on Windows with the command ipconfig /flushdns.

Full troubleshooting for different systems and routers is a separate topic — the steps above resolve most cases without deeper diagnostics.

Nodea is a company based in Leszno, Poland, optimising IT services for business: hosting, KVM VPS, dedicated servers, Linux and Windows administration and domain registration. We maintain client DNS zones and keep records, DNSSEC and email protections configured correctly so domains stay fast and secure.