Comment exploiter le DNS avec un primaire caché et des secondaires publics

Le serveur sur lequel vous éditez vos zones DNS n'a pas besoin de répondre à l'internet, et il ne devrait pas. Un primaire caché détient la copie autoritaire et reçoit les changements de vos équipes et de votre automatisation. Un ensemble de secondaires publics, qui sont les seuls serveurs listés dans vos enregistrements NS, répond à chaque requête. Le primaire peut être mis à jour, redémarré ou attaqué par personne, parce que personne à l'extérieur ne sait où il est. Cet article montre comment construire cela avec PowerDNS, les deux façons de faire passer les données du primaire aux secondaires, et les vérifications qui prouvent que le primaire est réellement caché.

La forme du design

• Un primaire sur un réseau privé, sans adresse publique, jamais nommé dans les enregistrements NS ou SOA. Il fait tourner l'API et l'interface web que votre équipe utilise.
• Deux secondaires publics ou plus sur des sites différents, idéalement sur des réseaux différents et chez des fournisseurs ou des plateformes différents, pour qu'aucune défaillance unique ne les emporte tous.
• Un chemin privé du primaire vers chaque secondaire, pour la réplication seulement.
• Les secondaires continuent de répondre si le primaire disparaît. Ils détiennent une copie complète, donc un primaire mort signifie « pas de changements pendant un moment », pas « domaine hors ligne ».

Il y a deux façons d'alimenter les secondaires. Les deux fonctionnent. Elles conviennent à des équipes différentes.

Option un : transferts de zone avec NOTIFY et TSIG

C'est du DNS standard et cela fonctionne avec n'importe quel mélange de serveurs DNS. Le primaire envoie un NOTIFY quand une zone change. Le secondaire vérifie le serial SOA et tire la zone par AXFR ou IXFR.

Sur le primaire, dans pdns.conf :

primary=yes
allow-axfr-ips=192.0.2.21/32,198.51.100.31/32
also-notify=192.0.2.21,198.51.100.31
only-notify=

Ces adresses sont les adresses privées des secondaires. Laisser only-notify vide et lister les cibles dans also-notify signifie que le NOTIFY ne va qu'à vos secondaires, jamais à ce qui se trouve par hasard dans les enregistrements NS.

Signez ensuite les transferts. Une liste d'IP autorisées fait confiance au réseau. Une clé TSIG prouve que la requête vient de votre secondaire.

# on the primary
pdnsutil generate-tsig-key xfr hmac-sha256
pdnsutil activate-tsig-key example.com xfr primary
pdnsutil list-tsig-keys      # copy the secret

# on each secondary (pdns.conf contains: secondary=yes)
pdnsutil import-tsig-key xfr hmac-sha256 '<secret>'
pdnsutil create-secondary-zone example.com 203.0.113.10
pdnsutil activate-tsig-key example.com xfr secondary

Où 203.0.113.10 est l'adresse privée du primaire. Pour éviter de créer chaque zone à la main sur chaque secondaire, PowerDNS peut les créer automatiquement quand le primaire envoie un NOTIFY pour une nouvelle zone. Configurez le primaire comme autoprimary sur chaque secondaire :

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

et définissez autosecondary=yes sur les secondaires.

Option deux : zones natives et réplication de base de données

PowerDNS peut aussi se passer entièrement des transferts DNS. Marquez les zones comme NATIVE, gardez-les dans un backend MySQL, MariaDB ou PostgreSQL, et laissez la base de données répliquer les données du primaire vers un réplica en lecture seule sur chaque secondaire.

pdnsutil set-kind example.com native

Sur chaque secondaire, PowerDNS lit depuis sa base réplica locale, configurée en lecture seule. La réplication ne passe que par le réseau privé.

Pourquoi choisir cette option :

