使用進階 DNSSEC

本頁面提供數種進階網域名稱系統安全性擴充功能 (DNSSEC) 設定選項，如果您在代管區域中啟用 DNSSEC，即可使用這些選項。這些選項的範圍從不同的簽署演算法和拒絕存在，到使用需要或建議使用 DNSSEC 的記錄類型功能；說明如下。

如需 DNSSEC 的概念總覽，請參閱 DNSSEC 總覽。

委派 DNSSEC 簽署的子網域

只要您在主網域中啟用了 DNSSEC，就可以在委派的子網域中啟用 DNSSEC。如要為委派的子網域啟用 DNSSEC，請先在 Cloud DNS 區域中建立 DS 記錄。您也必須建立一或多個 NS 記錄。

如要為委派的子網域建立 DS 記錄，您必須取得區域的 DS 記錄。如果委派的區域也在 Cloud DNS 中託管，您可以透過 Google Cloud 控制台或 Google Cloud CLI 取得 DS 記錄。

主控台

  1. 前往 Google Cloud 控制台的「Cloud DNS」頁面。

    前往 Cloud DNS

  2. 前往要查看 DS 記錄的代管區域。

  3. 如要查看區域的 DS 記錄，請在「區域詳細資料」頁面的右上角，按一下「註冊商設定」。

  4. 您可以在「註冊機構設定」頁面中找到 DS 記錄。

  5. 如要建立 NS 記錄，請按照「新增記錄」中的指示操作。

「註冊商設定」頁面

gcloud

  1. 如要取得委派子網域的 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

  2. 如要取得完整的 DS 記錄和金鑰的所有詳細資料，您需要 KEY_SIGNING 金鑰 (KSK) 的 ID，通常為零 (0)。執行下列指令：

    gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
   --format "value(ds_record())"

    更改下列內容：

    • EXAMPLE_ZONE：專案中委派子網域 DNS 區域的名稱
    • KSK_ID：KSK ID 編號，通常為 0

    輸出看起來類似以下內容：

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

  3. 複製先前指令的輸出內容，以便在後續步驟中使用。

  4. 如要為安全的子委派作業建立 DS 記錄，請執行下列指令來啟動交易：

    gcloud dns record-sets transaction start --zone EXAMPLE_ZONE

    將 EXAMPLE_ZONE 替換為專案中父級 DNS 區域的名稱，您會在該專案中建立委派子網域的記錄。

    輸入如下所示： 

    Transaction started [transaction.yaml].

  5. 接著，執行下列指令來新增記錄集：

    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：區域的存留時間 (以秒為單位)，例如 3600
    • 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].

  6. 如要新增 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：區域的存留時間 (以秒為單位)，例如 3600
    • subdomain.example.com：區域 DNS 名稱的子網域

  7. 輸入以下 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].

  8. 如要執行交易，請使用下列指令：

    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」。

下列指令會啟用使用 256 位元 ECDSA 和 NSEC 的 DNSSEC，透過 Cloud DNS 取得最小的 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 使用不同的演算法，這會降低相容性且可能會危害安全。對於使用 DNSKEY 演算法，但未用於簽署該區域中所有記錄的區域，部分 DNSSEC 驗證解析器可能無法驗證。即使 RFC 6840 指出「DNSKEY RRset 中的所有演算法不得運作」，這項情況仍適用。如果這不是問題 (大多數驗證解析器都遵循 RFC 6840)，如果您的網域註冊商或頂層網域註冊管理機構不支援 ECDSA，且您需要縮減回應大小，可以使用 RSASHA256 做為 KSK，並使用 ECDSA 做為 ZSK。

NSEC3 是預設的拒絕存在類型，對嘗試在區域中探索所有記錄的區域巡查者提供有限保護。NSEC3PARAM 設定是固定的；基於安全考量，NSEC3 opt-out 已停用，且 64 位元的加碼會有 1 個額外的雜湊疊代 (總計 2 個)。

NSEC 的回應略小，但沒有任何區域巡查保護措施。使用 NSEC 也可以減少查詢不存在的網域。Google 公用 DNS 和其他幾個 DNSSEC 驗證解析器可以合成快取的 NSEC 記錄中的否定回應，而無需查詢您的 Cloud DNS 區域。

RFC 8624 提供有關演算法選取的其他指南。

配合受 DNSSEC 保護區域使用新的 DNS 記錄類型

在您的網域受到完整的 DNSSEC 保護後，您可以開始使用數種新的 DNS 記錄類型，這些記錄類型會使用 DNSSEC 簽署區域的真實性和完整性保證，來強化其他服務的安全性。

SSHFP

SSHFP 記錄含有 SSH 伺服器公開金鑰的指紋，可供 SSH 用戶端應用程式用來驗證 SSH 伺服器。SSH 用戶端在第一次連線時，通常需要透過使用者互動來確認伺服器的公開金鑰，如果金鑰已變更，則會產生警告。設定為使用 SSHFP 的 SSH 用戶端一律使用該伺服器 SSHFP 記錄中的金鑰；系統只會儲存伺服器的金鑰 (不含 SSHFP 記錄) 以供重複使用。

SSHFP 記錄格式如下：

  • 演算法編號
  • 指紋類型編號
  • 伺服器金鑰指紋

SSH 的演算法編號如下：

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

指紋類型如下：

  • SHA-1 (已淘汰，只在有相容性問題時使用)
  • SHA-256

