Sử dụng DNSSEC nâng cao

Trang này cung cấp một số tuỳ chọn cấu hình Tiện ích bảo mật hệ thống tên miền (DNSSEC) nâng cao mà bạn có thể sử dụng nếu bật DNSSEC cho các vùng được quản lý. Các tuỳ chọn này bao gồm nhiều thuật toán ký và tính năng từ chối tồn tại cho đến khả năng sử dụng các loại bản ghi yêu cầu hoặc đề xuất sử dụng DNSSEC.

Để biết thông tin tổng quan về khái niệm DNSSEC, hãy xem bài viết Tổng quan về DNSSEC.

Uỷ quyền cho các miền con đã ký DNSSEC

Bạn có thể bật DNSSEC cho các miền con được uỷ quyền sau khi bật DNSSEC cho miền chính. Để bật DNSSEC cho các miền con được uỷ quyền, trước tiên, hãy tạo một bản ghi DS trong vùng DNS trên đám mây. Bạn cũng phải tạo một hoặc nhiều bản ghi NS.

Để tạo bản ghi DS cho các miền con được uỷ quyền, bạn phải lấy bản ghi DS cho vùng. Nếu vùng được uỷ quyền cũng được lưu trữ trong Cloud DNS, bạn có thể lấy bản ghi DS từ bảng điều khiển Trusted Cloud hoặc từ Google Cloud CLI.

Bảng điều khiển

  1. Trong bảng điều khiển Trusted Cloud , hãy chuyển đến trang Cloud DNS.

    Chuyển đến Cloud DNS

  2. Chuyển đến vùng được quản lý mà bạn muốn xem bản ghi DS.

  3. Để xem bản ghi DS cho vùng, ở góc trên bên phải của trang Thông tin chi tiết về vùng, hãy nhấp vào Thiết lập trình đăng ký.

  4. Bạn có thể xem bản ghi DS trên trang Thiết lập trình đăng ký.

  5. Để tạo bản ghi NS, hãy làm theo hướng dẫn trong phần Thêm bản ghi.

Trang Thiết lập trình đăng ký

gcloud

  1. Để lấy thông tin bản ghi DS cho các miền con được uỷ quyền, hãy chạy lệnh sau:

    gcloud dns dns-keys list --zone EXAMPLE_ZONE

    Thay thế EXAMPLE_ZONE bằng tên của vùng DNS miền con được uỷ quyền trong dự án.

    Kết quả sẽ có dạng như sau: 

    ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
0   1234     KEY_SIGNING   True
1   12345    ZONE_SIGNING  True

  2. Để có được bản ghi DS hoàn chỉnh và tất cả thông tin chi tiết về khoá, bạn cần có mã nhận dạng của khoá KEY_SIGNING (KSK), thường là 0. Chạy lệnh sau:

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

    Thay thế nội dung sau:

    • EXAMPLE_ZONE: tên của vùng DNS miền con được uỷ quyền trong dự án
    • KSK_ID: mã nhận dạng KSK, thường là 0

    Kết quả sẽ tương tự như sau:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

  3. Sao chép kết quả từ lệnh trước để sử dụng trong bước tiếp theo.

  4. Để tạo bản ghi DS cho một quá trình uỷ quyền phụ an toàn, hãy chạy lệnh sau để bắt đầu giao dịch:

    gcloud dns record-sets transaction start --zone EXAMPLE_ZONE

    Thay thế EXAMPLE_ZONE bằng tên của vùng DNS gốc trong dự án mà bạn đang tạo bản ghi cho miền con được uỷ quyền.

    Kết quả sẽ có dạng như sau: 

    Transaction started [transaction.yaml].

  5. Tiếp theo, hãy chạy lệnh sau để thêm một tập hợp bản ghi:

    gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
   --ttl TIME_TO_LIVE \
   --type DS \
   --name subdomain.example.com \
   "DS_RECORD_AND_KEY"

    Thay thế nội dung sau:

    • EXAMPLE_ZONE: tên của vùng DNS gốc trong dự án
    • TIME_TO_LIVE: thời gian tồn tại của vùng tính bằng giây, chẳng hạn như 3600
    • subdomain.example.com: miền con của tên DNS của vùng
    • DS_RECORD_AND_KEY: bản ghi DS và khoá mà bạn nhận được ở bước 2, chẳng hạn như 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

    Kết quả sẽ có dạng như sau: 

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Record addition appended to transaction at [transaction.yaml].

  6. Để thêm bản ghi NS, hãy sử dụng lệnh sau:

    gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
   --ttl TIME_TO_LIVE \
   --type NS \
   --name subdomain.example.com \

    Thay thế nội dung sau:

    • EXAMPLE_ZONE: tên của vùng DNS gốc trong dự án
    • TIME_TO_LIVE: thời gian tồn tại của vùng tính bằng giây, chẳng hạn như 3600
    • subdomain.example.com: miền con của tên DNS của vùng

  7. Nhập RRData sau:

    ns-cloud-e1.googledomains.com. \
