---
title: "Stateful/stateless and DNS working"
subject: "Distributed System"
chapter: 2
key: "semester_7/distributed_system:stateful-dns-example"
source: https://www.bctengineer.com/q/semester_7/distributed_system/stateful-dns-example
site: BCT Engineering
---

# Stateful/stateless and DNS working

Distributed System · Chapter 2: Distributed Objects and File System

- Asked in: 2074 Asoj, 3+5 marks
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/stateful-dns-example
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-2

## Question

What is stateful and stateless service in file system? Explain the DNS working mechanism with suitable practical example.

## Short answer

Stateful services maintain client session state like open files; stateless services require each request to carry full context. DNS works by recursive queries from a client to a local resolver, which iteratively queries root, TLD, and authoritative servers; e.g., resolving www.tu.edu.np follows referrals to .np, edu.np, tu.edu.np, returning the IP and caching it.

## Answer

#### Stateful and stateless service in a file system
- A **stateful service** keeps information (state) about the clients' sessions at the server, for example the table of open files and the current file pointer. A client first `open`s a file, receives a connection identifier, then sends short `read(id, n)` requests.
- A **stateless service** keeps no client information. Every request contains complete information (file handle, offset, count), so the server can handle each request independently. NFS is stateless.

| Point | Stateful service | Stateless service |
|---|---|---|
| Server memory | Keeps information about each client (open files, file pointers) | Keeps no client information |
| Request | Short; refers to a session or open file id | Longer; each carries file id, offset, count |
| Crash recovery | Complex; server must rebuild or clients must re-establish state | Simple; just restart |
| Client crash | Server must detect and clean orphaned state | No effect |
| Operations | Need not be idempotent | Must be idempotent (repeatable) |
| Performance | Fewer disk accesses, read-ahead is easier | More overhead per request |
| Locking | Easy to support | Needs a separate lock service |
| Example | AFS (callbacks), RFS | NFS (v2, v3) |

#### DNS working mechanism with example
The **Domain Name System (DNS)** is a distributed, hierarchical naming service of the Internet that maps human friendly domain names (www.tu.edu.np) to IP addresses and other attributes (mail servers, aliases).

**Why naming is needed:** names are easy to remember, are independent of the physical address, allow a resource to move without users noticing (location transparency), and let resources be shared and found by many users.

**Distributed and hierarchical:** the name space is a tree. The root has top-level domains (com, org, edu, np), below them are second-level domains (edu.np), then organisations (tu.edu.np) and hosts. No single server holds the whole database. The tree is split into **zones**, each managed by one organisation with its own authoritative servers. Delegation passes authority downwards, and replication of each zone (primary and secondary servers) gives fault tolerance. This is why DNS is a distributed hierarchical database.

**Name servers**

- **Root servers:** know the addresses of the top-level domain servers.
- **TLD servers:** know the authoritative servers of each second-level domain.
- **Authoritative servers:** hold the actual records of a zone (A, AAAA, MX, NS, CNAME, PTR).
- **Local (resolver) server:** run by the ISP or organisation, accepts the client's request and does the lookup, with a cache.

**Working mechanism (name resolution)**

```text
 Client -> Local DNS -> Root -> .np TLD -> edu.np -> tu.edu.np
   ^          |  <----- referrals / answers ------|
   +----------+  answer IP, cached with TTL
```

1. The application calls the resolver to find www.tu.edu.np.
2. The resolver checks its cache; if present it returns the answer.
3. Otherwise it asks the local DNS server (recursive query).
4. The local server asks a root server, which refers it to the .np server.
5. The .np server refers it to the edu.np server, which refers it to the tu.edu.np authoritative server.
6. The authoritative server returns the A record (IP address).
7. The local server caches the reply for the **TTL** and returns it to the client, which connects to the IP.

**Resolution methods:** *iterative* (the server returns the next server to ask, the resolver continues) and *recursive* (the server does the whole lookup for the client). *Multicast* and *non-recursive server-controlled navigation* are other variants.

**Features:** hierarchical naming, distribution of administration, replication, caching with TTL, scalability, and support for many record types.

**Practical example:** a student on a home network types `www.ioe.edu.np`.
1. The browser asks the OS resolver, which looks in its cache. Not found.
2. It sends a recursive query to the ISP's local DNS server (e.g. WorldLink's).
3. The local server asks a root server, gets a referral to the `.np` server (NPIX/Mercantile).
4. The `.np` server refers to the `edu.np` server, which refers to the authoritative server for `ioe.edu.np`.
5. The authoritative server returns the A record, e.g. 202.xx.xx.xx.
6. The local server caches it for the TTL and answers the browser, which opens the HTTP connection. A second user asking within the TTL gets the answer from the cache.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What is the key difference between stateful and stateless file services?
   A. A stateful server keeps per-client information (open files, file pointers); a stateless one keeps none
   B. A stateless server keeps a table of open files; a stateful one does not
   C. A stateful server needs longer requests than a stateless one
   D. Both keep state but only stateless saves it on disk
   Answer: A. Stateless servers hold no client information, so every request must be self-contained. (Key point: Server memory)

2. Which pairing is correct?
   A. Stateless: short requests using a session id, as in AFS
   B. Stateful: long requests carrying file id, offset and count, as in NFS
   C. Stateless: longer requests carrying file id, offset and count, as in NFS (v2, v3)
   D. Stateful: no need to track clients, as in NFS
   Answer: C. A stateless request must say which file, where and how much; NFS is the standard stateless example. (Key point: Request size and example)

3. In the www.ioe.edu.np example, what happens before the local DNS server asks a root server?
   A. The OS resolver cache is checked and, if empty, a recursive query goes to the ISP's local DNS server
   B. The authoritative server is contacted directly
   C. The .np server is asked first
   D. The browser queries the root server itself
   Answer: A. The client side only asks the local server; the local server does the iterative walk. (Key point: DNS resolution order)

4. What benefit does the TTL cache give in the example?
   A. The authoritative server is asked again every time
   B. A second user asking within the TTL gets the answer from the cache
   C. The record never expires
   D. The root server answers all repeats
   Answer: B. The local server caches replies for the TTL. (Key point: TTL benefit)

## Related in Distributed System

- [DNS and its working mechanism](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adns-working) — Distributed System, chapter 2, asked 3×
- [DFS; stateless vs stateful services](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adfs-stateless-stateful) — Distributed System, chapter 2
- [Stateful vs stateless; NFS architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anfs-stateful-stateless) — Distributed System, chapter 2
- [DFS requirements and file service architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adfs-requirements-architecture) — Distributed System, chapter 2

## Related in other subjects

- [Types of doors by working mechanism](https://www.bctengineer.com/question.md?key=semester_6%2Fbuilding_technology%3Adoor-types-working) — Building Technology, chapter 6, asked 2×
- [Working mechanism of WDM](https://www.bctengineer.com/question.md?key=semester_5%2Fdata_communication%3Awdm-working) — Data Communication, chapter 6
- [Google File System architecture](https://www.bctengineer.com/question.md?key=semester_8%2Fbig_data_technologies%3Agfs-architecture) — Big Data Technologies, chapter 2, asked 2×
- [File system layout, i-node, backup](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Afs-layout-inode-backup) — Operating System, chapter 5
