Dans la saga qui se poursuit : Network Solutions m’a confirmé qu’ils ne voyaient aucun enregistrement DNSSEC associé au domaine de leur côté… donc… un fantôme dans la machine provenant de l’ancien registraire ?
En tout cas, comme ils ne peuvent pas supprimer ce qui n’existe pas, nous essayons d’ajouter de nouveaux enregistrements en espérant qu’ils écraseront les fantômes et remettront tout là où il devrait être.
C’est de loin le problème DNS le plus étrange que j’aie jamais rencontré.
Je suis tout à fait d’accord 
C’est un serveur de noms .org.
La gestion du DNSSEC doit être effectuée chez votre registraire, car, tout comme les enregistrements glue, les enregistrements DS de votre domaine doivent être présents sur les serveurs de noms du TLD. Votre fournisseur de DNS n’aura aucun contrôle sur cela.
Je vois toujours les enregistrements présents ici :
pidforum.org. 86400 IN DS 30311 8 2 A75DEB1CF7CE3EE94899941C7E92B72A7E83A7B5DCD3717D6731804B 4D851E46
pidforum.org. 86400 IN RRSIG DS 8 2 86400 20211008152857 20210917142857 39681 org. goYqP/QgI0+8jN/pL3yVhZfeWAGXoibV/DHDduL+DWj47b9U18nRKctf OJB+TNznVcQeEtG67UM5O+nr5FmrfzowCHvgRsUaanVlo1nCXjlOg9eV KqZmkVcN2no1oklqbQBtN7GDqtX+G1BYmQCaIWbZ38PGBAnc2aQ0Ftr8 cAg=
;; Reçu 252 octets depuis 199.19.53.1#53(c0.org.afilias-nst.info) en 93 ms
et l’analyseur affiche toujours une erreur :
Vous devez les harceler jusqu’à ce qu’ils fassent intervenir quelqu’un de leur côté pour corriger cela — c’est la responsabilité du registraire de s’assurer que tout est correct.
Vous pourriez aussi avancer en parlant à l’ancien registraire et en leur demandant d’arrêter de soumettre les enregistrements glue et DS pour votre zone.
MODIF :
Pour l’instant, les enregistrements de la zone .org publiés sont les suivants :
pidforum.org. 86400 in ns lee.ns.cloudflare.com.
pidforum.org. 86400 in ns jillian.ns.cloudflare.com.
pidforum.org. 86400 in ds 30311 8 2 (a75deb1cf7ce3ee94899941c7e92b72a7e83a7b5dcd3717d6731804b4d851e46 )
pidforum.org. 86400 in rrsig ds 8 2 86400 20211005151127 20210914141127 39681 org. bDTwz7kYTRJXb7LuN1qj1mCBtiq0DMUM9dNzppGgR/+pTX6b0cWuMhFngI1zMk870aJU6BozFxwuv/AhUHl3y3/PHrjDOsSVA1SubPZM/tC/ylWSUexcVxVhQkQRLkpKPUlL61sZTX8VNca3MBWXx/kFSt7uThR0IYeW+2fQXqQ=
J’ai reçu confirmation ce matin que l’ancien registraire (Argeweb aux Pays-Bas) a bien supprimé les enregistrements DS de ce domaine de son système.
À ce stade, Network Solutions (le registraire) a confirmé qu’ils ont mis en place les bons enregistrements DS (nouveaux) provenant de Cloudflare (serveur de noms), et que l’ancien registraire (Argeweb) a supprimé les siens.
J’espère qu’il ne me reste plus qu’à attendre que tout cela se résolve à l’échelle mondiale. La confirmation de NetSol et de Cloudflare est arrivée tard mercredi, et celle d’Argeweb ce matin. Peut-être que tout s’alignera d’ici le week-end. Croisons les doigts
Cela ne devrait pas prendre plus d’un jour.
Il y a beaucoup de « devrait » dans tout cela… Argeweb aurait dû désactiver DNSSEC avant de transférer le domaine dès le départ. Network Solutions aurait dû pouvoir le voir et le désactiver de leur côté lors du transfert.
Le « devrait » est la plaie de tout ce projet.
Je ne connais pas exactement l’interface entre le registraire et les opérateurs de la zone racine ; je ne sais pas s’ils envoient des deltas ou des mises à jour complètes quotidiennes. Mais ils devraient connaître le processus et avoir fait ce qu’il fallait.
De même, Network Solutions aurait dû importer les enregistrements DS précédents dans leur interface lors du transfert de la zone. Ils ont vraisemblablement également transféré les enregistrements NS, mais peut-être deviez-vous les fournir ?
DNS est difficile à configurer correctement ; DNSSEC l’est encore plus.
Aurait dû / aurait pu / aurait voulu
Au moins, vous savez quel est le problème et comment le résoudre.
Les fournisseurs se rejettent presque toujours la faute les uns sur les autres.
Je vois aujourd’hui que le DS glue de pidforum.org n’a pas changé.
Avez-vous ajouté les enregistrements corrects à l’interface de Network Solutions ?
Oui, les enregistrements corrects ont été ajoutés fin de la semaine dernière chez Network Solutions. Nous avons attendu tout le week-end… sans aucun changement. L’enregistrement DS 30311 erroné est toujours quelque part, et personne ne semble pouvoir le modifier.
Vous pouvez y voir à la fois les enregistrements corrects et incorrects.
L’enregistrement correct n’est pas présent au niveau .org, ce qui est le plus important.
Vous devez insister auprès de Network Solutions pour qu’il publie l’enregistrement correct.
Avez-vous une capture d’écran de cette partie de la configuration de votre domaine ?
Network Solutions ne propose pas d’interface d’administration publique pour aucun aspect de DNSSEC. Un seul groupe au sein du support s’en occupe, et vous devez les contacter par e-mail.
Non, je ne plaisante pas.
J’ai réussi à contacter un niveau de support aujourd’hui qui semblait peut-être savoir de quoi il retournait, et ils m’ont indiqué qu’ils me répondraient dans un délai de 24 à 48 heures.
Ceci n’est toujours pas réglé. Ouch. Je comprends ta douleur @griffey.
J’ai effectué une vérification ici. Vous pouvez voir où se trouve le KeyTag 30311 dans les résultats.
Erreur : DNSKEY 2371 signe le jeu d'enregistrements DNSKEY, mais aucun enregistrement DS de confirmation n'a été trouvé dans la zone parente. Aucune chaîne de confiance n'a été créée.
Erreur fatale : La zone parente contient un enregistrement DS signé (Algorithme 8, KeyTag 30311, DigestType 2, Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=), mais le DNSKEY de destination n'existe pas ou ne valide pas le jeu d'enregistrements DNSKEY. Aucune chaîne de confiance n'a été créée.
Toujours pas résolu. Disons que Network Solutions est absolument inutile en ce qui concerne DNSSEC et les problèmes complexes de domaine. Il s’agit bien de DNSSEC, et il y a une dSKEY (30311) qui reste bloquée quelque part dans les limbes, sans que personne ne semble penser pouvoir la supprimer.
Déplacez votre domaine vers Google Cloud.
Vous pourrez ainsi gérer vous-même les paramètres DNSSEC.
Dernière mise à jour à ce sujet… C’est décevant, mais quelque chose s’est résolu et le domaine a commencé à se propager. On ne sait pas exactement ce qui a changé, car je vois toujours l’entrée DSKEY 30311. Mais quoi qu’il se soit passé côté registraire, cela fonctionne désormais.
Merci pour la mise à jour