고급 DNSSEC

관리형 영역에 DNSSEC를 사용 설정하는 경우에 사용 가능한 몇 가지 고급 DNSSEC 구성 옵션이 있습니다. 이러한 옵션은 다양한 서명 알고리즘과 존재 거부부터 DNSSEC를 요구하거나 권장하는 레코드 유형을 사용하는 기능에 이르기까지 다양합니다. 이러한 기능 모두 아래에 설명되어 있습니다.

DNSSEC 서명된 하위 도메인 위임

기본 도메인에 DNSSEC를 사용 설정하면 위임된 하위 도메인에 DNSSEC를 사용 설정할 수 있습니다. 이를 위해 DS 레코드를 만들게 되며,이 경우 Cloud DNS 영역 내에서 만들게 됩니다.

Google Cloud Platform Console을 사용하여 위임된 하위 도메인의 DS 레코드를 만들 수 있습니다(또한 NS 레코드를 하나 이상 만들어야 함). 위임된 영역이 Cloud DNS에서도 호스팅되는 경우, 관리형 영역으로 이동한 후 '영역 세부정보' 페이지의 오른쪽 상단 모서리에 있는 '레지스트라 설정' 링크를 클릭하여 DS 레코드를 GCP Console에서 가져올 수 있습니다.

등록기관 설정 팝업

gcloud 명령줄 도구를 사용하여 다음 정보를 가져올 수도 있습니다.

$ gcloud dns dns-keys list EXAMPLE ZONE
ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
0   1234     KEY_SIGNING   True       -
1   12345    ZONE_SIGNING  True       -

전체 DS 레코드와 만드는 데 필요할 수 있는 키의 모든 세부정보를 가져오려면 KEY_SIGNING 키(KSK)의 ID(일반적으로 0)가 필요합니다(일부 세부정보는 생략되고 공개 키는 축약되어 표시됨). EXAMPLE_ZONE을 영역 ID로 바꾸고, KSK_ID를 위의 ID로 바꿉니다.

$ gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
--format "value(ds_record())"
1234 7 1 2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12

다음 예와 같이 gcloud를 사용하여 보안 하위 위임을 위한 DS 레코드를 만들 수도 있습니다.

