La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: HLFH le 28 juillet 2023 à 12:34:25
-
Quel FAI supporte le rDNS/reverse DNS IPv6?
MilkyWan : oui
OVH : peut-être
Orange Pro : non
Free & Free Pro : non https://dev.freebox.fr/bugs/task/12749 (https://dev.freebox.fr/bugs/task/12749).
Orange : non
Bouygues : non
SFR : non
Autres FAI : n'hésitez pas à préciser
-
Nous :)
Orange Pro : oui, vous confirmez ?
Par contre ça j'en doute, Orange n'a pas d'interface pour ça à priori.
-
Merci pour MilkyWan, je vous ai contacté sur le formulaire de votre site.
Pour Orange Pro, peut-être : https://dev.freebox.fr/bugs/task/12749#comment177971.
La personne qui en parlait va confirmer d'ici peu.
-
Il ne faut pas confondre les offres "Pro" et les offres "Entreprises".
Les offres "Pro" sont des offres grand public (que j'abrège GP ensuite) qui ont subi quelques changements (la box peut être différente ou pas) et quelques fonctions (seconde ligne téléphonique par exemple).
Pour Orange depuis la Livebox 5 c'est le même matériel pour Pro / GP (d'où la présence d'un second port RJ-11 inutilisé pour les offres GP).
Les offres entreprises, c'est du sur-mesure, mais le tarif est bien plus élevé.
-
au besoin https://tunnelbroker.net/, pas vraiment un FAI, mais permet d'avoir un un /64 voir meme un /48 avec reverse dns.
Donc ensuite faire un tunnel sur IPv4 avec pour recevoir ce trafic IPv6 sur son FAI.
-
au besoin https://tunnelbroker.net/, pas vraiment un FAI, mais permet d'avoir un un /64 voir meme un /48 avec reverse dns.
Donc ensuite faire un tunnel sur IPv4 avec pour recevoir ce trafic IPv6 sur son FAI.
C'est un peu compliqué à mettre en place mais ça marche en effet.
Le seul problème étant le débit faiblard via le tunnel, qui combiné la propension des navigateurs à privilégier IPv6 donne un résultat pénible.
Il y a peut être des parades mais je n'ai pas poursuivit l'expérience.
-
C'est un peu compliqué à mettre en place mais ça marche en effet.
Le seul problème étant le débit faiblard via le tunnel, qui combiné la propension des navigateurs à privilégier IPv6 donne un résultat pénible.
Il y a peut être des parades mais je n'ai pas poursuivit l'expérience.
Une parade consiste à déployer des adresses ULA (adresses privées en fd::/8) sur le réseau local et à les traduire globalement avec NPTv6 vers le préfixe attribué par Hurricane Electric (c'est assez simple à mettre en œuvre avec un routeur type OpnSense). De cette manière, le réseau disposera bien d'une connectivité IPv6 globale, mais le trafic IPv4 restera prioritaire. Cela n'empêche pas d'assigner directement des GUA sur certaines machines (comme le serveur de messagerie) pour qu'elles communiquent quant à elles en IPv6 préférentiellement. Notez que dans le cas d'un tunnel HE, il faut aussi valider leur niveau de certification "IPv6 Sage" (http://ipv6.he.net/certification/ (http://ipv6.he.net/certification/)) pour obtenir l'ouverture du SMTP sortant.
Une autre possibilité est de prendre un tunnel chez MilkyWAN (https://milkywan.fr/services/tunnel/ (https://milkywan.fr/services/tunnel/)): le débit est supérieur !
-
Quel FAI supporte le rDNS/reverse DNS IPv6?
Orange Pro : oui, vous confirmez ?
Bonjour
Non pas supporté chez Orange sur le monde GP et Pro/ PME
Tout ce qui donne un reverse en abo.wanadoo.fr (le reverse PTR des IPv4/Ipv6 de Orange FR GP / PROPME) que ce soit IPv4 ou IPv6 n'est pas personnalisable.
LeVieux
-
Salut à tous.
A moins de me tromper, on ne peut pas personnaliser le rDNS de chez SFR.
Quand j'ai eu besoin de le faire, je suis passé par Hurricane Electric sur des adresses de Hurricane Electric bien sûr.
-
Bonjour
Non pas supporté chez Orange sur le monde GP et Pro/ PME
Tout ce qui donne un reverse en abo.wanadoo.fr (le reverse PTR des IPv4/Ipv6 de Orange FR GP / PROPME) que ce soit IPv4 ou IPv6 n'est pas personnalisable.
LeVieux
ca m'y fait repenser: la raison historique pèse plus que toute autre raison pour faire perdurer les reverses en abo.wanadoo.fr?
Ca me fait faire un voyage instantané à l'époque France Télécom Câble avec l'âge d'or d'IRC (<2000).
-
Sur IRC, tu pouvais cacher ton PTR en demandant un cloak aux admins ;D
-
ca m'y fait repenser: la raison historique pèse plus que toute autre raison pour faire perdurer les reverses en abo.wanadoo.fr?
Ca me fait faire un voyage instantané à l'époque France Télécom Câble avec l'âge d'or d'IRC (<2000).
Bonjour
Non cela c'est un choix pour raison sécu pour la protection des abonnés.
Je laisserai les pro sécu donner leur analyse de ce point, moi je ne le donnerai pas (même si je la connais)
LeVieux
-
Je serais curieux de savoir en quoi un abo.wanadoo.fr serait mieux niveau sécurité qu'un abo.orange.fr ?
Surtout qu'en plus les reverse d'orange indiquent en toutes lettres la localité approximative donc on va pas vraiment dans le sens de la protection des données personnelles
-
abo.wanadoo.fr serait mieux niveau sécurité qu'un abo.orange.fr ?
Rien à voir mais en cas de changement, le .abo.orange.fr semble peu probable à la lecture de la nouvelle nomenclature des rDNS des IP mobile Orange :
92-184-117-179.mobile.fr.orangecustomers.net
Avant le 20 septembre 2023, ils étaient de la forme :
pop.92-184-117-179.mobile.abo.orange.fr
-
j'espère que ce n'est pas que la marque wanadoo a été (partiellement) oubliée, et donc ne saute pas (immédiatement) aux yeux du premier haxx0rz ru/cn que c'est Orange. ;D
ou peut être une séparation de certains équipements (dns, bas/bng, ... ?) donc répartition des risques?
-
Et OVH Telecom supporte-t-il le rDNS IPv6 ?
IPv4, c'est certain. https://help.ovhcloud.com/csm/fr-internet-access-reverse-dns?id=kb_article_view&sysparm_article=KB0039308
rDNS IPv6 sans doute, mais j'ai besoin d'une confirmation.
-
Bonjour,
oui ;)
-
Je confirme, j'ai un VPS chez OVH et il est possible de spécifier le rDNS de la (seule) adresse IPv6 associée au VPS dans la console d'admin. Idem pour l'IPv4 évidemment.
-
Je confirme, j'ai un VPS chez OVH et il est possible de spécifier le rDNS de la (seule) adresse IPv6 associée au VPS dans la console d'admin. Idem pour l'IPv4 évidemment.
Oui sur un vps, mais la question porte sur un abonnement Télécom fibre ou xdsl.
-
Oui sur un vps, mais la question porte sur un abonnement Télécom fibre ou xdsl.
Oui le reverse custom marche pour un abo ADSL ou FTTH, en IPv4 et IPv6. Ça se manage simplement dans l’interface client OVH.
-
Bonjour,
1. Chez OVH en "serveur dédié" j'ai le rDNS sur toutes les IPv6::/64 (ils appelaient çà la "délégation IPv6" - Je ne retrouve plus, l'option), par contre sur l'IPv4 on devrait pouvoir mettre plusieurs nom de pointeur (pas seulement qu'un seul).
2. Tjrs chez OVH en VPS je n'ai pas trouvé d'option ni pour l'IPv4 ni pour l'IPv6, il me semble.
3. Chez Online.net en "serveur dédié" -- c'est sûr que oui, à l'époque j'avais déjà configuré mon parc avec les machines et leurs reverse DNS.
4. Sinon chez Orange (pour particulier), non. J'expliquai cela dans la nuit ici sur le forum tiens -> https://lafibre.info/ipv6/comment-faire-plusieurs-reseaux-ipv664-dans-le-bloc-dorange-ipv656/msg1053518/#msg1053518 (toujours le même sujet).
Pour l'IPv4 rDNS (chez nos hébergeurs, OVH) -- parce que çà nous bloque de n'en n'avoir qu'une seule (j'ai lancé un sujet ici (https://www.debian-fr.org/t/tlsa-rrset-ipv4-https-smtps-interrogation/89183) sur Debian-FR) :
RFC 2181 : Clarifications to the DNS Specification → Enregistrements PTR (July 1997) (https://datatracker.ietf.org/doc/html/rfc2181#section-10.2)
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.
Sinon, nous on est en 2024 !
:/
Sinon ce n'est pas pour le reverse DNS (rDNS) mais :
Chez mon "enregistreur de nom de domaine" -- j'ai fais pointé mes DNS en externes sur les IPv4/32 et IPv6::/128 d'OVH, pour que je gère mes "zones" moi-même, le reverse IP/nom va avec dirais-je.
vps:~ # whois zw3b.eu
% The WHOIS service offered by EURid and the access to the records
% in the EURid WHOIS database are provided for information purposes
% only. It allows persons to check whether a specific domain name
% is still available or not and to obtain information related to
% the registration records of existing domain names.
[...]
Registrar:
Name: GANDI
Website: https://www.gandi.net
Name servers:
ns1.ipv10.net
ns2.ipv10.net
ns3.ipv10.net
[...]
J'aurais aimé ajouter le serveur "ns4.ipv10.net." chez Gandi avec l'IPv4 et une IPv6 Orange (et pouvoir configurer mes rDNS de mes machines locales avec des adresses Orange) mais pour l'instant çà ne rentre pas, cela n'est pas délégué "not authoritative".
Un bon "dig +trace" sur mon domaine (on ne voit pas l'hébergeur OVH) - après le TLD (eu.) les requêtes (zw3b.eu.) viennent chez moi directement, sur mes NameServers (sur mon bloc IPv6 délégué par OVH) :
vps:~ # dig ANY zw3b.eu @dns.google +trace
; <<>> DiG 9.16.44-Debian <<>> ANY zw3b.eu @dns.google +trace
;; global options: +cmd
. 87203 IN NS d.root-servers.net.
. 87203 IN NS k.root-servers.net.
. 87203 IN NS j.root-servers.net.
. 87203 IN NS m.root-servers.net.
. 87203 IN NS h.root-servers.net.
. 87203 IN NS b.root-servers.net.
. 87203 IN NS e.root-servers.net.
. 87203 IN NS f.root-servers.net.
. 87203 IN NS a.root-servers.net.
. 87203 IN NS g.root-servers.net.
. 87203 IN NS c.root-servers.net.
. 87203 IN NS i.root-servers.net.
. 87203 IN NS l.root-servers.net.
. 87203 IN RRSIG NS 8 0 518400 20240214170000 20240201160000 30903 . fl1nY+rNtotEQhJT7N9Uzs9UzAsOjh/Ya1wMJVmuW7SuYzqiWNwaR1a8 eJTx9IaV0DEiCQ7rIohFjGrLrNcBMUW5aMjOOtqX4uccSogVvyNc609i s6BRY4l7+DaKhuWDCBAtrcEuiMq5JvIkODw8pNyDr3T/M0g68El4Fuue VwBepV8mLhz5Bmy2tFX2sSpwZSmFBPO1HdcqdnUUiANECyxCC/yhJDgu QGXDcGEo1l4lE3QbRb3LsgvV9UemST93vEvQc1C0lbVEKBntNxNXFEHi BYeUh4tDwpcfN/5+KOmkNaH4M98x/+uXxCwpF4zeL0bsyrIAiPvjNLOa cdtdRQ==
;; Received 525 bytes from 2001:4860:4860::8888#53(dns.google) in 0 ms
eu. 172800 IN NS w.dns.eu.
eu. 172800 IN NS x.dns.eu.
eu. 172800 IN NS y.dns.eu.
eu. 172800 IN NS be.dns.eu.
eu. 172800 IN NS si.dns.eu.
eu. 86400 IN DS 35926 8 2 89B9EF0445904E7C6074B5BECE823C3E264FBD91C103D10BDE603412 343CE70C
eu. 86400 IN RRSIG DS 8 1 86400 20240214170000 20240201160000 30903 . wUJWyxgz7RMNDVFQuXAfMidaLTSSFF6cXcF05UDpM1B/fyn1lgKa/hE8 K902JVzaT2/DmYcKtM8pEJ7RuKtK8Ge8n2EuYTEW92skbWMRfkxBgmhT yoVyWV4GEDf3MjSj6FimB1y/wXT15sgGeRBpoaAbAfN1OpP8VJ8vlUvq qimmCrXsRdKXv7PsvhVmG9wlJ10Zg/Y+dNDIFGY9OWLKUput/Cbw3yDk yn6HYsR7i93Lirm/tT+H2DnevDLTq8vHhx8ykeYa/e9lwZ6WXZEr2lBu odjTknvzqFv1Mko1wcBFEu1OGSJ9WIJB2ZDri0ShTHKp2mF0sgdtSFMD Hzyutg==
;; Received 677 bytes from 193.0.14.129#53(k.root-servers.net) in 128 ms
zw3b.eu. 86400 IN NS ns2.ipv10.net.
zw3b.eu. 86400 IN NS ns3.ipv10.net.
zw3b.eu. 86400 IN NS ns1.ipv10.net.
zw3b.eu. 86400 IN DS 34934 8 2 464DFCA0CD494F203C0F6FCE7CA0A33F52DECD242F62042F38CE2255 75D91D14
zw3b.eu. 86400 IN DS 45480 8 2 72F51479DFC8A3F793192304231FDAAB92DC92CF0935979729608C21 FE7BA521
zw3b.eu. 86400 IN RRSIG DS 8 2 86400 20240204171710 20240128165333 36861 eu. RewjGMqRsu0onyZyzsGgYZVvxT2z1azX/3q3d31zQ5WR5WVJma6k7y1A hSJmEDB+NlkVyX988CEHHM6BmpCgvGGQ8qhecgBImd/nVNbboPADD+ki x3etzv8Cnqvd2HXzFaPhbjnmHycwbtrOfImKNhOKBjMiDcexzrgONti6 6nA=
;; Received 385 bytes from 2001:978:2:1::93:2#53(be.dns.eu) in 12 ms
zw3b.eu. 3600 IN SOA dns.lab3w.fr. hostmaster.lab3w.fr. 2022120528 300 60 420 60
zw3b.eu. 3600 IN RRSIG SOA 8 2 3600 20240302202743 20240201192743 45480 zw3b.eu. K7/WDiUG5hk/4JIiAoOV78pA/xYKTnVUZ24TTbwx5hRoG7aV+XvEXT4z KQls0jNxww3OmCbmfIVTh0czE5/cgsjqjj/xyILwWI5ymiGfcWdW/g/S Dizhngv2bSZBBdD04/3n6I3zK7Wa716ONLFefuW4xWOy15W+Gr4NbS1P q9Y=
zw3b.eu. 3600 IN NS ns3.ipv10.net.
zw3b.eu. 3600 IN NS ns1.ipv10.net.
zw3b.eu. 3600 IN NS ns2.ipv10.net.
zw3b.eu. 3600 IN RRSIG NS 8 2 3600 20240221013639 20240122005341 45480 zw3b.eu. WPAmKv0yckPq4pYOb/m+eCD4KWXkiA1jxwamQMuwqadULkG6OLLOzrxb iasSfwZXREZ1e41xc302ba0H+PgFiyU1xXuA/mb/CTu+BoKuZKei9Stm J7dtnNydkQjQcLPXmx+LYCbczVxbciMt1rPq6p0KViPRRwAdnmV7+HFs LlY=
zw3b.eu. 3600 IN A 158.69.126.137
zw3b.eu. 3600 IN RRSIG A 8 2 3600 20240213200403 20240114194933 45480 zw3b.eu. O11c3NphGGyUVG2Y97kJN8OfvPCbZvYiFrMojnGId2CAvlw3/tfknQMm rjw0XOc5fSE/y6BS+3bqMTMfAzdo+hliJbyluAaHaeoSyDEJ0N7mFg8e u0Lv8QHFK+vw6zi6H3hLHdXsuLdEZlEPpF7xZjKTAZzDu0we5LFQtAjK U08=
zw3b.eu. 3600 IN MX 10 smtp.zw3b.eu.
zw3b.eu. 3600 IN RRSIG MX 8 2 3600 20240302200044 20240201192114 45480 zw3b.eu. NO1OKuRlqKEyV5gHDHeVnXbgkfu5Zm5UN2ykaq+josAXoW+HXdzPN0rM vwmtK6pJvc5JVOh+bWAbrfc3TT1rdC7szWSF4Bl4GRNxy90cWOj9Jlj9 C5dbjWXT3U0StAETf1uIW4PxXqBY2qJzT8v6eUs6TkVGDTUWWwOj+ivH JxY=
zw3b.eu. 10800 IN TXT "google-site-verification=_pC2W3tVOrB8EAO4dAGrxQuVtkpVw0v8hmqGAB7Sol8"
zw3b.eu. 10800 IN TXT "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/124 ~all"
zw3b.eu. 10800 IN RRSIG TXT 8 2 10800 20240301143643 20240131140005 45480 zw3b.eu. nwvUtY6r8+lpeCnbChj9w9vA6fBxnmZAsy8bxFG/5pe5XxqLDNb69lAV kmMOoXPs9VqLs4APmiEuyDJWu8NxKwO0CicZWXASMqjLmQs0yMe4xMrd t0xIi41PEM7Vta2UQUqgpD2LT1rg5RPoPG15FlSEDBAyv4mHG3wnI3wL Iqo=
zw3b.eu. 3600 IN AAAA 2607:5300:60:9389::1
zw3b.eu. 3600 IN RRSIG AAAA 8 2 3600 20240210230415 20240111223912 45480 zw3b.eu. Ld+sYCGnUgVFZDp0Wq4HywhvK7x1J+3re5MDxpo4AjiWVUYD1srqS2rK Usn6EZThQrOAYG1jXWjVAXUJU6tLXsu4TmY4c32ncfyB3xVqn2Kaukna h2fnSP1Pda7eKUh4dVy9T0sM7LWqf5pFciopB76hHcZVpEcIBk5/EK7+ YPg=
zw3b.eu. 3600 IN DNSKEY 256 3 8 AwEAAbWS95oUl7zAN8rRNkYGMwOyfVEvNuocNNwfgVmpnrKkX0TKSSfq nFON5VumE+9U9HASAd/UuIPgMMrRwl00lHNzO+NztvMovAeXtIAu3Z/3 GMRlOoI5boiN6D72s0JbPs58Uv6jKVtuLM7vosg3tVec6hnMAyjU5lIA GXHyCOjL
zw3b.eu. 3600 IN DNSKEY 257 3 8 AwEAAdzTbvGuybZDbBLupf7xwFV9Mm+ps4bCQp44lve+kRzpsEqzIXvk a4tW3UnmzilLJiGFLeTJ0brQUT2yFYd4ot9K6NO+5TjjCkLGwISuoPEh mimEJAt1dUe4u7fEQQEEHd2AylM6MHHyE5x1q4x/g+sAr6w6Hs5WbuK5 vq9pB+UaJf/LpuUIMXgo6NUrfWjqYHe4PaDMLvwSLuMAEc4G7oAjp/2P 4twYk/3G4AxjSj7+cBhcEAENwdxiKY3xxQkBTzaPWnLFJKSUUDlbg/5s HtugqvgOKoJH7RdhRtxhZUNunq/lntNQhW7nt/vjsuGBIHFP9g3tEKZU fmLsu9PdpNk=
zw3b.eu. 3600 IN RRSIG DNSKEY 8 2 3600 20240302200044 20240201192114 34934 zw3b.eu. KBjzWn3BjILL6p4oaYSoy2k7G+a+76iPp4VlmAxNaB6840dq5bXadEvl WMFcdk1YJpfLH4pSBVXZK0bvtsnaxU75C98gafo8Fc4+a2O9c2Ab99rM DBCRy0M2a796ZYytr2F73hB4VpNmmiuvmb7UlTrBzoHRmj1ssShKqMYC H2uGiiaXK33GPFfd5qALc4XHN+iUYL9tsGnCKnhGdq2Y4sPGMWwz6T3T UkLJyUgpDJ7fWHianIZDX4+6d7NPUVxyvHHr1qx5CWarwnjiiPeB/CIV qth/9MhnrqOxli+n+xRJKRzMOiXOqV8yq2iKnkfbl8V20+/sVXeRHA5F lmkR2g==
zw3b.eu. 3600 IN RRSIG DNSKEY 8 2 3600 20240302200044 20240201192114 45480 zw3b.eu. lB2KfIHktc4R6DRSEJfp6SssLWGAZXPPkagpKGxsqr+g294DEuAq5yA1 CuVGgS9jyinNBmv+24Xa975VH1/9lw8vGEDt+orenlpU6f3ZoMr5GcBV LV0Kw47rdTT53e3O23FVfcnvgx8Q5LpImWb5vnsvT86p4gCQC6QYTpxi Dv4=
zw3b.eu. 0 IN NSEC3PARAM 1 0 10 1129762FE162034A
zw3b.eu. 0 IN RRSIG NSEC3PARAM 8 2 0 20240302200044 20240201192114 45480 zw3b.eu. KNDCKvY7NsVFvQjUrC4YTGif0tfVz1juKBW/wNIG3/Cb3F9W8UfT+NfF 1pt3vLii/kr0yaQYrWHANgRVO/vsW2YYRgJkX6gmVvn3vI0W7K001T9l 3FumSkOxUijH8XrYTT2lbXODpvGyQ1ff6DEJ9e/HikS5TnADq/JDtyag jjI=
zw3b.eu. 10800 IN SPF "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/124 ~all"
zw3b.eu. 10800 IN RRSIG SPF 8 2 10800 20240301143643 20240131140005 45480 zw3b.eu. eXrt48VPd0GNZ8XvDG4k8Gt2cZjQNYH8E7CXQxCNpxeGBqAFI5yOLfs+ BPOq8iMbHgs6bLSEaupi1TrshiMuDcbD1zPk4Pj3zMntaTXyG/6ryqfP rGeXv9XXIvwDqxWA/U8ixg4jOOh8eTQgqpOI/m+L5HsNN1d8FbBEXIwH 3UI=
;; Received 4110 bytes from 158.69.126.137#53(ns2.ipv10.net) in 92 ms
C'est-ce que moi, j'appelle de la "Délégation de blocs IPv6" - mais sinon, sinon j'dis qu'çà.
RienÀVoir mais si vous ne connaissez pas -> https://dnsviz.net/d/zw3b.eu/dnssec/ -- l'erreur vient du dessus, ce n'est pas chez moi :)
Je vous ajoute une doc que j'ai écris : Configuration BIND9 Masters et Slaves (https://howto.zw3b.fr/linux/serveurs/configuration-bind9-master-and-slaves), et celle-ci : How To Setup DNSSEC on an Authoritative BIND DNS Server (https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2) (pour sécuriser notre serveurs DNS - en plus, ceux qui est bien, c'est qu'il n'y a pas de Tierce personne (l'algorithme de cryptage est créait avec "openssl" selon nos eXigences). Ce n'est pas comme un certificats Web ou mail, FTP.. et çà permet de sécuriser (validité et conformité..) "nos champs/nos entités" DNS de nom de domaine sur le réseau Internet.
Romain
-
Bonjour,
1. Chez OVH en "serveur dédié" j'ai le rDNS sur toutes les IPv6::/64 (ils appelaient çà la "délégation IPv6" - Je ne retrouve plus, l'option), par contre sur l'IPv4 on devrait pouvoir mettre plusieurs nom de pointeur (pas seulement qu'un seul).
Je ne pense pas comprendre l'intérêt d'avoir plusieurs ptr sur une même IPV4.
plusieurs A oui, mais plusieurs ptr, non.
J'aurais aimé ajouter le serveur "ns4.ipv10.net." chez Gandi avec l'IPv4 et une IPv6 Orange (et pouvoir configurer mes rDNS de mes machines locales avec des adresses Orange) mais pour l'instant çà ne rentre pas, cela n'est pas délégué "not authoritative".
Rien compris non plus. vu que tu n'as pas autorité sur les zones arpa d'orange, je ne pense pas comprendre l'intérêt...
je suis peut être mal réveillé :)
Jerem
-
Franchement ça pique les yeux et c'est pas mal HS, on parle ici de reverse sur les abonnements fixes => FAI
-
Je ne pense pas comprendre l'intérêt d'avoir plusieurs ptr sur une même IPV4.
plusieurs A oui, mais plusieurs ptr, non.
Jerem
L'intérêt peut-être celui-ci : avoir des "entitées" DANE (DNS-Based Authentication of Named Entities) par TLSA (TLS Authentication record) -> https://docs.emailerize.com/fr/dane <- c'est pareil pour les certificats SSL/TLS -- Il faut avoir un SNI (Server Name Indicator) qui corresponde au nom de la machine que retourne le PTR (les champs A et AAAA on sans fout, c'est juste pour l'accessibilité).
Par exemple : j'ai un serveur mail, j'ai 20 clients - lors de l'installation d'une "adresse mail" dans un logiciel client (celui-ci cherche) -- smtp.DOMAIN.TLD et imap.DOMAIN.TLD - Parcontre mon client lui s'appelle "CLIENT.TLD" et donc lors de la configuration le logiciel mail ressoud "smtp.CLIENT.TLD" et imap.CLIENT.TLD et c'est là que çà permet de pouvoir "assigner" une IPv4 et IPv6 à un Nom, plusieurs Nom - Ne serais-ce que pour le certificats SSL.
Par exemple t'es hébergé en "payant" sur les serveur Google en ton nom de domaine mail, mais tu dois changer la configuration en "smtp.google.com" et "imap.google.com" -- ce n'est pas très usersFriend ; çà fait peur au client. Surtout si tu t'appelles truc muche comme moi.
Exemple d'un de mes clients (son nom de domaine est hébergé sur mes serveurs) :
- Email test: masterpiecetobuy.info (97%) https://internet.nl/mail/masterpiecetobuy.info/1082782/ -> SMTP.MASTERPIECETOBUY.INFO (not DANE) - Donc avec sa configuration "normal" - SMTP.SONDOMAIN
- Email test: masterpiecetobuy.info (100%) https://internet.nl/mail/masterpiecetobuy.info/1091499/ (2023-12-11 13:54 UTC) -> SMTP.ZW3B.EU (ok DANE) - Avec ma configuration (celui de l'hébergeur de mails) SMTP.MONDOMAIN
CF : Les sites web et domain mail que j'ai "scanné" pour vérifier la sécurité des transactions protocolaires IP -> https://www.zw3b.fr/pub/screens/internet-nl/ (du travail à faire, pour nos FAI/ISP).
J'ajoute pour le SNI et le certificat (TLS) -> Tests SSL LABS (captures d’écran : https://www.zw3b.fr/pub/screens/ssllabs.com/ )
Je vous ajoute ce site web de TEST et outils MX -> https://mxtoolbox.com/emailhealth (santé du domaine "email" etc.)
Rien compris non plus. vu que tu n'as pas autorité sur les zones arpa d'orange, je ne pense pas comprendre l'intérêt...
Justement aussi, vu que j'ai des milliard de milliard d'addresse IPv6 -- ce serait envisageable de pouvoir configurer nos PTR - Il faudrait que Orange y pense. Oui ils n'ont pas activés la "Délégation de mon bloc IPv6" , sur leur serveur DNS autoritaire -- Il le faut !
Franchement ça pique les yeux et c'est pas mal HS, on parle ici de reverse sur les abonnements fixes => FAI
Okay c'est de plus grande importance sur un "abonnement de domicile". On n'est pas limité par le nombre de machines (comparé à dans un Data-centre dans lequel on peut créer plusieurs Virtual Machine avec des "chroots", des containers et des dockers (travailleurs)), mais bien moins que chez soi.
Bon journée.
Romain
Et donc la "Délégation de nos blocs client d'adresses IPv6" permet de pouvoir configurer NOS PTR (PoinTeur Records ressource). Encore faut-il que l'e prestataire de service nos l'autorise :) Même pour lui.. pour qu'il puisse plus facilement nous "identifier" -- oui les services -- pas les postes des gens -- les routeurs aussi, de nos réseaux "internes", intranet, eXtranet, Internet (sur leurs IPs). Encore faut-il que les "administrateurs des réseaux" appliquent cette recommandation de l'IETF !
Sur l'IPv6, de déléguer un bloc d'IP, çà permet d'avoir "comme" une Zone Dé-Militarisée (DMZ) automatiquement. Sinon, (sans délégation) on passerait par l'adresse IPv6 de la passerelle du FAI (la livebox), celle qu'on verrait l'autre côté sur les serveurs -- de sites web etc..
En DMZ, on passerait sur une IP externe à chez nous (sur le chemin) (qui nous identifierait grâce à notre bloc IPv6::/56 (qui correspondant) à plusieurs milliards de milliards d'adresses et qui nous aurez délégué cette plage d'IP), soit on sort par la passerelle en fe80:: (la livebox) soit, on entre et sort par le routeur de nos livebox (celui qui gère sa connexion son lien) qui serait une adresse de type 2a01:cFFF:FFFF:FFFF:XXXX:XXXX:XXXX:XXXX pour mon bloc IPv6::/56 - 2a01:cb1d:2d4:8800::/56 et tous les autres entre "2a01:cb00:0000:0000:0000:0000:0000:0000-2a01:cb7f:ffff:ffff:ffff:ffff:ffff:ffff" soit : 2,147,483,648 networks /56
IANA - IPv4/IPv6 subnet calculator -> http://www.gestioip.net/cgi-bin/subnet_calculator.cgi
FAI/ISP : 2,147,483,648 networks /56 (nombre de clients ou presque (il faut toujours enlever un bloc pour la gestion des blocs client (inférieurs) de l'autorité supérieur))
CLIENT : 1 réseau IPv6::/56 à soi (client du FAI/ISP) avec 256 IPv6::/64 (donc moins 1 réseau, donc 255, 1 réseau pour les adresse locales FFFF et pourquoi un autre les FEFE (encrypté).
Exemple :
- 2a01:cb1d:2d4:88FF:FFFF:FFFF:FFFF:FFFF/56 (réseau d'administration/supervision de mon bloc client) celui est comme "personnel/privé"
- 2a01:cb1d:2d4:8800:0000:0000:0000:0000/64 (réseau par default de mon bloc client)
- 2a01:cb1d:2d4:8801:0000:0000:0000:0000/64 (réseau 01 de mon bloc client)
- 2a01:cb1d:2d4:8802:0000:0000:0000:0000/64 (réseau 02 de mon bloc client) etc..
Pour le FAI/ISP son réseau d'aministration /supervision est plus haut -> lui ce qu'il veut savoir cest qui est 2a01:cb1d:2d4:88XX::
grâce à ses FF d'ici par exemple -> 2a01:cFFF:FFFF:XXFF:XXXX:XXXX:XXXX:XXXX
Le link-local FE80 est ici : 2a01:cFFF:FFFF:FE80:XXXX:XXXX:XXXX:XXXX qui correspondant à ma LIVEBOX connecté au répartiteur (lien local entre ma livebox et le répartiteur d'immeuble, dans la rue ou plus loin encore). "FE" est égal à moi "88" (lien sûr, encrypté) et "80" est égal de toute MON association "8" (mes serveurs, machines connectées) et "0" tout le reste sur mon réseau chez moi (à moi de faire mes liens, routes). Je vous précise qu'en fait c'est décalé d'1 bit vers l'autorité supérieure - mais pour plus de compréhension, je vous explique de cette manière ;) le "fe80" c'est plutôt - chez-eux lié, encrypté à nous "leur association" "8" et nous "0" ; la MAC ADDR de la livebox :)
Tiens, XX qui est-ce ? c'est 88 donc c'est "romain" et son réseau ;) Monsieur Jaillet-ramey ;D
Définition de "Délégation" : Acte par lequel tout ou une partie du pouvoir d'une autorité (FAI) est déléguée à une autre autorité (CLIENT).
je vous écrit la même phrase en version "IANA (Internet Assigned Numbers Authority) (https://www.iana.org/) <-> FAI/ISP" : Acte par lequel tout ou une partie du pouvoir d'une autorité (IANA) est déléguée à une autre autorité (FAI/ISP).
;) 8)
----
Note de Moi-même 20240205 at 03h20 GMT+1 : Pour la sécurité des abonnées, les adresses IPv6 (hors délégation IPv6) devraient être sur des adresses ULA (Unique Local Address, non routable d'internet) -- je vous ai fait une démonstration ici -> https://lafibre.info/ipv6/comment-faire-plusieurs-reseaux-ipv664-dans-le-bloc-dorange-ipv656/msg1053533/#msg1053533 -- Ils se choisissent un bloc, "fc00::/8", tout simplement et nous mettent un DHCP (pour l'adressage static et dynamique des IP) et le RADVD (pour le lien de la passerelle en "fe80::" - vu qu'on est connecté sur leur ports RJ45 des boxes internet). Et ils nous font une délégation de blocs IPv6 "UNICAST" (adresses IP de l'Internet) qui permet de pouvoir entrer et sortir sur ces machines déléguées. Et le tour est joué. En plus ils nous autorisent à gérer nos PTR (çà va ensemble) - surtout vu les nombres IPv6 qu'on peut utiliser -- si on s'est administrer un serveur DNS ou/et ils nous font une gestion d'adresses IPv6 / rDNS sur leurs NS (NameServeurs autoritaire).
Personnellement, moi j'dirais, on Délègue et on les laisse faire (z'ont qu'à savoir faire un serveur DNS s'il veulent changer de nom -- mais surtout pour identifier un appareil, un réseau, une passerelle (chez nous, pour nous, nos potes, nos partenaires) sur un total d'IPv6 adresses de "18,446,744,073,709,551,616" pour 1 seul bloc IPv6::/64 - le nombre se lit "18 billions" ou "dix-huit mille milliards" en français 10^18 cf (http://www.google.com/search?q=1+000+000+000+000+000+000+(nombre)+se+lit)).
Sinon y'a le "Whois" sur l'IP pour savoir qui est le fournisseur de services internet (l'IP, le réseau).
-
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.
(https://www.zw3b.fr/pub/screens/ovh/Screenshot%202024-02-04%20at%2020-20-45%20OVHcloud%20-%20VPS.png)
En fait c'est ICI (je viens de trouver l'option at 23h20 2024-02-04) :
(https://www.zw3b.fr/pub/screens/ovh/Screenshot%202024-02-04%20at%2023-17-21%20OVHcloud%20-%20Networks%20-%20IP.png)
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 medium
root@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.
(https://www.zw3b.fr/pub/screens/ovh/Screenshot%202024-02-04%20at%2020-19-56%20OVHcloud%20-%20Severurs%20D%c3%a9di%c3%a9s.png)
J'ajoute les "routes" vers leurs passerelles sur/de mon serveur dédié (on s'aperçoit que la passerelle IPv6 est au dessus "93ff" de mon bloc "9389" -- 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 medium
root@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 :D
----
RFC 2181 : Clarifications to the DNS Specification → Enregistrements PTR (July 1997) (https://datatracker.ietf.org/doc/html/rfc2181#section-10.2)
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
-
On discuter où mettre à jour le reverse DNS des VPS chez OVH etc.
ICI.. La deuxième image du commentaire.
Y'a 3 ou 4 jours (le jour de mon commentaire ci-dessus (j'avais réussis à changer mon reverse DNS)), çà fonctionné, MAIS aujourd'hui çà ne fonctionne plus.
(https://www.zw3b.fr/pub/screens/ovh/Screenshot%202024-02-08%20at%2007-34-12%20OVHcloud%20-%20Networks%20-%20IP.png)
;)
-
bonjour,
l'erreur n'est pas explicite, mais c'est parce que ton FQDN ne résous pas l'IP ou tu veux mettre le reverse.
je leur ai remonté le "problème" il y a de nombreuses années sans que ça n'ai jamais été changé (ça pourrait indiquer clairement le problème plutôt que de se vautrer lamentablement)
-
Franchement, c'est HS ! Le titre c'est FAI !
Tu pourris le sujet qui aurait pu être une bonne source de recensement des pratiques des FAI dans le temps. Au lieu de ça, on a l'impression de lire un skyblog !
-
bonjour,
l'erreur n'est pas explicite, mais c'est parce que ton FQDN ne résous pas l'IP ou tu veux mettre le reverse.
je leur ai remonté le "problème" il y a de nombreuses années sans que ça n'ai jamais été changé (ça pourrait indiquer clairement le problème plutôt que de se vautrer lamentablement)
Oui c'était de mon côté ^^-sorry-^^ il faut configuré le champ AAAA en premier, après çà fonctionne.
La documentation OVH "reverse DNS" :
https://help.ovhcloud.com/csm/fr-dedicated-servers-optimise-email-sending?id=kb_article_view&sysparm_article=KB0043647#configurer-le-reverse-ip
Vous devez tout d'abord créer un enregistrement A dans la zone DNS de votre domaine avec l'adresse IP de votre serveur comme cible.
[...]
Une fois cela fait, ajoutez l'enregistrement PTR (également connu sous le nom de reverse) :
DNS :
$ dig A vps.uk.ipv10.net. +short
57.128.171.43
$ dig AAAA vps.uk.ipv10.net. +short
2001:41d0:801:2000::44f9
rDNS :
$ dig -x 57.128.171.43 +short
vps.uk.ipv10.net.
$ dig -x 2001:41d0:801:2000::44f9 +short
vps.uk.ipv10.net.
çà fait plus mieux :D
bon j'ai menti :p il faut attendre que çà se propage haha.
(https://www.zw3b.fr/pub/screens/ovh/Screenshot%202024-02-21%20at%2018-38-51%20OVHcloud%20-%20Networks%20-%20IP.png)
Chez OVH Dédié (Barre cloud), je n'arrive plus à gérer mon bloc IPv6::/64 reverse" - Est-ce la même interface Web "config reverse Ipv6" pour OVH FAI/ISP ?
J'avais configuré les IP/Nom des serveurs autoritaires, mais j'aimerai les changer.
-> pour ajouter 1 adresse d'un de mes serveurs DNS authoritaire (donc sur et de leur bloc)
-> modifier les noms.
Je ne trouve que l'option pour configurer le nom du reverse des IPv6 de mon bloc::/64, mais une par une.
Franchement, c'est HS ! Le titre c'est FAI !
Tu pourris le sujet qui aurait pu être une bonne source de recensement des pratiques des FAI dans le temps. Au lieu de ça, on a l'impression de lire un skyblog !
Oui désolé, c'est un peu lié.. J'ai lu l'intro :D
----
Quel FAI supporte le rDNS/reverse DNS IPv6?
MilkyWan : oui
OVH : peut-être
Orange Pro : non
Free & Free Pro : non https://dev.freebox.fr/bugs/task/12749 (https://dev.freebox.fr/bugs/task/12749).
Orange : non
Bouygues : non
SFR : non
Autres FAI : n'hésitez pas à préciser
Chez Starlink (https://www.starlink.com/) d'Elon Musk ? Y'a t'il de l'IPv6 ?
Si vous avez 2 ou 3 impressions d'écran de ce routeur - pour voir les options, je suis interessé @HLFH -- 555€ + 40€/mois -- Pendant que j'y suis ; Y'a t'il des mises à jour du firmware et du webUI.
Romain,
bonne fin de journée.
-
Salut, j'ai trouvé ces pages sur le reverse DNS IP... En d'autres termes "Comment délégué une zone IP DNS à un client".
https://services.renater.fr/noms_de_domaine/delegation_des_zones_inverses
https://tldp.org/HOWTO/DNS-HOWTO-5.html#ss5.5
5.5 Pourquoi les recherches inversées ne fonctionnent pas.
Il existe quelques « pièges » qui sont normalement évités avec les recherches de noms et qui sont souvent observés lors de la configuration de zones inversées. Avant de continuer, vous devez effectuer des recherches inversées de vos machines fonctionnant sur votre propre serveur de noms. Si ce n'est pas le cas, revenez en arrière et corrigez-le avant de continuer.
Je vais discuter de deux échecs de recherches inversées vus de l'extérieur de votre réseau :
# -----
La zone inversée n'est pas déléguée.
Lorsque vous demandez à un fournisseur de services une plage d'adresses réseau et un nom de domaine, le nom de domaine est normalement délégué de manière systématique. Une délégation est l'enregistrement NS de liaison qui vous aide à passer d'un serveur de noms à un autre comme expliqué dans la section sur la théorie sèche ci-dessus. Vous avez bien lu, n'est-ce pas ? Si votre zone inversée ne fonctionne pas, revenez en arrière et lisez-la. Maintenant.
La zone inversée doit également être déléguée. Si vous avez obtenu le réseau 192.168.196 avec le domaine linux.bogus de votre fournisseur, il doit mettre des enregistrements NS pour votre zone inverse ainsi que pour votre zone de transfert. Si vous suivez la chaîne depuis in-addr.arpa jusqu'à votre réseau, vous trouverez probablement une rupture dans la chaîne, très probablement chez votre fournisseur de services. Après avoir trouvé la rupture dans la chaîne, contactez votre fournisseur de services et demandez-lui de corriger l'erreur.
# -----
Vous avez un sous-réseau sans classe
Il s'agit d'un sujet assez avancé, mais les sous-réseaux sans classe sont très courants de nos jours et vous en avez probablement un si vous êtes une petite entreprise.
Un sous-réseau sans classe est ce qui permet à Internet de fonctionner de nos jours. Il y a quelques années, on a beaucoup parlé de la pénurie de numéros IP. Les gens intelligents de l'IETF (Internet Engineering Task Force, ils font fonctionner Internet) se sont mis la tête à la tâche et ont résolu le problème. À un prix. Le prix est en partie que vous obtiendrez moins qu'un sous-réseau « C » et que certaines choses peuvent se casser. Veuillez consulter Ask Mr. DNS pour une bonne explication de cela et comment le gérer.
L'avez-vous lu ? Je ne vais pas l'expliquer, alors lisez-le.
La première partie du problème est que votre FAI doit comprendre la technique décrite par M. DNS. Tous les petits FAI n'ont pas une compréhension pratique de cela. Si c'est le cas, vous devrez peut-être leur expliquer et insister. Mais assurez-vous d'abord de bien la comprendre ;-). Ils mettront ensuite en place une belle zone inversée sur leur serveur que vous pourrez examiner pour vérifier son exactitude avec dig.
La deuxième et dernière partie du problème est que vous devez comprendre la technique. Si vous n'êtes pas sûr, revenez en arrière et lisez-la à nouveau. Vous pouvez ensuite configurer votre propre zone inversée sans classe comme décrit par M. DNS.
Il y a un autre piège qui se cache ici. Les (très) anciens résolveurs ne pourront pas suivre l'astuce CNAME dans la chaîne de résolution et ne parviendront pas à résoudre votre machine en sens inverse. Cela peut entraîner l'attribution par le service d'une classe d'accès incorrecte, le refus d'accès ou quelque chose du genre. Si vous tombez sur un tel service, la seule solution (à ma connaissance) est que votre FAI insère votre enregistrement PTR directement dans son fichier de zone sans classe au lieu de l'enregistrement CNAME.
Certains FAI proposent d'autres moyens de gérer cela, comme des formulaires Web dans lesquels vous pouvez saisir vos mappages inversés ou d'autres systèmes automatiques.
Et cet exemple :
Délégué la zone 10.0.3.0/24 : Only the authority for 0.10.in-addr.arpa. can delegate 3.0.10.in.addr.arpa.
CF : https://superuser.com/questions/1340694/delegating-a-reverse-dns-zone
Bonne journée.