The labs on this site need JavaScript to run. The same content is written out below.

Fundamentals › Networking

DNS

What does DNS turn a name into?

Computers connect to each other by IP address (a number), but people use names like shop.example. DNS is the service that turns a name into an IP address, and a DNS server is a computer that holds a table listing each name with its IP address. The code box on the screen has two parts. The upper part is what is registered on the DNS server (name → IP address), and the lower part is the address the client tries to reach. A client that connects by name first asks the DNS server for the IP address of that name, before it connects to the server, and then connects to the IP address it got in the answer. In this lab you leave the name unregistered, register it with a different IP address, or write an IP address directly in the address instead of a name, and make the same connection each time, to see how many times the DNS server is asked and which computer is reached. The 8080 on the screen is a port number written as an example.

Checked against real execution · Ran all 6 combinations on Node.js 24.18.0 with a small DNS server (RFC 1035 messages) started inside 127.0.0.x, a dns.Resolver client, and two HTTP servers, and checked against the results

Concepts in this lab

DNS

The system that translates a domain name (example.com) into the IP address that computers use to communicate. When you enter an address in a browser, the browser first asks this system for the IP address of that name and then connects to that IP address. Lookup results are cached for a certain time.

Domain names

A domain name is a name written as text separated by dots, like shop.example, that points to a computer and is easy for people to read and remember. Computers connect to each other by IP address, not by name, so to connect by name, DNS must first turn the name into an IP address. The pairs of names and IP addresses are held by the DNS server, and if you pair a name with a different IP address, the same name points to a different computer. A name that ends in .example is reserved for documents and examples, so it is not actually registered (RFC 6761 section 6.5).

IP address (IPv4)

This is a 32-bit numeric address used to find a device on the internet. To make it easy for people to read, it is cut into 8-bit groups and written as four decimal numbers from 0 to 255, such as 192.168.0.10. The front part of the address shows which network the device is on, and the back part shows which device it is within that network. Where the front part ends cannot be known from the address alone; it is decided only together with a subnet mask.

NXDOMAIN response

An NXDOMAIN response is the answer a DNS server gives to say that the name it was asked about does not exist. It is a response whose RCODE field in the message header is 3 (Name Error), and RFC 1035 says that this value has a meaning only in responses from an authoritative name server (section 4.1.1). It is commonly called NXDOMAIN. When a client gets this answer, it has not obtained an IP address, so it cannot start a connection to the server. It appears when a name is not registered or a name has a typo, and it has nothing to do with whether a server for that name is running.

Try these

• Default settings — The name is registered. The client first asks the DNS server, and then connects to the IP address it got.
• Leaving the name unregistered — The DNS server answers that there is no such name, so the client does not get an IP address. Even if the server is running, the client cannot start a connection.
• Registering a different IP address — The client connects with the same name, but the DNS answer is different, so it reaches a different computer.
• Writing the IP address directly — It is not a name, so the client does not ask the DNS server and connects straight to that IP address.

Running with the default settings

1. The client (a program, like a browser, that connects to a server) looks at the host part of the address it wants to reach, http://shop.example:8080/. The host is the part of the address that says which computer to connect to, and here it is shop.example. This is a name, not an IP address. Computers connect to each other by IP address, so before it connects, the client has to find out the IP address of this name.
2. The client asks the DNS server, "What is the IP address of shop.example?" The DNS server is a computer that holds a table listing each name with its IP address (the "Registered" part at the top of the screen) and turns a name into an IP address. This question goes out before the client connects to the server.
3. The DNS server finds shop.example in its table and answers. The IP address of shop.example is 127.0.0.1. Now the client knows where to connect.
4. The client connects to port 8080 of the IP address it got in the answer, 127.0.0.1, and sends a GET / request. 8080 is the port number, the number of the door that a server program waits at inside that computer. The name shop.example written in the address is not used for the connection. The place it connects to is the IP address that DNS gave.
5. The server that was running on the computer at IP address 127.0.0.1 receives the request and sends back a 200 response. The body is "This is the first computer". The DNS server did not take part in this connection.
6. The client receives the 200 response. The body is "This is the first computer".

Result of this run

• DNS is the service that turns a name into an IP address. A client that connects by name first asks the DNS server for the IP address of shop.example before it connects, and it connected to 127.0.0.1, the IP address it got in the answer.
• What connects to a server is an IP address, not a name. A name is for people to use, and just before the connection it is turned into an IP address through DNS.

Code

# Registered on the DNS server (name → IP address)
shop.example    127.0.0.1

# The address the client tries to reach
http://shop.example:8080/

Assumptions of this model

All 6 combinations were checked against real execution, entirely within the 127.0.0.x addresses of the PC used to write this lab. No outside network and no actual DNS settings of this PC were asked. The DNS server is a small server started with dgram in Node.js 24.18.0 on a free UDP port of 127.0.0.1. Its messages were built by hand in the format of RFC 1035 section 4.1 (a 12-byte header, a question, and an answer). It answers an A query for a name in its registration table with that IP address, and it answers a name that is not in the table with RCODE 3 (Name Error, section 4.1.1). The client reads the two parts of the code box as written. If the host of the address is not an IP address according to net.isIP, it asks with resolve4 of a dns.Resolver whose only server is set to the server above with setServers, and it sends an HTTP request to the IP address it received. If the host is an IP address, it sends the request directly without calling the Resolver. The flow shown on the screen, "ask first if it is a name, and do not ask if it is an IP address", was made the same as the flow of this probe. The name resolution order of the operating system, the hosts file, the caches of browsers and operating systems, and recursive resolvers were not covered, and it was not checked whether a real browser works in the same order as this probe. Those details are covered in the in-depth lab "DNS". As servers, two HTTP servers were started on 127.0.0.1 and 127.0.0.2 with the same port number. The 8080 on the screen is an example number and a free port was actually used, and 127.0.0.2 imitates a "different computer" but is actually a different loopback address of the same PC. On the PC used to write this lab (Windows), the server bound to 127.0.0.2 right away. What was checked against is the number and kind of queries the DNS server received, the RCODE of the no-such-name answer, the answer the client received, the destination IP address of the connections the servers received, the status and body of the response, the order in which the query comes before the connection in the combinations with a name, and the fact that neither server received a connection or a request when the answer was no such name. "Times the DNS server was asked" is the number of A queries the DNS server received. This Resolver sent no queries of a kind other than A, and it did not ask again after receiving the no-such-name answer, so the number of queries and the number of A queries were the same. This is what was observed with the default settings of this Node.js version. That Node.js reports the no-such-name answer as an ENOTFOUND error is also observed behavior. The DNS server is not an independent implementation but one made for this lab, and what read its answers is dns.Resolver (c-ares) of Node.js, so it is checked against the outside only in the sense that the DNS messages were read by an independent implementation, and it was not checked against a DNS server that is actually in operation. What was checked against the documentation is RFC 1034 section 5.2.1 (a request to turn a host name into a host address becomes a request for an A record, and a name error is returned if the name does not exist), section 3.6 (resource records), section 4.3.1 (the response saying that the name does not exist), RFC 1035 section 3.4.1 (an A record is a 32-bit internet address), sections 4.1 and 4.1.1 (message format, RCODE 3 Name Error), and RFC 6761 section 6.5 (names ending in .example are reserved for documentation and are not registered). Registering several IP addresses for one name and using AAAA records were not covered, and the server code on the screen is not shown.

Previous lab: URLs · Next lab: HTTP requests