docs: expand reference pages and fix children shortcode rendering

Enable Goldmark block-level attributes so the relearn `children`
shortcode applies its CSS classes instead of printing them literally
in the table-of-contents pages. Also expand the deploy, plugins,
records, and email reference docs and add the checks pages.

content/reference/records/SOA.en.md

@@ -2,9 +2,36 @@
 date: 2021-01-12T21:38:49+02:00
 author: Frederic
 title: SOA (Start Of Authority)
+description: "Understand the Start Of Authority record, the mandatory record at the apex of every DNS zone, and how happyDomain manages it for you."
 weight: 10
 aliases:
     records/SOA
 ---
 
-The Start of Authority-SOA is the first record of a zone.
+The **Start Of Authority** (SOA) record is defined by [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035). It is mandatory and unique: exactly one SOA must sit at the apex (the root) of every DNS zone. Its presence declares that the name server is authoritative for the zone and carries the parameters that govern how the zone is replicated between servers and cached by resolvers.
+
+## Fields of the SOA record
+
+The SOA record gathers seven values:
+
+| Field | Description |
+|---|---|
+| **MNAME** (primary name server) | The hostname of the primary (master) name server for the zone. |
+| **RNAME** (responsible party) | The email address of the person responsible for the zone, encoded in DNS form: the `@` is replaced by a dot (for example `hostmaster.example.com.` means `hostmaster@example.com`). |
+| **Serial** | A version number for the zone. It must increase every time the zone changes, so that secondary servers know they need to transfer the new content. |
+| **Refresh** | How often (in seconds) a secondary server checks the primary for an updated serial. |
+| **Retry** | How long (in seconds) a secondary waits before retrying a failed refresh. |
+| **Expire** | How long (in seconds) a secondary keeps serving the zone when it cannot reach the primary, before considering the data stale. |
+| **Minimum** (negative-cache TTL) | The duration for which resolvers cache negative answers (NXDOMAIN), per [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308). |
+
+## The SOA in happyDomain
+
+happyDomain does not present the SOA as a standalone record to edit field by field. Instead, the apex of your zone is modelled as an **Origin** service, which groups the SOA together with the zone's name servers (NS records). You will therefore find the SOA at the root of your domain, alongside the list of authoritative name servers, rather than in a separate form.
+
+The **serial** is, in most cases, handled automatically. When you publish your changes, many DNS providers manage the serial themselves: happyDomain detects this capability and re-reads the zone after publication to reflect the serial the provider actually assigned. You normally do not need (nor are you expected) to set it by hand.
+
+{{% notice style="info" title="What you can and cannot change" %}}
+The exact behaviour depends on your DNS provider. Some providers expose the full SOA and let happyDomain submit its values; others manage the SOA serial — and sometimes the other timers — on their side. When the provider takes care of the serial, any value happyDomain shows for it simply reflects the published state and is refreshed automatically.
+{{% /notice %}}
+
+For more on how the apex and other groupings are represented, see the {{< relref "../services" >}} chapter.

content/reference/records/SOA.fr.md

@@ -1,9 +1,36 @@
 ---
 date: 2020-12-15T01:01:08+01:00
 title: SOA (Start Of Authority)
+description: "Comprendre l'enregistrement Start Of Authority, présent obligatoirement à la racine de chaque zone DNS, et la façon dont happyDomain le gère pour vous."
 weight: 10
 aliases:
     records/SOA
 ---
 
