How to Find Out Who Your Domain Registrar, DNS Provider and Web Host Are
Before renewing a domain, you need to know which company handles each service. You also need that information to change its DNS…
When you run Docker containers behind Traefik, Traefik can route requests to a container based on its hostname, such as app.example.com. That hostname still needs a DNS record in Cloudflare so clients know where to send their requests. A DNS record is the entry that connects a hostname to an IP address or another hostname.
Traefik’s Docker labels configure HTTP routing, but they do not publish DNS records. To create Cloudflare records automatically, run a separate DNS automation service that reads container labels and uses Cloudflare’s API, which lets software manage Cloudflare settings, to write records. The record should point to the public endpoint clients use to reach Traefik, not to the container’s private Docker-network address.
Traefik reads Docker labels to learn which hostnames belong to which containers. For example, these Docker Compose labels tell Traefik to send requests for app.example.com to the app service on port 8080:
services:
app:
image: example/app
labels:
traefik.enable: "true"
traefik.http.routers.app.rule: "Host(<code>app.example.com)"
traefik.http.services.app.loadbalancer.server.port: "8080"
The Host(...) rule supplies the hostname Traefik matches in incoming HTTP requests. The port label tells Traefik which port to use inside the container; Docker networking must also let Traefik reach that port. The Docker Traefik guide shows how Docker labels configure this routing.
These labels do not create a Cloudflare record. A separate service must read the hostname and make the corresponding DNS change.
Choose the record target based on the endpoint your intended clients can reach. Cloudflare’s DNS record documentation describes the main choices:
A container’s private address, such as an address on a Docker network, is not the public endpoint. Publishing that address does not make the container reachable from the internet. For a LAN-only or VPN-only service, use a record and network path suited to those clients rather than assuming a public DNS record provides access.
If every service name should resolve to the same Traefik endpoint, create one wildcard record, which covers multiple service hostnames, and let Traefik route each hostname. This avoids a Cloudflare write for each container, but Cloudflare will not maintain a separate record for each service.
For individual records, use a Docker-aware DNS manager that reads Traefik labels and calls Cloudflare’s DNS API. The Traefik Cloudflare Companion describes extracting hostnames from Traefik labels and creating or updating CNAME records that point to a configured target. Its documented settings include CF_TOKEN, TARGET_DOMAIN, and zone-specific configuration.
A different project, cloudflare-dns-manager, describes deriving hostnames from Docker labels and creating records such as A records that point to a configured IP. Its example uses a private LAN address, which is suitable only when the intended clients can reach that LAN address. The two projects use different record-target approaches, so select one that matches your endpoint and check its current configuration before deploying it.
Before choosing a companion, check which Traefik versions it supports. The Traefik Cloudflare Companion documentation describes support for Traefik 1.x and 2.x; it does not establish compatibility with Traefik v3. Test the exact Traefik and companion versions you plan to run. Also verify how the selected service handles containers that stop or disappear and whether it protects existing manually managed records. Do not assume that a service which creates records also safely deletes stale ones.
Create a Cloudflare API token with DNS write access for only the DNS zone, the domain managed in Cloudflare, that the automation needs. Cloudflare’s DNS record API accepts DNS Write permission for record creation, and Cloudflare recommends using scoped API tokens. Give the token additional permissions only when the selected service needs them, such as permission to discover a zone rather than using a configured zone ID.
Store the token as a Docker secret or use another protected secret store supported by your deployment. Avoid putting it in a public repository or an image. A companion that reads Docker labels also needs Docker API access, commonly through the Docker socket. That access exposes container metadata and gives the service significant influence over the Docker host, so restrict which containers it reads and consider a Docker socket proxy that limits API access. Traefik’s Docker provider documentation warns that unrestricted Docker API access creates a host security risk.
A working hostname depends on several separate pieces: Cloudflare must publish the record, the client must reach the record’s target, and Traefik must match the hostname and forward the request to the right container. Check each part independently when a new service does not load. Confirm that the record has the intended type and target, that the target is reachable from the client’s network, and that the Traefik router uses the same hostname.
A proxied record routes HTTP and HTTPS traffic through Cloudflare and returns Cloudflare addresses; a DNS-only record returns the server’s IP address directly. The proxy status documentation explains the behavior. The proxy setting does not create a route through Traefik or make a private address publicly reachable.
DNS automation that publishes application records is separate from Traefik’s ACME DNS-01 certificate challenge. ACME is the protocol Traefik uses to obtain certificates, and DNS-01 proves domain control by creating a DNS value during certificate validation. It does not publish the normal A, AAAA, or CNAME record that lets clients find an application hostname. Traefik’s ACME documentation describes that certificate-validation function; check documentation for your Traefik version before copying version-specific settings.
A companion’s polling interval, how often it checks for changes, and a DNS TTL, how long resolvers cache a record, do not guarantee how long you must wait. The Companion documents a 60-second default polling interval, while Cloudflare documents a 300-second automatic TTL for proxied records. Local DNS caches can take longer to show a change, so check the result from the client network that needs to use the hostname.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com