[TUTO] DNS Server

[Jeff777]

il y a 3 minutes, Mic13710 a dit :

Ce qui signifie : rien dans les règles de mise à jour 😊

Oui pardon. Mais je ne comprends pas vraiment la différence entre transfert de zone et mise à jour de zone !

il y a 10 minutes, Mic13710 a dit :

que ton problème vienne de là

Tu veux parler du pb de @Brenac. Justement j'utilise les clés et je n'ai effectivement pas de warning.

[Mic13710]

Le transfert c'est entre la ou les zones slaves et la zone master.  La mise à jour concerne les enregistrements de la zone.

il y a 15 minutes, Jeff777 a dit :

Tu veux parler du pb de @Brenac. Justement j'utilise les clés et je n'ai effectivement pas de warning.

Oui, désolé, c'est effectivement à Brennac que mon message aurait dû s'adresser.

[Jeff777]

il y a 23 minutes, Mic13710 a dit :

Le transfert c'est entre la ou les zones slaves et la zone master.

ça d'accord.

il y a 23 minutes, Mic13710 a dit :

La mise à jour concerne les enregistrements de la zone.

mais là je ne comprends pas bien. Si l'option 4 n'est pas cochée il n'y a pas de mise à jour des DNS slaves dans le cas par exemple de l'ajout d'une ressource même si ceux-ci sont notifiés par le paragraphe 3 ?

Modifié le 10 décembre 2019 par Jeff777

[Mic13710]

Ce n'est pas très clair je te l'accorde et je suis incapable de t'expliquer la différence entre ces deux notions. Il faudrait qu'un spécialiste nous éclaire sur ces points.

[PiwiLAbruti]

Si l’option 4 (Limiter la mise à jour de zones) n’est pas cochée, il n’y a aucune restriction IP pour les mises à jour des clients.

[Jeff777]

Bonjour @PiwiLAbruti

D'accord la dessus mais ce que je ne comprends pas c'est la différence entre :

"transfert de zone" et "mise à jour de zone"

"zone slave" et "client"

"zone master" et "zone principale"

pour moi les $ 1 et 4 veulent dire la même chose ce qui est certainement faux. La différence est certainement dans la signification exacte des termes précédents.

zone master ou principale c'est la même chose. slave et client je ne vois pas trop la subtilité, il n'y a vraiment que transfert de zone et mise à jour qui peuvent sembler différentes. Un transfert concerne l'ensemble des enregistrements et la mise à jour ne concerne que les enregistrements modifiés. 

Bref je ne m'explique pas trop la finalité.

[PiwiLAbruti]

Les explications de l'interface me paraissent pourtant suffisamment explicites. Je ne peux que paraphraser ce qui est déjà expliqué :

Il y a 14 heures, Jeff777 a dit :

"transfert de zone" et "mise à jour de zone"

Le transfert de zone sert à définir quels clients peuvent demander le contenu intégral de la zone principale (ou master) pour en faire une copie dans une zone esclave (ou slave).

La mise à jour de zone sert à définir les zones esclaves qui peuvent se mettre à jour depuis la zone principale. Sans ce réglage, la zone esclave ne peut pas demander à se mettre à jour avec les modifications faites à la zone principale.

Il y a 14 heures, Jeff777 a dit :

"zone slave" et "client"

Un client est un serveur DNS qui va communiquer avec le serveur DNS principal.

Une zone esclave (ou slave) est une copie de la zone master du serveur DNS principal. Elle est créée sur le client.

Il y a 14 heures, Jeff777 a dit :

"zone master" et "zone principale"

C'est la même chose.

[Jeff777]

Merci @PiwiLAbruti

OK pour ces explications mais je ne comprends toujours pas la finalité du paragraphe 4.

Une fois qu'un transfert de zone a été autorisé pourquoi en limiter la mise à jour à certains clients.Il y a certainement des applications mais ça m'échappent.

En tout cas merci d'avoir passé du temps à éclairer ma lanterne !

 

[PiwiLAbruti]

Par exemple, stopper les mises à jour peut te permettre de faire des tests sur ton DNS principal sans impacter les clients qui utilisent les DNS esclaves.

C’est très pratique et pour passer en production il suffit de rétablir les mises à jour vers les DNS esclaves.

Il y a probablement d’autres cas d’utilisation.

[.Shad.]

@PiwiLAbruti super explications merci !

[Jeff777]

Il y a 9 heures, PiwiLAbruti a dit :

Par exemple, stopper les mises à jour peut te permettre de faire des tests sur ton DNS principal sans impacter les clients qui utilisent les DNS esclaves.

Ah oui je comprends. Mais dans ce cas il faut interdire au client l'accès au DNS principal tout en autorisant l'accès à ton IP de test (avec le pare-feu ?).

Merci

[Jeff777]

Je reviens ici car après avoir fait plusieurs tests je ne suis finalement pas convaincu par l'explication de @PiwiLAbruti Désolé 😐

Nous avons les deux options suivantes dans les paramètres de zone :

1/Limiter le transfert de zone

4/ limiter la mise à jour de zone

Résultat de mes tests

