IDN ccTLD를 구성 할 수있는 기회가 주어졌습니다. DNS 서버를 이미 구성했으며 제대로 작동하고 있습니다. 이제 DNSSEC에 의한 DNS 서비스 보안을 유지하는 데 어려움이 있습니다. 자체 서명으로 DNSSECC를 구성했습니다. 하지만 이제는 DS 레코드를 어디서 어떻게 입력해야하는지 이해할 수 없습니다.IDN ccTLD에 대한 DNSSEC DS 레코드 제출 방법 및 방법
위의 DS 레코드는 위임 영역에 있습니다. 실제로 위탁 영역이 ccTLD를 루트 영역으로 구성하는 경우입니다. 따라서 ICANN의 담당자에게 필요한 정보를 얻는 방법에 대해 문의하십시오.
Calle Dybedahl은 "어디에" "어떻게"에 대해 귀하의 ccTLD (IDN 또는 기타)에 대해 DNSSEC를 사용해야하는지에 대한 몇 가지 지침을 제공하고자합니다.
Viktor Dukhovni의 "Common Mistakes" 페이지는 DANE (DNSSEC를 인증서의 앵커, 특히 SMTP의 앵커로 사용)와 관련된 많은 사항을 다루지 만 처음 두 점 (마지막 점은 마지막 점)은 DNSSEC을 구현하는 운영자, 특히 어떤 종류의 TLD라도. 특히
은 아래 요약 된 첫 번째 점은 매우 중요하다 :
출판 DNSSEC DS 레코드가 ... 패션 성명
이러한 올바른 유지하는 동작 훈련이 필요합니다. 관리자 "fire and forget"을 기대하는 사람은 DNSSEC의 서명 된 영역을 게시해서는 안됩니다 ... 또는 다른 사람에게 비용을 지불하여 영역을 호스트 할 수 있습니다 ... DNSSEC 영역을 유지 관리 할 때 문제가 발생했습니다 ... 뿐만 아니라 도메인과 통신하려는 모든 도메인에 대해서도 마찬가지입니다. DNSSEC ... 심각하게 받아 들여지는 경우 모두가 더 좋습니다.
올바른 작동으로 DNSSEC 서명 구역을 유지하는 것과 관련된 기록이 별과 멀리 떨어져있는 ccTLD가 여러 개 있습니다.- IANIX 정전 목록에 두 번 이상 나타나는 TLD를 찾으십시오.
IDN ccTLD가 새로운 TLD이므로 DNSSEC는 필수 항목이므로 IANIX가 제공하는 빨간 알약을 삼키고 DNSSEC를 포기하더라도 여전히 구현할 수 밖에 없습니다. TLD는 도메인의 운영뿐만 아니라 도메인에 등록 된 모든 도메인의 운영 및 보안에 직접 영향을 미치기 때문에 DNSSEC 배포를 최대한으로 처리해야합니다.
DNSSEC이기 때문에 또한, 같은 어려운 문제, 그것은, exceeding 15% of all clients worldwide 멀리 가서 clients that validate DNSSEC 자신의 번호 (또는 Google Public DNS, Comcast ISP, 또는 Verisign Public DNS 같은 DNSSEC - 유효성 확인 서비스에만 의존) 중요 할 가능성이과 많은 국가에서 IDN ccTLD의 후보가 될 가능성이 훨씬 높습니다 (및 이전 링크의 국가 별 드릴 다운을 참조하십시오. 예 : Kenya where 40% of clients rely on DNSSEC validation 및 .KE TLD had a significant DNSSEC outage last month).
ISOC 및 a best practices PDF에는 훌륭한 리소스가있어 "직접 해보고"자신의 DNSSEC 영역 서명을 롤업하려는 경우 DNSSEC를 관리하는 데 도움이됩니다.하지만이 문제를 해결하는 것은 매우 쉽습니다. 정기적 인 모니터링과 전화 응답없이 DNSSEC 서명이 만료되어 수백만 명의 전체 도메인에 도달 할 수 있습니다. 더욱이 DNSSEC 서명에 사용되는 개인 키가 유출되면 DNSSEC에 따라 도메인의 보안이 위태로울 수 있습니다.
장기적으로 관리 DNSSEC를 제공 할 수있는 상용 DNS 제공 업체 (귀하가 TLD의 레지스트리 측을 운영하는 동안)에 IDN ccTLD의 영역을 호스팅하는 것이 더 쉽고 저렴하지 않을 수 있는지 여부를 심각하게 고려할 수 있습니다 DNS 관리 API를 사용하여 레지스트리 구현에서 영역을 업데이트하십시오.
마지막 조언 하나; ccTLD에 DS 레코드가없는 수백만 개의 도메인에 위임자가없고 NSEC3 opt-out이 필요하거나 데이터 보호 법률 [1][2]에 유럽을 사용하는 경우가 아니면 NSEC3을 사용해야 할 수도 있습니다. Google 공개 DNS (및 기타 구현 aggressive NSEC caching)가 권한있는 서버로 전달하지 않고 NXDOMAIN 서비스 거부 공격 및 정크 쿼리를 흡수 할 수 있습니다. NSEC3이 실제로 영역 열거에 대해 상당한 보호를 제공한다면 가치가있을 수도 있지만 not hard to break it if you have a decent GPU이고 protection against NXDOMAIN attacks (2016-2017은 NSEC에서만 가능함)이 더 유용합니다.