What an IP address is
An IP address is a number that identifies a device on a network so data can be sent to the right place. It works much like a postal address: without one, packets would have nowhere to go.
Addresses come in two versions. IPv4 addresses are written as four numbers separated by dots, for example 203.0.113.10 (a range reserved for documentation examples). IPv6 addresses are longer, written in hexadecimal groups separated by colons, and exist because IPv4 has a limited supply.
An address usually belongs to a network interface, not a person. A laptop on Wi-Fi has one, and when it moves to another network, it generally gets a different one.
Public and private addresses
Not all addresses are visible to the whole internet.
- Public addresses are reachable across the internet. Your provider assigns one to your connection, and websites see it when you visit.
- Private addresses are used inside homes and offices, from ranges set aside for that purpose, and are not routed publicly. Many internal devices share one public address through address translation at the router.
This is why your phone and your colleague’s laptop may both show 192.168.x.x addresses on different networks while appearing to the outside world through a single public one. How internal ranges are organized is covered in the discussion of subnet masks.
Addresses can be assigned in two ways. Static addresses are set by hand and stay the same, which suits servers and printers. Dynamic addresses are leased automatically from a pool, which suits most laptops and phones.
Why we need DNS
People remember names, not numbers. The Domain Name System, or DNS, is the distributed directory that translates a name such as a website address into the IP address a computer needs. Without it, you would have to type numbers for every site, and those numbers can change when a service moves servers.
You can think of DNS as a phone book that is split across many cooperating servers rather than held in one place.
What happens when you visit a site
Suppose you type a website name into a browser. Roughly, this happens before anything appears:
- Local check. The browser and operating system look in their caches for a recent answer. If one exists, the lookup ends here.
- Ask the resolver. If not, the device asks its configured DNS resolver, typically run by the network, the internet provider or a public service you chose. The resolver does the legwork on your behalf.
- Resolver cache. The resolver checks its own cache. Popular names are usually already there.
- Walk the hierarchy. If it does not know, the resolver asks a root server which servers handle the ending of the name, then asks those servers which handle the specific domain, and finally asks the domain’s authoritative server for the actual record.
- Answer returns. The resolver passes the address back to your device and keeps a copy for future requests.
- Connect. Only now does your browser open a connection to that IP address and request the page.
Typically all this takes a small fraction of a second. Because of caching, repeat visits skip most of the steps.
Caching and time to live
Each DNS answer carries a time to live, a value that tells caches how long they may reuse it. Short values let changes spread quickly; long values reduce load and speed up lookups. This explains an irritating effect: after a site moves servers, some people see the new one immediately and others see the old one for a while.
Common record types
DNS stores more than addresses. Frequently met types include:
- A and AAAA: map a name to an IPv4 or IPv6 address.
- CNAME: makes one name an alias for another.
- MX: says which servers handle email for a domain.
- TXT: holds free-form text, often used to prove ownership of a domain or to publish email-authentication settings.
- NS: lists the servers responsible for a domain.
Organizations often manage their records in a web dashboard or, increasingly, through infrastructure as code so changes are tracked and repeatable.
What goes wrong
DNS problems tend to have recognizable symptoms:
- A site will not load, but you can reach it by IP address. The name lookup is failing, perhaps because the resolver is down or misconfigured.
- Some sites work and others do not. The problem may be with the domain’s own records.
- A site loads slowly at first and then quickly. The first, uncached lookup was slow, perhaps because the resolver is overloaded or distant.
- Changed records do not seem to apply. Caches have not expired yet.
- A device shows an unexpected address for a familiar name. This can be a harmless configuration change, but unexpected redirection is also a sign worth investigating as part of incident response, because attackers sometimes tamper with DNS.
Lookup tools available from the command line show what a resolver returns for a name. When a slowdown is baffling, include name resolution in the checklist for network troubleshooting.
Privacy and security notes
Ordinary DNS queries are sent without encryption, which means the network can often see which names you look up. Encrypted DNS options exist and are increasingly supported, though how and where they are enabled varies. Because DNS decides where traffic goes, it is a sensible target to protect: restrict who can edit records, use multi-factor authentication on the account that manages the domain, and keep a record of changes. Treat these as general good practice, not guarantees.
Putting the pieces together
An IP address says where a device is on a network. DNS says which address belongs to a name. Together they let a human-friendly request turn into a connection between two machines, and understanding both makes much of how the internet behaves, including how it fails, easier to follow.