[OpenBSD 6.1] nsd failed ?! (résolu)
#1

Bonsoir :-)

J’ai besoin de vos éventuelles lumières sur un problème qui m’ennuie depuis au moins deux heures. Pour l’instant, je n’ai pas de solution car je ne parviens pas à en trouver la source.

Voici le log de mon dernier redémarrage du système OpenBSD concernant le serveur nsd :

Code :
[2017-07-18 01:05:35.029] nsd[21875]: notice: nsd starting (NSD 4.1.15)
[2017-07-18 01:05:35.205] nsd[57505]: info: zone chezmoi.tld read with success

Voici le log de mon dernier démarrage manuel du serveur nsd :

Code :
[2017-07-18 01:05:35.205] nsd[57505]: notice: nsd started (NSD 4.1.15), pid 79843
[2017-07-18 01:10:32.337] nsd[57698]: notice: nsd starting (NSD 4.1.15)
[2017-07-18 01:10:32.338] nsd[57698]: warning: nsd is already running as 79843, continuing
[2017-07-18 01:10:32.339] nsd[57698]: error: can't bind udp socket: Address already in use
[2017-07-18 01:10:32.339] nsd[57698]: error: server initialization failed, nsd could not be started

Voici le fichier « nsd.conf » :

Code :
server:
    server-count: 2
    hide-version: yes
    zonesdir: "/var/nsd/"
    logfile: "/var/nsd/etc/nsd.log"
    ip-address: 192.168.1.13
    do-ip6: no
    debug-mode: no
    verbosity: 2

zone:
    name: "chezmoi.tld"
    zonefile: "chezmoi.tld/zone.db"

Voici le fichier « chezmoi.tld/zone.db » :

Code :
$ORIGIN chezmoi.tld.
$TTL 86400

@           IN SOA    titi.chezmoi.tld. toto.3hg.fr. (
            ; domaine A enregistre avant
            ; suivi de l'adresse mail pour
            ; contacter le responsable du serveur.
            ; Ici, cette adresse
            ; est hostmaster@example.com.
            ; Oui, le "@" est remplace par un "."
                    2017071701      ; numero de serie a augmenter
                                    ; a chaque modification.
                    86400           ; refresh
                    7200            ; retry
                    3600000         ; expire
                    172800 )        ; negative

@           IN NS        titi.chezmoi.tld.

@           IN MX       10 tata.chezmoi.tld.

titi        IN A        192.168.1.13

tata        IN A        192.168.1.13


En fait, je ne comprends pas ce que ce message signifie :

Code :
[2017-07-18 01:10:32.339] nsd[57698]: error: can't bind udp socket: Address already in use

Même si je ne voyais pas le rapport, j’ai changé le port de nsd en 5353 (ainsi que sur mon routeur -> la Box de mon FAI) et cela ne fonctionne pas mieux. J’ai aussi essayé en stoppant les serveurs ntpd et sshd. Fonctionne toujours pas !

Voici le résultat de commande « netsat -af inet » :

Code :
Active Internet connections (including servers)
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
ip           0      0  *.*                    *.*                    17
Active Internet connections (including servers)
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp          0      0  *.222                  *.*                    LISTEN
tcp          0      0  192.168.1.13.domain    *.*                    LISTEN
tcp          0      0  localhost.domain       *.*                    LISTEN
tcp          0      0  localhost.smtp         *.*                    LISTEN
Active Internet connections (including servers)
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
udp          0      0  192.168.1.13.45200     main.arcanite.ch.ntp  
udp          0      0  192.168.1.13.23398     ns310436.ip-188-.ntp  
udp          0      0  192.168.1.13.42484     ntp.lweber.net.ntp    
udp          0      0  192.168.1.13.23258     eva.aplu.fr.ntp      
udp          0      0  *.syslog               *.*                  
udp          0      0  localhost.domain       *.*                  
udp          0      0  192.168.1.13.domain    *.*                  
udp          0      0  *.*                    *.*

Donc :

- unbound écoute bien sur 127.0.0.1:53 (TCP/UDP).
- nsd écoute bien sur 192.168.1.13:53 (TCP/UDP).
- ssh écoute bien sur le port 222 (TCP).

L’adresse IP 192.168.1.13 est obtenue via le serveur DHCP de mon routeur (rappel : la Box de mon FAI).

Une idée ?

ps : J'ai aussi essayé de créer un forward-zone sur nsd (écoutant sur 5353) depuis unbound. Résultat : échec ! :-(

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#2

Apparament, t'as déjà un serveur DNS à l'ecoute sur le port 53. Probablement Unbound.

Par contre, les sshd et ntpd n'ont rien à voir avec la choucroute à priori.

Je te suggère de redemarrer du début :
  • Coupe tous tes serveurs DNS
  • verfie dans la liste des processus que t'as rien qui tourne qui pourrait ressembler à un DNS
  • Vérifie que rien n'écoute sur le port 53
  • initialise Unbound
  • regarde quels ports 53 sont ouverts (localhost seulement ?)
  • Initialise NSD, si possible en debug verbose

Si comme je le pense, Unbound écoute sur plus d'adresses que ce que tu as prévu, alors t'as gagné. Sinon, ca deviendra plus interessant...
Répondre
#3

oui, vérifie ta config unbound, et nsd... à nouveau !

GPG:Fingerprint ed25519 : 072A 4DA2 8AFD 868D 74CF  9EA2 B85E 9ADA C377 5E8E
GPG:Fingerprint rsa4096 : 4E0D 4AF7 77F5 0FAE A35D  5B62 D0FF 7361 59BF 1733
Répondre
#4

Salut :-)

Citation :Par contre, les sshd et ntpd n'ont rien à voir avec la choucroute à priori.

Je sais bien qu'a priori cela n'a rien à voir. Comme c'est ma première fois avec nsd, on fait des trucs "idiots" pour se rassurer et effectivement cela n'a pas changer la situation. ;-)

