1단계: DNSSEC 서명 활성화 준비 2단계: DNSSEC 서명 활성화 및 KSK 생성 3단계: 신뢰 체인 설정

DNSSEC 서명 활성화 및 신뢰 체인 설정

증분 단계는 호스팅 영역 소유자와 상위 영역 유지 관리자에게 적용됩니다. 두 사람은 동일한 사람이 될 수 있지만, 그렇지 않은 경우 영역 소유자는 상위 영역 유지 관리자에게 알리고 협력해야 합니다.

이 문서의 단계를 따라 영역에 서명하고 신뢰 체인에 포함시키는 것이 좋습니다. 다음 단계는 DNSSEC로의 온보딩 시 위험을 최소화해 줍니다.

참고

시작하기 전에 Amazon Route 53에서 DNSSEC 서명 구성에서 사전 조건을 읽어야 합니다.

DNSSEC 서명을 활성화하려면 다음 섹션에 설명된 세 가지 단계를 수행해야 합니다.

1단계: DNSSEC 서명 활성화 준비

준비 단계는 영역 가용성을 모니터링하고 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄여 DNSSEC로의 온보딩 시 위험을 최소화하는 데 도움이 됩니다.

DNSSEC 서명 활성화를 준비하려면

영역 가용성을 모니터링합니다.

영역의 도메인 이름 가용성을 모니터링할 수 있습니다. 이것은 DNSSEC 서명을 활성화한 후 한 단계 뒤로 롤백해야 하는 모든 문제를 해결하는 데 도움이 될 수 있습니다. 쿼리 로깅을 사용하여 대부분의 트래픽에서 도메인 이름을 모니터링할 수 있습니다. 쿼리 로깅 역할 설정에 대한 자세한 내용은 Amazon Route 53 모니터링 단원을 참조하세요.

모니터링은 셸 스크립트 또는 서드 파티 서비스를 통해 수행할 수 있습니다. 그러나 이것이 롤백이 필요한지 결정하기 위한 유일한 신호는 아닙니다. 도메인을 사용할 수 없는 문제로 고객으로부터 피드백을 받을 수도 있습니다.

영역의 최대 TTL을 낮춥니다.

영역의 최대 TTL은 영역에서 가장 긴 TTL 레코드입니다. 다음의 영역 예에서 영역의 최대 TTL은 1일(86,400초)입니다.

명칭	TTL	레코드 클래스	레코드 유형	레코드 데이터
example.com.	900	IN	SOA	ns1.example.com. hostmaster.example.com. 2002022401 10800 15 604800 300
example.com.	900	IN	NS	ns1.example.com.
route53.example.com.	86400	IN	TXT	`some txt record`

영역의 최대 TTL을 낮추면 서명 활성화와 DS(Delegation Signer) 레코드 삽입 사이의 대기 시간을 줄이는 데 도움이 됩니다. 영역의 최대 TTL을 1시간(3,600초)으로 낮추는 것이 좋습니다. 이렇게 하면 해석기가 서명된 레코드를 캐싱하는 데 문제가 있는 경우 단 1시간 후에 롤백할 수 있습니다.

롤백: TTL 변경 사항을 실행 취소합니다.

SOA TTL 및 SOA 최소 필드를 낮춥니다.

SOA 최소 필드는 SOA 레코드 데이터의 마지막 필드입니다. 다음 SOA 레코드 예제에서 최소 필드는 5분(300초)의 값을 가집니다.

명칭	TTL	레코드 클래스	레코드 유형	레코드 데이터
example.com.	900	IN	SOA	ns1.example.com. hostmaster.example.com. 2002022401 10800 15 604800 300

SOA TTL 및 SOA 최소 필드는 해석기가 부정 답변을 얼마나 오래 기억할지 결정합니다. 서명을 활성화하면 Route 53 이름 서버가 부정 답변을 위한 NSEC 레코드를 반환하기 시작합니다. NSEC에는 해석기가 부정 답변을 합성하는 데 사용할 수 있는 정보가 포함되어 있습니다. NSEC 정보로 인해 해석기가 이름에 대한 부정 답변을 가정하기 때문에 롤백해야 하는 경우, 해석기가 가정을 중지하게 하려면 SOA TTL 및 SOA 최소 필드의 최댓값을 기다리기만 하면 됩니다.

롤백: SOA 변경 사항을 실행 취소합니다.