-Le SOA est le premier enregistrement d'une zone.
+L'enregistrement **Start Of Authority** (SOA) est défini par la [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035). Il est obligatoire et unique : un seul SOA figure à l'apex (la racine) de chaque zone DNS. Sa présence indique que le serveur de noms fait autorité sur la zone. Il porte également les paramètres qui régissent la réplication de la zone entre serveurs et sa mise en cache par les résolveurs.
+
+## Les champs de l'enregistrement SOA
+
+Le SOA réunit sept valeurs :
+
+| Champ | Description |
+|---|---|
+| **MNAME** (serveur primaire) | Le nom du serveur de noms primaire (maître) de la zone. |
+| **RNAME** (responsable) | L'adresse de courriel du responsable de la zone, encodée à la manière du DNS : le `@` est remplacé par un point. Ainsi, `hostmaster.example.com.` désigne `hostmaster@example.com`. |
+| **Serial** | Un numéro de version de la zone. Il augmente à chaque modification, afin que les serveurs secondaires sachent qu'ils doivent transférer le nouveau contenu. |
+| **Refresh** | L'intervalle (en secondes) au bout duquel un serveur secondaire vérifie le numéro de série auprès du primaire. |
+| **Retry** | Le délai (en secondes) que respecte un secondaire avant de retenter une vérification ayant échoué. |
+| **Expire** | La durée (en secondes) pendant laquelle un secondaire continue de servir la zone lorsqu'il ne parvient pas à joindre le primaire, avant de considérer les données comme périmées. |
+| **Minimum** (cache négatif) | La durée pendant laquelle les résolveurs conservent en cache les réponses négatives (NXDOMAIN), selon la [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308). |
+
+## Le SOA dans happyDomain
+
+happyDomain ne présente pas le SOA comme un enregistrement à éditer champ par champ. La racine de votre zone est plutôt modélisée par un service **Origin**, qui regroupe le SOA et les serveurs de noms de la zone (les enregistrements NS). On retrouve donc le SOA à la racine du domaine, aux côtés de la liste des serveurs faisant autorité, et non dans un formulaire distinct.
+
+Le **numéro de série** est, dans la plupart des cas, géré automatiquement. Lors de la publication de vos modifications, de nombreux hébergeurs DNS gèrent eux-mêmes ce numéro. happyDomain détecte cette capacité, puis relit la zone après publication afin de refléter le numéro de série réellement attribué par l'hébergeur. Vous n'avez normalement pas à le renseigner à la main.
+
+{{% notice style="info" title="Ce que l'on peut modifier, et ce que l'on ne peut pas" %}}
+Le comportement exact dépend de votre hébergeur DNS. Certains exposent l'ensemble du SOA et laissent happyDomain en transmettre les valeurs ; d'autres gèrent eux-mêmes le numéro de série (et parfois les autres minuteries). Lorsque l'hébergeur prend en charge le numéro de série, la valeur affichée par happyDomain reflète simplement l'état publié et se met à jour automatiquement.
+{{% /notice %}}
+
+Pour en savoir plus sur la représentation de l'apex et des autres regroupements, consultez le chapitre {{< relref "../services" >}}.

content/reference/records/TXT.en.md

@@ -5,6 +5,40 @@ title: TXT
 weight: 20
 aliases:
     records/TXT
+description: "The TXT record attaches free-form text to a DNS name. Learn what it is used for and how happyDomain edits it through the Text Record service."
 ---
 
-Please, help us to write this Documentation screen
+A **TXT record** (defined in [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035)) attaches one or more free-form text strings to a name in your zone. It carries no predefined meaning of its own, which makes it one of the most versatile record types: any application is free to define its own convention for the text it stores there.
+
+## Common uses
+
+Because a TXT record can hold arbitrary text, it has become the carrier for many widespread conventions:
+
+- **Domain ownership and site verification** — a provider asks you to publish a token so it can confirm you control the domain.
+- **SPF** — declares which servers are allowed to send e-mail for your domain.
+- **DKIM** — publishes the public key used to sign your outgoing e-mail.
+- **DMARC** — sets the policy applied when SPF or DKIM checks fail.
+- Various other key or policy publications defined by different tools.
+
+For most of these purposes, happyDomain offers dedicated, higher-level **services** (SPF, DKIM, DMARC, site verification, and more) that are easier and safer to use than a raw TXT record: they guide you with the right fields and validate the syntax for you. Browse them in the {{< relref "/reference/services" >}} chapter, in particular the e-mail-related services. Prefer those services whenever one matches your need.
+
+{{% notice style="info" title="When a TXT record becomes a service" %}}
+When happyDomain reads your zone, it recognises TXT records that follow a known convention (SPF, DKIM, DMARC, …) and presents them as their dedicated service rather than as a plain Text Record. Only TXT records without a recognised prefix or syntax are shown as a raw **Text Record**.
+{{% /notice %}}
+
+## Editing a TXT record in happyDomain
+
+In the zone editor, a plain TXT record appears as a **Text Record** service. It is intentionally minimal: a single field holds the text content of the record.
+
+To work with one:
+
+1. Open the subdomain where the record should live (the apex of the zone, or any subdomain such as `www`).
+2. Add or open the **Text Record** service.
+3. Type the full text string in its only field.
+4. Adjust the **TTL** if needed, then publish your changes to apply them.
+
+The value you enter is stored verbatim. Editing it and publishing updates the corresponding TXT record on that subdomain.
+
+{{% notice style="note" title="Long strings" %}}
+A single text string inside a TXT record cannot exceed 255 bytes at the DNS protocol level. Longer values are automatically split into 255-byte chunks for you. You simply enter the complete string in happyDomain — no manual splitting is required.
+{{% /notice %}}

