DNS của hải đăng Nebula: ai được hỏi những bản ghi nào?

Vai trò hải đăng trong Nebula làm nhiều việc mà người ta cho là tự động, và trả lời DNS không phải một trong số đó. Dịch vụ tên là một bộ lắng nghe tùy chọn khởi động ở trạng thái tắt, vì thế một máy chủ phân giải tốt trong overlay có thể hoàn toàn không có gì để phân giải laptop của đồng nghiệp. Trước khi bật nó, hãy quyết định ai nên tiếp cận nó và bạn sẵn sàng trả lời những loại bản ghi nào, vì hai câu trả lời đó khác nhau.

Bộ lắng nghe là tùy chọn và tắt theo mặc định

Khám phá và DNS là hai dịch vụ riêng biệt. Hải đăng giúp các peer tìm thấy nhau và ngoài ra có thể trả lời truy vấn tên về những máy chủ nó biết, nhưng phần thứ hai đó phải được bật rõ ràng trong cấu hình.

Hãy quyết định giao diện và mạng nào nên tiếp cận bộ lắng nghe trước khi bật bất cứ thứ gì. Một dịch vụ DNS trả lời trên giao diện bạn không định dùng sẽ trở thành một rò rỉ thông tin nhỏ mà không có một dòng nhật ký nào để ai đó đọc. Quyết định bây giờ rẻ hơn nhiều so với thu hẹp sau này, khi đã có thứ gì đó phụ thuộc vào câu trả lời sai. Hai dòng cấu hình dễ biện minh hơn một ghi chú sự cố sau nửa năm.

Bản ghi A và TXT không chia sẻ cùng đối tượng

Hai loại bản ghi này được trả lời trong những điều kiện khác nhau, và coi chúng như một dịch vụ duy nhất chính là sai lầm mà bài viết này tồn tại để ngăn chặn.

Sự bất đối xứng đó là có chủ đích chứ không phải sơ suất. Ánh xạ tên sang địa chỉ có ít giá trị với người ngoài, trong khi siêu dữ liệu chứng chỉ mô tả các danh tính trong overlay của bạn. Đừng mang một giả định từ hàng này sang hàng khác chỉ vì cùng một tiến trình trả lời cả hai.

Nó chỉ trả lời về các máy chủ của chính hải đăng

Đây không phải là bộ phân giải chung cho văn phòng, VPC trên đám mây hay internet công cộng của bạn. Hải đăng trả lời từ thông tin máy chủ mà nó được cung cấp, vì thế tính năng này sống trên các nút hải đăng chứ không phải trên mọi peer.

Khi một tên thất bại mà overlay không liên quan gì, hãy tìm vùng và bộ phân giải thực sự sở hữu nó. Trộn một bộ phân giải overlay vào cấu hình DNS chung của máy chủ sẽ tạo ra những lỗi trông có vẻ ngẫu nhiên, vì một số tên phân giải được còn những tên khác thì không có gì trả lời.

Cũng hãy chú ý đến điểm vào bootstrap. Tên máy chủ dùng để tiếp cận hải đăng đầu tiên phải phân giải qua một đường thông thường trước khi khám phá có thể dựa vào nó, nên vấn đề con gà và quả trứng ở đây trông giống hệt một overlay hỏng. Nó thậm chí báo cáo theo cùng một cách: một peer không bao giờ khởi động và không có lý do rõ ràng. Hãy kiểm tra phân giải tên trước khi chạm vào chứng chỉ, vì thứ tự này bắt được những người bắt đầu từ nửa khó hơn.

Kiểm tra địa chỉ liên kết, rồi thử từ bên ngoài

lighthouse.dns.host và lighthouse.dns.port quyết định nơi dịch vụ tùy chọn lắng nghe. Hãy xem lại các giá trị đó cùng với tường lửa của máy chủ và chính sách mạng, vì địa chỉ liên kết là một tuyên bố ý định chứ không phải biện pháp kiểm soát bảo mật tự thân.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

Hãy truy vấn từ những mạng bạn định cho phép, không phải từ chính hải đăng. Một lần tra cứu thành công trên hải đăng chứng minh tiến trình đang chạy và không cho bạn biết gì về việc máy chủ bên ngoài có thể hỏi gì, và đó mới là câu hỏi thực sự quan trọng.

Hãy phơi bày nó một cách có chủ đích

Tên và siêu dữ liệu chứng chỉ là thông tin vận hành hữu ích, và tính hữu ích cắt theo cả hai hướng. Hãy quyết định liệu bộ lắng nghe chỉ dành cho overlay, loại bản ghi nào được phép và ai xem xét cấu hình khi nó thay đổi.

Sau đó ghi nó bên cạnh phần cài đặt hải đăng. Người tiếp theo gỡ lỗi một thất bại phân giải sẽ nếu không thì cho rằng dịch vụ luôn ở đó. Người đó cũng sẽ cho rằng nó luôn tiếp cận được từ bất cứ nơi nào họ tình cờ kiểm tra. Một đoạn ghi lại địa chỉ liên kết, các mạng được phép và các loại bản ghi tiết kiệm cho người đó một buổi chiều và tiết kiệm cho bạn một tin nhắn hỏi tại sao điều gì đó đã thay đổi.