Les DNS ... forward vers ROOT ou FAI?

#1

Les DNS issoire-linux.org sont opérationnels.
Cependant dans ma conf. un truc me taquine l’esprit : les forwarders.

  1. Est-ce conseillé de placé ceux de son FAI (illyse) ou bosser avec les ROOT (et intermédiaires ?)?
  2. Si oui dans /etc/bind/named.conf.options ou dans le /etc/bind/named.conf.local ?
  3. Niveau firewall j’ai autorisé les DNS ROOT (ip sur wikipedia etc) mais visiblement la requête dns tape aussi dans d’autres DNS … ceux autoritaires pour le .fr etc … : normal !
    Donc sommes nous obligé d’ouvrir vers un “any” (tcp/udp) notre firewall en sortie de DMZ pour les forward DNS ?
#2

A priori, ton FAI a un engagement moral de faire des choses propres, notamment avec les DNS, donc tu peux tranquillement utiliser leurs DNS en tant que fordwarder. (pour l’endroit ou l’indiquer, j’aurais envie de dire, essaie, tu verra bien ou ça marche :))

Maintenant, si tu veux être parano ou tout simplement gérer toi même et voir comment ça marche, tu peux faire resolver complet. Dans ce cas, tu ne forward pas du tout. Et, de fait, ton serveur DNS est susceptible de causer à tous les autres de la planète en fonction des requêtes que tu fais, il te faut donc ouvrir les ports qui vont bien en sortie (53, obviously, en udp et tcp pour pouvoir gérer les grosses réponses, mais aussi probablement 443 si tu veux gérer le DoH qui se profile à l’horizon)

1 Like
#3

+1
Pas de forwarders, utilise ton serveur DNS pour faire des recherche dans la racine directement

#4

Mon FAI principal (j’ai deux accès) c’est iLLyse : j’ai confiance en eux. yep.
Mais bon la djayroma me dit " forward pas" et toi “forward” !!! argghghhghhghhghghh.
pouf plouf … :wink:

La je forward avec l’option “first”, DONC je dois ouvrir vers any : j’aime pas ça.
je vais probalement , faire forward only; et cloisonner aux dns illyse et FDN.
Car si on veut remonter aux ROOT ben les ip changent sans arrêts … ce que je trouve étrange d’ailleur ???
Car j’ai bien mis TOUTES les IP des DNS root mais ca tape toujours ailleurs …

#5

C’est quand même relativement rare de faire de la ségregation sortante à ce point là … J’en connais qui ont des plateformes depuis des 10aines d’années juste avec du filtrage entrant mais laissent tout sortir.

On te conseille de ne pas forward pour la bonne et simple raison que c’est infiniment plus secure et propre d’avoir ton propre resolver (sans compter que quand c’est pété, tu peux réparer toi même) … Mais si pour toi le filtrage de ton trafic sortant est plus important, tu va effectivement devoir te contenter de forward

#6

ouaih comme une box quoi … rien rentre mais “any” en sortie : c’est une stratégie de sécurité aussi.
j’en conviens.
J’ai préféré ça :

#7

Salut,

J’ai l’impression que tu mélange les serveurs faisant autorités sur des noms de domaine et serveurs résolveurs.
Les 2 roles peuvent être fait par les mêmes serveurs, mais en pratique il est plus saint de séparer les 2 (l’excellente littérature/blog de M. Bortzmeyer aka M. DNS t’expliquera plus bien plus simplement le pourquoi que moi):

  • un serveur faisant autorité est une source de vérité il ne demande rien à personne (excepté son maître si c’est un esclave) donc pas de forwarder, ni de serveurs racine à connaitre, on lui demande banane.com si il fait autorité dessus il réponds, sinon il réponds que ça n’existe pas (réponse vide NXDOMAIN, ce qui est normal en théorie on ne demandera jamais à un serveur autoritaire un domaine pour lequel il n’est pas déclaré faire autorité),
  • un résolveur lui ne sais rien sauf l’adresse des 13 “serveurs” racines (roots servers) et va par récursions trouver les réponses aux requêtes que l’on lui envois (et le mettre en cache suivant le TTL de celle ci ou jusqu’à qu’on le redémarre).

Je dit un de chaque mais rien n’empêche d’en avoir 2, 5, 100, visible ou non d’ailleurs (anycast), cela n’ajoute que la réplication pour des serveurs autoritaires et rien pour des résolveurs (qui sont autonome et n’on aucune raison de se connaitre ou de collaborer).