Sinon pour information, j'ai réussi à lancer unbound ET nsd en même temps. Cependant, cela ne fonctionne pas. Je ne sais pas comment vous procéder face à un problème nouveau mais pour ma part dans une telle situation, je bidouille, je prends des notes, je reviens en arrière, je m'embrouille (,nécessairement), j'arrête tout, je lis* et je réfléchis puis je reprends, etc...

Là j'y suis depuis ce matin. Vous avez raison, il y a un conflit entre les deux serveurs DNS sur le port 53. Par conséquent, j'ai décidé qu'unbound écouterait sur le port 53 uniquement de la machine (127.0.0.1) et que nsd écouterait sur le port 5355 (127.0.0.1 aussi ? sur 192.168.1.13 ça coince ?!). Le routeur (la Box) a été configuré pour redirigé le traffic sur le port 53 provenant de l'extérieur vers le port 5355 de la machine ayant pour IP 192.168.1.13 (ce qui m'évite, a priori, d'avoir une règle pf supplémentaire sur cette machine).

Pour ce qui est du bureau de registre, j'ai créé une colle de mon serveur dans le registre de mon Registrar. J'ai mis l'IP locale 192.168.1.13. Voilà c'est fait mais du coup je ne comprends plus où doit apparaitre l'IP publique de mon routeur (la Box) au sein du registre. En effet, pour l'instant, cette addresse IP n'apparait plus. Donc, cela ne m'étonne pas non plus que cela, ne focntionne pas ! Bref vous l'aurez compris, j'ai des soucis à régler sur plusieurs niveaux. Je vais commencer, comme vous me le conseillez, de repartir sur la configuration des services nsd/unbound de mon serveur.

Je vous tiens au courant. ;-)

ps :*Ici notamment :
https://yeuxdelibad.net/ah/
https://www.22decembre.eu/2014/04/14/loc...nbound-en/

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#5

Ah non mais là tu mélange tout !

kuniyoshi a écrit :Salut :-)

Là j'y suis depuis ce matin. Vous avez raison, il y a un conflit entre les deux serveurs DNS sur le port 53. Par conséquent, j'ai décidé qu'unbound écouterait sur le port 53 uniquement de la machine (127.0.0.1) et que nsd écouterait sur le port 5355 (127.0.0.1 aussi ? sur 192.168.1.13 ça coince ?!).

Et pourquoi NSD n'écouterait pas sur 192.168.1.13 (port domain) ? Et Unbound serait restreint à localhost. Tu peux aussi le faire écouter sur une autre ip qui n'est pas "en face" d'internet. Par exemple 192.168.1.20. Evidemment il faut que cette adresse soit aussi declarée dans hostname.if... mais c'est possible (C'est ce que j'ai actuellement).

Va lire les man des nsd.conf et unbound.conf, il y a décrit comment définir les adresses qui ecoutent.

kuniyoshi a écrit :Le routeur (la Box) a été configuré pour redirigé le traffic sur le port 53 provenant de l'extérieur vers le port 5355 de la machine ayant pour IP 192.168.1.13 (ce qui m'évite, a priori, d'avoir une règle pf supplémentaire sur cette machine).

C'est effectivement ce que j'avais fais au debut. T'as le choix. Ca ou ce que j'ai ecris au dessus.

kuniyoshi a écrit :Pour ce qui est du bureau de registre, j'ai créé une colle de mon serveur dans le registre de mon Registrar. J'ai mis l'IP locale 192.168.1.13.

WWWWHHHAATTTT ? Erreur fatale ! T'as pas compris le principe des ip privées ????? Tu devrais relire plus attentivement mon blog (La solution est dessus)


kuniyoshi a écrit :Voilà c'est fait mais du coup je ne comprends plus où doit apparaitre l'IP publique de mon routeur (la Box) au sein du registre. En effet, pour l'instant, cette addresse IP n'apparait plus. Donc, cela ne m'étonne pas non plus que cela, ne focntionne pas ! Bref vous l'aurez compris, j'ai des soucis à régler sur plusieurs niveaux. Je vais commencer, comme vous me le conseillez, de repartir sur la configuration des services nsd/unbound de mon serveur.

Je vous tiens au courant. ;-)

ps :*Ici notamment :
https://yeuxdelibad.net/ah/
https://www.22decembre.eu/2014/04/14/loc...nbound-en/
Répondre
#6

Citation :Ah non mais là tu mélange tout !
Et pourquoi NSD n'écouterait pas sur 192.168.1.13 (port domain) ? Et Unbound serait restreint à localhost. Tu peux aussi le faire écouter sur une autre ip qui n'est pas "en face" d'internet. Par exemple 192.168.1.20. Evidemment il faut que cette adresse soit aussi declarée dans hostname.if... mais c'est possible (C'est ce que j'ai actuellement).

Va lire les man des nsd.conf et unbound.conf, il y a décrit comment définir les adresses qui ecoutent.

Oui je pense effectivement qu'il y a des aspects qui ne me sont pas clairs. Par contre, je pense avoir compris comment imposer les addresses sur lesquels peut écouter nsd et unbound. Alors pourquoi faire écouter nsd sur 192.168.1.13:53 (et depuis peu 192.168.1.13:5355 après avoir lu ton article) et unbound sur 127.0.0.01:53* ? Et bien parce que c'est mon choix. A priori, j'envisage cela ainsi. Je te l'accorde, ce n'est peut-être pas judicieux (je ne sais, je suis en période de tests) et si je vois que cela ne vas pas, je recommencerai. ;-)

*Pourquoi unbound devrait écouter sur le réseau de mon FAI (en 192.168.1.*) ? Je n'en ai aucune envie. J'ai un réseau local "derrière" le réseau de mon FAI. Dans mes plans, le service unbound ne sert que pour le système hôte OpenBSD du serveur. Et c'est tout.

Cependant comme tu me le conseilles, je relirai les pages de manuel de unbound.conf et de nsd.conf. ;-)

Citation :C'est effectivement ce que j'avais fais au debut. T'as le choix. Ca ou ce que j'ai ecris au dessus.

OK. Merci. Je verrai.

Citation :WWWWHHHAATTTT ? Erreur fatale ! T'as pas compris le principe des ip privées ?????

