In der fortlaufenden Geschichte: Network Solutions bestätigte mir, dass sie auf ihrer Seite keine mit der Domain verknüpften DNSSEC-Einträge sehen konnten… also… ein Geist in der Maschine des vorherigen Registrars?
Wie auch immer, da sie löschen können, was nicht existiert, versuchen wir, neue Einträge hinzuzufügen und hoffen, dass diese die phantasmaischen überschreiben und alles wieder an den richtigen Ort bringen.
Dies ist mit Abstand das seltsamste DNS-Problem, das ich je gesehen habe.
Da muss ich zustimmen 
Das ist ein .org-Nameserver.
DNSSEC-Steuerung muss bei Ihrem Registrar erfolgen, da die DS-Einträge für Ihre Domain – ähnlich wie Glue-Einträge – auf den TLD-Nameservern vorhanden sein müssen. Ihr DNS-Anbieter hat darauf keinen Einfluss.
Ich sehe die Einträge dort immer noch:
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=
;; Received 252 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 93 ms
und der Analyser zeigt immer noch einen Fehler an:
Sie müssen sie so lange belästigen, bis jemand auf ihrer Seite das behebt – es ist die Verantwortung des Registrars, dies korrekt zu stellen.
Sie könnten auch Fortschritte machen, indem Sie mit dem vorherigen Registrar sprechen und bitten, dass sie keine Glue- und DS-Einträge mehr für Ihre Zone einreichen.
EDIT:
Im Moment sind Ihre veröffentlichten .org-Zonen-Einträge:
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=
Ich habe heute Morgen die Bestätigung erhalten, dass der vorherige Registrar (Argeweb in den Niederlanden) bestätigt hat, dass sie die DS-Einträge für diese Domain endlich aus ihrem System entfernt haben.
Zu diesem Zeitpunkt hat Network Solutions (Registrar) bestätigt, dass die korrekten (neuen) DS-Einträge von Cloudflare (Nameserver) hinterlegt sind, und der vorherige Registrar (Argeweb) hat seine Einträge entfernt.
Hoffentlich muss ich nur noch warten, bis sich das alles weltweit abspielt. Die Bestätigung von NetSol und Cloudflare kam am späten Mittwoch, und die Bestätigung von Argeweb erfolgte heute Morgen. Vielleicht klärt sich das alles über das Wochenende auf. Finger gekreuzt
Es sollte nicht länger als einen Tag dauern.
Bei all dem geht es viel zu sehr um „sollte". Argeweb hätte DNSSEC vor der Domainübertragung von vornherein deaktivieren müssen. Network Solutions hätte es beim Empfang der Domain erkennen und auf ihrer Seite deaktivieren können.
„Sollte" ist der Fluch dieses gesamten Projekts.
Ich weiß nicht genau, wie die Schnittstelle zwischen dem Registrar und den Betreibern der Root-Zone funktioniert; ob sie nur Änderungen (Deltas) oder täglich vollständige Updates senden. Aber sie sollten den Prozess kennen und das Richtige getan haben.
Ebenso hätte Network Solutions die vorherigen DS-Einträge bei der Übernahme der Zone in ihre Schnittstelle importieren müssen. Vermutlich wurden auch die NS-Einträge übertragen, aber vielleicht musstest du diese selbst bereitstellen?
DNS ist tricky, korrekt einzurichten; DNSSEC noch mehr.
Hätte / hätte können / hätte sollen
Zumindest weißt du, worum das Problem geht und wie es behoben werden kann.
Lieferanten geben fast immer die Schuld einer anderen Person.
Ich sehe, dass sich die DS-Glue-Einträge für pidforum.org heute nicht geändert haben.
Haben Sie die korrekten Einträge in der Network Solutions-Schnittstelle hinzugefügt?
Ja, letzte Woche wurden die korrekten Einträge bei Network Solutions hinzugefügt, über das Wochenende gewartet… keine Änderung. Der fehlerhafte DS-Eintrag 30311 versteckt sich immer noch irgendwo, und niemand scheint ihn ändern zu können.
Dort sind sowohl die korrekten als auch die falschen Einträge sichtbar.
Der korrekte Datensatz ist auf der .org-Ebene nicht vorhanden, und genau dort kommt es an.
Sie müssen Network Solutions drängen, den korrekten Datensatz zu veröffentlichen.
Haben Sie einen Screenshot dieses Bereichs Ihrer Domainkonfiguration?
Network Solutions bietet keine öffentliche Verwaltungsoberfläche für irgendeinen Aspekt von DNSSEC an. Es gibt nur eine Gruppe im Support, die sich damit befasst, und man muss per E-Mail mit ihr interagieren.
Nein, ich mache keinen Spaß.
Ich habe es heute tatsächlich geschafft, eine Supportstufe zu erreichen, die vielleicht Ahnung hatte, und sie teilten mir mit, dass sie mir innerhalb weiterer 24 bis 48 Stunden eine Antwort geben würden.
Das ist immer noch nicht gelöst. Auweia. Ich kann deinen Schmerz verstehen, @griffey.
Ich habe eine Prüfung hier durchgeführt. Sie können sehen, wo der KeyTag 30311 in den Ergebnissen steht.
Fehler: DNSKEY 2371 signiert den DNSKEY RRset, aber im übergeordneten Bereich wurde kein bestätigender DS RR gefunden. Es wurde keine Vertrauenskette erstellt.
Schwerwiegender Fehler: Der übergeordnete Bereich verfügt über einen signierten DS RR (Algorithmus 8, KeyTag 30311, DigestType 2, Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=), aber der Ziel-DNSKEY existiert nicht oder validiert den DNSKEY RRset nicht. Es wurde keine Vertrauenskette erstellt.
Immer noch nicht gelöst. Nehmen wir an, Network Solutions ist absolut nutzlos, wenn es um DNSSEC und komplexe Domain-Probleme geht. Es handelt sich definitiv um DNSSEC, und es gibt einen DSKEY (30311), der irgendwo in der Luft hängt und den niemand zu entfernen vermag.
Verschieben Sie Ihre Domain zu Google Cloud.
Anschließend können Sie die DNSSEC-Einstellungen selbst verwalten.
Als abschließendes Update dazu: Unbefriedigend, aber etwas wurde bereinigt, und die Domain begann sich zu propagieren. Es ist nicht klar, was genau geändert wurde, da ich den 30311 DSKEY-Eintrag immer noch sehen kann. Aber was auch immer auf Seiten des Registrars passiert ist, es funktioniert jetzt.
Danke für das Update