Configure Domains and DNS for Wiredoor

Domains give HTTP services a public hostname and provide a name for optional TCP TLS certificates. Wiredoor can validate records that you manage manually or create A records through a configured Cloudflare or GoDaddy account.

Choose a Public or Internal Domain

Use a public domain when users need normal browser trust. Use an internal domain only when you control name resolution and certificate trust on every client.

Use Wiredoor Without Public DNS

You do not need to own a public domain to use Wiredoor. You can create a local domain such as app.wiredoor.internal and resolve it from each client with an internal DNS server or a hosts file.

To configure a local domain:

1. Add app.wiredoor.internal as a domain in the Wiredoor dashboard.
2. Enable Skip Domain Validation.
3. Confirm that SSL Certificate Type changes to Self Signed.
4. Create the HTTP service with the local domain.
5. Point the local domain to the IP address of Wiredoor Server on every computer that must access it.

If you do not use an internal DNS server, add the entries to the hosts file for each client operating system:

203.0.113.10 app.wiredoor.internal

203.0.113.10 app.wiredoor.internal

Replace 203.0.113.10 with the IP address used to reach Wiredoor Server. No public DNS record is required, but the hosts entry must exist on every client that opens the domain.

Configure DNS Records

Choose one DNS management method. The automatic options require credentials in the Wiredoor Server environment and a server restart.

DNS_PROVIDER=cloudflare
CLOUDFLARE_API_TOKEN=replace-with-a-restricted-token

DNS_PROVIDER=godaddy
GODADDY_API_KEY=replace-with-api-key
GODADDY_API_SECRET=replace-with-api-secret

See the DNS provider settings reference for variable requirements and secret-handling guidance.

Understand Automatic DNS

When a service uses a domain that does not already resolve to Wiredoor Server, Wiredoor checks whether the configured provider can manage it. If it can, Wiredoor:

1. Discovers the public IP address of Wiredoor Server.
2. Creates an unproxied A record with a one-hour TTL.
3. Waits briefly for public DNS to return the new address.
4. Requests the certificate after validation succeeds.

If the provider cannot manage the domain, Wiredoor does not create the record. Create it manually and try again.

Understand Certificate Behavior

Wiredoor supports two certificate modes:

• Let’s Encrypt certificates for public domains that pass DNS or HTTP validation.
• Self-signed certificates for internal domains, IP-based access, or deployments that intentionally skip public validation.

TCP services can use a domain certificate when TLS termination is enabled. UDP services do not use TLS termination.

Self-signed certificates produce a browser or client warning until the issuing certificate is explicitly trusted. Do not disable certificate validation permanently as a workaround.

Change or Remove a Domain

A stored domain name cannot be renamed. Create the replacement domain, move or recreate the affected service routes, verify the new address, and then delete the old domain.

Deleting a domain removes its generated NGINX server configuration, certificate material managed by Wiredoor, OAuth2 process for that domain, and domain log directory. Review services that still reference the domain before deletion.

Changing certificate mode causes Wiredoor to load or request the certificate required by the new mode.

Verify DNS and HTTPS

After adding or changing a domain:

1. Confirm that public or internal DNS returns the intended Wiredoor Server address.
2. Open the HTTPS domain from an intended client.
3. Confirm that the certificate name matches the domain.
4. Confirm that the expected Wiredoor service responds.
5. Recheck the DNS record if certificate issuance fails.

See Wiredoor troubleshooting for DNS and TLS failures, and Wiredoor services for routing behavior.