a: Si 1 est décochée le transfert s'effectue dans tous les cas ( je change juste un enregistrement TXT dans la zone). Donc option par défaut : transfert autorisé du master vers le slave à l'issue de la fréquence d'actualisation (que j'ai fixée à 600s pour les besoins des tests)

b: Si 1 est coché et que le slave n'est pas autorisé (soit par clé soit par IP) alors le slave affiche : Further AXFR attemps for this zone have been suspended (échec)

c : Si 1 est coché et que le slave est autorisé (soit par clé soit par IP) alors le transfert s'effectue dans les même conditions que a:

L'option 4 n'a aucune incidence sur ces résultats...............Alors à quoi sert t'elle ?

 

Et bien j'ai fini par trouvé ici : https://www.zytrax.com/books/dns/ch7/xfer.html#allow-update

il faut comparer les commandes allow-update et allow-transfer de bind et cela donne une piste.

D'après ce site allow-update (donc je pense l'option 4) sert à mettre à jour la zone master dans le cas d'un DDNS et non la zone slave. C'est à dire que l'enregistrement ndd A IP (par exemple mais pas que) est mise à jour en dynamique dans la zone master par le client (dyndns ou autre... à voir).

Si l'option 4 est décochée, par défaut il n'y a pas de mise à jour de la part d'un client ce qui donc n'autorise pas les IP non fixes.

 

Ce serait bien d'avoir confirmation de ce que je raconte de la part d'un membre qui est en IP dynamique et utilise une zone publique 😊

En tout cas, comme j'ai une IP fixe je peux décocher cet option.

Si je ne me trompe pas cela pourrait signifier que contrairement à ce que l'on dit en permanence ici : on pourrait avoir une zone publique sur DNS serveur même avec une adresse IP dynamique.

 

Modifié le 14 décembre 2019 par Jeff777

[Jeff777]

Bonjour,

Pas d'avis.......😞

[Jeff777]

Bonjour,

Pas d'avis.......😞

Je viens de parcourir ce post à la recherche de l'option 4. En page 3 (16 mai 2017) on peut remarquer qu'elle n'existait pas !

Modifié le 15 décembre 2019 par Jeff777

[Mic13710]

C'est une bonne piste mais je ne peux pas tester, j'ai une IP fixe.

Comme on a toujours dit que la zone publique n'est possible qu'avec une IP fixe, il n'y aura vraisemblablement personne qui l'a mise en place avec une IP dynamique. Peu d'espoir de vérifier ce que tu dis. D'autant que ça ne peut pas fonctionner.

Et ça se comprend car à mon humble avis, un serveur DNS qui change constamment d'IP perd en crédibilité. Et puis surtout, la diffusion d'une nouvelle IP pour un serveur DNS donné prend du temps (24 à 48h). Entre temps, l'IP aura encore changée et ce sera la course à l’échalote sans fin entre les différents serveurs. Totalement inexploitable au quotidien.

