Gestion des DNS avec Unbound

Unbound est un résolveur DNS validant, récursif, avec mise en cache des informations. Il est conçu pour être rapide et léger et intègre des fonctionnalités modernes basées sur des normes ouvertes.

DynFi Firewall utilise Unbound comme service DNS par défaut depuis son lancement, c’est donc le service DNS qui est lancé par défaut lors d’une nouvelle installation.

Paramètres généraux

L’accès à la configuration du service se fait à partir de l’onglet Services >> Unbound DNS >> Général du menu de gauche. Vous trouverez ci-dessous les paramètres les plus importants de la section Général de ce menu.

Activer

Active le résolveur DNS Unbound

Port d’écoute

Port d’écoute : s’il est vide, la valeur par défaut (53) est utilisée.

Interfaces réseau

Adresses IP des interfaces utilisées pour répondre aux requêtes des clients. Si une interface possède à la fois des adresses IPv4 et IPv6, les deux sont utilisées. Les requêtes adressées à d’autres adresses IP d’interface non sélectionnées sont rejetées. Le comportement par défaut consiste à répondre aux requêtes sur toutes les adresses IPv4 et IPv6 disponibles.

DNSSECl

Activez DNSSEC pour utiliser des signatures numériques afin de valider les résultats des serveurs en amont. Permet d’éviter l’empoisonnement du cache.

DNS64

Activez DNS64 pour que les clients exclusivement IPv6 puissent atteindre les serveurs exclusivement IPv4. Si cette option est activée, Unbound synthétise les enregistrements AAAA pour les domaines qui n’ont que des enregistrements A. DNS64 nécessite NAT64 pour être utile, par exemple le plugin Tayga ou un service NAT64 tiers. Le préfixe DNS64 doit correspondre au préfixe IPv6 utilisé par le NAT64.

Enregistrement DHCP

IPv4 uniquement Si cette option est activée, les machines qui spécifient leur nom d’hôte lorsqu’elles demandent un bail DHCP seront enregistrées dans Unbound, afin que leur nom puisse être résolu.

La source de ces données est le fichier client-hostname du fichier dhcpd.leases.

Contournement de domaine DHCP

Lorsque les enregistrements ci-dessus ne doivent pas utiliser le même nom de domaine que celui configuré sur ce pare-feu, vous pouvez en spécifier un autre ici.

Config. statiques DHCP

Enregistre les entrées dhcpd statiques pour que les clients puissent les résoudre. Pris en charge sur IPv4 et IPv6.

Lien-local IPv6

Enregistre les adresses locales de lien pour IPv6.

Enregistr. du système A/AAAA

Si cette option est activée, aucun enregistrement A/AAAA ne sera généré pour les interfaces d’écoute configurées. Cela signifie également qu’aucun enregistrement PTR ne sera créé. Si vous le souhaitez, vous pouvez ajouter manuellement des enregistrements A/AAAA pour les interfaces d’écoute configurées. Utilisez ceci pour pour contrôler quelles adresses IP d’interface sont mappées au nom d’hôte/domaine du système, ainsi que pour restreindre la quantité d’informations exposées dans les noms d’hôte/domaine du système.

Support des commentaires TXT

Permet d’enregistrer des descriptions comme commentaires pour les entrées d’hôtes statiques dhcp.

Cache DNS

Si cette option est définie, le cache DNS sera vidé à chaque recharge du démon.

Type de Zone locale

Le type de zone locale utilisé pour le domaine du système. Les descriptions des types sont disponibles sous “local-zone :” dans le fichier unbound.conf(5) dans la page de manuel de unbound.conf(5). La valeur par défaut est “transparent”.

Note

Pour que le client puisse interroger unbound, il faut qu’une ACL soit créée dans Services >> Unbound DNS >> Listes d'accès. Les interfaces configurées obtiennent une ACL automatiquement. Si l’adresse du client n’est pas dans l’un des réseaux prédéfinis, veuillez en ajouter un manuellement.

Surcharges

