Bonjour, bonsoir.
Pour vous signaler que :
Pour mon "VPS" chez OVH : root@uc1:~ # host 135.125.133.51
51.133.125.135.in-addr.arpa domain name pointer vps.zw3b.eu.
root@uc1:~ # host 2001:41d0:701:1100::6530
0.3.5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.1.0.7.0.0.d.1.4.1.0.0.2.ip6.arpa domain name pointer vps.zw3b.eu.
En fait c'est ICI (je viens de trouver l'option at 23h20 2024-02-04) :
J'ajoute les "routes" vers leurs passerelles sur/de mon VPS (on s'aperçoit que la passerelle est "au dessus/
au dessous (comme dire?)" de mon IPv6::/128 en "
0001" pour "
6530" -- chose normale/logique puisque c'est un VPS (cette passerelle doit avoir plusieurs Virtual Private Server sur "elle-même") :
root@vps:~ # ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
[...]
default via 2001:41d0:701:1100::1 dev vmbr0 metric 1024 onlink pref mediumroot@vps:~ # ip -4 route show
default via 135.125.132.1 dev vmbr0 onlink
[...]Pour mon "serveur dédié" chez OVH : root@uc1:~ # host 158.69.126.137
137.126.69.158.in-addr.arpa domain name pointer mail.zw3b.eu.
root@uc1:~ # host 2607:5300:60:9389::
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ovh.lab3w.com.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer ovh.lab3w.fr.
root@uc1:~ # host 2607:5300:60:9389::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer wan.ipv10.net.
J'ajoute les "routes" vers leurs passerelles sur/de mon serveur dédié (on s'aperçoit que la passerelle IPv6 est au dessus "93
ff" de mon bloc "93
89" -- chose normale/logique puisque elle gère toutes mes adresse d'un ou plusieurs blocs IPv6::/64 - elle est exactement où il faut (en "FF" pour tout les blocs IPv6::/64 -- par exemple le mien le "89")) :
root@lab3w:~ # ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
[...]
default via 2607:5300:60:93ff:ff:ff:ff:fe dev vmbr0 metric 1024 onlink pref mediumroot@lab3w:~ # ip -4 route show
default via 158.69.126.254 dev vmbr0 onlink
[...]Je ne retrouve pas l'option
"Délégation de blocs IPv6" sur la page OVH "Network - IP (la 2eme imprime écran)"
qui m'avait permis d'activer mes NS (Name Serveurs).
----
Sinon ;
Sans vouloir embrouiller tout le monde, pour le reverse DNS IPv4 -- il faudrait pouvoir déclarer plusieurs PTR/NOMss !
C'est un bon exemple, j'ai dû configurer "mail.zw3b.eu" pour que les serveurs de mails "récepteurs" (gmail, hotmail etc) acceptent mes mails ; Eux qui veulent à tout pris avoir le bon "rDNS" du serveur mail envoyeur (moi).
Mon serveur mail est sur l'IPv6 suivante (mais si je devais configurer "mail.client_1_domain.com" çà me retournerait "une erreur" - Enfin plutôt les mails envoyé depuis "mon IPv4" et ce nom ne serait pas bien vu et leurs mails risqueraient de ne pas rentrer chez l'hébergeur de mails récepteur (hotmail, gmail etc.).
root@vps:~ # host mail.zw3b.eu
mail.zw3b.eu has address 158.69.126.137
mail.zw3b.eu has IPv6 address 2607:5300:60:9389:17:4c1:0:1a
mail.zw3b.eu mail is handled by 10 smtp.zw3b.eu.
root@vps:~ # host 2607:5300:60:9389:17:4c1:0:1a
a.1.0.0.0.0.0.0.1.c.4.0.7.1.0.0.9.8.3.9.0.6.0.0.0.0.3.5.7.0.6.2.ip6.arpa domain name pointer mail.zw3b.eu.Même avec le SNI (Server Name Indicator) etc.. çà fait perdre des points sur les tests mails DMARC (Domain-based Message Authentication, Reporting, and Conformance) et compagnies de bonne conformité de mails etc.
Par exemple le site
https://mail-tester.com me retourne 10/10 même en envoyant avec des serveurs "proxy" en sous-domaine de mon/mes noms de domaine".
Par exemple à la place d'être un "utilisateur normal" avec une adresse mail normale (ex: mon_mail@mondomain.com --> en sous-domaine veut dire -> contact@newsletter.mondomain.com ou no-reply@newsletter.mondomain.com - pour que vous compreniez du sous domaine "newsletter" de mon nom de domaine
)
Pour exemple "j'ai autorisé mon serveur web 2 à envoyer des mails valident et bien conforme" - contre l'usurpation d'identité de mon nom" grâce au protocole DMARC (ici on parle de la signature numérique DKIM et SPF (adressses IP des serveurs envoyeurs)), eux dirais-je, ils ont l'anti-spams DMARC (qui vérifient que les mails qu'ils reçoivent sont bien valident, conforment, qu'ils ont bien étés signés).
J'ai bien ma politique DMARC active sur mon serveur "ww2.zw3b.eu" (ce qui me permet d'envoyer des mails conforment en "un_mail@ww2.zw3b.eu") ->
https://mxtoolbox.com/SuperTool.aspx?action=mx%3aww2.zw3b.eu&run=toolpage----
Bon j'suis limite hors sujet du fil de cette discussion :/ Merci à vous, pour celles et ceux qui comprennent, il faut sauver tous ces protocoles de communication, pour nous, ce sont nous les travailleurs et nous les utilisateurs
----
RFC 2181 : Clarifications to the DNS Specification → Enregistrements PTR (July 1997)
La confusion au sujet des noms canoniques a conduit à croire qu’un enregistrement PTR devrait avoir exactement un RR dans son RRSet. C’est incorrect, la section pertinente de la RFC1034 (section 3.6.2) indique que la valeur d’un enregistrement PTR doit être un nom canonique. Autrement dit, il ne devrait pas s’agir d’un pseudonyme. Rien dans cet article n’implique qu’un seul enregistrement PTR soit autorisé pour un nom. Aucune restriction de ce type ne devrait être déduite.
Notez que même si la valeur d’un enregistrement PTR ne doit pas être un alias, il n’est pas obligatoire que le processus de résolution d’un enregistrement PTR ne rencontre aucun alias. L’étiquette recherchée pour une valeur PTR peut avoir un enregistrement CNAME. Autrement dit, il pourrait s’agir d’un pseudonyme. La valeur de ce RR CNAME, sinon un autre alias, ce qui ne devrait pas être le cas, donnera l’emplacement où se trouve l’enregistrement PTR. Cet enregistrement donne le résultat de la recherche du type PTR. Ce résultat final, la valeur du RR PTR, est le label qui ne doit pas être un alias.
Bonne soirée à toutes et à tous.
Thious !
Salutations,
Romain
IPv6