Hésite pas à poser des questions, je pense avoir assez paluché de DNS pour au moins pouvoir dégrossir la réponse et te pointer la prose de M. DNS ou consorts qui aidera bien.

HS: tes beaux schémas sont fait avec quel soft ?

#8

Avec libreOffice impress ! (import ) et surtout ce pack de clipart :

Note : non je ne pense pas mélanger les 2 concepts. En DMZ les 2 serveurs ne répondent qu’aux demandes sur les zones (domaines) que nous hebergeons.
Ils ne résolvent que pour les machines de la DMZ … et encore, car c’est le proxy Squid qui peut aller sur le web (et uniquement lui!)

Ensuite si j’avais du encore rajouter 2 DNS c (pour séparer le SOA et les forward en dmz …ouachhh) … je pense que déjà avec 5 , dont un master Hidden … on est pas mal non ?

#9

Pour le coup tu as bien de la résolution et de l’autoritaire sur le même serveur, ce qu’il faut éviter.
Monter un récursif interne séparé pour tes machine se résume à installer un résolveur sur une machine non exposé (par exemple avec bind9 sous Debian c’est facile c’est déjà bien configuré dès l’installation !), pour ton cas directement sur la machine du squid serai le plus logique (comme ça il peut écouter uniquement sur localhost).
Le seul vrai intérêt d’un hidden master (ou stealth server) est de servir de une source d’autorité hors ligne pour de la signature DNSSEC rien à voir avec le mix des fonctions qu’un serveur peu accomplir.

#10

“Monter un récursif interne séparé pour tes machine se résume à installer un résolveur sur une machine non exposé” , c’est exactement ce que font les SLAVE (primary et secondary) qui servent uniquement le LAN.

Je pense que mon schéma n’est pas bon quand je liste les fonctionnalités des “Public xxxx xxxx”.

Voila la conf d’un ns publique , les dns publiques ne resolvent en recursif que pour eux meme (localhost) et pour mes serveurs de DMZ (dmz10_nets):

Note : je ne suis pas un expert du DNS

/////////////////////////////////////////////
// ACL

//Reseau DMZ10
acl dmz10_nets { 10.10.10.0/24; };

//////////////////////////////////////////////
// OPTIONS
options {
directory “/var/cache/bind”;

    listen-on port 53 { 127.0.0.1; 10.10.10.11; };
    listen-on-v6 { none; };
    allow-query { any; };
    allow-recursion { localhost; dmz10_nets; };

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable
    // nameservers, you probably want to use them as forwarders.
    // Uncomment the following block, and insert the addresses replacing
    // the all-0's placeholder.

    forward first;
    forwarders {
            89.234.140.1;   #iLLyse 1 et 2
            89.234.140.2;
            80.67.169.12;   #FDN    1 et 2
            80.67.169.40;
    };
#11

Effectivement sur ton schéma les 4 slaves semble avoir les mêmes rôles.

Tu déclare une ACL mais tu ne l’utilise pas ? (il manque un morceau de la config je pense)

Pour le coup vu que tu utilise des forwarders, ton serveur est un stub resolver (résolveur minimum cf. https://www.bortzmeyer.org/8499.html) pas un résolveur complet (qui est capable de résolution par récursion), l’intérêt est juste la mise en cache des requêtes, cela peut d’autant plus être installé directement sur la même machine ton proxy Squid.

Pour ta structure DNS avec 5 machines j’aurai plutôt mis 1 master caché pour DNSSEC avec 2 esclaves publics et 2 résolveurs complets privées.
Si les domaines présent sur les serveurs esclaves publics sont critiques pour les usages locaux alors je pense que quelque chose à mal été conçu: soit utiliser un autre domaine non public (.local/.lan/…) soit utiliser des sous domaines différent publiquement et en privée avec chacun un duo maître-esclave chacun si besoin d’un usage à l’extérieur.
L’un demande autant de machine mais uniquement pour un usage interne (ou la mélanger résolveurs et autoritaires sur un même serveur n’est pas un soucis) ou l’autre demande 2 machines de plus.

Pas d’IPv6 ? C’est bien dommage les résolutions peuvent quand même fonctionner en IPv4 mais c’est (amha) plus propre d’avoir une réseau double pile IPv4/IPv6, perso je déploie d’abord de l’IPv6 puis si besoin de l’IPv4, et j’encourage et aide qui le souhaite à faire de même (tellement plus simple de pas avoir de NAT, et de pouvoir avoir un adressage à plat sur plusieurs réseaux).