DNS

ByteBite uses Cloudflare as the DNS provider. The registrar is DomainNameAPI. All application records described here are DNS-only (grey cloud) — not Cloudflare-proxied.

Verified: 2026-09-08

Edge record

All staging application hostnames ultimately resolve to the ByteBite edge:

Staging app records alias or CNAME through edge.getbytebite.co.

Staging records

Wildcard DNS was verified with arbitrary hostnames (e.g. random subdomains resolving correctly).

Production-facing records (DNS only — app not deployed)

The following records already point toward 88.99.0.118 / the edge:

Production application infrastructure is NOT deployed. DNS existence does not mean production is live. See Production deployment.

Mail DNS

Mail server software (Stalwart), PTR (mail.getbytebite.co), SPF, DKIM, and DMARC are not complete. See Mail.

Wildcard DNS vs tenant existence

A hostname resolving via *.staging.getbytebite.co does not mean a restaurant tenant exists. Tenant identity requires an exact row in restaurant_domains:

DNS resolves -> Traefik routes -> Storefront/API
  -> database lookup by hostname
    -> found: tenant context
    -> not found: "Restaurant not found" (storefront) or HTTP 404 (API)

Seeded staging tenants: luigi.staging.getbytebite.co, mario.staging.getbytebite.co (via seed-staging.js).

Custom domains (future)

The schema supports CUSTOM_DOMAIN type in restaurant_domains. Production custom-domain TLS and verification are not implemented. Wildcard staging TLS uses DNS-01 for *.staging.getbytebite.co; production custom domains will require a separate TLS strategy.

Local DNS

Local development does not use Cloudflare. Hosts are listed explicitly in /etc/hosts — no wildcard support. See Local deployment.

Related

• TLS — certificate issuance
• Traefik — hostname routing after DNS
• Database — restaurant_domains table
• Validation — dig smoke tests