Si a priori sinon je ne me poserai pas la question !! Par contre, ce que je n'ai pas encore bien compris, c'est quelle adresse IP doit être indiquée sur la colle. Mon premier réflexe (et je pense que c'est la seule réponse possible) a été de mettre l'IP publique de ma Box pensant que les redirections se feraient bien du routeur vers le serveur puis du serveur vers lui-même éventuellement via pf. Le fait est que cela ne fonctionne pas mais je ne nie pas que le dsyfonctionnement est nécessairement lié à ce paramétrage (IP publique de la Box sur la colle).

Citation :Tu devrais relire plus attentivement mon blog (La solution est dessus)

Oui je fais cela ainsi que tes écrits sur l'ouvrage de thuban ainsi que les pages de manuel. ;-)

J'y vais. J'ai du boulot. :-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#7

kuniyoshi a écrit :Oui je pense effectivement qu'il y a des aspects qui ne me sont pas clairs. Par contre, je pense avoir compris comment imposer les addresses sur lesquels peut écouter nsd et unbound. Alors pourquoi faire écouter nsd sur 192.168.1.13:53 (et depuis peu 192.168.1.13:5355 après avoir lu ton article) et unbound sur 127.0.0.01:53* ? Et bien parce que c'est mon choix. A priori, j'envisage cela ainsi. Je te l'accorde, ce n'est peut-être pas judicieux (je ne sais, je suis en période de tests) et si je vois que cela ne vas pas, je recommencerai. ;-)

Tu peux plutôt faire ecouter NSD sur 192.168.1.13 et Unbound sur 127.0.0.1, tous les deux sur le port 53 (domain). Mon bricolage avec le port n'était necessaire que parce que Dnsmasq écoutait déjà sur le 53. T'as pas cette restriction.

Citation :*Pourquoi unbound devrait écouter sur le réseau de mon FAI (en 192.168.1.*) ? Je n'en ai aucune envie. J'ai un réseau local "derrière" le réseau de mon FAI. Dans mes plans, le service unbound ne sert que pour le système hôte OpenBSD du serveur. Et c'est tout.

Bah, ce qui est bien, c'est qu'Unbound, tu sais qu'il te ment pas et t'as le contrôle. Donc tu peux lui dire de t'epargner les adresses pourries et le tracking. Tu peux faire de la validation dnssec ou du dns64, Ce qui fait 5 gros avantages pour ton reseau local. Mais c'est toi qui voit.

Citation :Ce que je n'ai pas encore bien compris, c'est quelle adresse IP doit être indiquée sur la colle. Mon premier réflexe (et je pense que c'est la seule réponse possible) a été de mettre l'IP publique de ma Box pensant que les redirections se feraient bien du routeur vers le serveur puis du serveur vers lui-même éventuellement via pf.

Oui, c'est bien ca qui doit se passer. Tu mets ton ip publique.

Citation :Le fait est que cela ne fonctionne pas mais je ne nie pas que le dsyfonctionnement est nécessairement lié à ce paramétrage (IP publique de la Box sur la colle).

C'est donc ton routeur / tes redirections qui fonctionnent pas. Au passage, pas d'ipv6 ? (Si tu l'as, bien plus facile)
Répondre
#8

Salut :-)

Citation :Tu peux plutôt faire ecouter NSD sur 192.168.1.13 et Unbound sur 127.0.0.1, tous les deux sur le port 53 (domain). Mon bricolage avec le port n'était necessaire que parce que Dnsmasq écoutait déjà sur le 53. T'as pas cette restriction.

Ok. Merci pour cette information. En fait, j'ai mis 127.0.0.1 et 192.168.1.13 pour les deux. Du coup, je garde ce changement de port en 5355 pour nsd. en effet, sur mes nombreuses lectures sur le Web, il semblerait que nsd et unbound doivent écouter sur la même addresse. Encore une fois, je ne comprends pas pourquoi, mais je l'ai fait ?! Je teste actuellement.

Citation :Bah, ce qui est bien, c'est qu'Unbound, tu sais qu'il te ment pas et t'as le contrôle. Donc tu peux lui dire de t'epargner les adresses pourries et le tracking. Tu peux faire de la validation dnssec ou du dns64, Ce qui fait 5 gros avantages pour ton reseau local. Mais c'est toi qui voit.

Oui je sais. Mais je préfère limiter les fonctionnalités inutiles. Sur mon serveur, a priori, car je viens de changer à contre coeur... pouah... ;-) (voir ce que je viens d'écrire ci-dessus), unbound n'a pas pour mission d'écouter sur le réseau de mon FAI. En fait, mon réseau local vit derrière une autre machine qui fait office de passerelle filtrante. Sur cette passerelle filtrante, unbound/BlockZones est actif (avec pf) à la fois pour le beau système qui exploite ce parefau mais aussi pour les machines de mon réseau local situées derrière. Conséquence : Je ne vois vraiment pas l'intérêt que le service unbound de ma machine serveur soit actif ailleurs et au delà de la machine serveur. En fait, j'ai créé ma propre DMZ.


Citation :et t'as le contrôle

Justement. Tu te tais unbound. Tu fais ce que je te dis. Tu bosses uniquement en localhost du système OpenBSD qui hébergera mon futur serveur de zone ! ;-)

Plus sérieusement, c'est bien cloisonné comme j'aime. C'est parfait de mon point de vue ! ;-)

Citation :Oui, c'est bien ca qui doit se passer. Tu mets ton ip publique.

Done ! ;-)

Passe toujours pas ! :-(

Citation :C'est donc ton routeur / tes redirections qui fonctionnent pas. Au passage, pas d'ipv6 ? (Si tu l'as, bien plus facile)

Peut-être. Je ne fais rien de spécial pourtant. Je veux dire rien de spécial par rapport à ce que j'ai déjà fait (redirection pour du sftp, http, https) et pour tous ces protocoles, cela a toujours bien fonctionné.

Bon, on cause, on cause mais je dois y aller. J'ai du ménage à faire sinon je vais me faire... par ma femme ! Je reviens tout à l'heure... ;-)

p : Pour l'ipv6... ce sera une autre hsitoire... oh je le sens bien ! :-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#9

kuniyoshi a écrit :Salut :-)

