이 페이지에서는 관리형 영역에 DNSSEC를 사용 설정할 때 사용할 수 있는 몇 가지 고급 도메인 이름 시스템 보안 확장 프로그램(DNSSEC) 구성 옵션을 제공합니다. 이러한 옵션은 여러 신호 알고리즘 및 존재 거부부터 DNSSEC가 필요하거나 권장되는 레코드 유형을 사용할 수 있는 기능까지 다양합니다.
DNSSEC의 개념 개요는 DNSSEC 개요를 참조하세요.
DNSSEC 서명된 하위 도메인 위임
기본 도메인에 DNSSEC를 사용 설정한 후 위임된 하위 도메인에 대해 DNSSEC를 사용 설정할 수 있습니다. 위임된 하위 도메인에 대해 DNSSEC를 사용 설정하려면 먼저 Cloud DNS 영역 내에서 DS 레코드를 만듭니다. 또한 하나 이상의 NS 레코드를 만들어야 합니다.
위임된 하위 도메인에 대한 DS 레코드를 만들려면 영역에 대한 DS 레코드를 가져와야 합니다. 위임된 영역이 Cloud DNS에서도 호스팅되는 경우 Google Cloud Console 또는 Google Cloud CLI에서 DS 레코드를 가져올 수 있습니다.
Console
Google Cloud 콘솔에서 Cloud DNS 페이지로 이동합니다.
DS 레코드를 보려는 관리형 영역으로 이동합니다.
영역의 DS 레코드를 보려면 영역 세부정보 페이지의 오른쪽 상단 모서리에서 등록기관 설정을 클릭합니다.
DS 레코드는 등록기관 설정 페이지에서 제공됩니다.
NS 레코드를 만들려면 레코드 추가의 안내를 따릅니다.
gcloud
위임된 하위 도메인에 대해 DS 레코드 정보를 가져오려면 다음 명령어를 실행합니다.
gcloud dns dns-keys list --zone EXAMPLE_ZONE
EXAMPLE_ZONE을 프로젝트에서 위임된 하위 도메인 DNS 영역의 이름으로 바꿉니다.출력은 다음과 같이 표시됩니다.
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
전체 DS 레코드 및 키의 모든 세부정보를 가져오려면 일반적으로 0인 KEY_SIGNING 키(KSK)의 ID가 필요합니다. 다음 명령어를 실행합니다.
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
다음을 바꿉니다.
EXAMPLE_ZONE: 프로젝트에 있는 위임된 하위 도메인 DNS 영역의 이름입니다.KSK_ID: 일반적으로 0인 KSK ID 번호입니다.
출력은 다음과 유사합니다.
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
이후 단계에 사용할 수 있도록 이전 명령어의 출력을 복사합니다.
보안 하위 위임을 위해 DS 레코드를 만들려면 다음 명령어를 실행하여 트랜잭션을 시작합니다.
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
EXAMPLE_ZONE을 위임된 하위 도메인에 대해 레코드를 만들려는 프로젝트에 있는 상위 DNS 영역의 이름으로 바꿉니다.출력은 다음과 같이 표시됩니다.
Transaction started [transaction.yaml].
그런 후 다음 명령어를 실행하여 레코드 집합을 추가합니다.
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
다음을 바꿉니다.
EXAMPLE_ZONE: 프로젝트에 있는 상위 DNS 영역의 이름입니다.TIME_TO_LIVE: 영역의 수명 시간(초 단위)입니다(예: 3,600).subdomain.example.com: 영역 DNS 이름의 하위 도메인입니다.DS_RECORD_AND_KEY: 2단계에서 얻은 DS 레코드 및 키입니다(예:44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb).
출력은 다음과 같이 표시됩니다.
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
NS 레코드를 추가하려면 다음 명령어를 사용합니다.
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
다음을 바꿉니다.
EXAMPLE_ZONE: 프로젝트에 있는 상위 DNS 영역의 이름입니다.TIME_TO_LIVE: 영역의 수명 시간(초 단위)입니다(예: 3,600).subdomain.example.com: 영역 DNS 이름의 하위 도메인입니다.
다음 RRData를 입력합니다.
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
출력은 다음과 같이 표시됩니다.
Record addition appended to transaction at [transaction.yaml].
트랜잭션을 실행하려면 다음 명령어를 사용합니다.
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
EXAMPLE_ZONE을 프로젝트의 DNS 영역 이름으로 바꿉니다.출력은 다음과 같이 표시됩니다.
Executed transaction [transaction.yaml] for managed-zone [dns-example]. Created [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42]. ID START_TIME STATUS 42 2019-08-08T23:12:49.100Z PENDING
고급 서명 옵션 사용
관리형 영역에 DNSSEC를 사용 설정하거나 DNSSEC로 관리형 영역을 만드는 경우, DNSSEC 서명 알고리즘과 존재 거부 유형을 선택할 수 있습니다.
DNSSEC를 사용 설정하기 전에 관리형 영역에 대한 DNSSEC 설정을 변경할 수 있습니다(예를 들어 레코드에 암호화 서명하는 데 사용되는 알고리즘). DNSSEC가 관리형 영역에 이미 사용 설정된 경우, 항목을 변경하려면 먼저 DNSSEC를 사용 중지하고, 필요한 항목을 변경한 후 다음 명령어를 사용하여 DNSSEC를 다시 사용 설정합니다.
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
EXAMPLE_ZONE을 프로젝트의 DNS 영역 이름으로 바꿉니다.
자세한 내용은 관리형 영역에 DNSSEC 사용 설정을 참조하세요.
다음 명령어는 Cloud DNS를 사용하여 가능한 가장 작은 DNSSEC 서명 응답 패킷에 대해 256 비트 ECDSA 및 NSEC가 있는 DNSSEC를 사용 설정합니다.
gcloud dns managed-zones update EXAMPLE_ZONE \ --dnssec-state on \ --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \ --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \ --denial-of-existence NSEC
EXAMPLE_ZONE을 프로젝트의 DNS 영역 이름으로 바꿉니다.
KSK 또는 ZSK 알고리즘이나 키 길이를 제공하는 경우 명령어에 모든 항목과 해당 인수를 제공해야 합니다.
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
알고리즘과 독립적으로 NSEC 또는 NSEC3으로 존재 거부를 지정할 수 있습니다.
지원되는 알고리즘 옵션과 인수는 다음 표에 나와 있습니다. Cloud DNS는 다른 알고리즘이나 매개변수 사용을 허용하지 않습니다.
| 알고리즘 | KSK 길이 | ZSK 길이 | 댓글 |
|---|---|---|---|
| RSASHA256 | 2048 | 1024, 2048 | |
| RSASHA512 | 2048 | 1024, 2048 | 폭넓게 지원되지 않음 |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | 폭넓게 지원되지 않음 |
알고리즘을 지정하지 않으면 Cloud DNS에서 다음과 같은 기본값을 사용합니다.
| 키 유형 | 기본 알고리즘 | 기본 키 길이 |
|---|---|---|
| 키 서명 키(KSK) | RSASHA256 | 2048 |
| 영역 서명 키(ZSK) | RSASHA256 | 1024 |
RSASHA256과 RSASHA512 간의 보안 및 성능 차이는 작으며 서명된 응답 크기가 동일합니다. 키 길이가 중요합니다. 키 길이가 길수록 느려지고 응답 크기가 커집니다(루트 영역 및 TLD의 응답 크기 분석과 Windows의 서버 측 성능 분석 참조).
ECDSA에 대한 리졸버 지원은 비교적 최근 시스템으로 제한됩니다. ECDSA 서명 영역을 검사할 수 없는 오래된 리졸버는 이를 서명되지 않은 것으로 간주하므로, DNSSEC에 의존하는 새 레코드 유형을 사용할 경우 안전하지 않을 수 있습니다. 256비트 ECDSA에 대한 등록기관 및 레지스트리 지원은 일반적이지만 보편적이지 않습니다. 384비트 ECDSA는 지원하는 레지스트리가 적고 등록기관은 더 적습니다. 이전 클라이언트를 지원할 필요가 없는 경우에는 ECDSA를 사용하는 것이 효과적일 수 있습니다. 서명은 훨씬 작고 계산 속도가 더 빠릅니다.
관리형 영역에서 KSK 및 ZSK에 서로 다른 알고리즘을 사용하지 마세요. 호환성이 줄어들고 보안이 저하될 수 있습니다. 일부 DNSSEC 검사 리졸버는 영역의 모든 레코드를 서명하기 위해 사용되지 않는 DNSKEY 알고리즘을 사용할 때 영역 검사가 실패할 수 있습니다. RFC 6840에 'DNSKEY RRset의 모든 알고리즘이 작동한다고 주장해서는 안 된다'고 나와 있더라도 마찬가지입니다. RFC 6840 이후의 대부분의 검사 리졸버에서와 같이 이것이 문제가 되지 않는 경우에는 도메인 등록기관 또는 TLD 레지스트리가 ECDSA를 지원하지 않고 응답 크기 감소가 필요한 경우 KSK에 RSASHA256을 사용하고 ZSK에 ECDSA를 사용할 수 있습니다.
NSEC3은 기본 존재 거부 유형입니다. 영역 워커가 영역 내의 모든 레코드를 검색하지 못하도록 제한 보호 기능을 제공합니다.
NSEC3PARAM 설정은 고정되어 있습니다. NSEC3 opt-out이 보안을 위해 사용 중지되어 있으며, 64비트 솔트를 사용하는 추가 해시 반복이 1개(총 2개) 있습니다.
NSEC는 응답 크기가 약간 더 작지만 영역 워킹에 대한 보호 기능이 없습니다. 또한 NSEC를 사용하면 존재하지 않는 도메인에 대한 쿼리가 줄어들 수 있습니다. Google Public DNS 및 일부 다른 DNSSEC 검사 리졸버는 Cloud DNS 영역을 쿼리하지 않고 캐시된 NSEC 레코드로부터 부정적인 응답을 합성할 수 있습니다.
RFC 8624에는 알고리즘 선택에 대한 추가 안내가 포함되어 있습니다.
DNSSEC 보안 영역에서 새 DNS 레코드 유형 사용
도메인이 완전히 DNSSEC로 보호되면 DNSSEC 서명 영역의 신뢰성과 무결성 보장을 사용하는 몇 가지 새로운 DNS 레코드 유형을 사용하여 다른 서비스의 보안을 강화할 수 있습니다.
SSHFP
SSHFP 레코드에는 SSH 클라이언트 애플리케이션이 SSH 서버 검사를 위해 사용할 수 있는 SSH 서버의 공개 키의 지문이 포함됩니다. SSH 클라이언트는 일반적으로 최초 연결 시 서버의 공개 키 확인을 위해 사용자 상호작용을 필요로 하며 키가 변경되면 경고를 생성합니다. SSHFP를 사용하도록 구성된 SSH 클라이언트는 항상 해당 서버에 대한 서버의 SSHFP 레코드에 있는 키를 사용합니다. SSHFP 레코드가 없는 서버의 키만 저장되어 다시 사용됩니다.
SSHFP 레코드 형식은 다음과 같습니다.
- 알고리즘 번호
- 지문 유형 번호
- 서버 키 지문
SSH의 알고리즘 번호는 다음과 같습니다.
- RSA
- DSA
- ECDSA
- ED25519
지문 유형은 다음과 같습니다.
- SHA-1(지원 중단됨, 호환성 제공 전용)
- SHA-256
StackExchange에는 SSHFP 생성을 위한 권장사항이 있으며, 기존의 알려진 호스트 파일 또는 구성 관리를 통해 서버를 검색하여 SSHFP를 생성하는 도구가 있습니다. 예시 및 링크는 SSHFP 레코드: 공개 ssh 호스트 키를 제공하는 DNS를 참조하세요.
TLSA와 DANE
TLSA 레코드에는 서명 인증 기관(CA)의 사전 구성된 집합 중 하나를 사용하지 않고 X.509 인증서(예: HTTPS에 사용되는 인증서) 검사를 위해 사용될 수 있는 정보가 포함됩니다.
따라서 고유 CA를 설정하고 HTTPS용 인증서를 생성할 수 있습니다. 또한 일반적으로 사전 구성된 신뢰할 수 있는 CA에 대해 애플리케이션 지원이 없는 SMTP와 같은 프로토콜에 대해 인증서 검사를 수행할 수 있습니다.
RFC 6698 및 관련 RFC에 명시된 DANE(Domain Authentication of Named Entities)은 특정 방식으로 TLSA 레코드를 사용하여 많은 프로토콜과 애플리케이션을 보호합니다. IETF Journal and Internet Society에는 유용한 소개 자료와 DANE 개요가 포함되어 있습니다.
HTTPS
DANE을 사용하면 OpenSSL 또는 Cloudflare의 CFSSL을 기반으로 자체 CA 인프라로 생성된 인증서를 사용하여 HTTPS 서버를 안전하게 구성할 수 있습니다.
HTTPS 서버에 대한 SIDNLabs의 DANE 유효성 검사 도구는 HTTPS에 대한 DANE 배포를 테스트하는 데 유용합니다.
SMTP(이메일) TLS 인증서 확인
SMTP 이메일 프로토콜은 암호화를 중지하는 다운그레이드 공격에 취약하며 DANE은 이를 방지할 수 있는 방법을 제공합니다.
Internet Society에는 Let's Encrypt 인증서로 특정 TLSA 레코드 형식을 사용하지 않도록 방지하기 위한 조언을 포함하여 Let's Encrypt에서 제공하는 무료 및 자동 인증서로 SMTP용 DANE을 사용하는 방법에 대한 2부 가이드가 있습니다.
Common Mistakes에서는 훌륭한 조언(및 HTTPS 및 SMTP를 위한 DANE 도메인 검사기)을 찾아볼 수 있습니다. Test your email validator에서도 DANE를 검사합니다.
XMPP(Jabber 채팅) TLS 인증서 확인
XMPP 및 SRV 레코드를 사용하는 다른 서비스도 DANE를 활용할 수 있습니다. XMPP 예시에서는 RFC 7673에 명시된 DANE-SRV 구성을 사용합니다.
TXT(OpenPGP/GnuPG) 공개 키 연결
TXT 레코드는 DNSSEC 없이 사용될 수 있지만 DNSSEC 서명 TXT 레코드는 신뢰성에 대한 확신을 줍니다. 이는 X.509 CA와 같이 잘 알려진 당사자가 서명하지 않은 OpenPGP(GnuPG) 공개 키의 DNS 기반 게시에 중요합니다.
예를 들어 Alice가 DNSSEC 서명 an.example 영역에 다음과 같은 TXT 레코드를 게시하고 지정된 URI에서 ASCII 형식의 공개 키 복사본을 호스팅하는 경우, Bob은 합당한 보안 수준으로 alice@an.example에 대한 OpenPGP 키를 조회할 수 있습니다. 이것이 신뢰의 웹(Web-of-Trust) 검사를 대신하지는 않지만, 이전에 알려지지 않은 당사자와 OpenPGP 암호화를 가능하게 합니다.
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
해당 안내에 따라 버전 1 PKA TXT 레코드(DNS의 키 게시에서 부르는 이름)를 생성할 수 있습니다.
DNS의 PGP 키 게시 전체 가이드에서 OpenPGP CERT 레코드를 만드는 방법을 설명합니다(하지만 Cloud DNS에서는 CERT 또는 OPENPGPKEY 레코드가 지원되지 않음).
Keybase.io에서 OpenPGP 키를 등록한 경우 자신의 서버에서 키를 호스팅할 필요가 없습니다. 대신 https://keybase.io/KEYBASE_USERNAME/key.asc와 같은 URL을 사용할 수 있습니다. KEYBASE_USERNAME은 Keybase.io 사용자 이름으로 바꿉니다.
OpenPGP 키를 키서버에 업로드한 경우에는 해당 키 서버에 대해 hkp://subkeys.pgp.net 또는 hkp://pgp.mit.edu와 같은 hkp: URI를 사용할 수도 있습니다. 단, 포트 11371을 차단하는 방화벽 뒤의 사용자가 연결할 수 없습니다. 일부 키서버는 포트 80 HTTP URL을 제공합니다.
TXT(SPF, DKIM, DMARC)
다음은 이메일 서비스를 보호하고, 스팸 발송자 또는 스캐머가 사용자의 도메인에서 보낸 것으로 보이는(실제로 그렇지 않더라도) 이메일을 보내지 못하도록 방지하기 위해 사용할 수 있는 세 가지 종류의 TXT 레코드입니다.
SPF: 도메인에 대해 이메일을 전송할 수 있는 SMTP 서버를 지정합니다(도메인 이름 또는 IP 주소 사용).
DKIM: 이메일이 어떤 도메인에서 전송되었는지 확인하기 위해 사용되는 공개 키 집합을 게시하고 메시지가 전송 중에 수정되지 않도록 보호합니다.
DMARC: SPF 및 DKIM 유효성 검사와 오류 보고를 위한 도메인 정책 및 보고를 지정합니다.
이러한 세 가지 레코드 유형을 모두 사용하도록 도메인이 올바르게 구성되었는지 확인하려면 이메일 검사기 테스트를 사용할 수 있습니다. SPF 레코드 구성에 대한 유용한 도움말은 Common mistakes FAQ를 참조하세요.
DNSSEC에 의해 강화되는 기타 레코드 모음 유형 사용
TXT 외에도 DNSSEC를 필요로 하지 않지만 DNSSEC의 이점을 누리는 몇 가지 다른 레코드 모음 유형이 있습니다.
CAA
인증 기관 승인(CAA) 레코드 집합을 사용하면 TLS 또는 도메인에 대해 다른 인증서를 생성할 수 있는 공개 CA를 제어할 수 있습니다. 이러한 제어는 도메인 검사(DV) 인증서(예: LetsEncrypt.org)를 발급하는 공개 CA가 도메인에 대해 인증서를 발급하지 않도록 하려는 경우에 가장 유용하며 효과적입니다.
일반적인 CAA 레코드에는 0 issue "best-ca.example"과 같이 간단한 형식이 사용됩니다. 이 형식을 사용하면 best-ca.example CA(그리고 다른 CA는 제외)가 CAA 레코드 집합이 있는 도메인의 이름에 대해 인증서를 발급할 수 있습니다.
여러 CA가 인증서를 발급할 수 있도록 하려면 여러 CAA 레코드를 만듭니다.
RFC 6844에서는 CAA 레코드 집합 유형의 사용에 대한 세부정보를 제공하며, DNSSEC를 사용할 것을 강력하게 권장합니다.
IPSECKEY
또한 IPSECKEY 레코드를 게시하여 IPsec 터널을 통해 낙관적 암호화를 사용 설정할 수 있습니다. strongSwan IPsec VPN 구현에는 IPSECKEY 레코드를 사용하는 플러그인이 포함됩니다.
IPSECKEY 레코드를 일반 전달 영역(service.example.com)에 배치하는 것 외에도 RFC 4025 섹션 1.2는 보안 게이트웨이가 역방향 영역(ip6.arpa 및 in-addr.arpa)에서 IPSECKEY 레코드를 찾도록 요구합니다.
역방향 영역에 대한 DNSSEC 지원은 전달 영역보다 덜 일반적이며, DNSSEC를 구현하는 인터넷 서비스 제공업체(ISP)가 필요합니다. 하지만 역방향 영역 위임에 대해 DNSSEC를 지원할 수 있는 일부 ISP가 있습니다.
Compute Engine VM 외부 IP 주소에 대한 역방향 영역은 아직 위임을 지원하지 않습니다.
다음 단계
- 관리형 영역을 생성, 업데이트, 나열, 삭제하려면 영역 관리를 참조하세요.
- Cloud DNS를 사용할 때 발생할 수 있는 일반적인 문제에 대한 해결책을 찾으려면 문제 해결을 참조하세요.
- Cloud DNS 개요는 Cloud DNS 개요를 참조하세요.