• Chaque changement arrive sous forme de ligne, dès que la base de données l'expédie. Il n'y a pas d'incrément de serial à oublier ni de NOTIFY à perdre.
• L'AXFR peut être désactivé partout, donc il n'y a aucune interface de transfert à protéger.
• Les nouvelles zones apparaissent automatiquement sur les secondaires, parce qu'elles sont aussi des lignes.
• Les clés DNSSEC se répliquent avec les enregistrements, et chaque secondaire signe lui-même ses réponses.

Pourquoi pas : chaque secondaire doit faire tourner le même backend, et vous exploitez maintenant une réplication de base de données, qui a besoin de sa propre supervision du retard et des threads cassés. Si vos secondaires incluent le DNS d'un autre éditeur, les transferts sont la seule option.

Nous construisons les nôtres avec des zones natives et une réplication de base de données, parce que cela supprime complètement la surface de transfert et fait de la base de données la source de vérité unique et évidente.

DNSSEC avec un primaire caché

Les deux options prennent en charge la signature :

• Avec les transferts, signez sur le primaire. Les secondaires reçoivent la zone signée et la servent comme données présignées. PowerDNS marque la zone PRESIGNED automatiquement quand il transfère des enregistrements signés.
• Avec la réplication de base de données, les clés vivent dans la base, donc chaque secondaire signe en direct avec les mêmes clés et répond à l'identique.

Dans les deux cas, testez la validation depuis l'extérieur avec un resolver validant :

dig +dnssec example.com SOA @1.1.1.1
delv example.com SOA

delv doit rapporter « fully validated ».

Nommez les bons serveurs

L'intérêt d'un primaire caché disparaît si son nom fuit dans les enregistrements que le monde lit.

• Les enregistrements NS ne listent que les secondaires publics.
• Le champ SOA MNAME nomme un secondaire public, pas le primaire. Dans PowerDNS, default-soa-content le définit pour les nouvelles zones. Corrigez les zones existantes avec pdnsutil edit-zone.
• Le glue au registre ne pointe que vers les adresses publiques des secondaires.

Certains outils mettent par défaut le nom du serveur lui-même dans le SOA MNAME. Vérifiez-le sur chaque zone, pas seulement la première.

Verrouillez chaque rôle

• Placez devant chaque secondaire public un front-end qui comprend le DNS, comme dnsdist, pour refuser les types de requêtes qui permettent l'amplification, limiter le débit, et rejeter les requêtes pour des zones que vous ne servez pas.
• Sur les secondaires, refusez les NOTIFY venant d'ailleurs que du primaire, et refusez les requêtes AXFR venant de l'internet.

Vérifiez-le depuis l'extérieur

# NS and SOA name only public secondaries
dig +short NS example.com
dig +short SOA example.com

# Every secondary has the same serial
for ns in $(dig +short NS example.com); do
  printf '%s ' "$ns"; dig +short SOA example.com @"$ns" | awk '{print $3}'
done

# Transfers are refused from the internet
dig AXFR example.com @ns1.example.net

# The primary does not answer from outside (expect a timeout)
dig example.com SOA @<primary-address> +time=2 +tries=1

Exécutez la comparaison des serials en continu, pas une seule fois. Un secondaire qui a cessé de recevoir les mises à jour continue de répondre avec assurance avec des données anciennes. Le seul symptôme est un serial qui prend du retard. Alertez dessus, et alertez si le nom ou l'adresse du primaire apparaît un jour dans un enregistrement NS ou SOA.

En bref

Le primaire est l'endroit où vous éditez, les secondaires sont l'endroit où le monde interroge, et les deux ne se rencontrent que sur un réseau privé. Choisissez les transferts si vous mélangez des éditeurs DNS, la réplication de base de données si vous ne voulez aucune surface de transfert. Ne nommez que les secondaires, signez la zone, et surveillez les serials.

Nous construisons et exploitons des clusters PowerDNS de cette façon pour les clients qui veulent posséder leur DNS. Si vous en planifiez un, nous serons heureux de vous aider.

CTA

Parler à un ingénieur

Related

Sur le même sujet : DNS autoritaire et récursif sur PowerDNS · DNS autoritaire et reverse DNS, exploités comme une infrastructure