ns-cloud-e2.googledomains.com. \
ns-cloud-e3.googledomains.com. \
ns-cloud-e4.googledomains.com.

    Kết quả sẽ có dạng như sau: 

    Record addition appended to transaction at [transaction.yaml].

  8. Để thực thi giao dịch, hãy sử dụng lệnh sau:

    gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE

    Thay thế EXAMPLE_ZONE bằng tên của một vùng DNS trong dự án.

    Kết quả sẽ có dạng như sau: 

    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

Sử dụng các tuỳ chọn ký nâng cao

Khi bật DNSSEC cho một vùng được quản lý hoặc tạo một vùng được quản lý có DNSSEC, bạn có thể chọn thuật toán ký DNSSEC và loại từ chối tồn tại.

Bạn có thể thay đổi chế độ cài đặt DNSSEC (ví dụ: thành thuật toán dùng để ký bản ghi bằng mã hoá) cho một vùng được quản lý trước khi bật DNSSEC. Nếu DNSSEC đã được bật cho một vùng được quản lý, trước tiên, để thực hiện thay đổi, hãy tắt DNSSEC, thực hiện các thay đổi cần thiết, sau đó sử dụng lệnh sau để bật lại DNSSEC:

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

Thay thế EXAMPLE_ZONE bằng tên của một vùng DNS trong dự án.

Để biết thông tin chi tiết, hãy xem phần Bật DNSSEC cho các vùng được quản lý hiện có.

Lệnh sau đây bật DNSSEC bằng ECDSA 256 bit và NSEC cho các gói phản hồi được ký DNSSEC nhỏ nhất có thể bằng cách sử dụng DNS trên đám mây:

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

Thay thế EXAMPLE_ZONE bằng tên của một vùng DNS trong dự án.

Nếu cung cấp bất kỳ thuật toán KSK hoặc ZSK hoặc độ dài khoá nào, bạn phải cung cấp tất cả các thuật toán đó và đối số của các thuật toán đó trong lệnh:

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

Bạn có thể chỉ định trường hợp từ chối tồn tại là NSEC hoặc NSEC3 độc lập với các thuật toán.

Các tuỳ chọn và đối số thuật toán được hỗ trợ được liệt kê trong bảng sau. Cloud DNS không cho phép sử dụng bất kỳ thuật toán hoặc tham số nào khác.

Thuật toán Chiều dài KSK Chiều dài ZSK Nhận xét
RSASHA256 2048 1024, 2048
RSASHA512 2048 1024, 2048 Không được hỗ trợ rộng rãi
ECDSAP256SHA256 256 256
ECDSAP384SHA384 384 384 Không được hỗ trợ rộng rãi

Nếu bạn không chỉ định thuật toán, Cloud DNS sẽ sử dụng các thuật toán mặc định sau:

Loại khoá Thuật toán mặc định Độ dài khoá mặc định
Khoá ký khoá (KSK) RSASHA256 2048
Khoá ký vùng (ZSK) RSASHA256 1024

Sự khác biệt về bảo mật và hiệu suất giữa RSASHA256 và RSASHA512 rất nhỏ và kích thước phản hồi đã ký giống hệt nhau. Độ dài khoá có ý nghĩa quan trọng: khoá dài hơn sẽ chậm hơn và phản hồi lớn hơn (xem phần phân tích kích thước phản hồi cho vùng gốc và TLD, cũng như phần phân tích hiệu suất phía máy chủ trên Windows).

Hỗ trợ trình phân giải cho ECDSA chỉ giới hạn ở các hệ thống khá mới. Các trình phân giải cũ không thể xác thực các vùng được ký bằng ECDSA sẽ coi các vùng đó là không được ký, điều này có thể không an toàn nếu bạn sử dụng các loại bản ghi mới dựa trên DNSSEC. Hỗ trợ của trình đăng ký và sổ đăng ký cho ECDSA 256 bit là phổ biến nhưng không phổ quát. Chỉ một số cơ quan đăng ký và thậm chí ít hơn là các nhà đăng ký hỗ trợ ECDSA 384 bit. Việc sử dụng ECDSA có thể hiệu quả nếu bạn không cần hỗ trợ các ứng dụng cũ; chữ ký nhỏ hơn và nhanh hơn nhiều khi tính toán.