TTL 및 SOA 최소 필드 변경의 효과가 적용되었는지 확인합니다.

지금까지의 변경 사항이 모든 Route 53 DNS 서버에 전파되었는지 확인하는 데 사용합니다 GetChange.

2단계: DNSSEC 서명 활성화 및 KSK 생성

Route 53 콘솔에서 AWS CLI 또는 를 사용하여 DNSSEC 서명을 활성화하고 키 서명 키 (KSK) 를 생성할 수 있습니다.

CLI
콘솔

고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 설명은 DNSSEC용 고객 관리형 키 작업 섹션을 참조하세요.

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용 고객 관리형 키 작업 단원을 참조하세요. CreateKeySigningKey 섹션도 참조하십시오.

DNSSEC 서명을 활성화하려면 고유한 값을 사용하여 다음과 같은 AWS CLI 명령을 실행합니다. hostedzone_id


aws --region us-east-1 route53 enable-hosted-zone-dnssec \
			--hosted-zone-id $hostedzone_id

자세한 내용은 enable-hosted-zone-dnssecDNSSEC를 참조하십시오. EnableHostedZone

Console

DNSSEC 서명 활성화 및 KSK 생성

https://console.aws.amazon.com/route53/ 에서 Route 53 콘솔에 AWS Management Console 로그인하고 여십시오.
탐색 창에서 호스팅 영역을 선택한 후 DNSSEC 서명을 활성화할 호스팅 영역을 선택합니다.
DNSSEC 서명 탭에서 DNSSEC 서명 활성화를 선택합니다.

참고
이 섹션의 옵션이 DNSSEC 서명 비활성화인 경우 DNSSEC 서명 활성화의 첫 단계를 이미 완료한 것입니다. DNSSEC의 호스팅 영역에 대한 신뢰 체인을 설정하거나 이미 존재하는지 확인하세요. 그러면 완료됩니다. 자세한 설명은 3단계: 신뢰 체인 설정 섹션을 참조하세요.
KSK(키 서명 키) 생성(Key-signing key (KSK) creation) 섹션에서 새 KSK 생성(Create new KSK)을 선택하고 KSK 이름 제공(Provide KSK name)에 Route 53가 생성할 KSK의 이름을 입력합니다. 이름에는 숫자, 문자, 밑줄(_)이 포함될 수 있습니다. 이름은 고유해야 합니다.
고객 관리형 CMK에서 Route 53에서 KSK를 생성할 때 사용할 고객 관리형 키를 선택합니다. DNSSEC 서명에 적용되는 기존 고객 관리형 키를 사용하거나 새 고객 관리형 키를 생성할 수 있습니다.

고객 관리형 KMS 키를 제공하거나 만드는 경우 몇 가지 요구 사항이 있습니다. 자세한 내용은 DNSSEC용 고객 관리형 키 작업 섹션을 참조하세요.
기존 고객 관리형 키의 별칭을 입력합니다. 새 고객 관리형 키를 사용하려면 고객 관리형 키의 별칭을 입력합니다. 그러면 Route 53에서 키를 생성합니다.

참고
Route 53에서 고객 관리형 키를 만들도록 선택한 경우 고객 관리형 키마다 별도의 요금이 부과됩니다. 자세한 내용은 AWS Key Management Service 요금을 참조하세요.
DNSSEC 서명 활성화를 선택합니다.

영역 서명을 활성화한 후 다음 단계를 완료합니다(콘솔 또는 CLI를 사용했는지 여부에 상관 없음).

영역 서명의 효과가 적용되었는지 확인합니다.

를 사용한 AWS CLI경우 EnableHostedZoneDNSSEC() 호출 출력의 작업 ID를 사용하여 get-change를 실행하거나 모든 Route 53 DNS 서버가 GetChange응답에 서명하고 있는지 확인할 수 있습니다 (status =INSYNC).
적어도 이전 영역의 최대 TTL 동안 기다립니다.

해석기가 서명되지 않은 모든 레코드를 캐시에서 비울 때까지 기다립니다. 이를 위해서는 적어도 이전 영역의 최대 TTL 동안 기다려야 합니다. 위의 example.com 영역에서는 대기 시간이 1일입니다.
고객 문제에 대한 보고서를 모니터링합니다.

영역 서명을 활성화한 후에는 고객에게 네트워크 디바이스 및 해석기와 관련된 문제가 표시되기 시작할 수 있습니다. 권장되는 모니터링 기간은 2주입니다.