Dans la section Surcharges, vous pouvez créer des entrées d’hôte distinctes et spécifier si les requêtes pour un domaine spécifique doivent être transférées à un serveur distinct.

Paramètres de contournements d’hôtes

Les contournements d’hôtes peuvent être utilisées pour modifier les résultats DNS des requêtes des clients ou pour ajouter des enregistrements DNS personnalisés. Les enregistrements PTR sont également générés afin de prendre en charge les recherches DNS inversées.

Ils sont générés de la manière suivante :

• Si Enregistrements système A/AAAA dans Général est décoché, un enregistrement PTR est créé pour l’interface primaire.

• Chaque entrée de contournement d’hôte qui n’inclut pas de joker pour un hôte, se voit attribuer un enregistrement PTR.

• Si une entrée de contournement d’hôte inclut un caractère générique pour un hôte, le premier alias défini se voit attribuer un enregistrement PTR.

• Tous les autres alias n’obtiennent pas d’enregistrement PTR.

Hôte	Nom de l’hôte sans la partie domaine. Utilisez “*” pour créer une entrée joker.
Domaine	Domaine de l’hôte (tel que exemple.com)
Type	Type d’enregistrement, A ou AAA (adresse IPv4 ou IPv6), MX pour définir un échange de courrier.
Adresse	IP de l’hôte
Description	Description lisible par l’utilisateur, uniquement à des fins d’information.
Alias	Copies des données ci-dessus pour différents hôtes

Alias

Vous pouvez créer d’autres noms pour un hôte. Par exemple, si vous avez un serveur web avec plusieurs hôtes virtuels, procédez comme suit :

1. Créez une entrée “Contournement d’hôte” avec une des IP et le nom de l’hôte

2. Cliquez sur le “+” pour ajouter une entrée “Alias”

3. Utilisez la première entrée créée en tant que “Hôte cible”.

4. Saisissez le nouveau nom d’hôte et domaine

Important

Vous devez d’abord sélectionner l’hôte dans la liste du haut pour permettre l’affichage des alias associés dans la liste du bas.

Paramètres de contournement d’un domaine

Les dérogations de domaine peuvent être utilisées pour transférer des requêtes pour des domaines spécifiques (et les sous-domaines suivants) vers des serveurs DNS locaux ou distants.

Important

Contournement de domaine a été remplacé par forwarding. La redirection de requêtes vous permet également de rediriger toutes les requêtes.

Domaine	Domaine à remplacer
Adresse IP	Adresse IP du serveur DNS faisant autorité pour ce domaine
Description	Description lisible par l’utilisateur, uniquement à des fins d’information.

Paramètres Avancés

Bien que les paramètres par défaut soient corrects pour la plupart des configurations, certains nécessitent plus de réglages ou des options spécifiques. Certains de ces paramètres sont activés et reçoivent une valeur par défaut d’Unbound, référez-vous à unbound.conf(5) pour la liste des valeurs par défaut.

:: Hide Identity ::

Si cette option est activée, les requêtes id.server et hostname.bind sont refusées.

:: Hide Version ::

Si cette option est activée, les requêtes version.server et version.bind sont refusées.

:: Prefetch Support ::

Les éléments du cache de messages sont préemptés avant d’expirer afin de maintenir le cache à jour. Lorsqu’elle est activée, cette option peut entraîner une augmentation d’environ 10 % du trafic et de la charge DNS sur le serveur, mais les éléments fréquemment demandés n’expireront pas du cache.

:: Prefetch DNS Key Support ::

Les clés DNSKEY sont récupérées plus tôt dans le processus de validation lorsqu’un délégataire de signataire est rencontré. Cela permet de réduire la latence des requêtes mais utilise un peu plus de CPU.

:: Durcissement des données DNSSEC ::

Les données DNSSEC sont requises pour les zones de confiance ancrées. Si ces données sont absentes, la zone devient incorrecte. Si cette fonction est désactivée et qu’aucune donnée DNSSEC n’est reçue, la zone n’est pas sécurisée.