content/reference/records/TXT.fr.md

@@ -4,6 +4,40 @@ title: TXT
 weight: 20
 aliases:
     records/TXT
+description: "L'enregistrement TXT associe du texte libre à un nom DNS. Découvrez à quoi il sert et comment happyDomain l'édite grâce au service Enregistrement texte."
 ---
 
-Documentation à faire
+Un **enregistrement TXT** (défini par la [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035)) associe une ou plusieurs chaînes de texte libre à un nom de votre zone. Il ne porte aucune signification propre. C'est ce qui en fait l'un des types d'enregistrement les plus polyvalents : chaque application est libre de définir sa propre convention pour le texte qu'elle y dépose.
+
+## Usages courants
+
+Comme un enregistrement TXT peut contenir n'importe quel texte, il est devenu le support de nombreuses conventions répandues :
+
+- **Vérification de propriété ou de site** : un fournisseur demande de publier un jeton afin de confirmer que l'on contrôle bien le domaine.
+- **SPF** : déclare quels serveurs sont autorisés à envoyer du courrier pour le domaine.
+- **DKIM** : publie la clé publique servant à signer le courrier sortant.
+- **DMARC** : définit la politique à appliquer lorsqu'une vérification SPF ou DKIM échoue.
+- Diverses autres publications de clés ou de politiques propres à différents outils.
+
+Pour la plupart de ces usages, happyDomain propose des **services** dédiés, de plus haut niveau (SPF, DKIM, DMARC, vérification de site, etc.). Ils sont plus simples et plus sûrs à utiliser qu'un enregistrement TXT brut : ils guident la saisie avec les bons champs et en valident la syntaxe. On les retrouve dans le chapitre {{< relref "/reference/services" >}}, notamment parmi les services liés au courrier électronique. Mieux vaut recourir à ces services dès que l'un d'eux correspond au besoin.
+
+{{% notice style="info" title="Quand un enregistrement TXT devient un service" %}}
+Lorsque happyDomain lit votre zone, il reconnaît les enregistrements TXT qui suivent une convention connue (SPF, DKIM, DMARC, etc.) et les présente sous leur service dédié plutôt que comme un simple enregistrement texte. Seuls les enregistrements TXT sans préfixe ni syntaxe reconnus apparaissent comme un **Enregistrement texte** brut.
+{{% /notice %}}
+
+## Éditer un enregistrement TXT dans happyDomain
+
+Dans l'éditeur de zone, un enregistrement TXT ordinaire apparaît sous la forme d'un service **Enregistrement texte**. Il est volontairement minimal : un unique champ contient le contenu textuel de l'enregistrement.
+
+Pour le manipuler :
+
+1. Ouvrez le sous-domaine où l'enregistrement doit se trouver (la racine de la zone, ou un sous-domaine comme `www`).
+2. Ajoutez ou ouvrez le service **Enregistrement texte**.
+3. Saisissez la chaîne de texte complète dans son unique champ.
+4. Ajustez la **durée de vie** (TTL) si besoin, puis publiez vos modifications pour les appliquer.
+
+La valeur saisie est conservée telle quelle. La modifier puis publier met à jour l'enregistrement TXT correspondant sur ce sous-domaine.
+
+{{% notice style="note" title="Chaînes longues" %}}
+Au niveau du protocole DNS, une chaîne de texte ne peut excéder 255 octets dans un enregistrement TXT. Les valeurs plus longues sont automatiquement découpées en fragments de 255 octets. Il suffit de saisir la chaîne complète dans happyDomain : aucun découpage manuel n'est nécessaire.
+{{% /notice %}}