Citation :Tu peux plutôt faire ecouter NSD sur 192.168.1.13 et Unbound sur 127.0.0.1, tous les deux sur le port 53 (domain). Mon bricolage avec le port n'était necessaire que parce que Dnsmasq écoutait déjà sur le 53. T'as pas cette restriction.

Ok. Merci pour cette information. En fait, j'ai mis 127.0.0.1 et 192.168.1.13 pour les deux. Du coup, je garde ce changement de port en 5355 pour nsd. en effet, sur mes nombreuses lectures sur le Web, il semblerait que nsd et unbound doivent écouter sur la même addresse.

Non.

Citation :Encore une fois, je ne comprends pas pourquoi, mais je l'ai fait ?! Je teste actuellement.

Je cherche pas à te convertir hein. Il faut juste que tu ais toutes les cartes en main.

La contrainte primordiale, c'est que tu dois pas avoir deux services/demons qui écoutent sur la même adresse ET le même port. En dehors de ca, rien n'est interdit.

Tu peux dériver les requetes DNS venant de l'internet sur une ip privée, ou sur un port de ton choix (c'est ton scenario actuel).

Citation :En fait, j'ai créé ma propre DMZ.

Ok. Là t'as bien expliqué. C'est clair et net. Notammant t'as aussi signalé que tu utilisais une autre instance Unbound pour faire le job que je suggérais AILLEURS. Donc t'as le controle AUSSI sur cet ailleurs (qui est ton chez-toi où tu vis).

Citation :
Citation :et t'as le contrôle

Justement. Tu te tais unbound. Tu fais ce que je te dis. Tu bosses uniquement en localhost du système OpenBSD qui hébergera mon futur serveur de zone ! ;-)

Plus sérieusement, c'est bien cloisonné comme j'aime. C'est parfait de mon point de vue ! ;-)

Citation :Oui, c'est bien ca qui doit se passer. Tu mets ton ip publique.

Done ! ;-)

Passe toujours pas ! :-(

Citation :C'est donc ton routeur / tes redirections qui fonctionnent pas. Au passage, pas d'ipv6 ? (Si tu l'as, bien plus facile)

Peut-être. Je ne fais rien de spécial pourtant. Je veux dire rien de spécial par rapport à ce que j'ai déjà fait (redirection pour du sftp, http, https) et pour tous ces protocoles, cela a toujours bien fonctionné.

Tu redirige le port 53 de ton ip publique en tcp ET udp vers l'adresse de NSD sur le port qu'il écoute ? <- C'est ca que tu dois checker 33 fois avant de revenir, ainsi que les sous-entendus comme pf sur le serveur ou ailleurs.

Citation :Bon, on cause, on cause mais je dois y aller. J'ai du ménage à faire sinon je vais me faire... par ma femme ! Je reviens tout à l'heure... ;-)

p : Pour l'ipv6... ce sera une autre hsitoire... oh je le sens bien ! :-)
Répondre
#10

Citation :Je cherche pas à te convertir hein.

Convertir ! De quoi parles-tu ? De toute façon, quand bien même tu essaierais de me convertir (?), tu n'y parviendrais pas. ;-)

Citation :Il faut juste que tu ais toutes les cartes en main.

Oui et pour cela je t'en remercie.
Citation :La contrainte primordiale, c'est que tu dois pas avoir deux services/demons qui écoutent sur la même adresse ET le même port. En dehors de ca, rien n'est interdit.

Ok. Merci C'est bien ce que j'avais compris a priori. D'autres pensent visiblement autrement. Pour ma part, je testerai et je prendrai la solution la plus adaptée et la plus efficace pour ma situation.

Citation :Tu peux dériver les requetes DNS venant de l'internet sur une ip privée, ou sur un port de ton choix (c'est ton scenario actuel).

Oui effectivement.

Citation :Ok. Là t'as bien expliqué. C'est clair et net. Notammant t'as aussi signalé que tu utilisais une autre instance Unbound pour faire le job que je suggérais AILLEURS. Donc t'as le controle AUSSI sur cet ailleurs (qui est ton chez-toi où tu vis).

Oui, j'ai dû le dire clairement même si cela n'a rien avoir avec al demande initiale. Ainsi, cela explique la démarche que j'essaie de mettre en oeuvre notamment avec unbound en écoute uniquement sur le localhost de mon serveur. Tout comme toi et bien d'autres sur ce forum, j'essaie d'avoir le contrôle sur mes systèmes informariques. Il est vrai ! ;-)

Citation :Tu redirige le port 53 de ton ip publique en tcp ET udp vers l'adresse de NSD sur le port qu'il écoute ?

Déjà fait sur la Box.

Citation : <- C'est ca que tu dois checker 33 fois avant de revenir

Ok. Pourquoi 33 ? 53 tu veux dire. ;-)

Citation : ainsi que les sous-entendus comme pf sur le serveur ou ailleurs.

Quels sous-entendus ? Le serveur est exploité par OpenBSD et a pour adresse 192.168.1.13. La passerelle filtrante est exploitée par OpenBSD et a pour adresse 192.168.1.14. Ces deux machines ont un point commun : OpenBSD. Cela s'arrête là. Ces deux systèmes sont indépendants*. Le "ailleur" est donc géré par la passerelle filtrante. Quant au serveur, je regarderai effectivement ce que disent les log et tcpdump en live.

ps : *Pour information, je me suis tout de même posé la question si je ne devais pas créer une 3ème "patte" sur la passerelle filtrante. Finalement je n'ai pas retenu cette solution. Peut-être ai-je eu tort ? Mais a priori, je ne le sentais pas.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#11

Citation :Il faut juste que tu ais toutes les cartes en main.