다음은 표시될 수 있는 문제의 예제니다.
- 일부 네트워크 디바이스는 DNS 응답 크기를 512바이트 미만으로 제한할 수 있으며 이는 일부 서명된 응답에 사용하기에 너무 작은 크기입니다. 이러한 네트워크 디바이스는 더 큰 DNS 응답 크기를 허용하도록 재구성되어야 합니다.
- 일부 네트워크 디바이스는 DNS 응답에 대한 세부적인 검사를 수행하여 DNSSEC에 사용된 것과 같이 디바이스가 이해하지 못하는 특정 레코드를 제거합니다. 이러한 디바이스는 재구성해야 합니다.
- 일부 고객의 해석기는 네트워크가 지원하는 것보다 더 큰 UDP 응답을 받아들일 수 있다고 주장합니다. 네트워크 역량을 테스트하고 해석기를 적절하게 구성할 수 있습니다. 자세한 내용은 DNS 응답 크기 테스트 서버를 참조하세요.

롤백: DisableHostedZone DNSSEC를 호출한 다음 단계를 롤백합니다. 1단계: DNSSEC 서명 활성화 준비

3단계: 신뢰 체인 설정

Route 53에서 호스팅 영역에 대해 DNSSEC 서명을 활성화한 후 호스팅 영역에 대한 신뢰 체인을 설정하여 DNSSEC 서명 설정을 완료합니다. 이렇게 하려면 Route 53에서 제공하는 정보를 사용하여 호스팅 영역에 대한 상위 호스팅 영역에서 DS(Delegation Signer) 레코드를 생성하면 됩니다. 도메인이 등록된 위치에 따라 Route 53의 상위 호스팅 영역 또는 다른 도메인 등록 기관에 레코드를 추가합니다.

DNSSEC 서명에 대한 신뢰 체인을 설정하려면

AWS Management Console 로그인하고 https://console.aws.amazon.com/route53/ 에서 Route 53 콘솔을 엽니다.
탐색 창에서 호스팅 영역을 선택한 후 DNSSEC 신뢰 체인을 설정할 호스팅 영역을 선택합니다. 먼저 DNSSEC 서명을 활성화해야 합니다.
DNSSEC 서명의 DNSSEC 서명 탭에서 DS 레코드를 만들기 위한 정보 보기를 선택합니다.

참고
이 섹션에 DS 레코드를 만들기 위한 정보 보기가 표시되지 않는 경우 신뢰 체인을 설정하기 전에 DNSSEC 서명을 활성화해야 합니다. DNSSEC 서명 활성화(Enable DNSSEC signing)를 선택하고 2단계: DNSSEC 서명 활성화 및 KSK 생성에 설명된 단계를 완료한 다음 이 단계로 돌아와 신뢰 체인을 설정합니다.
신뢰 체인 설정에서 도메인이 등록된 위치에 따라 Route 53 등록 기관 또는 다른 도메인 등록 기관 중 하나를 선택합니다.
3단계에서 제공된 값을 사용하여 Route 53의 상위 호스팅 영역에 대한 DS 레코드를 생성합니다. 도메인이 Route 53에서 호스팅되지 않는 경우, 제공된 값을 사용하여 도메인 등록 기관 웹 사이트에 DS 레코드를 생성합니다.
- 상위 영역이 Route 53을 통해 관리되는 도메인인 경우 다음 단계를 따르십시오.
  
  올바른 서명 알고리즘(ECDSAP256SHA256 및 유형 13) 및 다이제스트 알고리즘(SHA-256 및 유형 2)을 구성했는지 확인합니다.
  
  Route 53가 등록 기관인 경우 Route 53 콘솔에서 다음을 수행합니다.
  1. 키 유형, 서명 알고리즘 및 퍼블릭 키 값을 참고합니다. 탐색 창에서 등록된 도메인을 선택합니다.
  2. 도메인을 선택한 다음 DNSSEC 상태 옆의 키 관리를 선택합니다.
  3. DNSSEC 키 관리(Manage DNSSEC keys) 대화 상자의 드롭다운 메뉴에서 Route 53 등록 기관(Route 53 registrar)의 적절한 키 유형(Key type) 및 알고리즘(Algorithm)을 선택합니다.
  4. Route 53 등록 기관의 퍼블릭 키를 복사합니다. DNSSEC 키 관리(Manage DNSSEC keys) 대화 상자에서 값을 퍼블릭 키(Public key) 입력란에 붙여넣습니다.
  5. 추가를 선택합니다.
    
    Route 53는 공개 키의 상위 영역에 DS 레코드를 추가합니다. 예를 들어 도메인이 example.com인 경우 DS 레코드는 .com DNS 영역에 추가됩니다.
