wmantly
426fa111ec
- New docs/concepts-{hosts,dns,access,api-tokens}.md -- plain-language
guides aimed at less technical readers, each linking onward to the
existing system-design-level doc for anyone who wants that detail.
Card help links (Proxy List, Add/Edit host, DNS Provider cards,
Users/Permissions/Groups cards) now point here instead of straight at
Installation/Architecture.
- The "New API Token" card had no help link at all -- added, pointing to
the new API Tokens doc.
- Fixed the in-app docs viewer rendering every docs/*.md page with a
garbled heading + stray <hr> at the top: Jekyll front matter (meant
only for the GitHub Pages build) was never stripped before being
handed to the markdown renderer.
- Fixed cross-doc links never resolving in-app, since this viewer serves
docs at /docs/<slug> with no .html suffix: rewritten to the correct
in-app URL, first by registered slug, falling back to the doc's real
filename (the correct, working link form on the Jekyll/GitHub Pages
build) -- same idea as the existing image-path fix, and lets one link
written in a doc work on both targets.
Bumps to v1.1.13.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KDEx8ghuZR61pqPXc6da9C
50 lines
2.0 KiB
Markdown
50 lines
2.0 KiB
Markdown
---
|
|
layout: default
|
|
title: DNS Providers
|
|
description: A plain-language guide to why theta42/proxy needs a DNS provider, and only for wildcard certificates.
|
|
---
|
|
|
|
# DNS Providers
|
|
|
|
This page explains, in plain language, what a "DNS provider" is for in this
|
|
app and when you actually need one. For setup steps, see
|
|
[Installation](installation.html).
|
|
|
|
## Do you need this at all?
|
|
|
|
**Only if you want a [wildcard host](concepts-hosts.html)** (something like
|
|
`*.example.com` covering every subdomain with one certificate). A normal,
|
|
single-name host doesn't need a DNS provider configured at all — skip this
|
|
page entirely if that's all you're setting up.
|
|
|
|
## Why a wildcard cert needs this extra step
|
|
|
|
To prove you actually own `example.com` before issuing a certificate that
|
|
covers *every* possible subdomain of it, Let's Encrypt needs to see a
|
|
specific, temporary DNS record appear on that domain — something only the
|
|
real owner of the domain could add. A normal single-host certificate
|
|
doesn't need this because it can prove ownership a simpler way (by
|
|
responding to a web request instead).
|
|
|
|
So: to get a wildcard certificate, this app needs to be able to add (and
|
|
later remove) that one temporary DNS record on your domain automatically,
|
|
which means it needs your domain registrar or DNS host's API credentials —
|
|
that's what registering a **DNS provider** here does.
|
|
|
|
## What you're actually giving it access to
|
|
|
|
A DNS provider entry only needs enough access to add/remove TXT records —
|
|
it's not given your registrar account's full login, and it can't do
|
|
anything to your domain besides that one narrow task (and, for some
|
|
providers, keeping a dynamic A record updated if you use that feature
|
|
separately). Check your specific provider's page in the
|
|
[Installation guide](installation.html) for exactly what kind of
|
|
credential to generate and how narrowly you can scope it.
|
|
|
|
## Want more detail?
|
|
|
|
For exact setup steps per provider (Cloudflare, DigitalOcean, Porkbun,
|
|
DuckDNS, etc.), see [Installation](installation.html).
|
|
|
|
[← Back to Home](index.html)
|