:: Servir les réponses expirées ::

Servir les réponses expirées du cache avec un TTL de 0 sans attendre la fin de la résolution. Lorsque cette option est cochée, plusieurs options permettant de personnaliser le comportement des réponses expirées s’affichent.

:: Valeur TTL de la réponse à l’enregistrement expiré ::

Valeur TTL à utiliser pour répondre à des données expirées. Si le “Délai de réponse expirée du client” est également utilisé, il est recommandé d’utiliser 30 comme valeur par défaut, conformément à la RFC 8767. Applicable uniquement lorsque l’option “Servir les réponses expirées” est cochée.

:: TTL pour les réponses expirées ::

Limite la diffusion des réponses expirées au nombre de secondes configuré après l’expiration. La valeur 0 désactive la limite. Une valeur suggérée selon RFC 8767 est comprise entre 86400 (1 jour) et 259200 (3 jours). Uniquement applicable lorsque l’option “Servir les réponses expirées” est cochée.

:: Réinitialiser le TTL des enregistrement expirés ::

Défini le TTL des enregistrements expirés à la valeur “TTL pour les réponses expirées” après l’échec d’une tentative de récupération de l’enregistrement auprès d’un serveur en amont. Cela permet de s’assurer que les enregistrements expirés seront servis tant qu’ils y a des requêtes les concernant. Applicable uniquement lorsque l’option “Servir les réponses expirées” est cochée.

:: Délai de réponse expirée du client ::

Délai en millisecondes avant de répondre au client avec des données expirées. Cela permet essentiellement d’adopter le comportement “serve stable” spécifié dans la RFC 8767 qui tente d’abord de résoudre le problème avant de répondre immédiatement avec des données périmées. La valeur recommandée par la RFC 8767 est 1800. La valeur 0 désactive ce comportement. Applicable uniquement lorsque l’option “SServir les réponses expirées” est cochée.

:: Minimisation stricte du QNAME ::

Envoyer un minimum d’informations aux serveurs en amont pour améliorer la confidentialité. Ne pas se rabattre sur l’envoi du QNAME complet aux serveurs de noms potentiellement défaillants. De nombreux domaines ne pourront pas être résolus lorsque cette option est activée. N’utilisez cette option que si vous savez ce que vous faites.

:: Extended Statistics ::

Si cette option est activée, les statistiques étendues sont imprimées dans syslog.

:: Log Queries ::

Si cette option est activée, une ligne par requête est imprimée dans le journal, avec l’horodatage et l’adresse IP, le nom, le type et la classe. Notez que l’impression de ces lignes prend du temps, ce qui ralentit (considérablement) le serveur. Les caractères impairs (non imprimables) dans les noms sont imprimés sous la forme de “?”.

:: Réponses au journal ::

Si cette option est activée, une ligne est imprimée pour chaque réponse au journal, avec l’horodatage du journal et l’adresse IP, le nom, le type, la classe, le code de retour, le temps de résolution, si la réponse provient du cache et la taille de la réponse. Notez que l’impression de ces lignes prend du temps, ce qui ralentit (considérablement) le serveur. Les caractères impairs (non imprimables) des noms sont imprimés sous la forme de “?”.

:: Marquer les requêtes et les réponses ::

Si cette option est activée, le mot ‘query :’ et ‘reply :’ avec les requêtes et les réponses enregistrées. Cela facilite le filtrage des journaux.

:: Niveau de verbosité du journal ::

Sélectionnez la verbosité du journal. Le niveau 0 signifie qu’il n’y a pas de verbosité, mais uniquement des erreurs. Le niveau 1 donne des informations opérationnelles. Le niveau 2 donne des informations détaillées. Le niveau 3 donne des informations au niveau de la requête, sortie par requête. Le niveau 4 fournit des informations au niveau de l’algorithme. Le niveau 5 enregistre l’identification du client pour les erreurs de cache. La valeur par défaut est le niveau 1.

