DNS & TLS

DNS and TLS are two halves of one job: get a domain served safely by your server. A record points correctly → validation can reach the host → the certificate issues → HTTPS works. MZPanel keeps both on one DNS & TLS page per server, so the most common support problem (“SSL won’t issue / site won’t load” — almost always a DNS mistake) is visible in one place.

Per-site DNS & TLS

Each server’s DNS & TLS page lists your domains. Every row pairs two live signals:

• DNS — a live dig health check: resolves here, resolves elsewhere, or missing, plus the detected mode (External / Cloudflare) and a proxied chip.
• TLS — the real certificate status: valid, expiring, expired, or none, with the expiry date and auto-renew state.

From a row you can Issue / Renew a Let’s Encrypt certificate or open Manage to see certificate details and the DNS records for that domain.

The proxied state drives how TLS should be issued — this is the single variable that ties DNS and TLS together:

DNS state	How TLS is issued	Tier
DNS-only (A record points straight at the IP)	Let’s Encrypt HTTP-01 — the default	Free
Proxied (Cloudflare in front)	Cloudflare Origin Certificate at the origin + Full (strict) mode	Plus
Wildcard	DNS-01 challenge (writes an _acme-challenge TXT record)	Plus

Wildcard and DNS-01 certificates need a connected Cloudflare token (see below).

Cloudflare integration (Plus)

Most domains route through Cloudflare. To write DNS records, MZPanel needs a Cloudflare API token — dig alone is read-only (“what the world sees”), not a control layer.

Connect a token under Connect → DNS (account level). MZPanel verifies it against the Cloudflare API and stores it encrypted on the control plane; the token is never sent to your VPS. Record writes run server-side (control plane → Cloudflare API), not through the agent.

Use a scoped API token (not the Global API Key). The minimum scope is Zone.DNS:Edit + Zone.Zone:Read, restricted to the zones you want to manage.

Tip

Once a token owns the zone, the DNS tab of the Manage drawer becomes a full record editor — create/update records and toggle the proxied flag. Without a token, you get a read-only view of the resolved records plus a copy-paste hint to create the right A record by hand.

When a domain is External (someone else holds the zone, no token), MZPanel stays read-only: it shows the dig view and tells you exactly which record to create at your provider.

Authoritative nameservers (BIND9, Pro)

If you’d rather delegate a domain to your own nameservers (ns1.example.com, ns2.example.com) instead of pointing an A record, MZPanel can run BIND9 as the authoritative DNS server on your box.

• You provide the nameservers. MZPanel does not act as a DNS provider — you enter your own hostnames (e.g. ns1.example.com), and MZPanel configures BIND9 and generates the zones.
• Glue records are yours to create. At your registrar, point ns1 / ns2 at your box’s IP. MZPanel shows the exact glue checklist.
• Gated on the bind9 extension. Install it first from the server’s Extensions; until then the UI shows an install prompt.

Records for a BIND-served domain are edited from the same DNS & TLS page — A/AAAA/CNAME/MX/TXT/NS/SRV/CAA and more — validated with named-checkzone before every reload, so a broken zone is never loaded.

Single point of failure

Running a primary nameserver on one VPS is a real risk, and MZPanel says so up front. If the box goes down, the domain’s entire DNS goes down — web, mail, and every subdomain — which is worse than a plain A record (only that domain’s web is affected). Proper authoritative DNS wants two nameservers on two separate networks; a single box with ns1 and ns2 on the same IP does not meet that bar. Use it knowingly.

Rolling out

The BIND9 engine is built and validated, but the dashboard surface for nameservers and zone records is still rolling out. Availability may lag the rest of the DNS & TLS page.

See also

• Issuing SSL certificates for the certificate lifecycle.
• Architecture for how the control plane and agent divide responsibilities.