기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Route 53에서 DNSSEC 서명 구성 DNSSEC(도메인 이름 시스템 보안 확장) 서명을 사용하면 DNS 해석기가 DNS 응답이 Amazon Route 53에서 왔으며 변조되지 않았는지 검증할 수 있습니다. DNSSEC 서명을 사용하면 호스팅 영역에 대한 모든 응답이 퍼블릭 키 암호화를 사용하여 서명됩니다. DNSSEC에 대한 개요는 [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE)의 DNSSEC 섹션을 참조하세요. 이 장에서는 Route 53에 대해 DNSSEC 서명을 사용하는 방법, KSK(키 서명 키)에서 작업하는 방법 및 문제 해결 방법에 대해 설명합니다. 에서 DNSSEC 서명을 사용하거나 API를 사용하여 AWS Management Console 프로그래밍 방식으로 작업할 수 있습니다. CLI나 SDK를 사용하여 Route 53에서 작업하는 방법에 대한 자세한 내용은 [Amazon Route 53 설정](setting-up-route-53.md) 섹션을 참조하세요. DNSSEC 서명을 사용하기 전에 다음 사항에 유의하세요. + 영역 중단을 방지하고 도메인을 사용할 수 없게 되는 문제를 방지하려면 DNSSEC 오류를 신속하게 대응하고 해결해야 합니다. `DNSSECInternalFailure` 또는 `DNSSECKeySigningKeysNeedingAction` 오류를 감지할 때마다 알림이 전송되도록 CloudWatch 경보를 설정하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 섹션을 참조하세요. + DNSSEC에는 KSK(키 서명 키) 와 ZSK(영역 서명 키)라는 두 가지 키가 있습니다. Route 53 DNSSEC 서명에서 각 KSK는 사용자가 소유한 AWS KMS 의 [비대칭 고객 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)를 기반으로 합니다. 필요한 경우 교체를 포함한 KSK 관리에 대한 책임은 사용자에게 있습니다. ZSK 관리는 Route 53에서 수행합니다. + 호스팅 영역에 대해 DNSSEC 서명을 사용하면 Route 53가 TTL을 1주일로 제한합니다. 호스팅 영역의 레코드에 대해 TTL을 1주일보다 긴 기간으로 설정하면 오류가 발생하지 않습니다. 그러나 Route 53는 해당 레코드에 대해 1주일의 TTL을 적용합니다. TTL이 1주일 미만인 레코드와 DNSSEC 서명이 사용되지 않은 다른 호스팅 영역의 레코드는 영향을 받지 않습니다. + DNSSEC 서명을 사용하면 다중 공급 업체 구성이 지원되지 않습니다. 화이트 레이블 이름 서버(베니티 이름 서버 또는 프라이빗 이름 서버라고도 함)를 구성한 경우, 이 이름 서버가 단일 DNS 공급자로 제공되는지 확인합니다. + 일부 DNS 공급자는 권한 있는 DNS에 DS(Delegation Signer) 레코드를 지원하지 않습니다. DS 쿼리 응답에 AA 플래그를 설정하지 않고 DS 쿼리를 지원하지 않는 DNS 공급자가 상위 영역을 호스팅한다면, 하위 영역에서 DNSSEC를 활성화하는 경우에 하위 영역을 확인할 수 없게 됩니다. DNS 공급자가 DS 레코드를 지원하는지 확인하세요. + 영역 소유자 외에 다른 사용자가 해당 영역에 레코드를 추가하거나 제거할 수 있도록 IAM 권한을 설정하는 것이 도움이 될 수 있습니다. 예를 들어 영역 소유자는 KSK를 추가하고 서명을 활성화할 수 있으며 키 교체를 담당할 수도 있습니다. 그러나 다른 사람에게 호스팅 영역에 대한 다른 레코드로 작업할 책임이 있을 수 있습니다. IAM 정책 예제는 [도메인 레코드 소유자에 대한 사용 권한 예제](access-control-managing-permissions.md#example-permissions-record-owner) 단원을 참조하세요. + TLD에 DNSSEC 지원이 있는지 확인하려면 [Amazon Route 53에 등록할 수 있는 도메인](registrar-tld-list.md) 섹션을 참조하세요. **Topics** + [DNSSEC 서명 활성화 및 신뢰 체인 설정](dns-configuring-dnssec-enable-signing.md) + [DNSSEC 서명 비활성화](dns-configuring-dnssec-disable.md) + [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) + [KSK(키 서명 키)로 작업](dns-configuring-dnssec-ksk.md) + [Route 53에서의 KMS 키 및 ZSK 관리](dns-configuring-dnssec-zsk-management.md) + [Route 53에서 존재하지 않는다는 DNSSEC 증명](dns-configuring-dnssec-proof-of-nonexistence.md) + [DNSSEC 서명 문제 해결](dns-configuring-dnssec-troubleshoot.md) # DNSSEC 서명 활성화 및 신뢰 체인 설정 **** 증분 단계는 호스팅 영역 소유자와 상위 영역 유지 관리자에게 적용됩니다. 두 사람은 동일한 사람이 될 수 있지만, 그렇지 않은 경우 영역 소유자는 상위 영역 유지 관리자에게 알리고 협력해야 합니다. 이 문서의 단계를 따라 영역에 서명하고 신뢰 체인에 포함시키는 것이 좋습니다. 다음 단계는 DNSSEC로의 온보딩 시 위험을 최소화해 줍니다. **참고** 시작하기 전에 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md)에서 사전 조건을 읽어야 합니다. DNSSEC 서명을 활성화하려면 다음 섹션에 설명된 세 가지 단계를 수행해야 합니다. **Topics** + [1단계: DNSSEC 서명 활성화 준비](#dns-configuring-dnssec-enable-signing-step-1) + [2단계: DNSSEC 서명 활성화 및 KSK 생성](#dns-configuring-dnssec-enable) + [3단계: 신뢰 체인 설정](#dns-configuring-dnssec-chain-of-trust) ## 1단계: DNSSEC 서명 활성화 준비 준비 단계는 영역 가용성을 모니터링하고 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄여 DNSSEC로의 온보딩 시 위험을 최소화하는 데 도움이 됩니다. **DNSSEC 서명 활성화를 준비하려면** 1. 영역 가용성을 모니터링합니다. 영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이것은 DNSSEC 서명을 활성화한 후 한 단계 뒤로 롤백해야 하는 모든 문제를 해결하는 데 도움이 될 수 있습니다. 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 [Amazon Route 53 모니터링](monitoring-overview.md) 단원을 참조하세요. 모니터링은 셸 스크립트 또는 서드 파티 서비스를 통해 수행할 수 있습니다. 그러나 이것이 롤백이 필요한지 결정하기 위한 유일한 신호는 아닙니다. 도메인을 사용할 수 없는 문제로 고객으로부터 피드백을 받을 수도 있습니다. 1. 영역의 최대 TTL을 낮춥니다. 영역의 최대 TTL은 영역에서 가장 긴 TTL 레코드입니다. 다음의 영역 예에서 영역의 최대 TTL은 1일(86,400초)입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) 영역의 최대 TTL을 낮추면 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄이는 데 도움이 됩니다. 영역의 최대 TTL을 1시간(3,600초)으로 낮추는 것이 좋습니다. 이렇게 하면 해석기가 서명된 레코드를 캐싱하는 데 문제가 있는 경우 단 1시간 후에 롤백할 수 있습니다. **롤백:** TTL 변경 사항을 실행 취소합니다. 1. SOA TTL 및 SOA 최소 필드를 낮춥니다. SOA 최소 필드는 SOA 레코드 데이터의 마지막 필드입니다. 다음 SOA 레코드 예제에서 최소 필드는 5분(300초)의 값을 가집니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) SOA TTL 및 SOA 최소 필드는 해석기가 부정 답변을 얼마나 오래 기억할지 결정합니다. 서명을 활성화하면 Route 53 이름 서버가 부정 답변을 위한 NSEC 레코드를 반환하기 시작합니다. NSEC에는 해석기가 부정 답변을 합성하는 데 사용할 수 있는 정보가 포함되어 있습니다. NSEC 정보로 인해 해석기가 이름에 대한 부정 답변을 가정하기 때문에 롤백해야 하는 경우, 해석기가 가정을 중지하게 하려면 SOA TTL 및 SOA 최소 필드의 최댓값을 기다리기만 하면 됩니다. **롤백:** SOA 변경 사항을 실행 취소합니다. 1. TTL 및 SOA 최소 필드 변경의 효과가 적용되었는지 확인합니다. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 사용하여 지금까지의 변경 사항이 모든 Route 53 DNS 서버에 전파되었는지 확인합니다. ## 2단계: DNSSEC 서명 활성화 및 KSK 생성 Route 53 콘솔에서 AWS CLI 또는를 사용하여 DNSSEC 서명을 활성화하고 KSK(키 서명 키)를 생성할 수 있습니다. + [CLI](#dnssec_CLI) + [콘솔](#dnssec_console) KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하십시오. ------ #### [ CLI ] 이미 보유하고 있는 키를 사용하거나, 고유한 요청을 만들기 위해 `hostedzone_id`, `cmk_arn`, `ksk_name` 및 `unique_string`에 대한 자체 값을 사용하는 다음과 같은 AWS CLI 명령을 실행하여 키를 생성할 수 있습니다. ``` aws --region us-east-1 route53 create-key-signing-key \ --hosted-zone-id $hostedzone_id \ --key-management-service-arn $cmk_arn --name $ksk_name \ --status ACTIVE \ --caller-reference $unique_string ``` 사용자 지정 고객 관리형 키에 대한 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하세요. [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)도 참조하세요. DNSSEC 서명을 활성화하려면에 대한 자체 값을 사용하여 `hostedzone_id`다음과 같은 AWS CLI 명령을 실행합니다. ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 자세한 내용은 [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) 및 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)을 참조하세요. ------ #### [ Console ] **DNSSEC 서명 활성화 및 KSK 생성** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역**을 선택한 후 DNSSEC 서명을 활성화할 호스팅 영역을 선택합니다. 1. **DNSSEC 서명** 탭에서 **DNSSEC 서명 활성화**를 선택합니다. **참고** 이 섹션의 옵션이 **DNSSEC 서명 비활성화**인 경우 DNSSEC 서명 활성화의 첫 단계를 이미 완료한 것입니다. DNSSEC의 호스팅 영역에 대한 신뢰 체인을 설정하거나 이미 존재하는지 확인하세요. 그러면 완료됩니다. 자세한 내용은 [3단계: 신뢰 체인 설정](#dns-configuring-dnssec-chain-of-trust) 단원을 참조하십시오. 1. **KSK(키 서명 키) 생성(Key-signing key (KSK) creation)** 섹션에서 **새 KSK 생성(Create new KSK)**을 선택하고 **KSK 이름 제공(Provide KSK name)**에 Route 53가 생성할 KSK의 이름을 입력합니다. 이름에는 숫자, 문자, 밑줄(\$1)이 포함될 수 있습니다. 이름은 고유해야 합니다. 1. **고객 관리형 CMK**에서 Route 53에서 KSK를 생성할 때 사용할 고객 관리형 키를 선택합니다. DNSSEC 서명에 적용되는 기존 고객 관리형 키를 사용하거나 새 고객 관리형 키를 생성할 수 있습니다. 고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 섹션을 참조하세요. 1. 기존 고객 관리형 키의 별칭을 입력합니다. 새 고객 관리형 키를 사용하려면 고객 관리형 키의 별칭을 입력합니다. 그러면 Route 53에서 키를 생성합니다. **참고** Route 53에서 고객 관리형 키를 만들도록 선택한 경우 고객 관리형 키마다 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하세요. 1. **DNSSEC 서명 활성화**를 선택합니다. ------ **영역 서명을 활성화한 후 다음 단계를 완료합니다**(콘솔 또는 CLI를 사용했는지 여부에 상관 없음). 1. 영역 서명의 효과가 적용되었는지 확인합니다. 를 사용한 경우 `EnableHostedZoneDNSSEC()` 호출 출력의 작업 ID를 사용하여 [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) 또는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)를 실행하여 모든 Route 53 DNS 서버가 응답에 서명하는지 확인할 AWS CLI수 있습니다(상태 = `INSYNC`). 1. 적어도 이전 영역의 최대 TTL 동안 기다립니다. 해석기가 서명되지 않은 모든 레코드를 캐시에서 비울 때까지 기다립니다. 이를 위해서는 적어도 이전 영역의 최대 TTL 동안 기다려야 합니다. 위의 `example.com` 영역에서는 대기 시간이 1일입니다. 1. 고객 문제에 대한 보고서를 모니터링합니다. 영역 서명을 활성화한 후에는 고객에게 네트워크 디바이스 및 해석기와 관련된 문제가 표시되기 시작할 수 있습니다. 권장되는 모니터링 기간은 2주입니다. 다음은 표시될 수 있는 문제의 예제니다. + 일부 네트워크 디바이스는 DNS 응답 크기를 512바이트 미만으로 제한할 수 있으며 이는 일부 서명된 응답에 사용하기에 너무 작은 크기입니다. 이러한 네트워크 디바이스는 더 큰 DNS 응답 크기를 허용하도록 재구성되어야 합니다. + 일부 네트워크 디바이스는 DNS 응답에 대한 세부적인 검사를 수행하여 DNSSEC에 사용된 것과 같이 디바이스가 이해하지 못하는 특정 레코드를 제거합니다. 이러한 디바이스는 재구성해야 합니다. + 일부 고객의 해석기는 네트워크가 지원하는 것보다 더 큰 UDP 응답을 받아들일 수 있다고 주장합니다. 네트워크 역량을 테스트하고 해석기를 적절하게 구성할 수 있습니다. 자세한 내용은 [DNS 응답 크기 테스트 서버](https://www.dns-oarc.net/oarc/services/replysizetest/)를 참조하세요. **롤백:** [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)를 직접 호출한 다음 [1단계: DNSSEC 서명 활성화 준비](#dns-configuring-dnssec-enable-signing-step-1)의 단계를 롤백합니다. ## 3단계: 신뢰 체인 설정 Route 53에서 호스팅 영역에 대해 DNSSEC 서명을 활성화한 후 호스팅 영역에 대한 신뢰 체인을 설정하여 DNSSEC 서명 설정을 완료합니다. 이렇게 하려면 Route 53에서 제공하는 정보를 사용하여 호스팅 영역에 대한 *상위* 호스팅 영역에서 DS(Delegation Signer) 레코드를 생성하면 됩니다. 도메인이 등록된 위치에 따라 Route 53의 상위 호스팅 영역 또는 다른 도메인 등록 기관에 레코드를 추가합니다. **DNSSEC 서명에 대한 신뢰 체인을 설정하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역**을 선택한 후 DNSSEC 신뢰 체인을 설정할 호스팅 영역을 선택합니다. *먼저 DNSSEC 서명을 활성화해야 합니다.* 1. **DNSSEC 서명**의 **DNSSEC 서명** 탭에서 **DS 레코드를 만들기 위한 정보 보기**를 선택합니다. **참고** 이 섹션에 **DS 레코드를 만들기 위한 정보 보기**가 표시되지 않는 경우 신뢰 체인을 설정하기 전에 DNSSEC 서명을 활성화해야 합니다. **DNSSEC 서명 활성화(Enable DNSSEC signing)**를 선택하고 [2단계: DNSSEC 서명 활성화 및 KSK 생성](#dns-configuring-dnssec-enable)에 설명된 단계를 완료한 다음 이 단계로 돌아와 신뢰 체인을 설정합니다. 1. **신뢰 체인 설정**에서 도메인이 등록된 위치에 따라 **Route 53 등록 기관** 또는 **다른 도메인 등록 기관** 중 하나를 선택합니다. 1. 3단계에서 제공된 값을 사용하여 Route 53의 상위 호스팅 영역에 대한 DS 레코드를 생성합니다. 도메인이 Route 53에서 호스팅되지 않는 경우, 제공된 값을 사용하여 도메인 등록 기관 웹 사이트에 DS 레코드를 생성합니다. 상위 영역에 대한 신뢰 체인을 설정합니다. + 도메인이 Route 53를 통해 관리되는 경우 다음 단계를 따릅니다. 올바른 서명 알고리즘(ECDSAP256SHA256 및 유형 13) 및 다이제스트 알고리즘(SHA-256 및 유형 2)을 구성했는지 확인합니다. Route 53가 등록 기관인 경우 Route 53 콘솔에서 다음을 수행합니다. 1. **키 유형**, **서명 알고리즘** 및 **퍼블릭 키** 값을 참고합니다. 탐색 창에서 **등록된 도메인**을 선택합니다. 1. 도메인을 선택한 후 **DNSSEC 키** 탭에서 **키 추가**를 선택합니다. 1. **DNSSEC 키 관리** 대화 상자의 드롭다운 메뉴에서 **Route 53 등록 기관**의 적절한 **키 유형** 및 **알고리즘**을 선택합니다. 1. Route 53 등록 기관의 **퍼블릭 키**를 복사합니다. **DNSSEC 키 관리(Manage DNSSEC keys)** 대화 상자에서 값을 **퍼블릭 키(Public key)** 입력란에 붙여넣습니다. 1. **추가**를 선택합니다. Route 53는 공개 키의 상위 영역에 DS 레코드를 추가합니다. 예를 들어 도메인이 `example.com`인 경우 DS 레코드는 .com DNS 영역에 추가됩니다. + 도메인이 다른 레지스트리에서 관리되는 경우 **다른 도메인 등록 기관** 섹션의 지침을 따릅니다. 다음 단계가 원활하게 진행될 수 있도록 상위 영역에 낮은 DS TTL을 도입합니다. 변경 사항을 롤백해야 하는 경우 빠르게 복구할 수 있도록 DS TTL을 5분(300초)으로 설정하는 것이 좋습니다. + 하위 영역에 대한 신뢰 체인을 설정합니다. 상위 영역을 다른 레지스트리에서 관리하는 경우 등록 기관에 연락하여 해당 영역에 대한 DS 레코드를 도입하도록 합니다. 일반적으로 DS 레코드의 TTL은 조정할 수 없습니다. + 상위 영역이 Route 53에서 호스팅되는 경우 상위 영역 소유자에게 연락하여 해당 영역에 대한 DS 레코드를 도입하도록 합니다. 상위 영역 소유자에게 `$ds_record_value`를 제공합니다. 이 값은 콘솔의 **DS 레코드를 생성하기 위한 정보 보기(View Information to create DS record)**를 클릭하고 **DS 레코드(DS record)** 필드를 복사하거나 [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API를 호출하고 'DSRecord' 필드의 값을 검색하여 얻을 수 있습니다. ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` 상위 영역 소유자는 Route 53 콘솔 또는 CLI를 통해 레코드를 삽입할 수 있습니다. + 를 사용하여 DS 레코드 AWS CLI를 삽입하기 위해 상위 영역 소유자는 다음 예제와 유사한 JSON 파일을 생성하고 이름을 지정합니다. 상위 영역 소유자는 파일의 이름을 `inserting_ds.json`과 같이 지정할 수 있습니다. ``` { "HostedZoneId": "$parent_zone_id", "ChangeBatch": { "Comment": "Inserting DS for zone $zone_name", "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "$zone_name", "Type": "DS", "TTL": 300, "ResourceRecords": [ { "Value": "$ds_record_value" } ] } } ] } } ``` 그런 다음, 다음 명령을 실행합니다. ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + 콘솔을 사용하여 DS 레코드를 삽입하려면 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다. 탐색 창의 **호스팅 영역(Hosted zones)**에서 호스팅 영역의 이름을 선택한 다음 **레코드 생성(Create record)** 버튼을 선택합니다. **라우팅 정책(Routing policy)**에 단순 라우팅을 선택했는지 확인합니다. **레코드 이름** 필드에 `$zone_name`과 같은 이름을 입력하고, **레코드 유형** 드룹 다운에서 DS를 선택하고, **값** 필드에 `$ds_record_value`의 값을 입력한 다음 **레코드 생성**을 선택합니다. **롤백:** 상위 영역에서 DS를 제거하고 DS TTL 동안 기다린 다음 신뢰를 설정하는 단계를 롤백합니다. 상위 영역이 Route 53에서 호스팅되는 경우, 상위 영역 소유자는 JSON 파일의 `Action`을 `UPSERT`에서 `DELETE`로 변경하고 위의 예제 CLI를 다시 실행할 수 있습니다. 1. 도메인 레코드의 TTL을 기반으로 업데이트가 전파될 때까지 기다립니다. 상위 영역이 Route 53 DNS 서비스에 있는 경우, 상위 영역 소유자는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API를 통해 전파 완료를 확인할 수 있습니다. 그렇지 않으면 DS 레코드의 상위 영역을 주기적으로 조사한 다음 DS 레코드 삽입이 완전히 전파될 확률을 높일 수 있도록 10분 더 기다릴 수 있습니다. 일부 등록 기관은 일정(예: 하루에 한 번)에 따라 DS 삽입을 수행합니다. 상위 영역에 DS(Delegation Signer) 레코드를 도입하면 DS를 선택한 검증된 해석기가 해당 영역에서 응답의 유효성을 검사하기 시작합니다. 신뢰 설정 단계가 원활하게 진행되도록 하려면 다음을 완료합니다. 1. 최대 NS TTL을 찾습니다. 영역과 관련된 NS 레코드에는 2가지 세트가 있습니다. + 위임 NS 레코드 - 상위 영역이 보유한 영역에 대한 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다(영역이 example.com인 경우 상위 영역은 com). `dig -t NS com` NS 레코드 중 하나를 선택한 후 다음을 실행합니다. `dig @one of the NS records of your parent zone -t NS example.com` 예: `dig @b.gtld-servers.net. -t NS example.com` + 영역 내 NS 레코드 - 이것은 영역에 있는 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다. `dig @one of the NS records of your zone -t NS example.com` 예: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 두 영역 모두에 대한 최대 TTL을 확인합니다. 1. 최대 NS TTL 동안 기다립니다. DS 삽입 전에 해석기는 서명된 응답을 받지만 서명을 검증하지는 않습니다. DS 레코드가 삽입되면 영역의 NS 레코드가 만료되기 전까지는 해석기가 해당 레코드를 볼 수 없습니다. 해석기가 NS 레코드를 다시 가져오면 DS 레코드도 반환됩니다. 고객이 동기화되지 않은 클럭이 있는 호스트에서 해석기를 실행하는 경우 시계가 올바른 시간에서 1시간 이내인지 확인하십시오. 이 단계를 완료하면 모든 DNSSEC 인식 해석기가 영역을 검증합니다. 1. 이름 확인을 관찰합니다. 해석기의 영역 검증에 문제가 없음을 확인해야 합니다. 고객이 문제를 보고하는 데 필요한 시간도 고려해야 합니다. 최대 2주 동안 모니터링하는 것이 좋습니다. 1. (선택 사항) DS 및 NS TTL을 늘립니다. 설정에 만족하면 TTL 및 SOA 변경 사항을 저장할 수 있습니다. Route 53는 서명된 영역에 대해 TTL을 1주로 제한합니다. 자세한 내용은 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md) 섹션을 참조하세요. DS TTL을 변경할 수 있는 경우, 1시간으로 설정하는 것이 좋습니다. # DNSSEC 서명 비활성화 Route 53에서 DNSSEC 서명을 비활성화하는 단계는 호스팅 영역이 속한 신뢰 체인에 따라 다릅니다. 예를 들어 호스팅 영역에 신뢰 체인의 일부로 DS(Delegation Signer) 레코드가 있는 상위 영역이 있을 수 있습니다. 호스팅 영역 자체가 신뢰 체인의 또 다른 부분인 DNSSEC 서명을 활성화한 하위 영역의 상위 영역일 수도 있습니다. DNSSEC 서명을 사용하지 않는 단계를 수행하기 전에 호스팅 영역에 대한 전체 신뢰 체인을 조사하고 확인합니다. 서명을 사용하지 않는 경우 DNSSEC 서명을 활성화하는 호스팅 영역에 대한 신뢰 체인은 주의해서 실행 취소해야 합니다. 신뢰 체인에서 호스팅 영역을 제거하려면 이 호스팅 영역을 포함하는 신뢰 체인의 위치에 있는 모든 DS 레코드를 제거합니다. 즉, 순서대로 다음을 수행해야 합니다. 1. 이 호스팅 영역에 신뢰 체인의 일부인 하위 영역으로 있는 DS 레코드를 모두 제거합니다. 1. 상위 영역에서 DS 레코드를 제거합니다. 신뢰 영역이 있는 경우(상위 영역에 DS 레코드가 없고 이 영역의 하위 영역에 대한 DS 레코드가 없는 경우) 이 단계를 건너뜁니다. 1. DS 레코드를 제거할 수 없는 경우, 신뢰 체인에서 영역을 제거하려면 상위 영역에서 NS 레코드를 제거합니다. 자세한 내용은 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](domain-name-servers-glue-records.md) 단원을 참조하십시오. 다음 증분 단계를 통해 개별 단계의 효과를 모니터링하여 영역의 DNS 가용성 문제를 방지할 수 있습니다. **DNSSEC 서명을 비활성화하려면** 1. 영역 가용성을 모니터링합니다. 영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이것은 DNSSEC 서명을 활성화한 후 한 단계 뒤로 롤백해야 하는 모든 문제를 해결하는 데 도움이 될 수 있습니다. 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 [Amazon Route 53 모니터링](monitoring-overview.md) 단원을 참조하세요. 모니터링은 셸 스크립트 또는 유료 서비스를 통해 수행할 수 있습니다. 그러나 이것이 롤백이 필요한지 결정하기 위한 유일한 신호는 아닙니다. 도메인을 사용할 수 없는 문제로 고객으로부터 피드백을 받을 수도 있습니다. 1. 현재 DS TTL을 찾습니다. DS TTL은 다음 Unix 명령을 실행하여 찾을 수 있습니다. `dig -t DS example.com example.com` 1. 최대 NS TTL을 찾습니다. 영역과 관련된 NS 레코드에는 2가지 세트가 있습니다. + 위임 NS 레코드 - 상위 영역이 보유한 영역에 대한 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다. 먼저 상위 영역의 NS를 찾습니다(영역이 example.com인 경우 상위 영역은 com). `dig -t NS com` NS 레코드 중 하나를 선택한 후 다음을 실행합니다. `dig @one of the NS records of your parent zone -t NS example.com` 예: `dig @b.gtld-servers.net. -t NS example.com` + 영역 내 NS 레코드 - 이것은 영역에 있는 NS 레코드입니다. 이 레코드는 다음 Unix 명령을 실행하여 찾을 수 있습니다. `dig @one of the NS records of your zone -t NS example.com` 예: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 두 영역 모두에 대한 최대 TTL을 확인합니다. 1. 상위 영역에서 DS 레코드를 제거합니다. 상위 영역 소유자에게 연락하여 DS 레코드를 제거하도록 합니다. **롤백:** DS 레코드를 다시 삽입하고 DS 삽입이 효과가 있는지 확인한 다음 모든 해석기가 다시 검증을 시작할 때까지 최대 NS(DS가 아님) TTL 동안 기다립니다. 1. DS 제거의 효과가 적용되었는지 확인합니다. 상위 영역이 Route 53 DNS 서비스에 있는 경우, 상위 영역 소유자는 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API를 통해 전파 완료를 확인할 수 있습니다. 그렇지 않으면 DS 레코드의 상위 영역을 주기적으로 조사한 다음 DS 레코드 제거가 완전히 전파될 확률을 높일 수 있도록 10분 더 기다릴 수 있습니다. 일부 등록 기관은 일정(예: 하루에 한 번)에 따라 DS 제거를 수행합니다. 1. DS TTL 동안 기다립니다. 모든 해석기의 캐시에서 DS 레코드가 만료될 때까지 기다립니다. 1. DNSSEC 서명을 비활성화하고 KSK(키 서명 키)를 비활성화합니다. + [CLI](#CLI_dnssec_disable) + [콘솔](#console_dnssec_disable) ------ #### [ CLI ] [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) 및 [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) API를 호출합니다. 예: ``` aws --region us-east-1 route53 disable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id aws --region us-east-1 route53 deactivate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name ``` ------ #### [ Console ] **DNSSEC 서명을 비활성화하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택한 후 DNSSEC 서명을 비활성화할 호스팅 영역을 선택합니다. 1. **DNSSEC 서명(DNSSEC signing)** 탭에서 **DNSSEC 서명 비활성화(Disable DNSSEC signing)**를 선택합니다. 1. **DNSSEC 서명 비활성화(Disable DNSSEC signing)** 페이지에서 DNSSEC 서명을 비활성화하려는 영역의 시나리오에 따라 다음 옵션 중 하나를 선택합니다. + **상위 영역만(Parent zone only)** - 이 영역에는 DS 레코드가 있는 상위 영역이 있습니다. 이 시나리오에서는 상위 영역의 DS 레코드를 제거해야 합니다. + **하위 영역만(Child zones only)** - 이 영역에는 하나 이상의 하위 영역이 있는 신뢰 체인에 대한 DS 레코드가 있습니다. 이 시나리오에서는 해당 영역의 DS 레코드를 제거해야 합니다. + **상위 및 하위 영역(Parent and child zones)** - 이 영역에는 하나 이상의 하위 영역이 있는 신뢰 체인에 대한 DS 레코드 *및* DS 레코드가 있는 상위 영역 모두 다 있습니다. 이 시나리오의 경우 다음을 순서대로 수행합니다. 1. 해당 영역의 DS 레코드를 제거합니다. 1. 상위 영역의 DS 레코드를 제거합니다. 신뢰 영역이 있는 경우 이 단계를 건너뛰어도 됩니다. 1. 4단계에서 제거한 각 DS 레코드에 대해 TTL이 무엇인지 확인하고, 가장 긴 TTL 기간이 만료되었는지 확인합니다. 1. 단계를 순서대로 수행했음을 확인하는 확인란을 선택합니다. 1. 표시된 대로 필드에 *disable*을 입력한 다음 **비활성화(Disable)**를 선택합니다. **KSK(키 서명 키)를 비활성화하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역(Hosted zones)**을 선택한 후 KSK(키 서명 키)를 비활성화할 호스팅 영역을 선택합니다. 1. **KSK(키 서명 키)(Key-signing keys (KSKs))** 섹션에서 비활성화할 KSK를 선택한 다음 **작업(Actions)**에서 **KSK 편집(Edit KSK)**을 선택하고 **KSK 상태(KSK status)**를 **비활성(Inactive)**로 설정한 다음 **KSK 저장(Save KSK)**을 선택합니다. ------ **롤백:** [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) 및 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) API를 호출합니다. 예: ``` aws --region us-east-1 route53 activate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 1. 영역 서명 비활성화의 효과가 적용되었는지 확인합니다. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) 실행을 위한 `EnableHostedZoneDNSSEC()` 호출의 ID를 사용하여 모든 Route 53 DNS 서버가 응답 서명을 중지했는지 확인합니다(상태 =`INSYNC`). 1. 이름 확인을 관찰합니다. 해석기가 영역의 유효성을 검사하는 데 문제가 없음을 확인해야 합니다. 고객이 문제를 보고하는 데 필요한 시간도 고려하도록 1\$12주의 시간을 허용합니다. 1. (선택 사항) 정리. 서명을 다시 활성화하지 않을 것이라면 [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)를 통해 KSK를 정리하고 해당 고객 관리형 키를 삭제하여 비용을 절감할 수 있습니다. # DNSSEC용 고객 관리형 키 작업 Amazon Route 53에서 DNSSEC 서명을 활성화하면 Route 53에서 키 서명 키(KSK)를 생성합니다. KSK를 생성하려면 Route 53가 DNSSEC를 지원하는의 고객 관리 AWS Key Management Service 형 키를 사용해야 합니다. 이 섹션에서는 DNSSEC로 작업할 때 도움이 되는 고객 관리형 키의 세부 사항 및 요구 사항에 대해 설명합니다. DNSSEC에 대한 고객 관리형 키로 작업하는 경우 다음 사항에 유의하세요. + DNSSEC 서명에서 사용하는 고객 관리형 키는 미국 동부 (버지니아 북부) 리전에 있어야 합니다. + 고객 관리형 키는 [ECC\$1NIST\$1P256 키 사양](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc)의 [비대칭 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks)여야 합니다. 이러한 고객 관리형 키는 서명 및 확인에만 사용됩니다. 비대칭 고객 관리형 키를 생성하는 데 도움이 필요하면 AWS Key Management Service 개발자 안내서의 [비대칭 고객 관리형 키 생성을](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) 참조하세요. 기존 고객 관리형 키의 암호화 구성을 찾는 데 도움이 필요하면 AWS Key Management Service 개발자 안내서의 [고객 관리형 키의 암호화 구성 보기를](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) 참조하세요. + Route 53에서 DNSSEC와 함께 사용할 고객 관리형 키를 직접 생성하는 경우 Route 53에 필요한 권한을 부여하는 특정 키 정책 설명을 포함해야 합니다. Route 53는 고객 관리형 키에 액세스할 수 있어야 KSK를 생성할 수 있습니다. 자세한 내용은 [DNSSEC 서명에 필요한 Route 53 고객 관리형 키 권한](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC) 단원을 참조하십시오. + Route 53는에서 추가 AWS KMS 권한 없이 DNSSEC 서명과 함께 사용할 수 AWS KMS 있는 고객 관리형 키를 생성할 수 있습니다. 그러나 키를 만든 후 편집하려면 특정 권한이 있어야 합니다. 필요한 특정 사용 권한은 `kms:UpdateKeyDescription`, `kms:UpdateAlias` 및 `kms:PutKeyPolicy`와 같습니다. + 고객 관리형 키를 직접 생성하든 Route 53에서 생성하든 관계없이 보유한 각 고객 관리형 키에 대해 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오. # KSK(키 서명 키)로 작업 DNSSEC 서명을 활성화하면 Route 53에서 KSK(키 서명 키)를 생성합니다. Route 53에는 호스팅 영역당 최대 2개의 KSK가 있을 수 있습니다. DNSSEC 서명을 활성화한 후 KSK를 추가, 제거 또는 편집할 수 있습니다. KSK로 작업할 때는 다음 사항에 유의하세요. + KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다. + 호스팅 영역에 대해 DNSSEC 서명을 사용하면 Route 53가 TTL을 1주일로 제한합니다. 호스팅 영역의 레코드에 대해 TTL을 1주일 이상으로 설정하면 오류가 발생하지 않지만 Route 53에서는 TTL을 1주일로 실행합니다. + 영역 중단을 방지하고 도메인을 사용할 수 없게 되는 문제를 방지하려면 DNSSEC 오류에 신속하게 대응하고 해결해야 합니다. `DNSSECInternalFailure` 또는 `DNSSECKeySigningKeysNeedingAction` 오류를 감지할 때마다 알림이 전송되도록 CloudWatch 경보를 설정하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 섹션을 참조하세요. + 이 섹션에서 설명하는 KSK 작업을 통해 영역의 KSK를 대체할 수 있습니다. 자세한 내용 및 단계별 예제에 대해서는 블로그 게시물 [Amazon Route 53로 DNSSEC 서명 및 유효성 검사 구성](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/)에서 *DNSSEC 키 교체*를 참조하세요. 에서 KSKs를 사용하려면 다음 섹션의 지침을 AWS Management Console따르세요. ## KSK(키 서명 키) 추가 DNSSEC 서명을 활성화하면 Route 53에서 KSK(키 서명 키)를 생성합니다. KSK를 별도로 추가할 수도 있습니다. Route 53에는 호스팅 영역당 최대 2개의 KSK가 있을 수 있습니다. KSK를 생성하는 경우 KSK와 함께 사용할 고객 관리형 키를 생성하려면 Route 53를 제공하거나 요청해야 합니다. 고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 [DNSSEC용 고객 관리형 키 작업](dns-configuring-dnssec-cmk-requirements.md) 단원을 참조하십시오. AWS Management Console에 KSK를 추가하려면 다음 단계를 따르세요. **KSK를 추가하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다. 1. **KSK(키 서명 키)(Key-signing keys (KSKs))**의 **DNSSEC 서명(DNSSEC signing)** 탭에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음 **작업(Actions)**에서 **KSK 추가(Add KSK)**를 선택합니다. 1. **KSK**에 Route 53에서 생성할 KSK의 이름을 입력합니다. 이름에는 숫자, 문자, 밑줄(\$1)이 포함될 수 있습니다. 이름은 고유해야 합니다. 1. DNSSEC 서명에 적용되는 고객 관리형 키의 별칭을 입력하거나 Route 53에서 생성할 새 고객 관리형 키의 별칭을 입력합니다. **참고** Route 53에서 고객 관리형 키를 만들도록 선택한 경우 고객 관리형 키마다 별도의 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오. 1. **KSK 생성**을 선택합니다. ## KSK(키 서명 키) 편집 KSK의 상태를 **활성** 또는 **비활성**으로 편집할 수 있습니다. KSK가 활성화되면 Route 53에서는 DNSSEC 서명에 해당 KSK를 사용합니다. KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다. AWS Management Console에 KSK를 추가하려면 다음 단계를 따르세요. **태그를 편집하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다. 1. **DNSSEC 서명(DNSSEC signing)** 탭의 **KSK(키 서명 키)(Key-signing keys (KSKs))**에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음, **작업(Actions)**에서 **KSK 편집(Edit KSK)**을 선택합니다. 1. KSK를 원하는 대로 업데이트한 다음 **저장**을 선택합니다. ## KSK(키 서명 키) 삭제 KSK를 삭제하려면 먼저 KSK를 편집하여 KSK 상태를 **비활성**으로 설정해야 합니다. KSK를 삭제할 수 있는 이유 중 하나는 일상적인 키 교체의 일부이기 때문입니다. 암호화 키를 주기적으로 교체하는 것이 가장 좋습니다. 조직에 키를 교체하는 빈도에 대한 표준 지침이 있을 수 있습니다. AWS Management Console에서 KSK를 삭제하려면 다음 단계를 따르세요. **KSK를 삭제하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **호스팅 영역**을 선택한 후 호스팅 영역을 선택합니다. 1. **KSK(키 서명 키)(Key-signing keys (KSKs))**의 **DNSSEC 서명(DNSSEC signing)** 탭에서 **고급 보기로 전환(Switch to advanced view)**을 선택한 다음, **작업(Actions)**에서 **KSK 삭제(Delete KSK)**을 선택합니다. 1. 지침에 따라 KSK 삭제를 확인합니다. # Route 53에서의 KMS 키 및 ZSK 관리 이 섹션에서는 DNSSEC 서명 활성화 영역에 대해 Route 53가 사용하는 현재 방법을 설명합니다. **참고** Route 53는 변경될 수 있는 다음 규칙을 사용합니다. 향후 변경으로 인해 영역 또는 Route 53의 보안 태세가 줄어들지 않습니다. **Route 53가 KSK와 AWS KMS 연결된를 사용하는 방법** DNSSEC에서 KSK는 DNSSKEY 리소스 레코드 세트에 대한 리소스 레코드 서명(RRSIG)을 생성하는 데 사용됩니다. 모든 `ACTIVE` KSK는 RRSIG 세대에서 사용됩니다. Route 53는 연결된 KMS 키에서 `Sign` AWS KMS API를 호출하여 RRSIG를 생성합니다. 자세한 내용은 *AWS KMS API 가이드*의 [서명](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)을 참조하세요. 이러한 RRSIG는 영역의 리소스 레코드 세트 제한에 포함되지 않습니다. RRSIG가 만료되었습니다. RRSIG가 만료되는 것을 방지하기 위해 RRSIG를 1일에서 7일마다 다시 생성하여 정기적으로 새로 고칩니다. 또한 다음 API를 호출할 때마다 RRSIG가 새로 고쳐집니다. + [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) + [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html) + [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) + [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) + [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) + [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) Route 53가 새로 고침을 수행할 때마다 관련 KMS 키에 액세스할 수 없게 되는 경우를 대비하여 향후 며칠을 처리하기 위해 15개의 RRSIG를 생성합니다. KMS 키 비용 추정을 위해 하루에 한 번 정기적으로 새로 고침한다고 가정할 수 있습니다. KMS 키 정책을 실수로 변경하면 KMS 키에 액세스하는 것이 어려울 수 있습니다. 액세스할 수 없는 KMS 키는 연결된 KSK의 상태를 `ACTION_NEEDED`로 설정합니다. 마지막 RRSIG가 만료된 후 검증 확인자가 조회에 실패하기 때문에 `DNSSECKeySigningKeysNeedingAction` 오류가 감지될 때에는 CloudWatch 경보를 설정하여 이 상태를 모니터링하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 호스팅 영역 모니터링](monitoring-hosted-zones-with-cloudwatch.md) 단원을 참조하십시오. **Route 53가 영역의 ZSK를 관리하는 방법** DNSSEC 서명이 활성화된 각 새 호스팅 영역에는 하나의 `ACTIVE` 영역 서명 키(ZSK)가 있습니다. ZSK는 각 호스팅 영역에 대해 별도로 생성되며 Route 53가 소유합니다. 현재 키 알고리즘은 ECDSAP256SHA256입니다. 서명 시작 후 7\$130일 이내에 영역에서 정기적으로 ZSK 회전을 수행하기 시작합니다. 현재 Route 53는 사전 게시 키 롤오버 방법을 사용합니다. 자세한 내용은 [사전 게시 영역 서명 키 롤오버](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1) 단원을 참조하세요. 이 방법은 영역에 다른 ZSK를 도입합니다. 회전은 7\$130일마다 반복됩니다. Route 53는 영역의 ZSK의 변경 사항을 설명하기 위해 DNSKEY 리소스 레코드 세트에 대한 RRSIG를 다시 생성할 수 없기 때문에 영역의 KSK가 `ACTION_NEEDED` 상태인 경우 Route 53는 ZSK 회전을 일시 중단합니다. 조건이 지워지면 ZSK 회전이 자동으로 재개됩니다. # Route 53에서 존재하지 않는다는 DNSSEC 증명 **참고** Route 53는 변경될 수 있는 다음 규칙을 사용합니다. 향후 변경으로 인해 영역 또는 Route 53의 보안 태세가 줄어들지 않습니다. DNSSEC에는 세 가지 종류의 존재하지 않는다는 증거가 있습니다. + 쿼리 이름과 일치하는 레코드가 존재하지 않는다는 증거. + 쿼리 유형과 일치하는 유형이 존재하지 않는다는 증거. + 응답으로 레코드를 생성하는 데 사용되는 와일드카드 레코드가 존재하지 않는다는 증거. Route 53는 BL 메서드를 사용하여 쿼리 이름과 일치하는 레코드가 존재하지 않는다는 증거를 구현합니다. 자세한 내용은 [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00) 단원을 참조하세요. 이는 증거를 컴팩트하게 표현하고 영역 둘러보기를 방지하는 방법입니다. 쿼리 유형이 아닌 쿼리 이름과 일치하는 레코드가 있는 경우(예: web.example.com/AAAA에 대해 쿼리하지만 web.example.com/A만 있는 경우) 지원되는 모든 리소스 레코드 유형을 포함하는 최소 NSEC(다음 보안) 레코드를 반환합니다. Route 53가 와일드카드 레코드의 응답을 합성할 경우, 응답은 다음 보안 레코드인 와일드카드에 대한 NSEC 레코드와 함께 제공되지 않습니다. 이러한 NSEC 레코드는 응답의 리소스 레코드 서명(RRSIG)이 다른 응답을 스푸핑하는 데 재사용되는 것을 방지하기 위해 일반적으로 오프라인 서명을 수행하는 일부 구현에서 사용됩니다. Route 53는 non-DNSKEY 레코드의 온라인 서명을 사용하여 다른 응답에 재사용할 수 없는 응답으로 특정된 RRSIG를 생성합니다. # DNSSEC 서명 문제 해결 이 섹션의 정보는 활성화, 비활성화, KSK(키 서명 키)를 포함하여 DNSSEC 서명 문제를 해결하는 데 도움이 될 수 있습니다. DNSSEC 활성화 DNSSEC 서명을 활성화하기 전에 [Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md)에서 사전 조건을 읽어야 합니다. DNSSEC 비활성화 DNSSEC를 안전하게 비활성화하기 위해 Route 53는 대상 영역이 신뢰 체인에 속하는지 확인합니다. 대상 영역의 상위 영역에 대상 영역의 NS 레코드와 대상 영역의 DS 레코드가 있는지 확인합니다. 대상 영역을 공개적으로 확인할 수 없는 경우(예: NS 및 DS를 쿼리할 때 SERVFAIL 응답을 받음) Route 53는 DNSSEC를 비활성화해도 안전한지 여부를 판단할 수 없습니다. 상위 영역에 확인하여 해결한 다음에 DNSSEC를 다시 비활성화해 볼 수 있습니다. KSK 상태가 **Action needed(작업 필요)**인 경우 Route 53 DNSSEC가 해당 `ACTION_NEEDED`에 대한 액세스 권한을 상실하면(권한 변경 또는 AWS KMS key 삭제로 인해) KSK가 상태를 **필요한 작업** AWS KMS key (또는 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 상태)으로 변경할 수 있습니다. KSK의 상태가 **작업 필요(Action needed)**인 경우는 DNSSEC 검증 해석기를 사용하는 클라이언트에 영역 가동 중단이 발생함을 의미하므로 프로덕션 영역을 확인되지 않는 상황을 방지할 수 있도록 신속하게 조치를 취해야 합니다. 이 문제를 해결하려면 KSK가 기반으로 하는 고객 관리형 키가 활성화되었으며 올바른 권한이 있는지 확인하세요. 필요한 권한에 대한 자세한 정보는 [DNSSEC 서명에 필요한 Route 53 고객 관리형 키 권한](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC) 섹션을 참조하세요. KSK를 수정한 후에 설명된 AWS CLI대로 콘솔 또는를 사용하여 다시 활성화합니다[2단계: DNSSEC 서명 활성화 및 KSK 생성](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable). 향후이 문제를 방지하려면 Amazon CloudWatch 에 제안된 대로 KSK의 상태를 추적하는 지표를 추가하는 것이 좋습니다[Amazon Route 53에서 DNSSEC 서명 구성](dns-configuring-dnssec.md). KSK 상태가 **내부 오류(Internal failure)**인 경우 KSK의 상태가 **내부 오류(Internal failure)**(또는 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 상태가 `INTERNAL_FAILURE`)인 경우, 문제가 해결될 때까지 다른 DNSSEC 엔터티에서 작업할 수 없습니다. 이 KSK 또는 다른 KSK로 작업하는 것을 포함하여 DNSSEC 서명으로 작업하려면 먼저 조치를 취해야 합니다. 문제를 해결하려면 KSK를 다시 활성화하거나 비활성화합니다. 문제를 해결하려면 API로 작업할 때 서명 활성화([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) 또는 서명 비활성화([DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html))를 시도합니다. **내부 오류(Internal failure)** 문제는 신속하게 해결해야 합니다. 문제를 해결하기 전까지는 호스팅 영역을 변경할 수 없습니다. 단, **내부 오류(Internal failure)** 수정 작업은 예외로 합니다.