J'essaie d'établir un serveur de messagerie / calendrier personnel chez moi (oui, j'ai entendu dire que c'est difficile, c'est beaucoup de problèmes, etc., mais j'aimerais quand même essayer). J'ai un FAI qui n'offre pas d'adresses IP statiques, il semble donc qu'une sorte de service de nom de domaine dynamique (DDNS) soit la solution.
Cependant, j'ai fait des recherches et j'ai trouvé au moins quelques ressources en ligne qui expliquent que vous pouvez faire vous-même le DDNS: vous devez avoir un script / programme qui surveille périodiquement votre adresse IP et si l'adresse change , alors le script / l'application doit mettre à jour le nom de domaine que vous utilisez pour vos serveurs domestiques (il se trouve que j'ai un domaine parqué auprès d'un hébergeur pour cette éventualité, et si je comprends bien, j'ai juste besoin de la clé API de la société d'hébergement afin d'ajuster les enregistrements de domaine / IP nécessaires par programmation ... quelqu'un m'a fait savoir si je me trompe et il existe un moyen plus simple).
Voici la chose: lorsque vous mettez à jour vos enregistrements de nom de domaine de la manière que j'ai décrite ci-dessus, j'ai lu que la propagation dans le système / le monde peut prendre plusieurs heures (tous les serveurs DNS doivent être remplis avec votre adresse mise à jour) ). Cependant, plusieurs fournisseurs DDNS payants que j'ai consultés semblent promouvoir leur capacité à faire en sorte que le changement prenne effet presque instantanément (ou au moins, plus rapidement que ma méthode de bricolage). Est-ce vrai? Y a-t-il quelque chose que j'ai manqué?
De plus, j'ai une autre préoccupation: y a-t-il des problèmes de sécurité que je pourrais ignorer avec un fournisseur DDNS? Ne pourront-ils pas surveiller tout le trafic passant par le nom de domaine qu'ils fournissent? Quelqu'un a-t-il une opinion éclairée sur la méthode (payante ou bricolage) qui pourrait être la meilleure?
J'apprécie votre temps ... merci!
la source
Réponses:
Vous n'aurez probablement pas beaucoup de chance avec la partie courrier. Voir la réponse d'Alex @.
À peu près ça.
Oui, bien que si la société fournit simplement un service générique "tout héberger", il se peut qu'elle ne dispose pas du tout d'API de gestion DNS (se concentrant plutôt sur le Web et la messagerie) et que vous deviez déplacer le domaine ailleurs.
Non. Seuls les systèmes de votre fournisseur d'hébergement DNS doivent être mis à jour. Le reste du monde ne tient pas de registre permanent - il met simplement en cache les résultats des recherches individuelles, pour la durée indiquée dans le champ "TTL" (Time To Live) de chaque (sous) domaine.
Je suppose qu'ils permettent de configurer un TTL très bas sur les domaines dynamiques (jusqu'à quelques secondes), ce qui signifie qu'il disparaîtra très rapidement de tous les caches, au prix du fournisseur DDNS lui-même recevant beaucoup plus de demandes (plus élevé charger sur leurs serveurs DNS et bases de données, et une excuse pour vous facturer plus). Cela seul n'est pas quelque chose de spécial et pourrait être mis en œuvre avec n'importe quelle méthode de bricolage.
Non. Le serveur DNS ne vous fournit qu'une adresse (un peu comme un annuaire téléphonique) et n'est impliqué dans aucune autre communication.
(À moins que le fournisseur n'essaye réellement de renvoyer de fausses données , ce qui raccourcirait considérablement le TTL de la société au moment où les sites d'information en auraient connaissance.)
Cela dit, faites attention au fonctionnement de l'API; bien sûr, vous ne pouvez pas être sûr que le service ne présente aucune vulnérabilité, mais si (par exemple) l'API s'exécute sur HTTP non chiffré et transmet la clé d'API à la vue, alors ce n'est pas quelque chose sur lequel vous voulez vous fier.
la source
Si vous n'avez pas d'adresse IP statique, vous devez oublier le serveur de messagerie si vous optez pour la solution DDNS, la plupart des serveurs de messagerie rejetteraient vos e-mails ou marqueraient les e-mails avec le niveau de spam le plus élevé car toutes les adresses IP dynamiques sont dans des listes PBL . ( Vous pouvez voir plus de détails dans la section PS pourquoi ce n'est pas une bonne idée d'avoir un serveur de messagerie sur IP résidentielle, mais il existe toujours une solution de contournement en utilisant des VPS intermédiaires bon marché (serveur privé virtuel) )
En ce qui concerne "DDNS vous-même" - un bon registraire de domaine fournissant une mise à jour gratuite de l'IP via son API, tout ce que votre programme doit faire est de vérifier périodiquement l'IP publique et s'il change, envoyez une nouvelle IP au registraire qui mettra à jour un enregistrement AAAA. BTW, la plupart des routeurs actuels ont déjà une telle fonctionnalité (surveillez l'IP et signalez au fournisseur DDNS)
Cela dépend du fournisseur DNS, les registraires respectueux permettent de définir TTL (temps qui indique aux autres à quelle fréquence IP peut être changé) égal à 5 minutes. Tous les serveurs DNS intermédiaires de transfert ne suivent pas cela pour éviter un chargement élevé, mais généralement même s'ils ne suivent pas le TTL du propriétaire du domaine, cela dure rarement plus de quelques heures. La plupart des redirecteurs mettront à jour leurs caches comme vous le feriez dans le domaine TTL.
Aller en ligne est déjà un problème de sécurité possible. Isolez votre serveur du réseau local pour éviter les invités indésirables.
Vous jetterez votre temps et votre argent en l'air si vous optez pour le DDNS. De nos jours, vous pouvez obtenir un VPS décent (serveur privé virtuel) pour 3-4 dollars par mois. Alors que le site Web (si vous prévoyez d'en avoir un) peut être hébergé directement sur VPS, car il ne prend généralement pas beaucoup d'espace, le serveur de messagerie peut être problématique si vous prévoyez d'exécuter votre serveur pendant une longue période ou si vous vous attendez à un volume élevé de courriels. Généralement 20 Go d'espace suffisant pour les petites entreprises jusqu'à 3 à 5 ans, même sans supprimer les anciens e-mails. Même si vous attendez une énorme quantité de courriels, vous pouvez utiliser
nginxfonction de proxy du trafic de messagerie vers votre domicile. Ainsi, vous pouvez héberger le serveur de messagerie principal à la maison sur IP dynamique et VPS (qui a une adresse IP statique) proxy le trafic entrant / sortant vers votre domicile. Vous pouvez utiliser votre propre VPS dans une telle configuration sans douleur car il n'y a pas besoin de s'inquiéter de la propagation DNS, le domaine pointera toujours vers l'IP statique du VPS. Vous devez toujours gérer la notification de vos modifications d'adresse IP domestique sur VPS, afin que VPS sache où acheminer le trafic, mais c'est beaucoup plus facile, il suffit d'interroger une URL sur votre VPS et d'analyser dans les journaux votre IP entrante et d'ajuster nginx, afin qu'il sache toujours là où tu es.PS
Je peux voir que ce sujet est intéressant pour les super-utilisateurs, alors j'ajouterais un peu plus de détails.
PBL listes contiennent une base de données d'adresses IP qui sont généralement des adresses IP dynamiques, donc PBL aide beaucoup les opérateurs de serveurs de messagerie. Ce n'est pas un problème technique ou les FAI sont des méchants pour ne pas autoriser le serveur de messagerie sur les IP dynamiques, le problème est que la plupart du trafic de messagerie provenant d'IP dynamiques provient d'ordinateurs infectés qui envoient du spam ou des logiciels malveillants à un volume énorme qui peut facilement recevoir des DDoS serveur si l'on est une cible. Certains FAI bloquent les connexions sortantes vers le port 25 pour empêcher la propagation de logiciels malveillants et de DDoS , mais d'autres non. Pratiquement tous les serveurs de messagerie d'entreprise abandonnent simplement les connexions provenant de la liste PBL, ce qui réduit considérablement le spam.
La deuxième solution antispam efficace consiste à supprimer les connexions d'adresses IP qui n'ont pas d'enregistrement PTR inversé dans DNS et ne correspondent pas à l'enregistrement DNS du domaine. Même si les connexions proviennent d'une adresse IP statique qui n'a pas d'enregistrement PTR, il s'agit généralement d'une configuration mal configurée ou principalement de serveurs exécutés par des gangs de spam (il peut y avoir des exclusions pour certains grands fournisseurs (mais négligents), mais ils peuvent être ajoutés manuellement dans la liste blanche). Bien qu'il s'agisse de quelques minutes pour définir l'enregistrement PTR inverse sur VPS, ce n'est pas le cas si les adresses IP statiques obtenues auprès du FAI et le processus pour définir PTR est généralement un PITA (il faut les appeler, soumettre un ticket après vérification) que vous êtes le propriétaire d'origine de l'IP et attendez la pitié de leur administrateur système qui doit définir un enregistrement PTR inversé, parfois en quelques heures, mais parfois en quelques jours)
De plus, ce n'est pas critique, mais ... pour éviter la falsification des e-mails, la plupart des propriétaires de serveurs de messagerie utilisent ce que l'on appelle SPF (sender policy framework) qui permet de spécifier la méthode de traitement des politiques la plus rapide si une adresse IP DNS autorisée autorise l'envoi d'e-mails. au nom du domaine. (on peut spécifier les serveurs autorisés par FQDN comme référence à l'enregistrement MX, mais cela fait des allers-retours supplémentaires sur DNS pour connecter les serveurs) Donc, la gestion d'une IP flottante dans DNS ne serait pas amusante.
la source
Voilà une solution. Comme exemple d'une autre solution, un tunnel IPv6 HurricaneElectric.net fournit une adresse statique (IPv6) avec un point de terminaison de tunnel mobile. Certes, pour le moment, IPv4 serait plus agréable à supporter pour une telle fonctionnalité auprès du grand public, mais si vous pouvez trouver un ordinateur coopératif disposé, vous pourriez techniquement faire une telle chose avec IPv4 aussi.
Cela ressemble à un plan techniquement solide.
Les détails exacts dépendraient du choix du registraire de nom de domaine quant à la façon dont il implémenterait cette fonctionnalité. Certains peuvent utiliser une clé API quelconque, tandis que d'autres peuvent s'appuyer sur une interface Web pour les mises à jour automatiques. Autrefois, certains FAI fournissaient un tel service, mais comptaient sur des changements manuels en réponse aux demandes. Il appartient donc entièrement à celui qui vous fournit le service.
Bah humbug. La propagation DNS est connue pour prendre des minutes, des heures ou des jours (par exemple, 72 heures). Cependant, lorsque les gens ont analysé les choses en profondeur, ils ont constaté qu'une grande partie de ce temps de "propagation" vague venait simplement d'un fournisseur d'hébergement DNS qui était lent à mettre à jour.
Dans une meilleure théorie, vous devez simplement attendre la valeur TTL. Bien qu'il y ait un problème avec cette théorie ...
D'accord, voici la réalité: pour que votre mise à jour prenne pleinement effet, vous devez avoir Internet vider son cache actif d'anciennes informations.
Selon les normes, la mise en cache des serveurs DNS peut s'appuyer sur leur cache pendant la durée spécifiée par une valeur TTL que vous pouvez configurer.
Cependant, la réalité est qu'au moins certains (et peut-être même la plupart?) De très grands FAI sont connus pour exécuter leurs propres serveurs DNS de mise en cache qui sont connus pour ignorer complètement les valeurs TTL. Ils le font parce qu'ils ont l'impression que s'ils mettent à jour leurs caches DNS moins fréquemment, l'effet global sera moins de bande passante (et peut-être un peu moins de temps de calcul).
Par conséquent, tout serveur de messagerie qui s'appuie sur un tel serveur DNS peut être affecté et ne pas être en mesure de remarquer vos mises à jour jusqu'à ce que le serveur DNS soit mis à jour. Dans certains cas, cela peut prendre un jour ou deux (ou trois?).
Cependant, ces effets sont devenus de plus en plus rares. Dans la pratique, la plupart des serveurs DNS verront leurs caches vidés dans une heure ou deux.
Étant donné que certains caches ne seront pas mis à jour aussi rapidement que d'autres, il en résulte que certains endroits sur Internet fonctionneront avec la nouvelle adresse, tandis que d'autres endroits essaieront toujours d'utiliser l'ancienne adresse. En quelques heures, la plupart des ordinateurs fonctionnent très bien avec les nouvelles informations. (Beaucoup, beaucoup d'entre eux peuvent fonctionner en quelques minutes.)
Le comportement typique du logiciel de courrier électronique consiste à essayer d'envoyer le courrier électronique. Si cela échoue, réessayez plus tard. Les serveurs de messagerie continueront généralement à réessayer (peut-être environ une fois par heure) pendant des jours avant d'abandonner. Donc, ce qui risque de se produire, c'est que vous ne perdrez pas votre courrier électronique, mais cela sera un peu retardé.
Le commentaire d'Alex "toutes les adresses IP dynamiques sont dans des listes PBL" est clairement faux, car ces informations sont décentralisées (donc le mot "tous" est inexact), mais il est vrai que de nombreuses adresses IP dynamiques sont dans de telles listes, et donc cela peut signifie que certains ordinateurs / appareils liés au courrier électronique peuvent décider de ne pas coopérer avec vous.
La plus grande préoccupation sera de savoir si vos mises à jour sont gérées de manière sécurisée.
Non. Le travail du serveur DNS consiste à recevoir une demande de nom de domaine et à fournir une réponse. La réponse typique traditionnelle consiste à fournir une ou plusieurs adresses IP. D'autres réponses sont possibles, comme faire référence à un autre serveur DNS ou nom de domaine (par exemple, avec un CNAME), ou à d'autres données (par exemple, aider à assurer la sécurité via la nouvelle norme DNSSec).
Je voudrais souligner que si vous voulez vraiment exécuter un serveur de messagerie sérieux, vous voudrez peut-être envisager d'être conforme aux normes de messagerie modernes. Cela implique plus que la simple conformité aux spécifications techniques SMTP et DNS. Beaucoup de gens utilisent de grands fournisseurs, et ces grands fournisseurs peuvent mettre en œuvre leurs propres attentes.
Par exemple, je connais un serveur de messagerie qui a été installé avec Debian et Postgrey il y a des années. Postgrey est un logiciel qui fournit une gestion anti-spam "en liste grise". Toutefois, la version de Postgrey utilisée suppose que lorsqu'un serveur de courrier électronique réessaye le courrier électronique, le serveur de courrier électronique expéditeur utilise la même adresse IP pour ce faire. Les serveurs de messagerie Office 365 sont connus pour réessayer d'envoyer un courrier électronique à partir d'une adresse IP différente qui se trouve toujours dans un sous-réseau IPv6 / 64. Postgrey n'aime pas ça.
Comme de plus en plus d'organisations sont passées à Office 365, cela est devenu de plus en plus un problème pour les personnes utilisant cet ancien serveur de messagerie. Une version plus récente du logiciel Postgrey a été publiée, mais le moyen facile d'installer un tel logiciel est d'utiliser le référentiel de logiciels officiel pour ce système d'exploitation. Donc, dans la pratique, la façon intelligente de mettre à jour ce logiciel sera de mettre à niveau le système d'exploitation.
Il existe d'autres conventions, telles que les noms DNS qui commencent par «mail». ce qui peut faire en sorte que votre configuration soit jugée plus ou moins fiable. Cela peut avoir un impact sur le fait que les appareils vous traitent comme un spammeur non conforme ou comme un appareil avec lequel il vaut la peine de communiquer.
Bien sûr, peut-être en parlant très strictement des spécifications techniques officielles, les organisations géantes effectuent des actions différentes des exigences minimales exigées par les documents RFC qui contiennent les spécifications techniques des protocoles utilisés. Mais si vous souhaitez communiquer avec la communauté Internet dans son ensemble, il existe des normes supplémentaires qui sont imposées par certains acteurs importants / importants. Soyez prêt à bien respecter ces normes ou soyez prêt à rencontrer des problèmes.
Je suis un peu vague sur ce que sont exactement toutes ces normes, car elles peuvent changer avec le temps.
En ce qui concerne cet ancien serveur de messagerie électronique qui devra mettre à niveau son ancien système d'exploitation Debian, les gens devraient peut-être mettre à niveau leur système d'exploitation plus fréquemment de toute façon. Le point que je fais valoir, cependant, est qu'une configuration logicielle qui fonctionnait parfaitement bien depuis des années est maintenant rompue, en raison d'un comportement plus récent qui est couramment utilisé par de nombreuses adresses de messagerie. Si vous essayez de faire des choses inhabituelles, comme utiliser Dynamic DNS sur un fournisseur Internet plus lent, vous risquez plus de rencontrer des problèmes supplémentaires en cours de route. Comme vous paraissez ambitieux, vous pouvez peut-être y investir vos efforts. Je vous avertis simplement de vous préparer à devoir le faire.
Comme d'autres l'ont souligné, le paiement sera beaucoup plus facile et est assez économique pour la plupart des gens. Les grandes offres sont susceptibles de fournir une adresse IP stable vers laquelle vous pouvez avoir votre point d'enregistrement MX (donc le courrier électronique y va), et peut fournir une meilleure bande passante.
Le bricolage est préférable pour acquérir de l'expérience et apprendre comment les choses fonctionnent, et choisir de ne pas se fier uniquement aux implémentations des grandes entreprises. Avoir plus de contrôle sur votre implémentation peut également vous permettre d'apporter des modifications personnalisées significatives plus rapidement.
Ce qui est "mieux" dépendra de vos objectifs individuels, donc je laisse ces conclusions à vous.
la source
Oui, il est possible d'héberger le serveur DDNS vous-même (en fait, j'ai moi-même écrit une implémentation compatible DynDNS pour les DJBs il y a quelque temps). Vous pouvez utiliser le client DynDNS normal sur IP dynamique pour mettre à jour votre nom DNS, mais le code du serveur devrait toujours s'exécuter quelque part avec une adresse IP statique (car les serveurs GTLD doivent toujours pointer les enregistrements NS de votre domaine vers une IP statique).
De plus, si vous n'hébergez pas votre DNS vous-même mais que vous le déchargez sur un fournisseur DNS tiers, alors il se peut qu'il vous donne l'API pour changer IP comme vous le dites. Il se propagerait probablement plus lentement qu'une solution DDNS appropriée, et vous ne seriez évidemment pas entièrement auto-hébergé mais dépendriez de ce tiers pour les services DNS. Ils ne sont généralement pas malveillants (et il y a tellement d'autres problèmes de sécurité sur Internet pour s'inquiéter davantage), mais je préférerais toujours une solution sous mon contrôle (si rien d'autre, car cela me donne la liberté de choisir mon fournisseur DNS au lieu de étant enfermé).
Je gère également mes propres instances de serveur Calendrier / Contacts / Images au lieu de remettre des données à Google ou à quelqu'un d'autre (en utilisant des instances Open Source Nextcloud et Mediagoblin ). Bien que je les exécute sur "mon" VPS avec des adresses IP statiques (car c'est à la fois plus facile et offre plus de bande passante), les deux pourraient être exécutés sur une IP dynamique que vous avez à la maison.
En outre, comme d'autres l'ont mentionné, pour l'envoi de courrier, vous ne pourrez pas envoyer de courrier fiable directement à partir de ce serveur en raison des listes noires PBL (cela fonctionnera parfois, sera perdu ou renvoyé à d'autres moments, ou marqué comme SPAM), mais si vous '' re OK via le transfert via un autre serveur SMTP (comme à partir de gmail ou de votre FAI) cela fonctionnera très bien.
Cependant, le serveur de courrier entrant (MX) sur IP dynamique serait assez problématique. Par exemple, si le courrier arrive pendant que vous changez d'adresse IP, il est possible qu'il essaie de livrer sur IP que vous aviez il y a quelques instants, mais maintenant un autre client l'a fait. Dans la plupart des cas, cela entraînerait simplement une connexion échouée et donc un courrier retardé, mais si un autre client exécute également un serveur SMTP, le courrier lui serait remis ou rebondi avec une erreur fatale "le destinataire n'existe pas" (qui sera généralement vous désinscrire automatiquement de vos listes de diffusion, etc.). De plus, si votre IP n'a pas de DNS inversé (ou parfois même si elle a l'air dynamique!), Certains serveurs de messagerie refuseront de vous envoyer du courrier.
Mais si un certain pourcentage de courrier perdu ou mal acheminé ne vous pose pas de problème, n'hésitez pas à l'essayer.
Notez qu'il est également possible que votre FAI ait des règles vous interdisant d'exécuter des services sur votre "Internet grand public" à bas prix, et puisse vous arrêter s'il vous trouve rompre le contrat. Ou ils pourraient même bloquer activement toutes les connexions entrantes à votre domicile sur des ports populaires en nombre restreint comme tcp / 25, 80, 443, etc., ce qui pourrait détruire votre idée de l'auto-hébergement (à moins que vous ne changiez de fournisseur de services Internet ou que vous optiez pour une classe commerciale plus chère) "qui possède également généralement des adresses IP statiques).
Et la dernière chose à noter est que dans de nombreuses connexions Internet domestiques grand public (comme l'ADSL, le câble, etc.), la vitesse est asymétrique - c'est-à-dire que votre téléchargement est beaucoup plus rapide que votre vitesse de téléchargement. Ce qui est mauvais si vous souhaitez diffuser un contenu public plus important comme des images (au lieu de vous fier à Facebook ou Google pour cela et à renoncer à vos droits) depuis votre domicile, car cela sera lent (pas aussi pour le gars qui télécharge des images de vous, mais aussi pour toute votre connexion Internet).
la source
D'autres réponses ont déjà expliqué la partie DDNS.
Je vais expliquer pourquoi vous devez utiliser un serveur distinct pour envoyer des e-mails (car la brève explication de @Alex est incomplète).
Plus important encore, vous avez besoin d'un enregistrement PTR inverse valide pour envoyer des e-mails - de nombreux serveurs de messagerie le vérifieront et rebondiront votre courrier, si l'enregistrement DNS inversé pour l'adresse IP ne correspond pas au domaine de l'expéditeur. Cet enregistrement est fourni par le propriétaire de l'adresse IP - par exemple par votre FAI.
Imaginons maintenant que vous soyez en quelque sorte devenu valide, en mettant à jour dynamiquement le DNS inverse (ha-ha). Vous devez encore convaincre tout le monde, que votre domaine est légitime et que votre e-mail sortant n'est pas du spam.
Comme expliqué par @Alex, les petits hébergeurs de messagerie adorent utiliser spamhaus et d'autres listes noires en ligne. Mais j'ai vu ces administrateurs d'entreprise faire beaucoup d'autres choses stupides (comme bloquer tous les e-mails, qui ne proviennent pas de Gmail / Hotmail). En fait, ce ne sont pas seulement des "administrateurs d'entreprise" - j'ai vu Sourceforge bloquer l'enregistrement du domaine de messagerie d'entreprise légitime, car "nous ne savons pas pourquoi, mais notre filtre anti-spam pense que vous êtes mauvais". Ignorez-les simplement - vous ne pouvez pas rester compatible avec tout le monde sous le ciel.
Les énormes hébergeurs de messagerie de nos jours ne comptent pas sur spamhaus ou autre PBL. Ils suivent eux-mêmes votre fiabilité. La réputation de l'expéditeur (au moins la plupart) est attachée à l'IP. En effet, les spammeurs reçoivent souvent un démarrage de leurs hébergeurs, ils sont donc obligés de sauter les IP. Du point de vue de Gmail, votre domaine / IP récemment créé n'est pas différent du spammeur commun. Lorsque vous commencez à envoyer des e-mails, votre réputation est faible (vous êtes traité comme spammeur par défaut!). La plupart de vos e-mails sortants seront marqués comme spam. Lorsque quelqu'un répond à votre e-mail ou le marque en particulier comme légitime (en appuyant sur le bouton correspondant dans l'interface Web de son fournisseur de messagerie), la confiance envers vous augmentera légèrement. Comme vous pouvez le voir, pour accroître la réputation de l'expéditeur, vous devez utiliser le même domaine sur la même IP au fil des ans. Ceci peut'
Une fois que vous louez un VPS auprès de l'hébergeur, garder un serveur domestique sur IP dynamique deviendra beaucoup plus facile. Vous pourrez utiliser ce VPS comme votre propre serveur DDNS avec un TTL extrêmement faible. Vous pourriez même être en mesure de renoncer au DNS et d'utiliser d'autres moyens (tels que la redirection HTTP) pour gérer la modification de l'adresse IP de votre box d'origine. Vous serez toujours en mesure de recevoir des e-mails directement dans votre box d'origine - éventuellement avec retour au VPS, lorsque votre IP domestique est en panne ou récemment modifiée.
la source
Cela peut être fait sur CPanel en utilisant un script PHP - assurez-vous simplement de définir correctement votre sécurité (HTTPS, etc.) et de lire les ToS de votre hébergeur.
https://www.shadowsplace.net/1231/internet/use-whm-cpanel-as-dynamic-dns-service/
Si vous imitez un schéma d'URL de fournisseurs DNS dynamiques populaires, vous pouvez utiliser les fonctions DNS dynamiques intégrées dans les équipements de la «boîte noire» (par exemple NAS, IP Cam, etc.) et demander à votre routeur de rediriger la demande vers votre hôte à la place. .
la source
Mon humble additon au service Dyndns, qui est gratuit et fonctionne sur de nombreux systèmes (également sur des routeurs) - freedns.afraid.org
Je l'utilise pour que mon adresse IP personnelle pointe vers un nom de domaine sélectionné que la liste propose gratuitement. Mon rPi exécute le script "curl" et cela fonctionne bien pour moi (enfin, puisque je n'exécute pas de serveur de messagerie, ce n'est pas un problème si 10 minutes ne sont pas disponibles).
J'ai eu la même idée pour exécuter le serveur de messagerie également à la maison, mais le FAI a bloqué le trafic, j'ai donc dû l'abandonner :-(
Meilleures salutations.
la source