Tránh sử dụng các thuật toán khác nhau cho KSK và ZSK trong các vùng được quản lý; việc này làm giảm khả năng tương thích và có thể làm tổn hại đến tính bảo mật. Một số trình phân giải xác thực DNSSEC có thể không xác thực được các vùng có thuật toán DNSKEY không được dùng để ký tất cả bản ghi trong vùng. Điều này vẫn đúng mặc dù RFC 6840 cho biết "các thuật toán này không được nhấn mạnh rằng tất cả thuật toán ... trong RRset DNSKEY đều hoạt động". Nếu không cần quan tâm đến vấn đề này (hầu hết các trình phân giải xác thực đều tuân theo RFC 6840), bạn có thể sử dụng RSASHA256 cho KSK và ECDSA cho ZSK nếu tổ chức đăng ký miền hoặc đăng ký TLD không hỗ trợ ECDSA và bạn cần giảm kích thước phản hồi.

NSEC3 là loại từ chối tồn tại mặc định; loại này cung cấp khả năng bảo vệ hạn chế đối với trình duyệt vùng đang cố gắng khám phá tất cả bản ghi trong vùng của bạn. Chế độ cài đặt NSEC3PARAM được khắc phục: NSEC3 opt-out bị tắt để bảo mật và có thêm một lần lặp lại hàm băm (tổng cộng là hai) với một giá trị muối 64 bit.

NSEC có phản hồi nhỏ hơn một chút, nhưng không có biện pháp bảo vệ chống lại việc đi bộ theo vùng. Việc sử dụng NSEC cũng có thể làm giảm số lượng truy vấn cho các miền không tồn tại. Google Public DNS và một số trình phân giải xác thực DNSSEC khác có thể tổng hợp các phản hồi âm tính từ các bản ghi NSEC được lưu vào bộ nhớ đệm mà không cần truy vấn vùng DNS trên đám mây.

RFC 8624 chứa hướng dẫn bổ sung về cách chọn thuật toán.

Sử dụng các loại bản ghi DNS mới với các vùng được bảo mật bằng DNSSEC

Sau khi miền của bạn được bảo mật đầy đủ bằng DNSSEC, bạn có thể bắt đầu bằng cách sử dụng một số loại bản ghi DNS mới sử dụng tính năng đảm bảo tính xác thực và tính toàn vẹn của các vùng được ký bằng DNSSEC để tăng cường bảo mật cho các dịch vụ khác.

SSHFP

Bản ghi SSHFP chứa vân tay số của khoá công khai của máy chủ SSH mà các ứng dụng máy khách SSH có thể dùng để xác thực máy chủ SSH. Ứng dụng SSH thường yêu cầu người dùng tương tác để xác nhận khoá công khai của máy chủ trong lần kết nối đầu tiên và tạo cảnh báo nếu khoá đó bị thay đổi. Ứng dụng SSH được định cấu hình để sử dụng SSHFP luôn sử dụng khoá trong bản ghi SSHFP của máy chủ cho máy chủ đó; chỉ các khoá cho máy chủ không có bản ghi SSHFP mới được lưu để sử dụng lại.

Định dạng bản ghi SSHFP như sau:

  • Số thuật toán
  • Số loại vân tay số
  • Vân tay số của khoá máy chủ

Số thuật toán cho SSH như sau:

  1. RSA
  2. Đạo luật Dịch vụ kỹ thuật số (DSA)
  3. ECDSA
  4. ED25519

Sau đây là các loại vân tay số:

  • SHA-1 (không dùng nữa, chỉ dành cho khả năng tương thích)
  • SHA-256

StackExchange có các đề xuất để tạo SSHFP và có các công cụ để tạo các SSHFP đó bằng cách quét máy chủ, sử dụng các tệp máy chủ lưu trữ đã biết hiện có hoặc quản lý cấu hình. Để biết thêm ví dụ và đường liên kết, hãy xem bài viết Bản ghi SSHFP: DNS cung cấp khoá máy chủ ssh công khai.

TLSA và DANE

