Et moi, bah je ne vois pas l'intérêt de configurer chez mon fournisseur de nom de domaine pcdusalon.mamaison.xyz, alors qu'un bête dnsmasq avec un fichier /etc/hosts va faire l'affaire, à la fois pour le DHCPD, et le nom de domaine.
Quand pcdusalon se connecte au DHCP, fourni par dnsmasq, ce dernier regarde dans sa table l'IP à lui fournir, et est capable de répondre avec cette même IP à une requête DNS.
Ne pas le faire en local signifierait de devoir configurer ça à deux endroits différents, v'là la prise de tête, et la complexité.
J'ai un fichier /etc/ethers qui associe une adresse MAC à un nom de machine, à configurer une fois par nouvelle machine.
Un fichier /etc/hosts qui associe un nom de machine à une IP, à configurer une fois par changement de pile IP.
Un logiciel qui fournit tout ça automatiquement, et permet de laisser les autres machines en mode DHCP, dnsmasq, qui en plus sert de cache DNS, c'est toujours utile.
Et ça fonctionne même si la ligne internet est coupée : je peux encore accéder à mes machines par leurs petits noms mignons.
Et je sais quelles IPs locales, fournies par mon DHCPCD, ne sont pas reconnues, c'est la plage d'adresse publiques, et je peux configurer leur réseau, et le firewall, pour les limiter, donc un visiteur n'aura pas les mêmes accès que moi.
Ça s'appelle la gestion d'un réseau local.
Face à ça, l'intérêt d'aller configurer le DNS à l'extérieur, je vois vraiment pas.
pcdusalon, c'est privé, ça n'a aucune valeur en dehors de chez moi, même pour moi hors de chez moi, ça reste privé et basta.
Au pire j'ai une machine accessible en SSH depuis internet, et je saute sur pcdusalon depuis celle-ci.
C'est à dire que d'abord je rentre chez moi, et ensuite je vais voir pcdusalon.
Et c'est certes obligatoire en IPv4, mais ça reste pertinent en IPv6.
Parce que même si toutes mes machines ont une IP publique, je vais restreindre la surface d'attaque en laissant un unique SSH accessible à travers le pare-feu, je sauterai toujours à partir d'elle vers le reste du réseau.
Donc je n'ai jamais besoin d'avoir le DNS de pcdusalon.mamaison.xyz sur internet.
Et si pcdusalon héberge un site web public, et bien j'aurais un DNS vers monsiteweb.fr, qui pointerait vers son IP publique, ou plus probablement le reverse proxy que j'ai mis en frontal, ici pour ne pas exposer le serveur web de pcdusalon directement, mais avoir une couche de sécurité en plus, pour pré-filtrer des attaques par exemples, ou rediriger le HTTP vers le HTTPS.
On fait ça nettement mieux avec un haproxy qu'avec un thttpd.
Le DNS local, ce n'est même pas une question de sécurité juste de valeur, de portée, et d'accessibilité, de la donnée.
C'est décorrélé de la sécurité, c'est juste une question de pertinence.
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . En réponse au journal IPv6, cela en valait-il la peine ?. Évalué à 4.
Et moi, bah je ne vois pas l'intérêt de configurer chez mon fournisseur de nom de domaine pcdusalon.mamaison.xyz, alors qu'un bête dnsmasq avec un fichier /etc/hosts va faire l'affaire, à la fois pour le DHCPD, et le nom de domaine.
Quand pcdusalon se connecte au DHCP, fourni par dnsmasq, ce dernier regarde dans sa table l'IP à lui fournir, et est capable de répondre avec cette même IP à une requête DNS.
Ne pas le faire en local signifierait de devoir configurer ça à deux endroits différents, v'là la prise de tête, et la complexité.
J'ai un fichier /etc/ethers qui associe une adresse MAC à un nom de machine, à configurer une fois par nouvelle machine.
Un fichier /etc/hosts qui associe un nom de machine à une IP, à configurer une fois par changement de pile IP.
Un logiciel qui fournit tout ça automatiquement, et permet de laisser les autres machines en mode DHCP, dnsmasq, qui en plus sert de cache DNS, c'est toujours utile.
Et ça fonctionne même si la ligne internet est coupée : je peux encore accéder à mes machines par leurs petits noms mignons.
Et je sais quelles IPs locales, fournies par mon DHCPCD, ne sont pas reconnues, c'est la plage d'adresse publiques, et je peux configurer leur réseau, et le firewall, pour les limiter, donc un visiteur n'aura pas les mêmes accès que moi.
Ça s'appelle la gestion d'un réseau local.
Face à ça, l'intérêt d'aller configurer le DNS à l'extérieur, je vois vraiment pas.
pcdusalon, c'est privé, ça n'a aucune valeur en dehors de chez moi, même pour moi hors de chez moi, ça reste privé et basta.
Au pire j'ai une machine accessible en SSH depuis internet, et je saute sur pcdusalon depuis celle-ci.
C'est à dire que d'abord je rentre chez moi, et ensuite je vais voir pcdusalon.
Et c'est certes obligatoire en IPv4, mais ça reste pertinent en IPv6.
Parce que même si toutes mes machines ont une IP publique, je vais restreindre la surface d'attaque en laissant un unique SSH accessible à travers le pare-feu, je sauterai toujours à partir d'elle vers le reste du réseau.
Donc je n'ai jamais besoin d'avoir le DNS de pcdusalon.mamaison.xyz sur internet.
Et si pcdusalon héberge un site web public, et bien j'aurais un DNS vers monsiteweb.fr, qui pointerait vers son IP publique, ou plus probablement le reverse proxy que j'ai mis en frontal, ici pour ne pas exposer le serveur web de pcdusalon directement, mais avoir une couche de sécurité en plus, pour pré-filtrer des attaques par exemples, ou rediriger le HTTP vers le HTTPS.
On fait ça nettement mieux avec un haproxy qu'avec un thttpd.
Le DNS local, ce n'est même pas une question de sécurité juste de valeur, de portée, et d'accessibilité, de la donnée.
C'est décorrélé de la sécurité, c'est juste une question de pertinence.