:: Domaines privés ::

Liste des domaines à marquer comme privés. Ces domaines et tous leurs sous-domaines sont autorisés à contenir des adresses privées.

:: Réseaux de protection contre le rebind ::

Il s’agit d’adresses de votre réseau privé, qui ne sont pas autorisées à être renvoyées pour des noms Internet publics. Toute occurrence de ces adresses est supprimée des réponses DNS. En outre, le validateur DNSSEC peut marquer les réponses comme fausses. Cela permet de se protéger contre ce que l’on appelle le rebind DNS. (Uniquement applicable lorsque la vérification du rebind DNS est activée dans Administration)

:: Domaines non sécurisés ::

Liste des domaines à marquer comme non sécurisés. La chaîne de confiance DNSSEC est ignorée pour le nom de domaine.

:: Taille du cache de messages ::

Taille du cache de messages. Le cache de messages stocke les codes r du DNS et les statuts de validation. Le cache RRSet (qui contient les données RR réelles) sera automatiquement réglé sur le double de cette quantité. Les données valides sont des octets simples, éventuellement complétés par ‘k’, ‘m’ ou ‘g’ pour kilo-octets, mégaoctets ou gigaoctets respectivement.

:: RRset Cache Size ::

Taille du cache RRset. Contient les données RR actuelles. Les données valables sont des octets simples, éventuellement complétés par “k”, “m” ou “g” pour les kilo-octets, les méga-octets ou les giga-octets respectivement. Automatiquement fixé à deux fois la taille du cache des messages lorsqu’il est vide, mais peut être modifiée manuellement.

:: Tampons TCP sortants ::

Nombre de tampons TCP sortants à allouer par thread. Si 0 est sélectionné, aucune requête TCP n’est effectuée vers les serveurs faisant autorité.

:: Tampons TCP entrants ::

Nombre de tampons TCP entrants à allouer par thread. Si la valeur 0 est sélectionnée, aucune requête TCP provenant de clients n’est acceptée.

:: Nombre de requêtes par thread ::

Nombre de requêtes que chaque thread traitera simultanément. Si d’autres requêtes arrivent et doivent être traitées, et qu’aucune requête ne peut être éliminée (voir “Délai d’élimination des requêtes”), ces requêtes sont abandonnées, ces requêtes sont abandonnées. Cela oblige le client à renvoyer la requête après un délai d’attente, délai, ce qui laisse au serveur le temps de travailler sur les requêtes existantes.

:: Outgoing Range ::

Nombre de ports à ouvrir. Ce nombre de descripteurs de fichiers peut être ouvert par thread. Les nombres plus élevés nécessitent des ressources supplémentaires de la part du système d’exploitation. Pour des raisons de performance, il est préférable d’utiliser une valeur très élevée. A titre de référence, on utilise généralement le double du nombre de requêtes par thread.

:: Délai d’attente Jostle ::

Ce délai d’attente est utilisé lorsque le serveur est très occupé. Il est fixé à une valeur qui se traduit généralement par un aller-retour vers les serveurs d’autorité. Si le nombre de requêtes est trop élevé, 50 % d’entre elles peuvent être exécutées jusqu’à leur terme, et les 50 % restants sont remplacés par la nouvelle requête entrante s’ils ont déjà dépassé le temps alloué. plus de temps que prévu. Cela permet de se prémunir contre les dénis de service dus à par des requêtes lentes ou des taux de requêtes élevés.

:: TTL max. pour les RRsets et les messages ::

Configurez un Time to live maximum en secondes pour les RRsets et les messages dans le cache. Lorsque le TTL interne expire, l’élément du cache est périmé. Cette valeur peut être configurée pour forcer le résolveur à demander des données plus souvent et à ne pas faire confiance aux valeurs TTL (très élevées).

:: TTL min. pour les RRsets et les messages ::

