KAHIBARO
Discord Login Register ☰
☰

2.3. Domain Names

Table of Contents

Why Domain Names Exist

Computers on the internet talk to each other using IP addresses like 142.250.74.206 or 2a00:1450:4001:82f::200e. Humans are bad at remembering these numbers, and businesses and products usually have names, not numbers.

A domain name is a human friendly label that maps to one or more IP addresses. When you type google.com in your browser, your computer first finds the IP address for google.com, then talks to that IP.

You will learn the exact process in detail in the DNS chapter. For now, focus on what domain names are and how they are structured, because as a backend developer you will see and use them constantly.

A domain name is a human readable identifier, like example.com, that is mapped to an IP address so users can access servers without remembering numbers.

Backend applications are almost always deployed behind some domain, such as api.myapp.com or backend.shop.example. Understanding domain names helps you:

The Structure of a Domain Name

A domain name is a sequence of labels separated by dots. For example, in api.shop.example.com there are four labels: api, shop, example, com.

Conceptually, domain names are read from right to left, from the most general part to the most specific.

Consider this table:

Example domainExplanation
comTop level domain (TLD)
example.comSecond level domain (SLD) under .com
shop.example.comSubdomain shop of example.com
api.shop.example.comSubdomain api of shop.example.com

Top Level Domains (TLDs)

The rightmost part is the top level domain.

Examples:

You do not create TLDs as a normal user. They are managed globally by ICANN and specific organizations called registries.

Second Level Domains (SLDs)

The part immediately to the left of the TLD is usually what people think of as the main domain name.

Examples:

When you "buy a domain name", you are usually buying a second level domain under some TLD, for example myapp.com.

As the owner of example.com, you can then create subdomains like api.example.com or blog.example.com without buying anything extra.

Subdomains

Anything to the left of the second level domain is a subdomain. Subdomains are hierarchical. Each label to the left is a child of the one to the right.

For example:

You can create many subdomains to separate parts of your backend system.

Common patterns:

SubdomainTypical use
www.example.comMain website
api.example.comPublic API backend
admin.example.comAdmin or internal dashboard
static.example.comStatic files (images, CSS, JavaScript)
cdn.example.comContent delivery network endpoint
dev.example.comDevelopment or staging environment

As a backend developer, you may split services across subdomains, for example auth.myapp.com for authentication and orders.myapp.com for order processing.

Fully Qualified Domain Name (FQDN)

A Fully Qualified Domain Name is the complete domain name that specifies its exact position in the domain name hierarchy.

In theory, domain names end with a dot that represents the root of the DNS tree.

In practice, people say "FQDN" to mean a complete domain like api.example.com, as opposed to just api or example.

A server configured to identify itself as db.internal.example.com uses an FQDN. This can matter when generating certificates, configuring internal networks, or writing configuration files.

Labels and Naming Rules

Each part between dots is called a label. Labels must follow certain rules.

Basic rules:

Examples of valid domain names:

Examples of invalid domain names:

IDNs, or internationalized domain names, allow non ASCII characters, like münchen.de. Under the hood they are encoded into ASCII form, for example xn--mnchen-3ya.de. As a beginner backend developer you rarely need to handle this encoding manually, but be aware that domain names shown to users can contain non English characters.

Important naming rule: Use only letters, digits, and hyphens. No spaces, underscores, or special symbols. Never start or end a label with a hyphen.

Domain Names vs URLs

Domain names are only one part of a URL. A URL (Uniform Resource Locator) is a complete address that includes additional information, such as protocol, path, query parameters, and port.

Here is a breakdown:

https://api.example.com:8080/v1/users?active=true#section

PartMeaning
httpsProtocol (scheme)
api.example.comDomain name
:8080Port (optional, defaults depend on protocol)
/v1/usersPath to a resource on the server
?active=trueQuery string with parameters
#sectionFragment (used in browsers, not sent to server)

