Section 3.1.1 📖 ~10 min read

Domain Name Anatomy

SLDs, TLDs, subdomains, FQDNs, label rules, and internationalized domain names — every piece of a domain name explained.

You’ve seen domain names thousands of times. But can you identify every component of one? Do you know why my--domain.com is valid but -mydomain.com is not? Or how München.de becomes a valid DNS label despite containing non-ASCII characters?

Let’s dissect domain names completely.

The Building Blocks

A domain name is a structured identifier composed of labels separated by dots. We introduced this concept in Part 2, but now we need to go deeper — into the naming conventions, rules, and extensions that govern what you can actually register and use.

Take this domain:

blog.shop.example.co.uk.

Reading right to left (the DNS way):

Component Label(s) Role
. (root) empty label The invisible root of the DNS tree
uk Top-level domain (TLD) Country code TLD for United Kingdom
co Second-level domain Organizational category under .uk
example Third-level domain The registered domain name
shop Fourth-level domain Subdomain of example.co.uk
blog Fifth-level domain Subdomain of shop.example.co.uk

Each of these labels occupies a specific level in the DNS hierarchy, and each has different rules governing who can create it and how.

Second-Level Domains (SLDs)

The second-level domain is the label immediately to the left of the TLD. In most registrations, this is the part you actually choose and pay for:

  • In example.com → example is the SLD
  • In google.co.uk → co is the SLD (and google is technically third-level)
  • In wikipedia.org → wikipedia is the SLD

The SLD is where branding lives. It’s the part that becomes your identity on the internet. When someone says they “bought a domain,” they typically mean they registered an SLD under a specific TLD.

Some TLDs have structured second levels. The .uk namespace uses co.uk, org.uk, ac.uk, and others as organizational categories. In these cases, the registrable domain is actually at the third level. The Public Suffix List (maintained by Mozilla) tracks these multi-level registration boundaries — it’s the authoritative source for determining where the “registrable” part of a domain begins.

Subdomains

Everything to the left of the registered domain is a subdomain. If you register example.com, you can create unlimited subdomains under it:

www.example.com          ← subdomain
api.example.com          ← subdomain
staging.api.example.com  ← sub-subdomain

Subdomains are free — you don’t need to register them separately. You create them by adding DNS records in your zone. There’s no hard limit on depth (you can nest subdomains as deep as you want), but the total domain name can’t exceed 253 characters.

A common misconception: www is not a special prefix. It’s just a subdomain convention from the early web. www.example.com and example.com are two entirely separate DNS names that can resolve to different IP addresses. The only reason they usually point to the same place is because someone configured them that way.

Fully Qualified Domain Names (FQDNs)

We covered FQDNs in Part 2, but they deserve revisiting in the context of domain anatomy. An FQDN is the complete, unambiguous path from a node to the root:

www.example.com.
               ^
               └── trailing dot = root

The trailing dot signifies the root and makes the name absolute. Without it, a name could be relative — meaning it might have additional labels appended based on context (like a search domain configured on your operating system).

In everyday use, browsers and applications hide the trailing dot. But in zone files, DNS configurations, and SSL certificates, the distinction between relative and absolute names matters enormously.

The LDH Rule

The LDH rule (Letters, Digits, Hyphens) defines what characters are allowed in DNS labels. Formally specified in RFC 952 and refined in RFC 1123 §2.1:

  • Allowed characters: ASCII letters (a-z, A-Z), digits (0-9), and hyphens (-)
  • Labels cannot start or end with a hyphen: example.com ✓, -example.com ✗, example-.com ✗
  • Labels cannot be entirely numeric at the TLD level (by convention, not protocol restriction)
  • Case-insensitive: DNS treats A and a identically (RFC 4343)

Label Length Constraints

RFC 1035 §2.3.4 sets hard limits:

  • Each label: 1–63 octets
  • Total name: up to 253 characters in text representation (255 octets in wire format, including length bytes and the terminating root label)

These aren’t arbitrary numbers. The 63-octet label limit comes from the DNS wire format, where each label is prefixed by a single-byte length field. One byte can represent values 0–255, but values 192–255 are reserved for message compression pointers (the two high bits signal a pointer rather than a length). This effectively caps label lengths at 63 (binary 00111111).

The Double-Hyphen Restriction