Configurez un TTL minimum en secondes pour les RRsets et les messages dans le cache. Si la valeur minimale est activée, les données sont mises en cache plus longtemps que le propriétaire du domaine ne l’avait prévu, et donc moins de requêtes sont effectuées pour rechercher les données. La valeur 0 garantit que les données dans le cache sont conformes à l’intention du propriétaire du domaine. Des valeurs élevées peuvent entraîner des problèmes, car les données du cache peuvent ne plus correspondre aux données réelles.

:: TTL pour les entrées du cache de l’hôte ::

Durée de vie en secondes pour les entrées du cache de l’hôte. Le cache de l’hôte contient des informations sur le temps d’aller-retour, la boiterie et le support EDNS.

:: Keep probing down hosts ::

Continuez à sonder les hôtes qui sont en panne dans le cache d’hôte de l’infrastructure. Les hôtes en panne sont sondés environ toutes les 120 secondes avec un backoff exponentiel. Si les hôtes ne répondent pas dans ce laps de temps, ils sont marqués comme étant hors service pour la durée du TTL du cache de l’hôte. Ce paramètre peut être utilisé en conjonction avec “TTL pour les entrées du cache de l’hôte” afin d’augmenter la réactivité en cas de rebond de la connectivité Internet.

:: Nombre d’hôtes à mettre en cache ::

Nombre d’hôtes pour lesquels les informations sont mises en cache.

:: Unwanted Reply Threshold ::

Si cette option est activée, un nombre total de réponses non désirées est comptabilisé dans chaque thread. Lorsqu’il atteint le seuil, une action défensive est prise et un avertissement est imprimé dans le fichier journal. un avertissement est imprimé dans le fichier journal. Cette action défensive consiste à vider le RRSet et les caches de messages, ce qui devrait permettre d’éliminer tout poison.

Listes d’accès

Les listes d’accès définissent quels clients peuvent interroger notre résolveur DNS. Les enregistrements pour les interfaces assignées seront automatiquement créés et sont affichés dans l’aperçu. Vous pouvez également définir des politiques personnalisées, qui appliquent une action à des réseaux prédéfinis.

Note

L’action peut être définie dans la liste ci-dessous. La correspondance de bloc de réseau la plus spécifique est utilisée, si aucune correspondance n’est utilisée. L’ordre des instructions de contrôle d’accès n’a donc pas d’importance.

Actions

Deny	Cette action bloque les requêtes provenant d’hôtes situés dans les réseaux définis.
Refuse	Cette action bloque également les requêtes des hôtes au sein des réseaux définis, mais envoie un message d’erreur DNS rcode REFUSED au client.
Allow	Cette action autorise les requêtes provenant d’hôtes situés dans les réseaux définis.
Allow Snoop	Cette action autorise l’accès récursif et non récursif à partir d’hôtes au sein des réseaux définis. Elle est utilisée pour le snooping de cache et ne devrait être configuré que pour votre hôte administratif.
Deny Non-local	Autorise uniquement les requêtes de données locales faisant autorité provenant d’hôtes situés dans les réseaux définis. Les messages non autorisés sont abandonnés.
Refuse Non-local	Autorise uniquement les requêtes de données locales faisant autorité provenant d’hôtes situés dans lesréseaux définis. Renvoie un message d’erreur DNS rcode REFUSED au client pour les messages qui ne sont pas autorisés.

Listes de filtrage

Reportez-vous à la section Filtrer_les_requetes_DNS_avec_Unbound afin de comprendre comment les listes de filtrage RPZ fonctionnent avec DynFi Firewall.

Redirection des requêtes

La section Query Forwarding permet d’entrer des serveurs de noms vers lesquels transférer les requêtes. Il est nécessaire que les serveurs de noms spécifiés ici soient en mesure de gérer des requêtes DNS récursives. Dans cette section vous pouvez spécifier des serveurs de noms vers lesquels transférer vos requêtes pour des domaines spécifiques (par exemple à la demande de vos clients pour des domaines spécifiques).

Item

Description

Utiliser les serveurs de noms du système

