계속되는 사건의 전개: Network Solutions 측에 확인한 결과, 그들의 시스템에서는 해당 도메인과 연관된 DNSSEC 레코드가 전혀 보이지 않는다고 하였습니다… 그렇다면… 이전 등록업체 쪽에 유령 같은 레코드가 남아 있는 건가요?
어쨌든, 존재하지 않는 것을 삭제할 수 없으므로, 우리는 새 레코드를 추가하여 그 유령 레코드들을 덮어쓰고 모든 것을 제자리에 되돌리기를 희망하고 있습니다.
지금까지 제가 겪은 DNS 문제 중 가장 기이한 사례입니다.
동의합니다 
그것은 .org 네임서버입니다.
DNSSEC 컨트롤은 도메인 등록 기관(registrar)에서 수행해야 합니다. 글루 레코드(glue records)와 마찬가지로, 도메인의 DS 레코드는 TLD 네임서버에 존재해야 하기 때문입니다. DNS 제공업체는 이에 대해 통제할 수 없습니다.
여전히 해당 레코드들이 그곳에 존재하는 것을 볼 수 있습니다:
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
그리고 분석기에서도 여전히 오류가 표시됩니다:
그들이 누군가를 데려와서 이 문제를 해결할 때까지 계속 그들에게 요청해야 합니다 - 이것은 등록 기관의 책임으로 올바르게 처리해야 하는 부분입니다.
또한 이전 등록 기관과 대화하여 해당 존(zone)에 대한 글루 및 DS 레코드 제출을 중단하도록 요청하는 것도 도움이 될 수 있습니다.
수정(EDIT):
현재 공개된 .org 존 레코드는 다음과 같습니다:
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=
오늘 아침에 이전 등록기관(네덜란드의 Argeweb)이 해당 도메인의 DS 레코드를 시스템에서 마침내 제거했다는 확인을 받았습니다.
따라서 현재는 Network Solutions(등록기관)에서 Cloudflare(네임서버)의 올바른(새로운) DS 레코드가 설정되어 있음을 확인했고, 이전 등록기관(Argeweb)은 자신의 레코드를 제거했음을 확인했습니다.
이제 전 세계적으로 모든 설정이 반영되기만 기다리면 될 것 같습니다. NetSol과 Cloudflare의 확인은 수요일 늦게 이루어졌고, Argeweb의 확인은 오늘 아침에 이루어졌습니다. 이번 주말에 모든 것이 정상적으로 조정되길 바랍니다. 손가락 꼬아쥐며
최대 하루가 걸릴 것입니다.
여기저기 'should’가 너무 많네요… Argeweb은 도메인을 이전하기 전에 애초에 DNSSEC을 비활성화했어야 했습니다. Network Solutions도 도메인을 가져왔을 때 그쪽에서 확인하고 비활성화할 수 있었어야 합니다.
'Should’가 이 프로젝트 전체의 골칫덩이입니다.
레지스트라와 루트 존 운영자 뒤에 있는 인터페이스가 정확히 어떻게 작동하는지는 모르겠습니다. 델타를 보내는지, 아니면 매일 전체 업데이트를 보내는지요. 하지만 그들은 프로세스를 알고 있고, 올바른 조치를 취했어야 합니다.
마찬가지로, Network Solutions은 존을 이전할 때 이전 DS 레코드를 그들의 인터페이스에 가져왔어야 합니다. 아마도 NS 레코드도 함께 이전되었겠지만, 혹시 NS 레코드를 직접 제공해야 했을 수도 있습니다?
DNS를 올바르게 설정하는 것은 까다로운 일이며, DNSSEC은 그보다 훨씬 더 그렇습니다.
Should have / could have / would have
최소한 문제의 원인과 해결 방법을 알고 있잖아요.
공급업체는 거의 항상 다른 사람을 탓하기 일쑤입니다.
오늘 pidforum.org의 DS glue가 변경되지 않은 것을 확인했습니다.
Network Solutions 인터페이스에 올바른 레코드를 추가했나요?
네, 지난 주 후반에 Network Solutions에 올바른 레코드를 추가했고, 주말 내내 기다렸는데… 아무 변화가 없어요. 잘못된 DS 레코드 30311이 여전히 어딘가에 숨어 있고, 아무도 이를 수정할 수 없는 것 같습니다.
위 링크에서 올바른 레코드와 잘못된 레코드를 모두 확인하실 수 있습니다…
올바른 레코드가 .org 레벨에는 존재하지 않습니다. 중요한 부분이 바로 이 지점입니다.
Network Solutions에 올바른 레코드를 게시하도록 계속 요청해야 합니다.
도메인 설정의 해당 부분에 대한 스크린샷이 있으신가요?
Network Solutions는 DNSSEC의 어떤 측면에 대해서도 공개된 관리자를 제공하지 않습니다. 지원 그룹 중 DNSSEC을 담당하는 팀은 단 하나뿐이며, 이메일을 통해 소통해야 합니다.
아니, 장난이 아닙니다.
오늘 마침 어떤 단서라도 가지고 있을 것 같은 지원 단계에 도달했는데, 24~48시간 내에 답변을 주겠다고 하더군요.
아직도 해결이 안 됐네. 아파. 그리피, 너의 고충을 잘 알아.
여기에서(here) 검사를 실행했습니다. 결과에서 KeyTag 30311이 어디에 있는지 확인할 수 있습니다.
Error: DNSKEY 2371 signs DNSKEY RRset, but no confirming DS RR in the parent zone found. No chain of trust created.
Fatal error: Parent zone has a signed DS RR (Algorithm 8, KeyTag 30311, DigestType 2, Digest p13rHPfOPulImZQcfpK3Kn6Dp7Xc03F9ZzGAS02FHkY=), but the destination DNSKEY doesn't exist or doesn't validate the DNSKEY RR set. No chain of trust created.
아직 해결되지 않았습니다. Network Solutions는 DNSSEC과 복잡한 도메인 문제에서는 정말 쓸모없는 것 같습니다. 분명히 DNSSEC 문제이며, 아무도 제거할 수 없다고 생각하는 dSKEY(30311) 하나가 어딘가 허공에 떠 있는 상태입니다.
도메인을 Google Cloud로 이전하세요.
이후 DNSSEC 설정을 직접 관리할 수 있습니다.
이 문제에 대한 최종 업데이트입니다… 만족스럽지는 않지만, 뭔가 해소되어 도메인이 전파되기 시작했습니다. 정확히 무엇이 변경되었는지는 명확하지 않습니다. 여전히 30311 DSKEY 항목이 보이거든요. 하지만 등록국 쪽에서 무슨 일이 있었든, 지금은 정상적으로 작동하고 있습니다.
업데이트 감사합니다