Bản ghi TLSA chứa thông tin có thể dùng để xác thực chứng chỉ X.509 (chẳng hạn như chứng chỉ mà HTTPS sử dụng) mà không phụ thuộc vào một trong các nhóm tổ chức phát hành chứng chỉ (CA) được định cấu hình sẵn ký các chứng chỉ đó.

Điều này cho phép bạn thiết lập CA của riêng mình và tạo chứng chỉ cho HTTPS. Điều này cũng cho phép xác thực chứng chỉ cho các giao thức như SMTP, trong đó thường không có ứng dụng hỗ trợ cho các CA đáng tin cậy được định cấu hình trước.

DANE (Xác thực miền của các thực thể được đặt tên), như được chỉ định trong RFC 6698 và các RFC liên quan, sử dụng các bản ghi TLSA theo những cách cụ thể để bảo mật nhiều giao thức và ứng dụng. Tạp chí IETF và Internet Society có một bài viết giới thiệu và tổng quan về DANE hữu ích.

HTTPS

DANE cho phép bạn định cấu hình máy chủ HTTPS một cách an toàn bằng cách sử dụng các chứng chỉ được tạo bằng cơ sở hạ tầng CA của riêng bạn dựa trên OpenSSL hoặc CFSSL của Cloudflare.

Trình xác thực DANE cho máy chủ HTTPS của SIDNLabs rất hữu ích cho việc kiểm thử việc triển khai DANE cho HTTPS.

Xác minh chứng chỉ TLS SMTP (Email)

Giao thức email SMTP dễ bị các cuộc tấn công hạ cấp vô hiệu hoá tính năng mã hoá và DANE cung cấp một cách để ngăn chặn các cuộc tấn công này.

Internet Society có một hướng dẫn gồm hai phần về cách sử dụng DANE cho SMTP bằng các chứng chỉ tự động và miễn phí có sẵn từ Let's Encrypt, bao gồm cả lời khuyên để tránh sử dụng một số định dạng bản ghi TLSA nhất định với chứng chỉ Let's Encrypt:

Bạn có thể tìm thấy lời khuyên tuyệt vời (và trình xác thực miền DANE cho HTTPS và SMTP) tại phần Lỗi thường gặp. Tính năng Kiểm thử trình xác thực email cũng kiểm tra DANE.

Xác minh chứng chỉ TLS XMPP (trò chuyện qua Jabber)

XMPP (và các dịch vụ khác sử dụng bản ghi SRV) cũng có thể tận dụng DANE. Ví dụ về XMPP sử dụng cấu hình DANE-SRV như được chỉ định trong RFC 7673.

Liên kết khoá công khai TXT (OpenPGP / GnuPG)

Bạn có thể sử dụng bản ghi TXT mà không cần DNSSEC, nhưng bản ghi TXT được ký bằng DNSSEC sẽ giúp bạn tin tưởng hơn về tính xác thực của bản ghi. Điều này rất quan trọng đối với việc phát hành khoá công khai OpenPGP (GnuPG) dựa trên DNS. Các khoá này không được các bên nổi tiếng như CA X.509 ký.

Ví dụ: nếu Alice xuất bản một bản ghi TXT như sau trong vùng an.example được ký bằng DNSSEC và lưu trữ một bản sao của khoá công khai được bảo vệ bằng ASCII tại URI đã cho, thì Bob có thể tra cứu khoá OpenPGP cho alice@an.example với mức độ bảo mật hợp lý (đây không phải là thay thế cho quy trình xác thực web-of-trust, nhưng cho phép mã hoá OpenPGP với các bên không xác định trước đó):

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

Bạn có thể sử dụng các hướng dẫn này để tạo các bản ghi TXT PKA Phiên bản 1 (như được gọi trong phần Xuất bản khoá trong DNS).

Hướng dẫn đầy đủ về cách phát hành khoá PGP trong DNS giải thích cách tạo bản ghi OpenPGP CERT (nhưng Cloud DNS không hỗ trợ bản ghi CERT hoặc OPENPGPKEY).

Nếu đã đăng ký khoá OpenPGP tại Keybase.io, bạn không cần lưu trữ khoá trên máy chủ của riêng mình. Thay vào đó, bạn có thể sử dụng một URL như https://keybase.io/KEYBASE_USERNAME/key.asc (thay thế KEYBASE_USERNAME bằng tên người dùng Keybase.io của bạn).