- 상위 영역이 Route 53에서 호스팅되거나 도메인이 다른 레지스트리에서 관리되는 경우 상위 영역 또는 도메인 등록 소유자에게 문의하여 다음 지침을 따르십시오.
  
  다음 단계가 원활하게 진행될 수 있도록 상위 영역에 낮은 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 API를 호출하고 'DSRecord' 필드의 값을 검색하여 얻을 수 있습니다.
    
    aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id
    
    상위 영역 소유자는 Route 53 콘솔 또는 CLI를 통해 레코드를 삽입할 수 있습니다.
    
    를 사용하여 AWS CLI DS 레코드를 삽입하려면 상위 영역 소유자가 다음 예와 유사한 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/에서 Route 53 콘솔을 엽니다.
    
    탐색 창의 호스팅 영역(Hosted zones)에서 호스팅 영역의 이름을 선택한 다음 레코드 생성(Create record) 버튼을 선택합니다. 라우팅 정책(Routing policy)에 단순 라우팅을 선택했는지 확인합니다.
    
    레코드 이름(Record name) 필드에 $zone_name과 같은 이름을 입력하고, 레코드 유형(Record type) 드룹 다운에서 DS를 선택하고, 값(Value) 필드에 $ds_record_value의 값을 입력한 다음 레코드 생성(Create records)을 선택합니다.
롤백: 상위 영역에서 DS를 제거하고 DS TTL 동안 기다린 다음 신뢰를 설정하는 단계를 롤백합니다. 상위 영역이 Route 53에서 호스팅되는 경우, 상위 영역 소유자는 JSON 파일의 Action을 UPSERT에서 DELETE로 변경하고 위의 예제 CLI를 다시 실행할 수 있습니다.
도메인 레코드의 TTL을 기반으로 업데이트가 전파될 때까지 기다립니다.

상위 영역이 Route 53 DNS 서비스에 있는 경우 상위 영역 소유자는 API를 통해 전체 전파를 확인할 수 있습니다. GetChange

그렇지 않으면 DS 레코드의 상위 영역을 주기적으로 조사한 다음 DS 레코드 삽입이 완전히 전파될 확률을 높일 수 있도록 10분 더 기다릴 수 있습니다. 일부 등록 기관은 일정(예: 하루에 한 번)에 따라 DS 삽입을 수행합니다.

상위 영역에 DS(Delegation Signer) 레코드를 도입하면 DS를 선택한 검증된 해석기가 해당 영역에서 응답의 유효성을 검사하기 시작합니다.

신뢰 설정 단계가 원활하게 진행되도록 하려면 다음을 완료합니다.

최대 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을 확인합니다.
최대 NS TTL 동안 기다립니다.

DS 삽입 전에 해석기는 서명된 응답을 받지만 서명을 검증하지는 않습니다. DS 레코드가 삽입되면 영역의 NS 레코드가 만료되기 전까지는 해석기가 해당 레코드를 볼 수 없습니다. 해석기가 NS 레코드를 다시 가져오면 DS 레코드도 반환됩니다.

고객이 동기화되지 않은 클럭이 있는 호스트에서 해석기를 실행하는 경우 시계가 올바른 시간에서 1시간 이내인지 확인하십시오.

이 단계를 완료하면 모든 DNSSEC 인식 해석기가 영역을 검증합니다.
이름 확인을 관찰합니다.

해석기의 영역 검증에 문제가 없음을 확인해야 합니다. 고객이 문제를 보고하는 데 필요한 시간도 고려해야 합니다.

최대 2주 동안 모니터링하는 것이 좋습니다.
(선택 사항) DS 및 NS TTL을 늘립니다.

설정에 만족하면 TTL 및 SOA 변경 사항을 저장할 수 있습니다. Route 53는 서명된 영역에 대해 TTL을 1주로 제한합니다. 자세한 내용은 Amazon Route 53에서 DNSSEC 서명 구성 섹션을 참조하세요.

DS TTL을 변경할 수 있는 경우, 1시간으로 설정하는 것이 좋습니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

DNSSEC 서명 구성

DNSSEC 서명 비활성화