StackExchange 提供建立 SSHFP 的建議，且可以透過工具來掃描伺服器 (使用現有的已知主機檔案或設定管理)，藉此產生建議。如需更多範例和連結，請參閱「SSHFP 記錄：提供公開 SSH 主機金鑰的 DNS」。

TLSA 與 DANE

TLSA 記錄所含的資訊可用來驗證 X.509 憑證 (例如 HTTPS 使用的憑證)，而不管簽署憑證的是否為一組預先設定的憑證授權單位 (CA)。

這可讓您設定自己的 CA 並產生 HTTPS 的憑證。這也允許驗證通訊協定 (例如 SMTP) 的憑證，因為通常沒有任何應用程式支援預先設定的信任 CA。

在 RFC 6698 及相關 RFC 中指定的「具名實體的網域驗證 (DANE)」會透過特定方式使用 TLSA 記錄，保護許多通訊協定和應用程式的安全。IETF Journal and Internet Society 提供有用的介紹文章和 DANE 總覽。

HTTPS

DANE 可讓您根據 OpenSSL 或 Cloudflare 的 CFSSL，使用以您自己的 CA 基礎架構產生的憑證，以安全的方式設定 HTTPS 伺服器。

SIDNLab 提供 HTTPS 伺服器適用的 DANE 驗證工具，很適合用來測試 HTTPS 的 DANE 部署。

SMTP (電子郵件) TLS 憑證驗證

SMTP 電子郵件通訊協定容易遭受停用加密的降級攻擊，而 DANE 有辦法防止這些攻擊。

Internet Society 提供的教學課程分為兩部分，說明如何透過從 Let's Encrypt 取得的免費且自動化憑證，針對 SMTP 使用 DANE，其中包括建議，說明如何避免以 Let's Encrypt 憑證搭配使用特定 TLSA 記錄格式：

您可以在「常見錯誤」一文中找到實用的建議 (以及適用於 HTTPS 和 SMTP 的 DANE 網域驗證工具)。「測試您的電子郵件」驗證工具也會檢查 DANE。

XMPP (Jabber Chat) 傳輸層安全標準 (TLS) 憑證驗證

XMPP (及其他使用 SRV 記錄的服務) 也可以使用 DANE。XMPP 範例使用 RFC 7673 中指定的 DANE-SRV 設定。

TXT (OpenPGP / GnuPG) 公開金鑰關聯

雖然可以在沒有 DNSSEC 的情況下使用 TXT，但 DNSSEC 簽署的 TXT 記錄可讓您更加確認資訊的真實性。這在 DNS 發布 OpenPGP (GnuPG) 公開金鑰時很重要，因為這些金鑰並非由 X.509 CA 之類的知名單位簽署。

舉例來說，如果「Alice」在 DNSSEC 簽署的 an.example 區域中發布以下 TXT 記錄，並在指定的 URI 上託管 ASCII armor 的公開金鑰副本，那麼「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 等網址 (將 KEYBASE_USERNAME 替換為您的 Keybase.io 使用者名稱)。

如果您已將 OpenPGP 金鑰上傳至金鑰伺服器，那麼也可以使用該金鑰伺服器的 hkp: URI，例如 hkp://subkeys.pgp.net 或 hkp://pgp.mit.edu，雖然如果防火牆封鎖通訊埠 11371，則在防火牆後面的使用者可能無法存取該 URI (部分金鑰伺服器會提供通訊埠 80 HTTP 網址)。

TXT (SPF、DKIM 及 DMARC)

以下是三種其他 TXT 記錄，可用來保護電子郵件服務，並防止垃圾內容發布者和詐騙者假冒從您的網域傳送電子郵件 (即使不是從您的網域傳送)：

  • SPF：指定可以傳送某網域電子郵件的 SMTP 伺服器 (透過網域名稱或 IP 位址)。

  • DKIM：發布一組公開金鑰，您可以使用這組金鑰來驗證從某網域送出的電子郵件，避免郵件在傳輸過程中遭到修改。

  • DMARC：指定 SPF 和 DKIM 驗證與錯誤回報的網域政策與回報設定。

如要驗證您的網域是否正確設定為使用這三種記錄類型，您可以使用測試您的電子郵件驗證工具。如需 SPF 記錄設定的實用建議，請參閱常見錯誤問答集。

使用 DNSSEC 強化的其他記錄集類型

除了 TXT 外，雖然有些其他的記錄集類型不需使用 DNSSEC，但若使用 DNSSEC，還是能有些好處。

CAA

憑證授權單位授權 (CAA) 記錄集可讓您控制哪些公開 CA 可以為您的網域產生 TLS 或其他憑證。這非常適合 (且有效) 協助您確認發出網域驗證 (DV) 憑證的公開 CA (如 LetsEncrypt.org)「不」會發出您的網域適用的憑證。

一般 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 支援較不常見，需要網際網路服務供應商 (ISP) 實作 DNSSEC。不過，部分 ISP 可支援 DNSSEC 進行反解區域委派。

Compute Engine VM 外部 IP 的反解區域尚不支援委派。

後續步驟

  • 如要建立、更新、列出及刪除代管可用區，請參閱「管理可用區」。
  • 如要找出使用 Cloud DNS 時可能遇到的常見問題解決方案，請參閱「疑難排解」。
  • 如要瞭解 Cloud DNS 的總體概況，請參閱 Cloud DNS 總覽。