Nếu đã tải khoá OpenPGP lên một máy chủ khoá, bạn cũng có thể sử dụng URI hkp: cho máy chủ khoá đó, chẳng hạn như hkp://subkeys.pgp.net hoặc hkp://pgp.mit.edu, mặc dù người dùng phía sau tường lửa chặn cổng 11371 có thể không truy cập được vào máy chủ khoá đó (một số máy chủ khoá cung cấp URL HTTP cổng 80).

TXT (SPF, DKIM và DMARC)

Sau đây là 3 loại bản ghi TXT khác mà bạn có thể sử dụng để bảo mật các dịch vụ email và ngăn chặn những kẻ gửi thư rác và lừa đảo gửi email có vẻ như đến từ miền của bạn (mặc dù thực tế không phải vậy):

  • SPF: Chỉ định các máy chủ SMTP (theo tên miền hoặc địa chỉ IP) có thể gửi email cho một miền.

  • DKIM: Phát hành một tập hợp khoá công khai dùng để xác minh rằng email được gửi từ một miền và bảo vệ thư không bị sửa đổi trong quá trình truyền.

  • DMARC: Chỉ định chính sách miền và báo cáo để xác thực SPF và DKIM cũng như báo cáo lỗi.

Để xác minh rằng miền của bạn được định cấu hình đúng cách để sử dụng cả ba loại bản ghi này, bạn có thể sử dụng tính năng Kiểm thử trình xác thực email. Để tìm lời khuyên hữu ích về cách định cấu hình bản ghi SPF, hãy xem nội dung Câu hỏi thường gặp về các lỗi thường gặp.

Sử dụng các loại tập hợp bản ghi khác được DNSSEC nâng cao

Ngoài TXT, còn có một số loại tập hợp bản ghi khác được hưởng lợi từ DNSSEC, mặc dù các loại này không bắt buộc phải sử dụng DNSSEC.

CAA

Tập hợp bản ghi Uỷ quyền tổ chức phát hành chứng chỉ (CAA) cho phép bạn kiểm soát những CA công khai nào có thể tạo TLS hoặc các chứng chỉ khác cho miền của bạn. Chế độ kiểm soát này hữu ích nhất (và hiệu quả nhất) nếu bạn muốn đảm bảo rằng một CA công khai đang phát hành chứng chỉ xác thực miền (DV) (chẳng hạn như LetsEncrypt.org) không phát hành chứng chỉ cho miền của bạn.

Một bản ghi CAA thông thường có định dạng đơn giản như 0 issue "best-ca.example" cho phép CA best-ca.example (và không có CA nào khác) cấp chứng chỉ cho các tên trong miền chứa tập hợp bản ghi CAA. Nếu bạn muốn cho phép nhiều CA cấp chứng chỉ, hãy tạo nhiều bản ghi CAA.

RFC 6844 cung cấp thêm thông tin chi tiết về cách sử dụng loại tập hợp bản ghi CAA và bạn nên sử dụng DNSSEC.

IPSECKEY

Bạn cũng có thể bật tính năng mã hoá cơ hội thông qua đường hầm IPsec bằng cách phát hành các bản ghi IPSECKEY. Quá trình triển khai VPN IPsec strongSwan có một trình bổ trợ sử dụng bản ghi IPSECKEY.

Ngoài việc đặt bản ghi IPSECKEY trong các vùng chuyển tiếp thông thường, chẳng hạn như service.example.com, phần 1.2 của RFC 4025 yêu cầu các cổng bảo mật tìm kiếm bản ghi IPSECKEY trong các vùng đảo ngược ip6.arpa và in-addr.arpa.

Tính năng hỗ trợ DNSSEC cho vùng đảo ngược ít phổ biến hơn so với vùng chuyển tiếp và yêu cầu nhà cung cấp dịch vụ Internet (ISP) triển khai DNSSEC. Tuy nhiên, một số ISP có thể hỗ trợ DNSSEC cho việc uỷ quyền vùng ngược.

Vùng đảo ngược cho địa chỉ IP bên ngoài của máy ảo Compute Engine chưa hỗ trợ tính năng uỷ quyền.

Bước tiếp theo

  • Để tạo, cập nhật, liệt kê và xoá các vùng được quản lý, hãy xem phần Quản lý vùng.
  • Để tìm giải pháp cho các vấn đề thường gặp mà bạn có thể gặp phải khi sử dụng Cloud DNS, hãy xem phần Khắc phục sự cố.
  • Để biết thông tin tổng quan về Cloud DNS, hãy xem bài viết Tổng quan về Cloud DNS.