DNS, IP addresses and ports explained for beginners

Almost every “it does not connect” problem comes down to one of three questions: did the name resolve to the right address, did the packets reach that address, and is anything listening on that port? This article explains the three building blocks so the error messages in later articles make sense.

IP addresses: which machine

An IP address identifies one network interface on one machine. IPv4 addresses look like 192.0.2.10; IPv6 addresses look like 2001:db8::10. A few ranges have special meaning:

• 127.0.0.1 and ::1 (localhost) always mean “this machine”. A service bound only to 127.0.0.1 is unreachable from other computers, which is often exactly what you want for a database.
• 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are private ranges used inside homes and offices. They are not routable on the public internet; your router translates them (NAT) to one public address.
• 0.0.0.0 as a listen address means “all interfaces”, so the service accepts connections from anywhere the firewall lets through.
• The /24 in 192.168.1.0/24 is the prefix length: the first 24 bits are the network, the rest identify hosts, so this network holds 192.168.1.1 to 192.168.1.254.

See your own addresses and the default route (the gateway that handles everything not on your local network):

ip -brief address        # Linux: one line per interface
ip route                 # the line starting with "default" is your gateway
ifconfig                 # macOS

curl -4 https://ifconfig.me   # the public address the internet sees

Ports: which program

One machine runs many network programs at once, so each connection also carries a port number from 0 to 65535. The server side listens on a well-known port; the client side uses a random high port for the duration of the connection. Ports below 1024 can only be opened by root. Ports you will meet constantly:

• 22 SSH, 53 DNS, 80 HTTP, 443 HTTPS, 25 and 587 mail submission, 123 NTP.
• 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB.
• 3000, 5000, 8000, 8080: common development servers.
• 51820 WireGuard (UDP), 1194 OpenVPN (UDP).

A port is either TCP (connection-oriented: web, SSH, databases) or UDP (connectionless: DNS queries, VPNs, video). Port 53/tcp and port 53/udp are different things, which matters when you open a firewall. List what is listening on your machine:

ss -ltnp          # Linux: listening TCP sockets with the owning process
ss -lunp          # listening UDP sockets
sudo lsof -iTCP -sTCP:LISTEN -nP   # macOS and Linux alternative

In the output, 0.0.0.0:22 means SSH listens on all IPv4 addresses, [::]:22 on all IPv6 addresses, and 127.0.0.1:5432 means PostgreSQL only accepts local connections.

DNS: names to addresses

Nobody wants to remember 93.184.216.34, so the Domain Name System maps names to addresses. When you type example.com, your machine asks a resolver (from your router, your ISP, or a public one such as 1.1.1.1 or 9.9.9.9). The resolver walks from the root servers to the .com servers to the servers that are authoritative for example.com, caches the answer for the time given in its TTL and returns it. The important record types:

• A: name to IPv4 address. AAAA: name to IPv6 address.
• CNAME: this name is an alias for another name.
• MX: which servers accept mail for the domain.
• TXT: free text, used for domain verification, SPF and similar.
• PTR: the reverse direction, address to name.

dig example.com                 # full answer with TTL and the resolver used
dig +short example.com A        # just the addresses
dig +short example.com AAAA
dig @1.1.1.1 example.com        # ask a specific resolver
dig -x 93.184.216.34            # reverse lookup
getent hosts example.com        # what programs on this Linux box actually get
resolvectl status               # Linux with systemd-resolved: which resolver is in use

Two things trip up beginners. First, /etc/hosts is checked before DNS, so a stale line there overrides the real answer. Second, caching: after you change a record, resolvers keep the old answer until the TTL expires, so dig against the authoritative server (dig @ns1.example-dns.net example.com) can show the new value while your laptop still sees the old one.

Putting it together

When https://app.example.com fails, walk the same path the browser does: dig +short app.example.com (does the name resolve, and to the address you expect?), ping or nc -zv app.example.com 443 (can you reach that address and port?), then curl -v https://app.example.com (does the service answer correctly?). Each step isolates one layer, and the error messages at each layer are covered in the fix articles in this topic.

Official documentation

• ss(8)
• dig(1)
• RFC 1918: private address ranges