À ce propos, avoir tous tes serveurs DNS (recursif ou authoritaire) sur le port domain s'avère un truc cool dans la mesure où les outils de debug (dig par exemple) râlent pas. Idem, durand environ un an et demi, j'ai jamais pû interroger mon propre serveur authoritaire (les requetes DNS en provenance du reseau local étant directement dérivées vers dnsmasq et unbound). Juste une info de plus.

kuniyoshi a écrit :
Citation :Tu redirige le port 53 de ton ip publique en tcp ET udp vers l'adresse de NSD sur le port qu'il écoute ?

Déjà fait sur la Box.

Citation : ainsi que les sous-entendus comme pf sur le serveur ou ailleurs.

Ce que je voulais dire par sous-entendu, c'est que tous les intermediaires possibles entre internet et ta box doivent bien laisser passer tcp ET udp vers ton serveur sur le port choisi. Comme je ne connais pas le détail de ton réseau, je suis obligé d'être vague et c'est toi qui doit calculer.


Bon, t'en es où maintenant ?
Répondre
#12

Citation :À ce propos, avoir tous tes serveurs DNS (recursif ou authoritaire) sur le port domain s'avère un truc cool dans la mesure où les outils de debug (dig par exemple) râlent pas. Idem, durand environ un an et demi, j'ai jamais pû interroger mon propre serveur authoritaire (les requetes DNS en provenance du reseau local étant directement dérivées vers dnsmasq et unbound). Juste une info de plus.

OK. Merci pour cette information très intéressante. :-)

Citation :Ce que je voulais dire par sous-entendu, c'est que tous les intermediaires possibles entre internet et ta box doivent bien laisser passer tcp ET udp vers ton serveur sur le port choisi.

Ah ok. Entre Intrenet et ma Box, cela va être rapide : je n'ai aucun pouvoir sur cela si ce n'est la configuration chez mon Regsistrar et les redirections TCP/UDP du port 53 vers mon serveur. Entre ma Box et mon serveur, l'accès matériel est direct : un câble ethernet. Pas d'intermédiaire.

Citation :Comme je ne connais pas le détail de ton réseau, je suis obligé d'être vague et c'est toi qui doit calculer.

Oui je sais bien que ce n'est pas évident de dépanner quelqu'un à distance depuis un forum. Merci. ;-)

Citation :Bon, t'en es où maintenant ?

Là je n'ai pas accès à mon serveur et il est éteint. Je vois cela ce soir. Chez mon registrar (*https://en.wikipedia.org/wiki/Mahatma_Gandhi), je peux voir au niveau du DNS la mention "DNS Externe". Dans les détails concernant "dns : serveurs de nom", l'option "Gérer DNSSEC" est accessible, le nom de ma machine "chezmoi.tld" apparaît en première position et en deuxième position le nom d'un serveur DNS secondaire que mon Registrar me proposait. À noter que je l'ai positionné ce serveur secondaire mais je ne sais pas très bien ce que cela implique. Est-ce qu'il s'agit d'une furure réplique de mon serveur DNS "titi.chezmoi.tld" faisant autorité sur ma zone ? Je pense que c'est la cas. Mais dans ce cas, comment s'effectue cette réplication automatique de mon serveur maître vers ce serveur secondaire ? Là je me pose ces questions mais lciarement mon objectif premier est que le serveur DNS maître soit actif. Dans "Modfier les DNS", j'ai :

Code :
DNS1* titi.chezmoi.tld
DNS2 ns6.gandi.net

ce qui me confirme que mon serveur est vu comme le serveur maître.

Sur mon système FreeBSD, la commande :

Code :
$ drill  odin.cla2j.xyz

me rend

Code :
Error: error sending query: Could not send or receive, because of network error

ce qui me semble cohérent puisque mon serveur est éteint. J'en conclus que le changement a bel et bien eu lieu chez mon Registrar.

Ce soir, je regarderai la redirection TCP/UDP sur le port 53 de ma Box vers mon serveur. De plus, je vais reconfigurer unbound et nsd pour qu'ils puissent écouter sur le même port 53. Conséquence : Je vais devoir revoir la configuration des redirections sur ma Box.

Je vous tiens au courant.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#13

kuniyoshi a écrit :Là je n'ai pas accès à mon serveur et il est éteint. Je vois cela ce soir. Chez mon registrar (*https://en.wikipedia.org/wiki/Mahatma_Gandhi), je peux voir au niveau du DNS la mention "DNS Externe".

Donc tu es en fait dans la même situation que moi. Sauf que tu es sur FreeBSD quand je suis sur OpenBSD.

kuniyoshi a écrit :Dans les détails concernant "dns : serveurs de nom", l'option "Gérer DNSSEC" est accessible, le nom de ma machine "chezmoi.tld" apparaît en première position et en deuxième position le nom d'un serveur DNS secondaire que mon Registrar me proposait. À noter que je l'ai positionné ce serveur secondaire mais je ne sais pas très bien ce que cela implique. Est-ce qu'il s'agit d'une furure réplique de mon serveur DNS "titi.chezmoi.tld" faisant autorité sur ma zone ?

C'est concretement un deuxième serveur authoritaire disponible sur ta zone. Authoritaire veut dire que ce qu'il dit est vrai. Mais par contre il faut lui donner les bonnes infos et pour cela le laisser copier ta zone. Il y a une section sur ca dans la doc de Gandi. Le truc moyen, c'est que t'as peu de moyens de debug. Tu sais pas vraiment si les serveurs se parlent correctement ou pas.

À noter que la communication entre serveurs DNS ne marchera que quand on pourra faire des requetes sur ton serveur à toi.

Je propose aussi de mettre mon propre serveur en backup. LÀ au moins, t'as des indices quand ca marche ou pas.

kuniyoshi a écrit :Je pense que c'est la cas. Mais dans ce cas, comment s'effectue cette réplication automatique de mon serveur maître vers ce serveur secondaire ? Là je me pose ces questions mais clairement mon objectif premier est que le serveur DNS maître soit actif. Dans "Modfier les DNS", j'ai :

Code :
DNS1* titi.chezmoi.tld
DNS2 ns6.gandi.net

ce qui me confirme que mon serveur est vu comme le serveur maître.