Les serveurs de noms du système configurés seront utilisés pour transférer les requêtes. Cela remplacera toute entrée faite dans la grille de redirection personnalisée, sauf pour les entrées ciblant un domaine spécifique. Si aucun serveur de noms système n’existe, ajoutez-en un dans Système >> Paramètres >> Général Si vous attendez un serveur DNS depuis votre WAN et qu’il n’est pas listé, assurez-vous que vous avez activé la case dans “Options du serveur DNS” “Autoriser le remplacement des serveurs DNS par ceux obtenus par DHCP/PPP sur le WAN”.

Note

Gardez à l’esprit que si la case “Utiliser les serveurs de noms du système” est cochée, les serveurs de noms du système seront systématiquement utilisés. Toutes les entrée catch-all dans le transfert de requêtes et le DNS-over-TLS, seront systématiquement redirigés vers ces serveurs DNS.

---

Item	Description
Activé	Activer la redirection des requêtes pour ce domaine.
Domaine	Domaine de l’hôte. Toutes les requêtes pour ce domaine seront transférées vers le serveur de noms spécifié dans “Server IP”. Laisser vide pour capturer toutes les requêtes et les toutes les requêtes et les transmettre au serveur de noms.
Serveur IP	Adresse du serveur DNS à utiliser pour la résolution récursive.
Port	Spécifiez le port utilisé par le serveur DNS. La valeur par défaut est le port 53.

Warning

Attention à l’activation du Transfert de requêtes avec DNSSEC : aucune validation DNSSEC ne sera effectuée localement pour les transmissions vers un domaine spécifique. En effet, le serveur en amont peut ne pas supporter DNSSEC, ses réponses ne parviendront donc pas au client car aucune validation DNSSEC n’aura pu être effectuée.

DNS sur TLS

DNS over TLS utilise la même logique que Query Forwarding, sauf qu’il utilise TLS pour le transport.

Note

Attention aux interactions entre Transfert de requêtes et DNS over TLS. Une entrée catch-all spécifiée dans les deux sections sera considérée comme une zone dupliquée. Dans ce cas, DNS over TLS sera préféré.

---

Item	Description
Activé	Active le DNS over TLS pour ce domaine.
Domaine	Domaine de l’hôte. Toutes les requêtes pour ce domaine seront transmises au serveur de noms spécifié dans “Serveur IP”. Laisser vide pour capturer toutes les requêtes et les transmettre au serveur de noms.
Serveur IP	Adresse du serveur DNS à utiliser pour la résolution récursive.
Port	Spécifiez le port utilisé par le serveur DNS. Entrez toujours le port 853 ici, à moins d’avoir des instructions spécifiques de votre fournisseur de DNS, ou dans le cadre de l’utilisation d’un tunnel SSH.
Vérifier la NC	Nom à utiliser pour la vérification du certificat, par exemple “445b9e.dns.nextdns.io”. Utilisé par Unbound pour vérifier les certificats d’authentification TLS. Il est fortement déconseillé d’omettre ce champ car les attaques de type “man-in-the-middle” seront toujours possibles.

Note

Pour garantir un environnement sain, il est conseillé de bloquer tout le trafic DNS sortant sur le port 53 à l’aide d’une règle de pare-feu lors de l’utilisation de DNS via TLS. Parallèlement mettez en place une règle de redirection NAT pour les requêtes vers le port UDP 53 à destination de 127.0.0.1:53 (le service Unbound local) ceci afin de forcer ces requêtes à passer par TLS.

Résolveurs publics

Fournisseur	Adresse IP du serveur	Port	CN de vérification
Cloudflare	1.1.1.1 ; 1.0.0.1	853	cloudflare-dns.com
	2606:4700:4700::1111 ; 2606:4700:4700::1001
Google	8.8.8.8 ; 8.8.4.4	853	dns.google
	2001:4860:4860::8888 ; 2001:4860:4860::8844
Quad9	9.9.9.9 ; 149.112.112.112	853	dns.quad9.net
	2620:fe::fe ; 2620:fe::fe