Mixing up domains and URLs is common for beginners.

As a backend developer you will use full URLs in API documentation and HTTP calls, but when configuring DNS, TLS certificates, or CORS, you work mainly with domain names.

Registering and Owning a Domain

To use a domain name on the public internet, you must register it through a domain registrar such as Namecheap, Google Domains (phasing out), Cloudflare Registrar, GoDaddy, etc.

The process is:

  1. Search for an available domain, for example mycoolapp.com.
  2. Pay the yearly registration fee.
  3. Configure DNS records for that domain at your registrar or DNS provider.

You do not own the domain forever. You rent it for a period, usually one year at a time, and must renew it.

As a backend developer you may not be the one who buys the domain, but you will likely:

If your company already owns example.com, you might request that api.example.com be pointed to your server's IP address. This is done with DNS records, which you will learn in the DNS chapter.

Domains and Backend Environments

Real applications rarely have just one domain. You often separate environments, such as development, staging, and production, using different domains or subdomains.

Some common patterns:

EnvironmentPossible domain
Productionapi.myapp.com
Stagingstaging-api.myapp.com or api-staging.myapp.com
Developmentdev-api.myapp.com or api-dev.myapp.com
Locallocalhost or 127.0.0.1

localhost is a special hostname that always refers to the local machine, usually mapped to 127.0.0.1 (IPv4) and ::1 (IPv6). It behaves like a domain name, but it is handled specially and does not require DNS.

As a backend developer you often:

Cookies, CORS policies, and security settings can depend on the exact domain, so keeping the environment domains organized and consistent is important.

Domains and Cookies

Cookies, which you will learn about in detail later, are associated with domains. This is important because backend authentication often uses cookies.

Key ideas:

Example:

If your backend API is at api.example.com and your frontend is at www.example.com, you might set the cookie domain to .example.com so that both subdomains can access the same cookies.

Important cookie rule: Cookies are restricted by domain. Authentication cookies usually cannot be shared across completely different domains, such as between example.com and other.com.

This means that when designing your backend architecture you often choose your domains and subdomains so that cookies and authentication behave as needed.

Domains, HTTPS, and Certificates

HTTPS, which secures HTTP traffic, uses TLS certificates. Certificates are issued for specific domain names.

Some important points:

As a backend developer, when you configure HTTPS:

If the certificate name does not match the domain, browsers will show a security warning and API clients may reject the connection.

Internal vs Public Domains

Not every domain is visible on the public internet. Many organizations use internal domain names for services inside their private networks.

Examples:

These domains are usually resolved by internal DNS servers, not the global public DNS system.

For a backend developer this means:

You will often configure services to talk to each other by hostname, not by hard coded IP. This allows IP addresses to change while the domain name stays the same.

Practical Examples for Backend Developers

To make domain names more concrete, look at some realistic backend scenarios.

Example 1: Single service backend

You build a small API for a mobile app. You register mytodoapp.com and set up:

The mobile app calls URLs like https://api.mytodoapp.com/v1/tasks.

Example 2: Microservices with multiple domains

You build a larger system and decide to separate services.

Your frontend at www.myshop.com calls these different domains. You must think about CORS, cookies, and certificates across all of them.

Example 3: Environments and subdomains

Your product has different stages:

Your CI/CD pipeline deploys to each domain. You can test new backend features in staging-api.example.com without affecting real users on api.example.com.

Example 4: Combining subdomains with ports

You host an internal service reachable only from your company network.

People inside the company open http://metrics.internal.example.com:9090/ in their browser. The domain is resolved inside the internal DNS, and the port tells the browser which service to connect to.

Summary

Domain names are the human friendly entry points to your backend systems. They:

With this understanding you are ready to go deeper into DNS, which explains how domain names are translated into IP addresses when a client wants to talk to your backend.

Views: 10

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3054 / 24h
Impressum / Imprint
Datenschutz / Data Policy