$ gcloud dns record-sets transaction start -z EXAMPLE_ZONE
Transaction started [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type DS --name SUBDOMAIN.EXAMPLE.COM \
'36283 5 1 0173d13977ffdf12716E3A1225B1B0B639B8CB46'
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e1.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e2.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e3.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e4.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction execute -z EXAMPLE_ZONE
Executed transaction [transaction.yaml] for managed-zone [dns-example].
Created [https://www.googleapis.com/dns/v1beta2/projects/dns-example-info/managedZones/dns-example/changes/38].
ID  START_TIME                STATUS
38  2016-02-08T23:12:49.100Z  PENDING

고급 서명 옵션

관리형 영역에 DNSSEC를 사용 설정하거나 DNSSEC로 관리형 영역을 만드는 경우, DNSSEC 서명 알고리즘과 존재 거부 유형을 선택할 수 있습니다. DNSSEC가 아직 사용 설정되지 않은 경우, DNSSEC 설정 변경은 관리형 영역에만 적용됩니다. 사용 설정된 관리형 영역의 설정을 변경해야 하는 경우, DNSSEC를 끈 후 다른 설정으로 다시 사용 설정할 수 있습니다.

이 명령어는 Cloud DNS를 사용하여 가능한 최소 DNSSEC 서명된 응답 패킷에 NSEC 및 256비트 ECDSA로 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
creationTime: '2016-04-29T14:15:08.085Z'
description: Example Cloud DNS Zone
dnsName: cloud.example
dnssecConfig:
  defaultKeySpecs:
  - algorithm: ECDSAP256SHA256
    keyLength: 256
    keyType: KEY_SIGNING
    kind: dns#dnsKeySpec
  - algorithm: ECDSAP256SHA256
    keyLength: 256
    keyType: ZONE_SIGNING
    kind: dns#dnsKeySpec
  kind: dns#managedZoneDnsSecConfig
  nonExistence: NSEC
  state: 'ON'
id: '9140081045636672726'
kind: dns#managedZone
name: EXAMPLE_ZONE
nameServers:
- ns-cloud-e1.googledomains.com.
- ns-cloud-e2.googledomains.com.
- ns-cloud-e3.googledomains.com.
- ns-cloud-e4.googledomains.com.

KSK 또는 ZSK 알고리즘이나 키 길이를 제공하는 경우, 명령어에 네 가지 옵션과 인수를 모두 제공해야 합니다. 알고리즘과 독립적으로 NSEC 또는 NSEC3으로 존재 거부를 지정할 수 있습니다.

지원되는 알고리즘 옵션과 인수는 다음 표에 나열되어 있으며, 요청 시에만 사용할 수 있는 취약한 값과 함께 기본값이 표시되어 있습니다.

알고리즘 KSK 길이 ZSK 길이 설명
RSASHA1 1024, 2048 1024, 2048 SHA-1은 취약한 것으로 간주됨
RSASHA256 1024, 2048 1024, 2048
RSASHA512 1024, 2048 1024, 2048 폭넓게 지원되지 않음
ECDSAP256SHA256 256 256 폭넓게 지원되지 않음
ECDSAP384SHA384 384 384 폭넓게 지원되지 않음

호환성을 위해 필요한 경우 외에는 RSASHA1을 사용하지 마세요. 더 긴 키 길이 사용 시에 비해 보안상 이점이 없습니다.

RSASHA256RSASHA512 간의 보안 및 성능 차이는 작으며 서명된 응답 크기가 동일합니다. 키 길이가 중요합니다. 키 길이가 길수록 느려지고 응답 크기가 커집니다(루트 영역TLD의 응답 크기 분석과 Windows의 서버 측 성능 분석 참조).

ECDSA에 대한 클라이언트 지원은 최근의 시스템으로 제한됩니다. ECDSA 서명 영역의 유효성을 검사할 수 없는 이전 클라이언트는 이를 서명되지 않은 것으로 간주하므로 DNSSEC를 활용하는 새 레코드 유형을 사용하는 경우에는 안전하지 않을 수 있습니다. 256비트 ECDSA에 대한 등록기관 및 레지스트리 지원은 일반적이지만 보편적이지 않습니다. 384비트 ECDSA는 소수 레지스트리와 더 적은 수의 등록기관에서만 지원됩니다. 이전 클라이언트를 지원할 필요가 없는 경우에는 ECDSA를 사용하는 것이 효과적일 수 있습니다. 서명은 훨씬 작고 계산 속도가 더 빠릅니다.

관리형 영역에서 KSK 및 ZSK에 서로 다른 알고리즘을 사용하지 마세요. 호환성이 줄어들고 보안이 저하될 수 있습니다. 엄격한 유효성 검사를 거친 리졸버는 두 가지 알고리즘을 사용한 Cloud DNS 영역 확인을 거부할 수 있습니다. 엄격한 리졸버(대부분의 리졸버는 상당히 관대함)가 필요하지 않은 경우에 등록기관과 레지스트리가 ECDSA를 지원하지 않고 응답 크기를 줄여야 한다면 KSK에 RSASHA256을 사용하고 ZSK에 ECDSA를 사용하는 것이 유용할 수 있습니다.

NSEC3은 기본 존재 거부 유형입니다. 영역 워커가 영역 내의 모든 레코드를 검색하지 못하도록 제한 보호 기능을 제공합니다. NSEC3PARAM 설정은 고정되어 있습니다. NSEC3 '선택 해제'가 보안을 위해 중지되어 있으며, 64비트 솔트를 사용하는 추가 해시 반복 1개(총 2개)가 있습니다.

NSEC는 응답 크기가 약간 더 작지만 영역 워킹에 대한 보호 기능이 없습니다. NSEC를 사용하면 존재하지 않는 도메인에 대한 쿼리도 줄일 수 있습니다. Google Public DNS(그리고 제공 예정인 여러 다른 리졸버)는 Cloud DNS 영역을 쿼리하지 않고 NSEC 캐시의 부정적인 응답을 합성할 수 있습니다.

DNSSEC 보안 영역에서 새 DNS 레코드 유형 사용

도메인이 완전히 DNSSEC로 보호되면 DNSSEC 서명 영역의 신뢰성과 무결성 보장을 활용하는 몇 가지 새로운 DNS 레코드 유형을 사용하여 다른 서비스의 보안을 강화할 수 있습니다.

SSHFP

SSHFP 레코드는 SSH 서버 공개 키의 지문을 포함하며 SSH 클라이언트 애플리케이션에서 SSH 서버의 유효성을 검사하는 데 사용됩니다. SSH 클라이언트는 일반적으로 최초 연결 시 서버의 공개 키 확인을 위해 사용자 상호작용을 필요로 하며 키가 변경되면 경고를 생성합니다. SSHFP를 사용하도록 구성된 SSH 클라이언트는 항상 해당 서버에 대한 서버의 SSHFP 레코드에 있는 키를 사용합니다. SSHFP 레코드가 없는 서버의 키만 저장되어 다시 사용됩니다.

SSHFP 레코드 형식은 알고리즘 번호, 지문 유형 번호, 서버 키 지문입니다. SSH의 알고리즘 번호는 다음과 같습니다.

  1. RSA
  2. DSA
  3. ECDSA
  4. ED25519

지문 유형은 다음과 같습니다.

  1. SHA-1(지원 중단됨, 호환성 제공 전용)
  2. SHA-256

StackExchange에는 SSHFP 생성을 위한 권장사항이 있으며, 기존의 알려진 호스트 파일 또는 구성 관리를 통해 서버를 검색하여 SSHFP를 생성하는 도구가 있습니다. 이 메모에는 더 많은 예와 링크가 있습니다.

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을 기반으로 하는 자체 인증 기관 인프라로 생성된 인증서를 사용하여 HTTPS 서버를 안전하게 구성할 수 있습니다.

HTTPS 서버에 대한 SIDNLabs의 DANE 유효성 검사 도구는 HTTPS에 대한 DANE 배포를 테스트하는 데 유용합니다.

SMTP(이메일) TLS 인증서 확인

SMTP 이메일 프로토콜은 특히 암호화를 중지하는 다운그레이드 공격에 취약하며 DANE은 이를 방지할 수 있는 방법을 제공합니다. Internet Society에는 Let's Encrypt에서 제공하는 무료 자동 인증서로 SMTP용 DANE을 사용하는 가이드(2로 구성)가 있습니다. ('Let's Encrypt' 인증서와 함께 특정 TLSA 레코드 형식을 사용하지 않도록 권장사항에 주목하세요.)

https://dane.sys4.de/common_mistakes에도 권장사항과 HTTPS 및 SMTP용 DANE 도메인 유효성 검사 도구가 있습니다. '이메일 테스트' 유효성 검사 도구도 DANE을 확인합니다.

XMPP(Jabber 채팅) TLS 인증서 확인

XMPP 및 SRV 레코드를 사용하는 다른 서비스도 DANE를 활용할 수 있습니다. XMPP 예에서는 RFC 7673에 명시된 DANE-SRV 구성을 사용합니다.

TXT(OpenPGP/GnuPG) 공개 키 연결

TXT 레코드는 DNSSEC 없이 사용될 수 있지만 DNSSEC 서명 TXT 레코드는 신뢰성에 대한 확신을 줍니다. 이는 X.509 인증 기관과 같이 잘 알려진 당사자가 서명하지 않은 OpenPGP(GnuPG) 공개 키의 DNS 기반 게시에 중요합니다. Alice가 DNSSEC 서명 an.example 영역에서 다음과 같은 TXT 레코드를 게시한다고 가정해 보겠습니다.

alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

그런 다음 지정된 URI에서 ASCII 형식 공개 키의 사본을 호스팅하면 Bob은 합당한 보안으로 alice@an.example에 대한 OpenPGP 키를 조회할 수 있습니다. 이는 신뢰의 웹(Web-of-Trust) 유효성 검사를 대신하지는 않지만 이전에 알려지지 않은 당사자와 OpenPGP 암호화를 가능하게 합니다.

다음 안내를 따라 이러한 'PKA 버전 1' TXT 레코드(DNS의 키 개요에서 부르는 이름)를 생성할 수 있습니다. 또한 다른 방법 문서에서는 OpenPGP CERT 레코드를 만드는 방법을 설명합니다. 하지만 CERT 또는 OPENPGPKEY 레코드는 Cloud DNS에서 지원되지 않습니다.

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 유효성 검사와 오류 보고를 위한 도메인 정책 및 보고를 지정합니다.

'이메일 테스트' 유효성 검사 도구를 사용하여 도메인이 세 가지 레코드 유형을 모두 사용하도록 올바르게 구성되었는지 확인할 수 있습니다. 일반적인 실수 FAQ에서 SPF 레코드 구성에 대한 유용한 도움을 확인할 수 있습니다.

DNSSEC에 의해 강화되는 기타 레코드 모음 유형

TXT 외에도 DNSSEC를 필요로 하지 않지만 DNSSEC의 이점을 누리는 몇 가지 다른 레코드 모음 유형이 있습니다.

CAA

인증 기관 승인(CAA) 레코드 모음을 사용하면 도메인의 TLS 또는 기타 인증서를 생성할 수 있는 공개 인증서 인증(CA)을 제어할 수 있습니다. 이는 도메인 유효성 검사를 거친(DV) 인증서를 발급하는 공개 CA(예: LetsEncrypt.org)가 도메인의 인증서를 발급하지 않도록 하려는 경우에 가장 유용하고 효과적인 방법입니다.

일반적인 CAA 레코드는 0 issue "best-ca.example"과 같은 간단한 형식입니다. 이 예에서는 best-ca.example CA 단독으로만 CAA 레코드 모음이 있는 도메인의 이름에 대한 인증서를 발급할 수 있습니다. 여러 CA가 인증서를 발급할 수 있도록 허용하려면 CAA 레코드를 여러 개 만들면 됩니다.

RFC 6844는 CAA 레코드 모음 유형의 사용에 대한 자세한 내용을 제공하며 DNSSEC 사용을 강력히 권장합니다.

IPSECKEY

IPSECKEY 레코드를 게시하여 IPSEC 터널을 통해 상황별 암호화를 사용 설정할 수도 있습니다. StrongSwan IPSEC VPN 구현에는 IPSECKEY 레코드를 사용하는 플러그인이 있습니다.

IPSECKEY 레코드를 일반 정방향 영역(service.example.com)에 배치하는 것 외에도 RFC 4025 섹션 1.2는 보안 게이트웨이가 역방향 영역(ip6.arpain-addr.arpa)에서 IPSECKEY 레코드를 찾도록 요구합니다.

역방향 영역에 대한 DNSSEC 지원은 정방향 영역에 비해 덜 일반적이며 DNSSEC 자체를 구현하는 인터넷 서비스 제공업체(ISP)를 필요로 합니다. 하지만 역방향 영역 위임을 위해 DNSSEC를 지원할 수 있는 일부 서비스 제공업체가 있습니다.

Google Compute Engine VM 외부 IP의 역방향 영역은 아직 위임을 지원하지 않습니다. Google Compute Engine 기능 요청을 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...