What problem does DNS message compression actually solve?

A DNS response to an A record query for www.example.com typically repeats www.example.com (or a suffix of it) in both the question and answer sections. Spelling that out fully every time wastes bytes in a protocol that was designed to fit in a single small UDP packet, so RFC 1035 lets later occurrences point back to an earlier one instead.

How does a compression pointer work at the byte level?

A normal DNS label starts with a length byte with its top two bits clear. A pointer instead sets both top bits (0xC0), and the remaining 14 bits of that byte plus the next one encode the offset, in bytes from the start of the message, where the rest of the name can be found.

Why does the tool start numbering offsets at 12?

Every DNS message begins with a fixed 12-byte header (ID, flags, and four count fields) before the question section starts, so byte 12 is where the first name in any real DNS message actually begins.

DNS Name Compression Tool - RFC 1035 Wire Format Visualizer

Name	Offset	Wire bytes	Size
www.example.com	12	03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00	17
mail.example.com	29	04 6d 61 69 6c c0 10(pointer → offset 16, "example.com")	7 (was 18)
ftp.example.com	36	03 66 74 70 c0 10(pointer → offset 16, "example.com")	6 (was 17)

Overview

Introduction

Every domain name inside a DNS message is encoded as a sequence of length-prefixed labels, but when the same name (or a suffix of it) shows up more than once, the protocol compresses it into a 2-byte back-pointer instead of repeating it.

This tool encodes a list of names in the order they'd appear in a message and shows exactly which ones got compressed, and how many bytes that saved.

What Is DNS Name Compression Tool?

An educational encoder that turns domain names into DNS wire-format bytes, applying RFC 1035's name compression algorithm exactly as a real DNS server or resolver would.

It's part of this site's DNS & Domain Tools collection and runs entirely offline; it's a protocol visualizer, not a live lookup.

How DNS Name Compression Tool Works

Each name is checked against every suffix of every name already encoded earlier in the sequence; the longest matching suffix becomes a pointer instead of being spelled out.

Labels that aren't compressed are written as a length byte followed by their ASCII bytes, terminated by a zero byte for the root; a pointer instead uses two bytes with the top two bits set (0xC0) followed by the target offset.

When To Use DNS Name Compression Tool

Use it to see concretely how much DNS message compression actually saves for a realistic set of names, like a domain's several subdomains appearing together in a response.

It's also useful as a learning aid when implementing or debugging low-level DNS parsing code that needs to follow compression pointers correctly.

Often used alongside MX Record Lookup and DNS Propagation Checker.

Features

Advantages

Shows the exact byte sequence and offsets involved, not just an abstract description of the algorithm.
Computes real savings numbers by comparing against what the same names would cost fully uncompressed.

Limitations

This is a standalone visualizer, not a full DNS message: it doesn't build a real header, question, or resource record sections around the encoded names.
Capped at 12 names per run to keep the byte table readable.

Examples

Three subdomains of the same domain

Input

www.example.com
mail.example.com
ftp.example.com

Output

www.example.com: 18 bytes (full)
mail.example.com: 7 bytes (pointer to "example.com" at offset 16)
ftp.example.com: 6 bytes (pointer to "example.com" at offset 16)

The first name writes 'example.com' out in full; the next two both point back to that same suffix instead of repeating it.

Best Practices & Notes

Best Practices

Order names the way they'd actually appear in a real message (question first, then answers) to get a realistic compression picture.
Try a batch of unrelated domains alongside related subdomains to see how little compression helps when there's no shared suffix to point to.

Developer Notes

Offsets start at 12 to model where the question section begins in a real DNS message after its fixed header, and the dictionary only ever stores offsets for label sequences actually written to the simulated message, matching how RFC 1035 restricts valid pointer targets to positions that hold a real (non-pointer) label sequence.

DNS Name Compression Tool Use Cases

Teaching or learning exactly how DNS message compression works at the byte level
Estimating how much a specific batch of names would benefit from compression before optimizing a DNS server implementation
Debugging a hand-rolled DNS parser that isn't following compression pointers correctly

Common Mistakes

Assuming every repeated substring compresses; only suffixes that align exactly with a previously written label sequence qualify, not arbitrary repeated text.
Forgetting that a pointer's target offset is measured from the very start of the DNS message, not from the start of the name section.

Tips

Enter completely unrelated domains to see the case where no compression is possible; every name should show its full uncompressed size.

DNS Name Compression Tool