Par contre, si une IP fixe vient à changer (le cas récemment pour Free ou plus simplement après un changement d'opérateur), cette option, si elle fonctionne, prendrait tout son sens. Malheureusement, même si elle était cochée chez moi, elle ne comportait pas l'adresse du serveur secondaire et il n'a donc pas été modifié. Il a fallu le faire à la mano.

[Jeff777]

il y a 31 minutes, Mic13710 a dit :

Et ça se comprend car à mon humble avis, un serveur DNS qui change constamment d'IP perd en crédibilité. Et puis surtout, la diffusion d'une nouvelle IP pour un serveur DNS donné prend du temps (24 à 48h). Entre temps, l'IP aura encore changé et ce sera la course à l’échalote sans fin entre les différents serveurs. Totalement inexploitable au quotidien.

Merci de ta réponse Mic. Tu as raison ce ne serait pas exploitable.  L'idée d'une IP fixe qui change peut-être..... à creuser.

En tout cas dans l'Aide du NAS l'option 4 est beaucoup plus claire !

 

ça voudrait dire qu'à part en local on ne peut modifier la zone de l'extérieur que si notre IP est spécifiée dans la règle ?

 

 

 

 

Modifié le 15 décembre 2019 par Jeff777

[Mic13710]

On pourrait effectivement l'interprété comme cela. Si c'est le cas, je n'en vois pas l'intérêt, du moins pour moi. Si je suis amené à faire des interventions sur mon serveur DNS à partir de l'extérieur, je me connecte en VPN qui est mon seul moyen d'accès à DSM à partir du WAN. Hors VPN, les interventions à partir d'une adresse publique sont juste impossibles. S'il s'avère que ce paramétrage sert à ça, il est pour moi d'aucune utilité, mais assure une certaine sécurité car avec une liste à zéro, aucune IP publique ne peut intervenir. C'est plutôt rassurant.

[mik@el]

Bonjour,

 

Avant d'essayer de me lancer dans la compréhension qui m'a l'air un peu ardu du tutoriel, j'aimerais savoir si cela peut être une solution au problème du DNS reverse pour ceux qui veulent avoir leur serveur de mail sur le NAS ?

Je précise que j'ai déjà fait la partie "simple" du tuto, nécessaire à la mise en place du serveur de mail.

Je reste bloqué avec un problème avec Bouygues au niveau du reverse DNS, et je crois comprendre que même avec Free, c'est pas gagné pour avoir un dns reverse avec la fibre.

 

Modifié le 4 janvier 2020 par mik@el

[Titom7779]

Bonjour à tous,

Merci pour ce tuto que j'ai déroulé a la lettre jusqu'au DNS LAN inclus. Je rencontre un soucis de cohabitation entre mon DNS LAN et celui créé par le contrôleur de domaine issus de Directory Serveur.

J'ai créé une vue pour le domaine contrôleur, mais je suis contraint à mettre cette vue en première position pour que mes ordis le trouvent, ce qui rend du même coup la vue du DNS LAN secondaire. Un trace route sur un domaine me confirme alors que la résolution du nom se fait toujours hors LAN.

Quelle est la solution pour régler cela sur une même machine ?

Merci d'avance.

Modifié le 10 janvier 2020 par Titom7779

[_DR64_]

Bonjour @Fenrir merci à toi pour cet excellent tuto! Je m'en suis servi avec mon RT2600ac car je l'ai branché et derrière ma LiveBox 4 et du coup le loopback de la box ne fonctionnait plus avec mon ndd... !
Excellent ! Je t'aime ! Mdr 🤩

[Kylvan]

Bonjour @Fenrir

Je souhaité savoir comment utiliser le DoH avec son propre serveur DNS en cache (sans redirections) , via le paquet Synology, en parallèle du tutoriel fourni par unPixel.

Il n'y a pas besoin de créer de zone si on n'héberge rien chez nous, le cache suffit non ?

En vous remerciant d'avance !

Modifié le 11 février 2020 par Kylvan

[Kylvan]

C'est pas possible en passant par le paquet dns Syno, dommage:
 

3. Configurer le protocole DoH

Vous pouvez activer DoH (DNS sur HTTPS) pour vous assurer que les requêtes DNS sont envoyées via une connexion chiffrée afin d'améliorer la sécurité et la confidentialité. Pour configurer DoH pour votre Synology Router, vous pouvez effectuer les opérations suivantes :

1. Accédez à Centre réseau > Réseau local > Général > Options avancées.
2. Cochez la case Activer DoH (DNS sur HTTPS).
3. Sélectionnez CloudFare ou Google dans l'URL du serveur DoH ou saisissez l'URL de votre serveur DoH préféré dans le champ.
4. Cliquez sur Appliquer pour enregistrer vos paramètres.

Remarque :

• DoH ne peut pas être activé si le paquet DNS Server est installé sur votre système.

[VaMPyR]

Bonjour à tous,

tout d'abord merci pour tous ces tutoriels !

En gros pour administrer mon NAS d l'extérieur je passe par OpenVPN (je n'autorise pas aux clients l'accès au server LAN -> que l'accès au NAS)

J'ai configuré un DNS local et le reverse proxy ( pour que l'adresse nas.mondomaine.xx me renvoie sur l'administration du NAS.

Pris séparément les deux systèmes fonctionnent bien =

• en local nas.mondomaine.xx me renvoie bien sur mon NAS à travers le DNS du Synology et le reverse proxy (destination vers localhost). 
• J'accède à mon synology en externe avec OpenVPN en utilisant 10.8.0.1:port et non 192.168.xx.xx:port étant donné je n ai pas autorisé aux clients l'accès au server LAN.

Cependant quand je combine les deux ça ne fonctionne pas: 

• nas.mondomaine.xx ne me renvoie pas au NAS.
• 10.8.0.1:port lui fonctionne toujours bien

lorsque que connecté avec OpenVPN je fais un nslookup nas.mondomaine.xx 10.8.0.1 j'ai bien une réponse:
 

Server: UnKnown
Address: 10.8.0.1

Nom: ns.mondomaine.xx
Address: 192.168.xx.xx
Amiases: nas.mondomaine.xx

Et je suppose que c'est de la que vient le problème ? il me retourne l'adresse du nas en 192.168.xx.xx. ?

Merci pour vos avis/conseils.

Vincent

Modifié le 16 février 2020 par VaMPyR

[Jeff777]

Il y a 9 heures, VaMPyR a dit :

le reverse proxy (destination vers localhost). 

Bonjour,

Une idée si tu remplaces localhost par 10.8.0.1

Modifié le 17 février 2020 par Jeff777

[VaMPyR]

Il y a 3 heures, Jeff777 a dit :

Bonjour,

Une idée si tu remplaces localhost par 10.8.0.1

Merci pour l'idée, j'y avais pensé hier soir et avais testé à la hâte mais à priori ça ne fonctionnait pas mais bon j étais un peu dans le rush (pas fait de nslookup pour voir ce que ça renvoyait) ...  retesterai plus calmement ça ce soir. Après ça me ferait faire 2 noms de domaine différents pour le reverse proxy : 1 pour quand je suis en local et 1 en VPN ... Je me disais que je loupais peut-être un truc et qu'il y avait plus propre comme méthode.

Modifié le 17 février 2020 par VaMPyR