Sur mon système FreeBSD, la commande :

Code :
$ drill  odin.cla2j.xyz

me rend

Code :
Error: error sending query: Could not send or receive, because of network error

ce qui me semble cohérent puisque mon serveur est éteint. J'en conclus que le changement a bel et bien eu lieu chez mon Registrar.

Ce soir, je regarderai la redirection TCP/UDP sur le port 53 de ma Box vers mon serveur. De plus, je vais reconfigurer unbound et nsd pour qu'ils puissent écouter sur le même port 53. Conséquence : Je vais devoir revoir la configuration des redirections sur ma Box.

Je vous tiens au courant.

On attend...
Répondre
#14

Citation :Je propose aussi de mettre mon propre serveur en backup.

Peux-tu expliciter ce passage ? Tu me fais une proposition indécente là ? Non ? ;-) Si tel est le cas, mon serveur, lorsqu’il fonctionnera et... enfin il fonctionne \o/ (tu avais raison, le souci provenait du parefeu de mon serveur qui bloaquait le flux sur le port 53 ?!) et si tu le souhaites, pourra héberger une réplique de ton serveur DNS faisant autorité sur ta zone.

Bon je passe à DNSSEC ! :-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#15

Bien voilà où j'en suis : rentrer la clef dans le registre chez gandi.

(1) Avec la commande "zkt-signer -v -v", j'ai eu un message étrange du style "illegal algorithm RSASHA256".
Je viens d'éditer le fichier "Kchezmoi.tld.+005+12345.published" et effectivement l'algorithme est du "RSASHA1" d'où, le "5" dans le nom ?! C'est quoi le souci ?
(2) Sinon chez gandi, je suppose que je dois publier ce que contient le fichier "Kchezmoi.tld.+005+12345.key" qui est associé au fichier "Kchezmoi.tld.+005+12345.published". J'aimerais être certain même si cela semble évident puisque les trois autres fichiers "*.key" sont eux associés à des fichiers "*.private".
(3) Chez gandi, je vois des algo (courbes elliptiques) top-moumoutte... très certainement noyautés par l'immonde NSA ! ;-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#16

Grand allie de la france ,ptr !.
Répondre
#17

Salut :-)

@Kobol : ptr... PTR DNS ! :-)

@22decembre: Comme je l'ai évoqué ci-dessus, le serveur nsd est fonctionnel actuellement et il écoute sur le port 53 de l’adresse 192.168.1.13. Cependant, nsd refuse de se lancer (failed) si je ne mets pas ce passage dans le fichier de conf.

Code :
remote-control:
    control-enable: yes
    server-key-file: "/var/nsd/etc/nsd_server.key"
    server-cert-file: "/var/nsd/etc/nsd_server.pem"
    control-key-file: "/var/nsd/etc/nsd_control.key"
    control-cert-file: "/var/nsd/etc/nsd_control.pem"

Pourquoi ??? Mystère pour ma part ! Le dialogue entre localhost et le serveur nsd est donc nécessairement chiffré. Pourquoi pas ? Cela ne me dérange pas. Loin de là. Mais est-ce une spécifité de la version de nsd pour OpenBSD ?

NB : Je fais un nsd-control-setup pour créer les différents fichiers nsd_*{key,pem} puis j’utilise la commande associée nsd-control start.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#18

Tout d'abord t'as du remote control sur NSD. T'as besoin de ca ? Moi J'ai pas.

Ouais les courbes ellyptiques sont certainement pas une super idée, enfin, tout est relatif. Les courbes edward seraient pas mal, sauf qu'elles sont pas validées par beaucoup de resolveurs et les signeurs les supportent pas encore.

Je te conseille d'utiliser RSA... 512 avec des clés de 1024 et 2048 bits.

Pour savoir quels fichiers lire pour les clés à publier :

Code :
doas zkt-ls -f -k

Là tu n'as que les clés KSK (clés qui signent les clés) à mettre dans le registre. Tu repère le num de série de la clé et t'es bon. Tu dois retomber sur ce que tu viens de dire en effet.

NB : entre Thuban et Igor, j'ai assez de serveurs en backup merci. Mais toi, t'as besoin ?
Répondre
#19

Citation :Tout d'abord t'as du remote control sur NSD. T'as besoin de ca ? Moi J'ai pas.

Et bien oui sinon il ne veut pas se lancer. Vu ce que tu écris est c'est bien ce qu'il me semblait, ce fait n'est donc pas "normal" d'être contraint à utiliser remote-control. Je verrai cela car de toute façon mon actuelle installation est une installation de test. Je compte tout refaire de zéro par la suite car l'un de mes objectifs est aussi d'apprendre. Or, j'ai besoin de refaire et de refaire pour bien intégrer ce que j'ai déjà fait. J'ai bien compris l'histoire de devoir signer sa zone en passant pas DNSSEC (la théorie). Par contre, la pratique avec zkt/ksk, signatures à court et long terme, même si je vois à peu près et bien, ce n'est pas encore très clair dans la pratique. Il faut que je relise et que je refasse. Il faut que je voie ces concepts se mettre en place et vivre sur le terrain "Internet" pour mieux les intégrer. Je fonctionne ainsi. :-)

Citation :Ouais les courbes ellyptiques sont certainement pas une super idée, enfin, tout est relatif. Les courbes edward seraient pas mal, sauf qu'elles sont pas validées par beaucoup de resolveurs et les signeurs les supportent pas encore.

Ok.

Citation :Je te conseille d'utiliser RSA... 512 avec des clés de 1024 et 2048 bits.

Lorsque je recommencerai de construire l'ensemble de mon serveur, je regarderai cela de plus près. (Je prends des notes au fur et à mesure pour me faciliter la tâche.) (lire mon commentaire ci-dessous)

Citation :Pour savoir quels fichiers lire pour les clés à publier :

Code :
doas zkt-ls -f -k

Ok.

Citation :Là tu n'as que les clés KSK (clés qui signent les clés) à mettre dans le registre.

