---
title: "Resolver Domains"
description: "Serving GS1 Digital Links from your own hostname — CNAME setup, verification, and test prefixes to try it without a GS1 license."
canonical_url: "https://openepcis.io/docs/digital-data-management/resolver-domains"
last_updated: "2026-08-26T20:11:06.530Z"
---

## Why a domain of your own

The address in your QR codes is printed on physical products and will be scanned for years. Two things follow. First, it should carry *your* name — `https://id.your-brand.com/01/…` builds trust in a way a shared technical hostname never will, and consumers increasingly look at where a code leads before tapping. Second, and more strategically: the domain in the printed code is the one thing you can never change afterwards, so it had better be one *you* control. If it is your domain, you can move resolvers, providers, even platforms — the packaging never knows.

**Domains** is where you connect such a hostname to the resolver. Technically this is a **CNAME** binding: you create a DNS record that declares "requests to `id.your-brand.com` are answered by the resolver", and you tell the resolver which of your **GS1 Company Prefixes** the domain answers for — so it knows which identifiers are yours. From then on, scans of your products resolve under your brand, and because the resolver can attribute those scans to your domain, [EPCIS capture](/docs/digital-data-management/passport-editor#epcis-capture-on-resolve) and [Scan Analytics](/docs/digital-data-management/scan-analytics) know they belong to you.

## The domain list

![The resolver domains page | Figure 1: Each domain with its prefixes and where it stands — active, pending DNS, check failed or disabled](/img/13.Digital-Data-Management/resolver-domains.png)

The status badge is the page's whole answer to "does it work?":

<table>
<thead>
  <tr>
    <th>
      Status
    </th>
    
    <th>
      Meaning
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Active
      </strong>
    </td>
    
    <td>
      DNS verified; the domain serves Digital Links
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Pending DNS
      </strong>
    </td>
    
    <td>
      Created, waiting for the CNAME to appear
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Check failed
      </strong>
    </td>
    
    <td>
      DNS answered, but wrongly — the row says what DNS actually returned
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Disabled
      </strong>
    </td>
    
    <td>
      Kept, but not serving
    </td>
  </tr>
</tbody>
</table>

## Adding a domain

The drawer asks for the **hostname** (the domain's immutable identity — validated before anything is sent: a plain DNS name, no scheme, port, path or query), a **display name**, the **company prefixes** this domain answers for, and the **Enabled** switch.

![The add-domain drawer | Figure 2: Adding a domain — hostname, prefixes, the EPCIS-capture opt-in, and the DNS record already taking shape below](/img/13.Digital-Data-Management/resolver-domains-add.png)

Optionally, an **EPCIS capture** block names a read point (as a GLN of one of your [places](/docs/digital-data-management/organizations-and-places#places)), a business step and a business location — with these set, scans on this domain generate traceability events for products that opted in.

## DNS setup, made boring

Domain setup usually fails in the hand-over between two people: the person clicking in DDM and the person who administers DNS. The drawer's DNS card is written for that hand-over — it contains the exact record to create, ready to paste into a ticket:

![The CNAME instructions in the domain drawer | Figure 3: The DNS card — the exact CNAME to paste, and Check now to re-verify](/img/13.Digital-Data-Management/resolver-domains-cname.png)

```text
Type:    CNAME
Name:    id.your-brand.com
Target:  ingress.example.com   # the target shown in your drawer
```

Once DNS is set, **Check now** verifies on the spot. A failed check tells you what DNS *actually* answered — *"CNAME points at old-host.example instead of …"* — so the fix is never a guessing game. The same check keeps running periodically afterwards: a domain whose DNS silently breaks months later moves to *Check failed* with the same concrete diagnosis, instead of just going dark.

## Test prefixes (952 range)

Everything on this page can be tried without owning a GS1 license. GS1 reserves the prefix range **952** for demonstration and testing, and **Request test GCP** allocates a prefix from it to your tenant. Bind it to a domain, [create products](/docs/digital-data-management/product-catalog#creating-a-product) under it — the 952 range is exempt from Verified-by-GS1 — print a test QR code, scan it, watch it resolve. When the experiment is over, hand the prefix back. It is the sandbox for the whole Digital Link chain, end to end.