Nella continua saga: Network Solutions mi ha confermato che, dalla loro parte, non hanno rilevato alcun record DNSSEC associato al dominio… quindi… fantasma nella macchina del precedente registrar?
In ogni caso, dato che non possono eliminare ciò che non esiste, stiamo cercando di aggiungere nuovi record e speriamo che questi sovrascrivano quelli fantasma e riportino tutto dove dovrebbe essere.
Questa è di gran lunga la questione DNS più strana che abbia mai visto.
Devo concordare 
Quello è un nameserver .org
Il controllo DNSSEC deve essere gestito presso il tuo registrar, poiché, come le record glue, le record DS per il tuo dominio devono essere presenti sui nameserver del TLD. Il tuo provider DNS non avrà alcun controllo su questo.
Vedo ancora che le record sono presenti lì:
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
e l’analizzatore mostra ancora un errore:
Devi insistere finché non trovano qualcuno dalla loro parte per risolvere il problema: è responsabilità del registrar correggere questo.
Potresti anche ottenere risultati parlando con il precedente registrar e chiedendo loro di smettere di inviare record glue e DS per la tua zona.
EDIT:
Al momento, le record della zona .org pubblicate sono:
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=
Ho ricevuto conferma questa mattina che il precedente registrar (Argeweb nei Paesi Bassi) ha finalmente rimosso i record DS per questo dominio dal loro sistema.
Quindi, al momento, ho Network Solutions (registrar) che ha confermato di avere i record DS corretti (nuovi) in posizione da Cloudflare (nameserver) e che il precedente registrar (Argeweb) ha rimosso i propri record.
Spero di dover solo aspettare che tutto si assesti a livello globale. La conferma da NetSol e Cloudflare è arrivata tardi mercoledì, mentre quella da Argeweb è arrivata questa mattina. Forse nel fine settimana tutto si allineerà. incrocio le dita
Non dovrebbe richiedere più di un giorno.
C’è un sacco di ‘dovrebbe’ in tutto questo… Argeweb avrebbe dovuto disabilitare DNSSEC prima di trasferire il dominio, in primo luogo. Network Solutions avrebbe dovuto essere in grado di vederlo e disabilitarlo dalla loro parte al momento del trasferimento.
Il ‘dovrebbe’ è la rovina di tutto questo progetto.
Non conosco esattamente l’interfaccia tra il registrar e gli operatori della zona radice; non so se inviano delta o aggiornamenti completi giornalieri. Ma dovrebbero conoscere il processo e aver fatto la cosa giusta.
Allo stesso modo, Network Solutions avrebbe dovuto importare i precedenti record DS nella loro interfaccia durante il trasferimento della zona. Presumibilmente hanno anche trasferito i record NS, ma forse dovevi fornirli tu?
DNS è complicato da configurare correttamente; DNSSEC lo è ancora di più.
Avrebbe dovuto / avrebbe potuto / avrebbe voluto
Almeno sai qual è il problema e come risolverlo.
I fornitori danno quasi sempre la colpa all’altra parte.
Vedo che oggi i DS glue di pidforum.org non sono cambiati.
Hai aggiunto i record corretti all’interfaccia di Network Solutions?
Sì, abbiamo aggiunto i record corretti alla fine della scorsa settimana su Network Solutions, abbiamo aspettato tutto il fine settimana… nessun cambiamento. Il record DS errato 30311 è ancora nascosto da qualche parte e nessuno sembra riuscire a modificarlo.
Puoi vedere sia i record corretti che quelli errati in quella pagina…
Il record corretto non è presente a livello di .org, che è dove conta.
Devi sollecitare Network Solutions a pubblicare il record corretto.
Hai uno screenshot di quella parte della configurazione del tuo dominio?
Network Solutions non offre un’interfaccia pubblica di amministrazione per alcun aspetto di DNSSEC. Esiste un solo gruppo all’interno del supporto che se ne occupa e bisogna interagire con loro via email.
No, non sto scherzando.
Sono riuscito oggi a contattare un livello di supporto che forse aveva qualche conoscenza in materia e mi hanno detto che mi avrebbero fornito una risposta entro altre 24-48 ore.
questo non è ancora risolto. ouch. capisco il tuo dolore @griffey
Ho eseguito un controllo qui. Puoi vedere dove si trova il KeyTag 30311 nei risultati.
Errore: DNSKEY 2371 firma l'insieme di record DNSKEY, ma non è stato trovato un record DS di conferma nella zona padre. Non è stata creata una catena di fiducia.
Errore fatale: La zona padre ha un record DS firmato (Algoritmo 8, KeyTag 30311, DigestType 2, Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=), ma il DNSKEY di destinazione non esiste o non convalida l'insieme di record DNSKEY. Non è stata creata una catena di fiducia.
Ancora non risolto. Diciamo che Network Solutions è assolutamente inutile quando si tratta di DNSSEC e problemi complessi di dominio. Si tratta sicuramente di DNSSEC e c’è una dSKEY (30311) che è bloccata da qualche parte nell’etere e che nessuno sembra pensare di poter rimuovere.
Sposta il tuo dominio su Google Cloud.
Potrai quindi gestire autonomamente le impostazioni DNSSEC.
Come ultimo aggiornamento a riguardo… Insoddisfacente, ma qualcosa si è sbloccato e il dominio ha iniziato a propagarsi. Non è chiaro cosa sia cambiato esattamente, poiché riesco ancora a vedere la voce DSKEY 30311. Ma indipendentemente da ciò che è successo a livello del registrar, ora funziona.
Grazie per l’aggiornamento