Stateful/stateless and DNS working

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 opens 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.

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)

 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.