Quá trình chuyển đổi nameserver có thể trông như đã thành công trên mọi bảng điều khiển, nhưng website vẫn không thể truy cập được. Tên miền vẫn hoạt động, các máy chủ DNS có thẩm quyền mới trả về đúng địa chỉ mong đợi và máy chủ web không có gì thay đổi. Thế nhưng, các trình phân giải DNS có kiểm tra tính hợp lệ lại trả về SERVFAIL. Nguyên nhân thường bị bỏ sót là chuỗi ủy quyền DNSSEC vẫn tin cậy khóa ký của nhà cung cấp DNS trước đó.
Trong sự cố được phân tích ở đây, các truy vấn DNS thông thường thất bại, trong khi chính những truy vấn đó lại thành công khi bỏ qua bước xác thực DNSSEC. Vùng DNS cha vẫn công bố bản ghi DS cũ, còn vùng DNS có thẩm quyền mới ban đầu chưa được ký. Việc công bố khóa phù hợp và ký vùng DNS mới đã khôi phục các câu trả lời vượt qua kiểm tra xác thực trên những trình phân giải được thử nghiệm. Bài học quan trọng không phải là nên tắt DNSSEC, mà là chuyển nameserver và chuyển chuỗi tin cậy DNSSEC là hai công việc riêng biệt.
Vì sao bản ghi A chính xác vẫn có thể dẫn đến SERVFAIL
DNS giải quyết hai vấn đề khác nhau. Bản ghi A cho trình phân giải biết địa chỉ IPv4 tương ứng với một tên miền. Còn DNSSEC cho trình phân giải có thực hiện xác thực biết liệu câu trả lời đó có đáng tin cậy hay không. Dữ liệu địa chỉ chính xác không tự động đồng nghĩa với việc chuỗi tin cậy DNSSEC hợp lệ.
Đối với tên miền có ký DNSSEC, chuỗi tin cậy đi từ vùng DNS cha đáng tin cậy, qua bản ghi DS (Delegation Signer), đến DNSKEY trong vùng DNS con. Vùng con công bố các chữ ký (RRSIG) cho dữ liệu DNS của mình. Bản ghi DS chứa giá trị băm (digest) dùng để xác định một DNSKEY được ủy quyền. Đây không phải là bản ghi A, không phải bản sao khóa riêng và cũng không phải một thiết lập trong trình chỉnh sửa tệp vùng DNS thông thường.
Sau khi thay đổi các máy chủ DNS có thẩm quyền, vùng cha vẫn có thể tiếp tục công bố bản ghi DS gắn với khóa ký trước đây. Nếu vùng mới không có DNSKEY và chữ ký tương ứng, trình phân giải có xác thực sẽ không thể hoàn tất chuỗi tin cậy. Thông thường, nó coi câu trả lời là không hợp lệ về mặt mật mã và trả về SERVFAIL thay vì một địa chỉ chưa được xác minh.
Đây không phải là sự cố HTTP. Yêu cầu của người dùng có thể chưa bao giờ đến được máy chủ web. Nó cũng khác với chứng chỉ TLS hết hạn: DNSSEC xác thực dữ liệu DNS, còn HTTPS bảo vệ kết nối được thiết lập sau đó giữa trình duyệt và máy chủ.
Cách chẩn đoán để phân biệt lỗi DNSSEC với bản ghi bị thiếu
Phép kiểm tra hữu ích nhất là truy vấn cùng một tên miền hai lần qua cùng một trình phân giải. Trước tiên, thực hiện truy vấn thông thường và xem trạng thái phản hồi, không chỉ xem phần câu trả lời:
dig example.com A +noall +comments +answerSau đó, lặp lại truy vấn với bit DNSSEC Checking Disabled (CD) được bật:
dig example.com A +cdflag +noall +comments +answerTrong sự cố được quan sát, truy vấn thông thường trả về SERVFAIL, còn truy vấn có bật CD trả về đúng bản ghi A mong đợi. Sự khác biệt này cho thấy rất rõ khả năng vấn đề nằm ở khâu xác thực DNSSEC, thay vì thiếu bản ghi DNS hoặc ứng dụng không phản hồi. Tùy chọn +cdflag yêu cầu trình phân giải đệ quy có hỗ trợ bỏ qua quy trình xác thực DNSSEC thông thường đối với truy vấn đó. Đây là công cụ chẩn đoán, không phải cách khắc phục từ phía trình duyệt hay cách tắt DNSSEC cho người truy cập.
Đừng vội kết luận chỉ vì kết quả của +short trống. Cả trường hợp không có câu trả lời lẫn lỗi SERVFAIL đều có thể hiển thị trống với định dạng này. Trong quá trình chẩn đoán, hãy giữ +comments để vẫn nhìn thấy status: SERVFAIL và status: NOERROR.
Chỉ so sánh hai truy vấn có và không có CD chưa thể xác định chính xác phần nào của DNSSEC bị lỗi. Phép so sánh chỉ giúp khoanh vùng hướng điều tra tiếp theo. Trình phân giải cũng có thể gặp lỗi tạm thời ở máy chủ DNS phía trên, vì vậy hãy lặp lại phép kiểm tra khi cần và kiểm tra thông tin ủy quyền tại vùng cha.
Kiểm tra bản ghi DS ở vùng cha, không chỉ trong trình chỉnh sửa DNS
Kiểm tra các bản ghi DS của tên miền:
dig example.com DS +noall +comments +answerĐể xem đầy đủ hơn đường đi của quá trình ủy quyền, hãy truy vấn trực tiếp theo hệ thống phân cấp DNS:
dig +trace example.com DSMáy chủ có thẩm quyền của vùng cha cụ thể phụ thuộc vào tên miền cấp cao nhất. Điều quan trọng là tập hợp bản ghi DS (DS RRset) do vùng cha công bố, chứ không chỉ là phần tóm tắt trên bảng điều khiển của nhà cung cấp DNS. Chuyển tên miền sang nhà đăng ký khác không nhất thiết làm thay đổi nameserver; ngược lại, có thể thay đổi nameserver mà không cần đổi nhà đăng ký. Trong cả hai trường hợp, bản ghi DS ở vùng cha phải nhất quán với vùng DNS có thẩm quyền đang hoạt động.
Một bản ghi DS có bốn trường quan trọng: key tag, thuật toán, loại digest và giá trị digest. Key tag là nhãn thuận tiện cho việc xử lý sự cố, nhưng chỉ riêng nó không chứng minh được rằng DNSKEY tương ứng là chính xác. Thông tin về digest và thuật toán cũng phải khớp với khóa thực sự được cung cấp bởi vùng DNS có thẩm quyền.
Trạng thái mang tính quyết định trong sự cố này khá đơn giản: vùng cha vẫn công bố thông tin tin cậy DNSSEC cũ, trong khi vùng DNS có thẩm quyền thay thế báo rằng tính năng ký vùng chưa được bật. Các bản ghi A vẫn tồn tại và có thể truy xuất khi bỏ qua xác thực. Thay đổi cấu hình ứng dụng hoặc liên tục sửa lại cùng một bản ghi A sẽ không giải quyết được sự không khớp đó.
Hai cách khôi phục chuỗi ủy quyền DNSSEC bị lỗi
Có hai phương án khôi phục hợp lệ. Cả hai đều giải quyết cùng một sự không khớp trong chuỗi tin cậy, nhưng có hệ quả vận hành khác nhau. Hãy chủ động chọn một phương án, tránh tùy tiện chuyển qua chuyển lại giữa hai cách.
Phương án 1: Xóa DS lỗi thời và tạm thời sử dụng vùng DNS không ký
Yêu cầu nhà đăng ký tên miền hiện tại, hoặc sử dụng giao diện quản lý DNSSEC mà họ hỗ trợ, để xóa bản ghi DS cũ khỏi vùng cha. Khi vùng cha không còn khẳng định đây là một chuỗi ủy quyền được bảo vệ bằng DNSSEC, các trình phân giải có xác thực có thể coi vùng con không ký là vùng không được bảo vệ bằng DNSSEC, thay vì coi dữ liệu của nó là không hợp lệ. DNS sẽ tiếp tục hoạt động, nhưng tên miền tạm thời không còn được xác thực bằng DNSSEC.
Đây thường là phương án xử lý khẩn cấp đơn giản hơn, miễn là có cách đáng tin cậy để chỉnh sửa DS RRset ở vùng cha. Giữ nguyên cấu hình ký hiện có cho đến khi các bản ghi DS cũ hết hạn trong bộ nhớ đệm của các trình phân giải đệ quy. Việc xóa DS trong bảng điều khiển chưa đủ để chứng minh thay đổi đã có hiệu lực: cần kiểm tra bản ghi tại vùng cha từ bên ngoài và tính đến TTL của nó. HTTPS hoạt động độc lập với thiết lập DNSSEC. Quá trình tạm thời chuyển sang vùng không ký cũng được mô tả trong RFC 8078.
Phương án 2: Ký vùng DNS mới và công bố DS tương ứng
Phương án còn lại là bật DNSSEC tại nhà cung cấp DNS có thẩm quyền mới, tạo bộ khóa DNSKEY, ký vùng DNS rồi công bố bản ghi DS tương ứng ở vùng cha. Khi đó, trình phân giải có xác thực có thể xây dựng đường tin cậy đến DNSKEY mới và xác thực bản ghi A.
Đây chính là phương án khôi phục đã được quan sát trong thực tế. Giao diện quản lý DNS thông báo rằng hệ thống đã tạo khóa, ký vùng DNS và công bố một bản ghi DS mới. Truy vấn vùng cha sau đó cho thấy bản ghi DS mới xuất hiện cùng với bản ghi trước đó. Các truy vấn đệ quy có xác thực bắt đầu trả về bản ghi A mong đợi. Một lần kiểm tra tiếp theo cũng trả về NOERROR kèm cờ ad, cho biết trình phân giải đó đã xác thực dữ liệu.
Thứ tự thực hiện rất quan trọng: một bản ghi DS được công bố chỉ có tác dụng khi DNSKEY tương ứng và các chữ ký hợp lệ đã được dịch vụ DNS có thẩm quyền cung cấp. Trạng thái “published” trên bảng điều khiển không thể thay thế việc kiểm tra từ bên ngoài. Các bản ghi DS, DNSKEY, RRSIG và NS lưu trong bộ nhớ đệm có thể khiến các trình phân giải khác nhau khôi phục ở những thời điểm khác nhau.
Vì sao có hai bản ghi DS không nhất thiết khiến website tiếp tục bị lỗi
Một kết quả đáng ngạc nhiên là vùng cha tạm thời chứa cả bản ghi DS cũ không còn phù hợp lẫn bản ghi DS mới hợp lệ, nhưng quá trình xác thực DNSSEC vẫn thành công. Điều đó không có gì mâu thuẫn. Một DS RRset có thể chứa nhiều bản ghi, như thường thấy trong quá trình thay đổi khóa. Trình xác thực không yêu cầu mọi bản ghi DS đều phải trỏ đến một khóa còn sử dụng được; nó chỉ cần một đường xác thực hợp lệ thông qua bản ghi DS phù hợp, dẫn đến DNSKEY và các chữ ký hợp lệ. RFC 6840 làm rõ rằng trình xác thực nên chấp nhận chỉ một đường xác thực hợp lệ.
Tuy nhiên, điều đó không có nghĩa là nên giữ các khóa DS lỗi thời mãi mãi. Bản ghi DS không còn hiệu lực làm tăng sự nhập nhằng trong vận hành và cuối cùng nên được dọn dẹp sau khi đã xác minh chuỗi tin cậy mới. Nhưng đây là công việc bảo trì, không phải lý do để thực hiện thêm một lần đặt lại DNSSEC đầy rủi ro khi các truy vấn có xác thực đã thành công trở lại.
Có một cái bẫy đặc biệt nguy hiểm trong bảng điều khiển: thao tác mang tên “emergency unpublish DS” có thể đồng nghĩa với việc xóa tất cả bản ghi DS, kể cả bản ghi mới đang hoạt động. Tương tự, tắt tính năng ký vùng DNS trong khi bản ghi DS vẫn được công bố có thể lập tức tái diễn sự cố. Cả hai thao tác đều không tương đương với việc xóa riêng một bản ghi DS cũ cụ thể. Nếu giao diện không cho phép chọn từng bản ghi để xóa, hãy sử dụng phương thức chỉnh sửa có chọn lọc được nhà đăng ký hỗ trợ thay vì đặt lại toàn bộ.
Cách thay đổi nameserver có thẩm quyền một cách an toàn
Trình tự an toàn nhất phụ thuộc vào khả năng phối hợp khóa giữa nhà cung cấp DNS cũ và mới. Với quy trình chuyển đổi thông thường có một khoảng thời gian tạm thời không ký DNSSEC, thứ tự sau giúp tránh sự không khớp đã xảy ra trong sự cố này:
- Chuẩn bị vùng DNS đích trước. Sao chép các bản ghi A, AAAA, CNAME, MX, TXT và những bản ghi cần thiết khác. Kiểm tra trực tiếp các máy chủ DNS có thẩm quyền mới trước khi thay đổi thông tin ủy quyền.
- Kiểm tra DNSSEC tại vùng cha. Xác định xem có bản ghi DS hay không và ai có quyền cập nhật chúng. Hãy làm điều này ngay cả khi bạn chưa từng tự bật DNSSEC, vì một số dịch vụ DNS tự động thực hiện việc ký vùng.
- Xóa DS cũ khi vùng DNS đã ký trước đó vẫn đang hoạt động. Xác nhận thay đổi tại vùng cha có thẩm quyền, sau đó chờ đủ lâu để dữ liệu DS cũ trong bộ nhớ đệm hết hạn. Thời gian chờ phụ thuộc vào TTL quan sát được, không phải một số phút cố định áp dụng cho mọi trường hợp.
- Thay đổi thông tin ủy quyền nameserver. Duy trì dịch vụ DNS có thẩm quyền cũ trong thời gian các thông tin ủy quyền NS còn lưu trong bộ nhớ đệm có thể tiếp tục trỏ về đó. Tính đến TTL của các bản ghi NS ở vùng cha và kiểm tra những máy chủ thực sự đang được các trình phân giải khác nhau sử dụng.
- Quyết định có bật lại DNSSEC hay không. Nếu dịch vụ mới tiếp tục không ký vùng DNS, đừng công bố bản ghi DS. Nếu vùng mới sẽ được ký, hãy xác minh DNSKEY và các chữ ký mới đang được cung cấp chính xác trước khi công bố DS tương ứng. Cần phối hợp bước này với các bộ nhớ đệm NS cũ còn tồn tại để tránh phát sinh lỗi xác thực do không khớp lần nữa.
- Xác minh độc lập. Kiểm tra bản ghi DS tại vùng cha, DNSKEY trên máy chủ có thẩm quyền, khả năng phân giải đệ quy thông thường và kết quả xác thực dữ liệu từ các trình phân giải có kiểm tra DNSSEC.
Nếu bắt buộc phải duy trì khả năng bảo vệ DNSSEC liên tục, nên ưu tiên quy trình thay đổi khóa được phối hợp rõ ràng hoặc chuyển đổi với nhiều bên ký thay vì sử dụng giai đoạn không ký. Cách này đòi hỏi cả hai nhà cung cấp DNS hỗ trợ cơ chế phối hợp khóa và ký cần thiết. Chỉ sao chép giá trị digest của DS cũ sang nhà cung cấp mới không phải là một quy trình thay đổi khóa.
Danh sách kiểm tra ngắn sau khi chuyển đổi
Sau mỗi thay đổi liên quan đến DNSSEC, hãy kiểm tra cả các bản ghi DNS lẫn bằng chứng cho thấy các trình phân giải chấp nhận chúng:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerHãy sử dụng trình phân giải đệ quy có xác thực DNSSEC để kiểm tra câu trả lời đã được xác thực. Trong phản hồi của nó, NOERROR đi kèm bản ghi A mong đợi có nghĩa là quá trình phân giải đã thành công. Nếu có thêm cờ ad, trình phân giải đang cho biết câu trả lời đã được xác thực theo chính sách DNSSEC của nó. Chỉ riêng việc thiếu cờ ad không chứng minh có lỗi, vì các trình phân giải có thể khác nhau về khả năng hỗ trợ, chính sách và cách xử lý cờ truy vấn. Nếu truy vấn DNSKEY qua trình phân giải có xác thực thất bại trong lúc xảy ra sự cố, hãy bổ sung bước truy vấn trực tiếp dịch vụ DNS có thẩm quyền đang hoạt động vào quá trình điều tra.
Đừng dừng lại chỉ vì một trình phân giải đã trả lời thành công. Các bộ nhớ đệm khác nhau có thể tạm thời lưu thông tin ủy quyền và khóa khác nhau. Đồng thời, hãy cập nhật mọi yêu cầu hỗ trợ kỹ thuật đang mở: hướng dẫn trước đó yêu cầu xóa tất cả bản ghi DS sẽ trở nên nguy hiểm sau khi một bản ghi DS mới đang hoạt động được công bố. Nội dung trao đổi tiếp theo cần yêu cầu rõ ràng phải giữ nguyên khóa đang hoạt động và, nếu cần, chỉ xóa bản ghi cũ không còn hiệu lực.
Sự cố này không xuất phát từ địa chỉ máy chủ web sai. Nó xảy ra vì nơi cung cấp câu trả lời DNS đã được thay đổi mà thông tin tin cậy dùng để xác định câu trả lời nào đáng tin vẫn chưa được đồng bộ. Vì vậy, câu hỏi cần đặt ra trước mỗi lần chuyển đổi nameserver là: Vùng cha đang công bố những bản ghi DS nào, và DNSKEY cùng các chữ ký tại dịch vụ đích có đáp ứng được chúng hay không?