Labels with hyphens in positions 3 and 4 (like xn--example) are reserved for internationalized domain names (we’ll get to those shortly). You generally can’t register a domain like ab--something.com because the -- in positions 3–4 is reserved for the ACE prefix used in Punycode encoding.

Internationalized Domain Names (IDNs)

The original DNS was designed for ASCII-only labels — fine for English, but inadequate for the majority of the world’s languages. Internationalized Domain Names solve this.

The Problem

How do you make münchen.de or 例え.jp or مثال.مصر work in a system that only understands ASCII? You can’t change the DNS protocol — it’s deployed on billions of devices. The names need to be encoded in a way that’s backward-compatible.

The Solution: Punycode and IDNA

The answer is a clever two-layer system defined in RFC 5891 (IDNA 2008):

  1. The user sees Unicode: münchen.de in their browser
  2. The system converts to ASCII-Compatible Encoding (ACE): xn--mnchen-3ya.de

The xn-- prefix is the magic marker. It tells DNS software “this label is Punycode-encoded and represents a Unicode string.” The encoding after xn-- uses the Punycode algorithm (RFC 3492) to represent arbitrary Unicode as ASCII.

münchen.de    → xn--mnchen-3ya.de     (ü encoded)
例え.jp        → xn--r8jz45g.jp        (Japanese encoded)
مثال.مصر       → xn--mgbh0fb.xn--wgbh1c  (Arabic, including TLD)

How Punycode Works (Simplified)

Punycode separates a label into its ASCII characters and its non-ASCII characters. The ASCII characters appear directly after xn--, and the non-ASCII characters are encoded as a series of numbers that describe their positions and code points. The algorithm is deterministic — the same Unicode string always produces the same Punycode.

For münchen:

  • ASCII characters: m, n, c, h, e, n → mnchen
  • Non-ASCII: ü at position 1 → encoded as 3ya
  • Result: xn--mnchen-3ya

IDNA 2003 vs IDNA 2008

There are two versions of the internationalized domain names standard, and they disagree on some characters:

  • IDNA 2003 (RFC 3490): Maps characters during lookup. ß becomes ss, so straße.de and strasse.de are identical
  • IDNA 2008 (RFC 5891-5895): Does not map characters. ß and ss are distinct. straße.de (xn--strae-9ra.de) is a separate domain from strasse.de

This difference caused real-world conflicts. Germany actually addressed this by allowing both forms to be registered together. Different browsers and applications may implement different versions, creating occasional inconsistencies.

IDN TLDs

The internationalization extends to TLDs themselves. ICANN delegated the first internationalized country code TLDs in 2010:

  • .مصر (Egypt, Arabic)
  • .中国 (China, Chinese)
  • .рф (Russia, Cyrillic)
  • .भारत (India, Devanagari)

These are fully functional TLDs, Punycode-encoded at the root zone level. .中国 is xn--fiqs8s in the root zone file.

Putting It All Together

Every domain name you encounter is a structured path through the DNS hierarchy, built from labels that follow precise rules:

blog.münchen-shop.example.co.uk.
│    │              │       │  │
│    │              │       │  └── TLD (ccTLD)
│    │              │       └──── Second-level category
│    │              └──────────── Registered domain (SLD in this context)
│    └─────────────────────────── Subdomain (IDN, contains ü)
└──────────────────────────────── Sub-subdomain

The DNS doesn’t care about the semantics — blog, münchen-shop, example, co, and uk are all just labels in a tree. The meaning we assign to them (subdomain, brand, category, country) is a human convention layered on top of a purely hierarchical system.

Key Takeaways

  • SLDs are the labels you register; the registrable level varies by TLD structure
  • Subdomains are free, unlimited, and created via DNS records under your registered domain
  • FQDNs end with a trailing dot representing the root — absolute vs relative names matter
  • The LDH rule restricts labels to letters, digits, and hyphens (no leading/trailing hyphens)
  • Label limits: 63 characters per label, 253 characters total
  • IDNs use Punycode (xn-- prefix) to encode Unicode into ASCII-compatible labels
  • IDNA 2008 is the current standard, but differences from IDNA 2003 still cause edge cases

Next, we’ll explore the different types of top-level domains — from the original seven gTLDs to the 1,200+ extensions created in the new gTLD program.