Ok. Ça, j'avais bien compris cette histoire de "roulement" de clefs qui signent d'autres clefs. La mise en oeuvre est encore un peu confuse. Il y a de quoi s'embrouiller avec tous ces implémentations différentes du RSA. De plus, comme tu l'indiques, je trouve aussi étrange de devoir installer un paquet tiers lié au serveur bind pour le serveur nsd. Bah je pense que nsd est encore bien "jeune" en comparaison de bind.

Citation :Tu repère le num de série de la clé et t'es bon. Tu dois retomber sur ce que tu viens de dire en effet.

Ok. Je vais voir cela. Sinon pourquoi j'ai du RSASHA1 et pas du RSASHA256 comme indiqué dans le fichier dnssec.conf ?!

Voici le message exact

Code :
Illegal algorithm "RSASHA256" in line 17.

que donne la commande zkt-ls -f -k.

Or la ligne 17 du fichier dnssec.conf fait bel et bien mention au RSASHA256

Code :
Key_algo: RSASHA256

Une idée ? (Pour information : Lors de l'installation, l'ensemble des sets a été installé. J'ai donc tous les outils de la basesystem... en téhorie ?!)

Citation :NB : entre Thuban et Igor, j'ai assez de serveurs en backup merci. Mais toi, t'as besoin ?

Éventuellement. Mais ce ne sera pas dans l'immédiat. Il faut me laisser le temps de bien intégrer et digérer tout ce que je viens d'appprendre en moins d'une semaine. (Je ne désire pas être un "boulet" pour les autres. Ce sera dans l'intérêt de tous de me laisser le temps de maîtriser davantage ce que je fais... moi le premier ! ;-)) De plus, le plus difficile est à venir : le serveur de messagerie. C'est tout de même l'un des objectifs majeurs pour lequel j'entreprends tout ce que je suis en train de faire (avec la voonté d'en savoir plus sur le mode de fonctionnement d'Internet et d'OpenBSD).

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#20

Encore une fois... T'es sur FreeBSD ou OpenBSD ? Ou tu as Open hebergé dans Free ? On se mélange...

Après verif', remote control est bien actif chez moi. C'est parce que rcctl control le demon via nsd-control. Bon...

T'as pas mis de clés chez Gandi encore, rassure moi ???

La version en ports de zkt est une vieille version qui n'accepte pas rsa... 2.

J'ai installé la dernière version à la main.
Répondre
#21

Citation :Encore une fois... T'es sur FreeBSD ou OpenBSD ? Ou tu as Open hebergé dans Free ? On se mélange...

Comment dire ? J'utilise tout. Bon je vais éclaircir.

Mon serveur : OpenBSD.
Ma passerelle filtrante : OpenBSD. (Juste pour information car elle ne joue aucun rôle dans notre sujet.)
Mon poste de travail : Debian, Arch Linux, Gentoo, FreeBSD ou OpenBSD (selon mon humour et le contexte... en changeant de disque). Là je suis sur FreeBSD. (Cette station est "cachée" derrière la passerelle filtrante précédente, connectée via ethernet, pas de wifi.)

Essai de schéma : :-)

Internet -- Box -- Passerelle flitrante (OBSD) -- Mon réseau local (mon poste de travail "multi-OS" est situé sur ce réseau local)
|____ Serveur (OBSD) titi.chezmoi.tld

NB : Pas de virualisation ici. Pas encore du moins. J'ai dans l'idée de virtualiser le serveur de messagerie (tata.chezmoi.tld) sur le serveur exploité par OpenBSD grâce au couple vmm/vmd. Pour l'instant, je n'en suis pas arrivé à ce stade.

Donc, mon serveur est bel et bien exploité par OpenBSD. ;-)

Citation :Après verif', remote control est bien actif chez moi. C'est parce que rcctl control le demon via nsd-control. Bon...

Par conséquent c'est la version d'OpenBSD qui impose remote-control. Autrement dit sans remote-control, sur OpenBSD, nsd ne se lance pas. Si c'est bien le cas et c'est le cas, cet aspect a été l'un des éléments qui m'empêchait de faire fonctionner nsd (avec une règle de pf sur mon serveur).

Citation :T'as pas mis de clés chez Gandi encore, rassure moi ???

Non. J'attends tes réponses pour agir au mieux en cas de doute. ;-)

Citation :La version en ports de zkt est une vieille version qui n'accepte pas rsa... 2. J'ai installé la dernière version à la main.

Ok tout s'explique. Merci pour cette information.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#22

Un détail près, stp : ton serveur titi.cheztoi sert quoi ?
Personnellement, je ne mettrais pas un serveur @home directement derrière la FAI-Box.

Sincèrement, je ne m’embêterais pas autant.

Ta GW filtrante, tu lui mets trois pattes, une pour ton LAN, l'autre pour ta DMZ. Tu installes dessus une distribution, telle pfsense, voire OPNsense - que je plussoie ; les màj systèmes sont vraiment régulières et pertinentes ; je suis vraiment "bluffé" par cette distribution "HardenedBSD"...-, qui t'assurera sans coup férir, et mieux que toi, les fonctions de pare-feu, les fonctions DNS, DHCP - IPv4+6, et tout autre fonction qui t'intéresse. Alors, oui, ce n'est pas formateur, au sens, où tu n'apprendras pas à faire, mais plutôt à gérer !

Mes deux cents Wink

GPG:Fingerprint ed25519 : 072A 4DA2 8AFD 868D 74CF  9EA2 B85E 9ADA C377 5E8E
GPG:Fingerprint rsa4096 : 4E0D 4AF7 77F5 0FAE A35D  5B62 D0FF 7361 59BF 1733
Répondre
#23

Citation :Un détail près, stp : ton serveur titi.cheztoi sert quoi ?

Bah il devrait me servir moi (et ma zone) ! ;-)

Au niveau services ouverts (sur Internet donc) :

(1) un serveur ssh et encore sur ce point je me pose la question car pour gérer mon serveur à distance (et donc pour ne plus avoir un moniteur et un clavier) je pourrai tout aussi bien le faire depuis mon réseau local en ajoutant un adaptateur USB/ethernet. Qu'en penses-tu ? Pourquoi passer par Internet ?

