Tại sao máy chủ định danh có thẩm quyền không xác thực DNSSEC với kết quả của chính nó?
Bởi vì nó không thể, nếu không bản thân nó là một máy chủ định danh đệ quy, điều đó sẽ rất tệ.
Để xác thực đầy đủ DNSSEC, bạn cần bắt đầu từ gốc và đi qua toàn bộ liên kết của ĐS/DNSKEY các bản ghi và trình giải quyết có thẩm quyền mà bạn tham khảo không có thẩm quyền về tất cả những điều đó, chỉ là một phần của nó trong liên kết.
Xem ví dụ phần 6 của RFC 4033, "Cân nhắc trình giải quyết":
Trình phân giải nhận biết bảo mật phải có khả năng thực hiện mã hóa
các chức năng cần thiết để xác minh chữ ký số sử dụng ít nhất
(các) thuật toán bắt buộc phải thực hiện. Trình phân giải nhận biết bảo mật phải
cũng có khả năng hình thành một chuỗi xác thực từ một mới
vùng đã học trở lại khóa xác thực, như được mô tả ở trên. Cái này
quá trình có thể yêu cầu các truy vấn bổ sung tới các vùng DNS trung gian để lấy các bản ghi DNSKEY, DS và RRSIG cần thiết. Nhận thức về bảo mật
trình phân giải phải được định cấu hình với ít nhất một neo tin cậy làm
điểm bắt đầu mà từ đó nó sẽ cố gắng thiết lập xác thực
xiềng xích.
Và RFC 4035, phần §3.2.3 "Bit quảng cáo" trong "Máy chủ tên đệ quy":
Phía máy chủ tên của máy chủ tên đệ quy nhận biết bảo mật PHẢI
KHÔNG đặt bit AD trong phản hồi trừ khi máy chủ định danh xem xét tất cả
Các tập bản ghi tài nguyên trong phần Trả lời và Quyền hạn của phản hồi sẽ được
thật. Phía máy chủ tên NÊN đặt bit AD khi và chỉ khi
phía trình giải quyết xem xét tất cả các tập bản ghi trong phần Trả lời và bất kỳ
các RR phản hồi tiêu cực có liên quan trong phần Thẩm quyền sẽ được
thật. Phía giải quyết PHẢI tuân theo quy trình được mô tả trong
Mục 5 để xác định xem các RR được đề cập có xác thực hay không.
Tuy nhiên, để tương thích ngược, máy chủ định danh đệ quy CÓ THỂ đặt
bit AD khi một phản hồi bao gồm các bản ghi tài nguyên CNAME không được ký nếu các bản ghi tài nguyên CNAME đó
Rõ ràng là các RR có thể đã được tổng hợp từ một DNAME đích thực
RR cũng được bao gồm trong phản ứng theo tổng hợp
các quy tắc được mô tả trong [RFC2672].
Đối với:
nó tạo ra sự khác biệt cho dù một câu trả lời có được xác thực hay không
Tất nhiên là có, đó là toàn bộ mục đích của DNSSEC. Nhưng khách hàng cuối không tham khảo trực tiếp máy chủ tên có thẩm quyền trong quá trình hoạt động bình thường. Họ sử dụng một máy chủ tên đệ quy, máy chủ này sẽ lặp lại nhiều máy chủ tên có thẩm quyền khác nhau để nhận được câu trả lời cuối cùng và có thể xác thực DNSSEC nếu được định cấu hình để làm như vậy.
Tôi thắc mắc tại sao các bản ghi SSHFP không hoạt động khi thực hiện ssh -o VerifyHostKeyDNS từ chính máy chủ định danh
Bất kể vấn đề bạn có ở đây không liên quan đến bất cứ điều gì ở trên. ssh nên sử dụng bất kỳ trình phân giải cấp hệ điều hành nào được định cấu hình để lấy dữ liệu.
Nhìn thấy https://github.com/openssh/libopenssh/blob/05dfdd5f54d9a1bae5544141a7ee65baa3313ecd/ssh/dns.c#L191 đó là bên trong verify_host_key_dns chức năng:
kết quả = getrrsetbyname(tên máy chủ, DNS_RDATACLASS_IN,
DNS_RDATATYPE_SSHFP, 0, &dấu vân tay);
nếu (kết quả) {
verbose("Lỗi tra cứu DNS: %s", dns_result_totext(result));
trả về -1;
}
if (dấu vân tay->rri_flags & RRSET_VALIDATED) {
*cờ |= DNS_VERIFY_SECURE;
debug("đã tìm thấy %d dấu vân tay an toàn trong DNS",
dấu vân tay->rri_nrdatas);
} khác {
debug("đã tìm thấy %d dấu vân tay không an toàn trong DNS",
dấu vân tay->rri_nrdatas);
}
và getrrsetbyname được định nghĩa trong https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/openbsd-compat/getrrsetbyname.c và về cơ bản là một vỏ bọc xung quanh res_query đó là ràng buộc libc cấp thấp để thực hiện các truy vấn DNS.
tôi đã tìm thấy tại https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/ một số chi tiết về ssh hành vi giữa một xác thực (DNSSEC) SSHFP ghi lại hay không.
