[TUTO] DNS Server

[ben9111]

Bonjour, (je reposte ici sur les conseils d'Einsteinium)

j'ai un nom de domaine qui me permet d'avoir un accès via plusieurs sous-domaines à plusieurs services hébergés sur mon nas (ex: video, websation) et ailleurs (ex: box domotique) grâce au proxy inverse. tout fonctionne depuis internet. Et aussi en local (mon routeur fait loopback).

J'ai configuré le DNS (en suivant cet excellent tuto) pour ne plus passer par internet lorsque je suis en local et pour faire des sous-domaines supplémentaires pour accéder à des cameras de surveillance. Je ne veux bien entendu pas rendre accessibles ces cameras sur internet. Mon DNS n'est pas accessible par internet.

Voilà les difficultés auxquelles je fais face depuis plusieurs jours (j'ai purgé les cache DNS des machines et des navigateurs, redémarré le serveur des milliers de fois) :

- Absolument toutes les requêtes http sont tranformées en https bien que j'ai désactivé cette option dans tous DSM (y compris HSTS et Http/2) au fur et à mesure des tests. C'est gênant car mes cameras ne font pas du https (pour du local ça ira)

- Malgré une bonne configuration des adresses IP locales dans les enregistrements A des sous domaines "camera", le DNS résout les demandes vers le NAS.

J'ai donc enlevé toutes les entrées du reverse proxy pour tester (et re-purgé les caches) car il y a peut-être un conflit: cette fois la résolution et conforme à l'enregistrement et je n'ai plus de bascule automatique en HTTPS mais j'ai systématiquement "connection refused" (quel que soit le navigateur ou l'ordi y compris sur des domaines et sous-domaines exotiques tests)

Je vous remercie de m'avoir lu jusque là, si quelqu'un a une idée ... car là je sèche

[Fenrir]

Difficile de te répondre, ton post est assez confus. Ce que je peux te dire par contre, c'est que le DNS ne fait que résoudre des adresses, il ne s'occupe pas du https, des connexions refusées, ...

Si la résolution DNS renvoi bien la bonne adresse (à tester avec nslookup par exemple), alors le DNS est ok.

Je te recommande de refaire ta conf pas à pas (pour le reverse proxy, il y a un exemple dans le tuto sécu). Attention avec l'HSTS, c'est enregistré dans le navigateur (ce n'est pas du cache => voir ici par exemple)

[Sebichou]

J'ai suivi vos conseils, j'ai acheté mon nom de domaine auprès d'OVH.

J'ai ensuite ajouter le dynhost qui m'a permis de crée mon DDNS sur le NAS, j'ai éditer la zone d'OVH pour y ajouter tous mes CNAME. 2 questions à ce sujet: Est-il possible de renseigner directement son domaine plutôt qu'un sous-domaine sur le DynHost? Est-ce grave si je supprime l'enregistrement A de ma Zone OVH qui pointe par défaut vers la webmail OVH?

Sinon j'ai bien accès à mes applis/périphériques, ça fonctionne parfaitement via les noms que j'ai enregistré, en local et distant. J'ai aussi testé une réinitialisation mon IP Publique, ça a mis environ 3 minutes à repartir correctement après le reboot de ma box. En revanche, impossible de crée le certificat Let's Encrypt... J'ai vu ailleurs que Let's encrypt vérifierait qu'un serveur web soit bien installé lorsque l'on tente de créer un certificat. C'est curieux car ça ne m'a pas empêché d'avoir mon certificat sur mon ancien nom de domaine fourni par syno...

[Mic13710]

Il y a 9 heures, Sebichou a dit :

En revanche, impossible de crée le certificat Let's Encrypt... J'ai vu ailleurs que Let's encrypt vérifierait qu'un serveur web soit bien installé lorsque l'on tente de créer un certificat.

Si vos noms de domaine sont tous valides (enregistrement CNAME ou A chez OVH), que le port 80 est ouvert et dirigé vers le NAS et que le parefeu du NAS ne bloque pas le port 80, vous devriez pouvoir créer votre ou vos certificat(s).

Vous pouvez aller voir la rubrique Certificat de mon retour sur le serveur DNS :

 

[Sebichou]

OK, c'était bien un problème de port, mais c'est assez subtile... J'avais réglé mon parefeu pour le port 80 mais uniquement en France... Let's Encrypt doit passer par un autre pays, du coup en acceptant toutes les IP sources, il a accepté de créer mon certificat, bon à savoir. Ça m'embête un peu d'avoir le port 80 accessible all over the world, mais bon... On fera avec.

[Einsteinium]

État unis normalement, sauf s’ils ont des serveurs en Europe...

[Mic13710]

On peut très bien limiter l'accès à quelques pays dont les US. Perso, j'ai créé mes certifs avec les seuls pays avec lesquels j'ai des contacts (FR, GB, CA, ES) auxquels j'ai rajouté les US pour les certifs.

[PiwiLAbruti]

Apparemment je dois être le seul que ça dérange d'ouvrir le port 80 à des pays entiers... 

Pour ma part, j'ai identifié les adresses bloquées lors de la génération d'un certificat, et je n'ai autorisé que ces adresses à accéder au port 80 dans le pare-feu du NAS :

• outbound1.letsencrypt.org 66.133.109.36
• outbound2.letsencrypt.org 64.78.149.164

[Mic13710]

Merci PiwiLAbruti pour l'info. Si je balaye large c'est que je ne savais pas quelles sont les IP. Maintenant je n'ai aucune excuse.

[PiwiLAbruti]

J'ai fait un retour à Synology depuis la page d'aide afin qu'ils ajoutent une note sur la sécurité (déjà que l'utilisation du port tcp/80 pour gérer des certificats est fort discutable...).

Pour en revenir au sujet (DNS Server) , j'ai configuré une zone slave (esclave) sur un deuxième NAS. C'est plutôt simple à mettre en place et ça fonctionne.

Maintenant je vais m'atteler à la partie sécurité avec des clés TSIG.

[Mic13710]

il y a 2 minutes, PiwiLAbruti a dit :

déjà que l'utilisation du port tcp/80 pour gérer des certificats est fort discutable..

C'est malheureusement une exigence de Let's Encrypt. C'est assez incompréhensible que pour la gestion il faille passer par le 80 alors que le 443 serait plus approprié.

Pour la zone slave, ce n'est effectivement pas inclus dans le tuto de Fenrir. Un petit retour peut-être ?

[PiwiLAbruti]

J'attends d'avoir fait le tour des fonctions de sécurité, et je simulerais la perte du master (blocage au niveau du pare-feu ou arrêt du paquet DNS) pour voir comment les clients réagissent avec le DNS secondaire.

[Fenrir]

Il y a 12 heures, Mic13710 a dit :

C'est malheureusement une exigence de Let's Encrypt

Il y a 12 heures, Mic13710 a dit :

C'est assez incompréhensible que pour la gestion il faille passer par le 80 alors que le 443 serait plus approprié

Non, c'est une exigence de l'api que Synology a choisi d'utiliser, perso je créé mes certificats via des enregistrements DNS (DNS-01), d'autre le font via un fichier (webroot), d'autre encore via un reverse proxy (mélange de webroot et de nginx), mais aussi en https (TLS-SNI-01)

Il y a 11 heures, PiwiLAbruti a dit :

comment les clients réagissent avec le DNS secondaire.

Ça dépend des clients, pour Windows ça va, mais Linux c'est la cata par défaut, le timeout est trop long (resolv.conf => options timeout:1 attempts:2).

En pratique le DNS secondaire c'est plus pour les autres serveurs DNS que pour les clients, un client devrait normalement systématiquement avoir un resolver en local (unbound par exemple), c'est plus performant, ça permet de limiter la censure et c'est plus sécurisé (la plupart des logiciels, mais aussi les box ne gèrent pas, ou rarement DNSSEC).

[Sebichou]

Le 12/07/2017 à 09:40, PiwiLAbruti a dit :

Apparemment je dois être le seul que ça dérange d'ouvrir le port 80 à des pays entiers... 

Pour ma part, j'ai identifié les adresses bloquées lors de la génération d'un certificat, et je n'ai autorisé que ces adresses à accéder au port 80 dans le pare-feu du NAS :

• outbound1.letsencrypt.org 66.133.109.36
• outbound2.letsencrypt.org 64.78.149.164

Testé et approuvé! Merci pour l'info 

[PiwiLAbruti]

Il y a 13 heures, Fenrir a dit :

[...] , mais Linux c'est la cata par défaut, le timeout est trop long (resolv.conf => options timeout:1 attempts:2).

Oui, j'ai constaté cette latence. Ça voudrait dire qu'à chaque requête DNS il interroge sa liste de serveurs DNS dans l'ordre avec un timeout de 2x1 seconde par serveur ? 

Pour la partie esclave, après la création il faut désactiver/activer la zone pour qu'elle soit prise en compte. Synology a oublié de faire un reload après la création ou c'est normal ?

[pluton212+]

Citation

• outbound1.letsencrypt.org 66.133.109.36
• outbound2.letsencrypt.org 64.78.149.164

Doit on faire une redirection dans la box avec ces adresses et vers le NAS sur le port 80 ?

[Einsteinium]

Le 12/07/2017 à 09:40, PiwiLAbruti a dit :

Apparemment je dois être le seul que ça dérange d'ouvrir le port 80 à des pays entiers... 

Pour ma part, j'ai identifié les adresses bloquées lors de la génération d'un certificat, et je n'ai autorisé que ces adresses à accéder au port 80 dans le pare-feu du NAS :

• outbound1.letsencrypt.org 66.133.109.36
• outbound2.letsencrypt.org 64.78.149.164

Certains sont plus laxistes que d’autres, après ce n’est pas comme ci ces adresses étaient dispo depuis la création du projet sur le forum LE  

[Fenrir]

Il y a 11 heures, PiwiLAbruti a dit :

Oui, j'ai constaté cette latence. Ça voudrait dire qu'à chaque requête DNS il interroge sa liste de serveurs DNS dans l'ordre avec un timeout de 2x1 seconde par serveur ? 

non, par défaut c'est pire (5sec en général), ce que j'ai indiqué entre parenthèse c'est la conf que je fais sur mes serveurs au taf (1 seconde de timeout et on passe au suivant / 2 essais pour contacter le resolver et on renvoi "pas de résultat/erreur), ça passe correctement avec ces valeurs (le cache des appli et les buffers réseau compensent sans souci) => man resolv.conf

mais encore une fois (par client je veux TOUTE machine qui n'est pas serveur DNS)

Le 13/07/2017 à 00:26, Fenrir a dit :

un client devrait normalement systématiquement avoir un resolver en local

----------

Il y a 6 heures, pluton212+ a dit :

Doit on faire une redirection dans la box avec ces adresses et vers le NAS sur le port 80 ?

non, juste les autoriser dans le firewall du nas (sauf su tu as un vrai FW sur ton routeur)

[PiwiLAbruti]

Les détails qui fâchent :

1. DSM ne sait pas configurer plusieurs serveurs DNS via DHCP. On peut certes en saisir deux manuellement, mais je trouve ça regrettable pour ceux qui ont créé des réservations DHCP pour leurs NAS sur leur box/routeur et qui peuvent personnaliser les serveurs DNS distribués par le serveur DHCP. De ce fait, lorsque le DNS primaire tombe (arrêt du paquet DNS), le NAS l'hébergeant ne peut plus rien résoudre puisqu'il n'a pas de DNS secondaire.
2. Les options présentes dans le paquet DNS Server ne permettent pas la notification des esclaves basée sur les enregistrements NS du nom de domaine (ou alors c'est implicite alors que ça devrait être une option). Seule la notification d'un hôte identifié par son adresse IP est disponible.

En comblant manuellement ce détail non-négligeable (1.) en ajoutant manuellement le DNS secondaire dans /etc/resolv.conf, je me suis aperçu que le timeout est de 1 seconde (sans retry) avant d'envoyer la requête au DNS secondaire :

17:05:39.416408 IP primary.local.36530 > primary.local.53: UDP
17:05:40.417224 IP primary.local.39885 > secondary.local.53: UDP

Je vais m'arrêter là pour les tests de la zone secondaire. De mon point de vue, il manque des détails qui font que ce n'est pas pleinement utilisable tel qu'actuellement proposé par Synology.

[Fenrir]

@PiwiLAbruti

Je ne comprends pas bien tes problèmes (ma journée a été longue mais quand même).

1-

Le serveur DHCP permet de spécifier 2 serveurs de noms et les clients en tiennent compte (avec ou sans timeout, mais ça, ça dépend du client).

Pour le DNS du NAS lui même, tu peux aussi paramétrer 2 serveurs DNS dans les paramètres réseau (pas besoin de modifier le resolv.conf à la main) et rien ne t'oblige à utiliser le paquet comme serveur(chez moi mon nas utilise mon routeur comme DNS principal et lui même comme DNS secondaire, je considère que si mon routeur ne fonctionne plus, la résolution DNS de mon nas n'est pas ma priorité).

2-

Le comportement par défaut de bind (et de la plupart des serveurs de zones) est de notifier tous les slaves (tous les serveurs NS de la zone), c'est implicite comme demandé dans les RFC.

Je n'ai pas vérifié, mais je pense que l'option présente dans DSM correspond à la directive also-notify qui elle est forcement en IP (ou avec des clefs depuis la version 9.9). C'est volontaire pour des questions de sécurité (un empoisonnement de cache permettrait de dumper une zone) et de fonctionnement (un serveur NS n'est pas forcement en mesure de faire des résolutions DNS). En complément, les slave vont aussi d'eux même chercher les mises à jour en fonctions des paramètres SOA.

Qui plus est, les notifications n'ont d’intérêt que pour les serveurs MASTER, pas pour les secondaires.

--

De mon point de vu, même si le paquet est loin de permettre un hébergement "pro", il permet largement de remplir son rôle pour un particulier.

[PiwiLAbruti]

Quand je parle de DHCP, je parle de mes 2 NAS en tant que clients. Seule l'adresse du premier serveur DNS distribué par DHCP est conservée par DSM.

La modification de /etc/resolve.conf n'est conservée après redémarrage (normal, le client DHCP du NAS fair son œuvre).

Merci pour les précisions sur les notifications. Je n'ai pas configuré le serveur secondaire dans les NS, je teste ça demain ;-)

[Fenrir]

il y a 19 minutes, PiwiLAbruti a dit :

Quand je parle de DHCP, je parle de mes 2 NAS en tant que clients. Seule l'adresse du premier serveur DNS distribué par DHCP est conservée par DSM.

Ah ok !? Je n’avais pas fait attention, mes nas sont en DHCP sauf la partie DNS (Configurer manuellement le serveur DNS) => j'ai toujours les 2 entrées dans mon resolv.conf

[PiwiLAbruti]

J'ai signalé ce désagrément à Synology en leur suggérant de ne conserver qu'un seul champ pour définir les DNS avec des adresses IP séparées par des virgule :

DNS servers : [ 192.168.0.121, 192.168.0.122, 192.168.0.123, ... ]

Du coup dans /etc/resolv.conf ça donnerait :

nameserver 192.168.0.121
nameserver 192.168.0.122
nameserver 192.168.0.123
nameserver ...

En fait, je pars du principe que je peux modifier mon plan d'adressage en ayant le minimum de modifications à faire sur les NAS. Dans cette logique, je préfère laisser le serveur DHCP servir les adresses des serveurs DNS. Bien sûr c'est parfaitement inadapté au monde professionnel (un sysadmin vous lapidera à coups de PSU avant de vous pendre avec du CAT6a SSTP Mono).

Pour le reste, j'ai supprimé la règle de notification par IP et mis à jour les enregistrements NS, les notifications fonctionnent très bien.

Sinon j'ai commencé à chercher des complications inutiles. Heureusement que la RFC 1912 est explicite sur les questions stupides que je me pose :

Citation

Having NS records pointing to a CNAME is bad and may conflict badly 
with current BIND servers.  In fact, current BIND implementations 
will ignore such records, possibly leading to a lame delegation.

[Fenrir]

Il y a 1 heure, PiwiLAbruti a dit :

je préfère laisser le serveur DHCP servir les adresses des serveurs DNS. Bien sûr c'est parfaitement inadapté au monde professionnel

Non, configurer ses serveurs en DHCP (ou d'autres mécanismes dynamiques) n'a rien de fou, c'est même la norme lorsque le nombre de serveurs devient important. Bien sûr dans ce cas on dispose de plusieurs serveurs DHCP synchrones et on passe par des relais (ip helper cisco par exemple).

Sinon tu avances bien on dirait (et oui le cname c'est mal pour des ns, idem pour le nacked domain).

[PiwiLAbruti]

Maintenant que le master/slave est opérationnel, je vais rajouter dnsmasq entre mes serveurs DNS et ceux de FDN (filtrage DNS).