Cela donnerait :

Internet -- Box -- Passerelle flitrante (OBSD) -- Mon réseau local -- ssh inside -------------|
|____ Serveur (OBSD) titi.chezmoi.tld <------ adaptateur USB/ethernet --------|

(2) un serveur DNS primaire faisant autorité sur ma zone (et pour le serveur DNS secondaire faisant aurorité sur ma zone, j'en ai un offert chez gandi et j'ai une proposition de 22decembre)

(3) un serveur de messagerie maître (et pour l'esclave je verrai bien)

Citation :Personnellement, je ne mettrais pas un serveur @home directement derrière la FAI-Box.

thuban l'a fait ?! ;-)

Citation :Sincèrement, je ne m’embêterais pas autant.

Ta GW filtrante, tu lui mets trois pattes, une pour ton LAN, l'autre pour ta DMZ.

Oui j'avais pensé à la 3ème patte (mais avec OpenBSD). Cela donnerait cela :

Internet -- Box -- Passerelle flitrante (OBSD) -- Mon réseau local
|
|
adaptateur USB/ethernet |
(+ssh réseau local |
et le server uniquement) |____ Serveur (OBSD) titi.chezmoi.tld

Citation :Tu installes dessus une distribution, telle pfsense, voire OPNsense - que je plussoie ; les màj systèmes sont vraiment régulières et pertinentes ; je suis vraiment "bluffé" par cette distribution "HardenedBSD"...-, qui t'assurera sans coup férir, et mieux que toi, les fonctions de pare-feu, les fonctions DNS, DHCP - IPv4+6,

Oui je connais de nom Pfsense et HardenedBSD* ce qui n'est pas le cas de OPNsense (OpenSense non ?). Sur le principe, je suis d'accord avec toi. Ce sont des projets spécifiques et spécialisés. Il faut que je creuse et que je voie effectivement si l'un des trois ne peut pas remplacer ma passerelle filtrante...

*Lors de mes installations multiples de FreeBSD ces derniers temps, j'ai constatés de nouvelles options pour durcir la sécurité d'un système FreeBSD dès son installation. Je pense qu'il y a un lien avec son fork HardenedBSD.

Citation :et tout autre fonction qui t'intéresse. Alors, oui, ce n'est pas formateur, au sens, où tu n'apprendras pas à faire, mais plutôt à gérer !

... car effectivement pour le serveur, j'aimerais bien le créer moi-même de zéro ! Créer une passerelle filtrante, je l'ai fait et je l'ai refais maintes fois. Par contre, ce serveur (serveur DNS primaire + service de messagerie) c'est tout nouveau pour moi. Il faut que je le fasse pour mieux comprendre, plus tard éventuellement, ce qui peut bien se dérouler dans des solutions "clef en main" comme Pfsense. Tu comprends PengouinBSD ? Je sais bien que je ne choisis pas la voie la plus simple et la plus rapide mais il s'agit très certainement de la voie la plus formatrice. Je ne suis pas sur obsd4a avec vous par hasard ! ;-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#24

Je ne suis pas, moi-même, par hasard sur obsd4* Wink

Non, c'est bien OPNsense, fork de pfsense, que je trouve bien plus agréable à administrer, et à entretenir que son parent.

Donc, pour récapituler, ton serveur te sert de DNS primaire, - SSH étant installé pour l'administrer, je suppose ; là, il suffit de bien maîtriser tes options SSH, pour le blinder, telle que connexion uniquement par clés, etc ... - et ?
Bref, même dans ce contexte, il peut être en DMZ, car tu rediriges le trafic IP (IPv4 et/ou IPv6) vers ce serveur ou un autre à vrai dire. Et, il vaut mieux qu'il soit en DMZ, à la fois pour protéger ton LAN, et à la fois pour répondre à tes besoins.
Bien comprendre que la DMZ est en réalité un artefact lié à la translation NAT, nécessité par IPv4 ! Wink
Cela n'a plus aucun sens en IPv6.

GPG:Fingerprint ed25519 : 072A 4DA2 8AFD 868D 74CF  9EA2 B85E 9ADA C377 5E8E
GPG:Fingerprint rsa4096 : 4E0D 4AF7 77F5 0FAE A35D  5B62 D0FF 7361 59BF 1733
Répondre
#25

Citation :Je ne suis pas, moi-même, par hasard sur obsd4* ?

Je sais. Je te taquinais. ;-)

Non, c'est bien OPNsense, fork de pfsense, que je trouve bien plus agréable à administrer, et à entretenir que son parent.

Ok. Étrange pour "OPNsense" et pas "Opensense" ?! Enfin, les forkeurs avaient très certainement une bonne raison d'appeler leur fork ainsi.

Citation :Donc, pour récapituler, ton serveur te sert de DNS primaire, - SSH étant installé pour l'administrer, je suppose ;

Globalement c'est cela.

Citation :là, il suffit de bien maîtriser tes options SSH, pour le blinder, telle que connexion uniquement par clés, etc ... - et ?

Là j'ai un lien au top pour cela : https://blog.stephane-huc.net/doku.php (actullement en réparartion mais au top ;-))

Citation :Bref, même dans ce contexte, il peut être en DMZ, car tu rediriges le trafic IP (IPv4 et/ou IPv6) vers ce serveur ou un autre à vrai dire. Et, il vaut mieux qu'il soit en DMZ, à la fois pour protéger ton LAN, et à la fois pour répondre à tes besoins.

Ok. C'est ce que je pensais. Merci de confirmer.

Citation :Bien comprendre que la DMZ est en réalité un artefact lié à la translation NAT, nécessité par IPv4 ! ?
Cela n'a plus aucun sens en IPv6.

Oui bah, pour ma part, j'suis très certainement borné mais j'apprécie le côté facile et automatique (car nécessité) de mise en place de la NAT d'IPV4. Pour IPv6 que je ne connais pas du tout, je suppose que l'on fait de la "translation d'adresse" avec des redirections dans pf. Non ?

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)