Các vùng Route 53 riêng tư thay thế câu trả lời cho một tên thay vì hợp nhất với bản ghi công khai, và điều đó khiến mọi người bất ngờ vào thời điểm tồi tệ nhất. Thêm một bản ghi nội bộ cho api.example.net trong một vùng riêng tư cho example.net, liên kết nó với một VPC, và mọi tên khác dưới tên cha đó giờ chỉ được trả lời từ vùng riêng tư. Một máy khách hôm qua còn truy cập được www.example.net hôm nay nhận câu trả lời phủ định. Phần trình bày dưới đây bắt đầu từ truy vấn thất bại đó và đi ra ngoài tới vùng đã trả lời nó.

Hãy bắt đầu từ truy vấn, không phải từ bảng điều khiển

Tái hiện lỗi trên máy khách đã báo cáo, và ghi lại tên chính xác cùng loại bản ghi. Một tên thất bại với A vẫn có thể phân giải với AAAA, và trình duyệt thử lại một tên trong bộ nhớ đệm sẽ che giấu cái nào đã hỏng. Chạy truy vấn hai lần: một lần qua resolver mà máy khách thực sự dùng, một lần với theo dõi bỏ qua nó.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Lệnh thứ hai mới là quan trọng. Dòng trạng thái và phần authority của nó nêu tên vùng đã tạo ra câu trả lời, nhờ đó bạn phân biệt được câu trả lời phủ định từ vùng riêng tư với hết thời gian chờ, cổng bị chặn hoặc resolver chưa bao giờ nhận truy vấn. resolvectl cho biết máy chủ thượng nguồn nào đã được hỏi, và thường đó không phải resolver mà bạn cho rằng VPN đã đẩy xuống.

Nếu truy vấn có theo dõi trả về địa chỉ công khai còn truy vấn thường thì không, bản ghi công khai vẫn nguyên vẹn và chế độ xem riêng tư đang trả lời. Chính phép so sánh duy nhất đó quyết định nửa nào của phần còn lại trang này áp dụng cho bạn.

Đọc xem vùng nào đã trả lời

Một câu trả lời mang NXDOMAIN với SOA của vùng riêng tư trong phần authority là câu trả lời dứt khoát từ vùng đó, không phải tra cứu thất bại. Route 53 Resolver đã chọn vùng lưu trữ riêng tư vì tên khớp, sau đó không tìm thấy bản ghi thuộc loại được yêu cầu, và hành vi được ghi nhận là trả về câu trả lời phủ định thay vì chuyển câu hỏi tới DNS công khai.

Việc chọn lựa tuân theo độ đặc hiệu. Khi nhiều không gian tên riêng tư chồng lấn, vùng khớp đặc hiệu nhất sẽ thắng, và tên cha riêng tư rộng hơn không có cơ hội thứ hai cho một tên mà vùng con được chọn không có. Các quy tắc chuyển tiếp thêm một lớp nữa, vì quy tắc Resolver dành riêng cho miền có thể thắng liên kết vùng lưu trữ riêng tư. Liệt kê các liên kết và quy tắc trước khi kết luận một vùng là trống.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Cả hai lệnh đều cần thông tin xác thực của tài khoản sở hữu vùng, và lệnh thứ hai cần ID vùng từ lệnh thứ nhất. Hãy thay bằng ID của bạn; phần giữ chỗ ở trên cố ý không phải thật.

Vì sao vùng riêng tư thắng

Chính liên kết làm cho vùng hiển thị với một VPC, và resolver trong VPC đó là thứ áp dụng nó. Một vùng riêng tư không liên kết với VPC mà lưu lượng của máy khách đi ra từ đó thì không có tác dụng gì, trong khi liên kết với VPC sai lại tạo câu trả lời riêng tư cho nhóm người sai. Kiểm tra danh sách liên kết trước khi sửa bản ghi, vì một vùng có thể đúng mà vẫn vô hình.

Các không gian tên chồng lấn là nguồn nhầm lẫn thứ hai. Một vùng riêng tư cho example.net và một vùng riêng tư cho api.example.net cùng khớp với một truy vấn API, và cái đặc hiệu hơn trả lời. Điều đó hữu ích khi bạn muốn một không gian tên nội bộ hẹp, và nguy hiểm khi vùng hẹp thiếu bản ghi mà vùng rộng hơn có. Các cân nhắc về vùng lưu trữ riêng tư trong tài liệu Route 53 mô tả cả hành vi rơi xuống lẫn thứ tự ưu tiên của quy tắc, và đáng đọc trước khi bạn thêm vùng chồng lấn thứ hai.

Không điều nào trong số này thay đổi vùng công khai. Các resolver công khai vẫn trả lời đúng các bản ghi công khai, và đó là lý do sự cố trông như vấn đề của máy khách với mọi người bên ngoài VPC.

Chọn không gian tên trước khi thêm bản ghi

Nếu chỉ một nhóm dịch vụ nội bộ mới cần tên riêng tư, hãy cho nó một tên miền con riêng tư chuyên dụng và để yên tên cha công khai. Một tên như internal.example.net không thể che khuất www.example.net, và bán kính ảnh hưởng của một bản ghi thiếu chỉ giới hạn ở những tên bạn tự tạo cho mục đích đó. Cái giá là các URL và chứng chỉ hiện có có thể không khớp với tên mới.

Khi người dùng công khai và riêng tư phải giữ cùng một tên máy chủ, DNS với chế độ xem phân tách là thiết kế được hỗ trợ và nó đòi hỏi bạn duy trì bản ghi trong mỗi chế độ xem một cách rõ ràng. Một vùng riêng tư rộng chỉ có một bản ghi không bảo toàn các phụ thuộc công khai bên dưới vùng đó; nó thay thế chúng bằng một vùng chỉ có một bản ghi.

Kiểm kê các tên mà ứng dụng thực sự gọi trước khi hướng một nhóm máy khách sang chế độ xem riêng tư. Các máy chủ đăng nhập, máy chủ tài sản tĩnh, đích chuyển hướng và điểm cuối API là những thứ hỏng trước tiên, và chúng thường nằm rải rác trong bản ghi của nhiều nhóm.

Theo dõi đường đi của resolver, rồi tới tuyến đường

Máy tính xách tay chỉ thấy chế độ xem riêng tư nếu truy vấn của nó tới được resolver có liên kết. Sửa tệp hosts trên máy chủ VPN không công bố gì cho máy khách đang kết nối, và máy khách cấu hình với resolver công khai sẽ tiếp tục nhận câu trả lời công khai khi đường hầm còn hoạt động. Xác nhận địa chỉ resolver mà máy khách nhận được, rồi lặp lại truy vấn từ máy khách chứ không phải từ máy chủ.

Khi tên đã phân giải, hãy kiểm tra đường đi tới địa chỉ được trả về như một bước riêng, ví dụ với ip route get so với địa chỉ mà truy vấn trả về. Một câu trả lời riêng tư đúng mà không có tuyến tới địa chỉ là vấn đề định tuyến, và câu trả lời thiếu bản ghi là vấn đề chế độ xem DNS; coi chúng là một vấn đề sẽ tạo ra bản sửa không bền. Hãy để nguyên các kiểm tra tên máy chủ TLS và chứng chỉ của dịch vụ, vì địa chỉ riêng tư thay đổi nơi kết nối đi tới chứ không thay đổi điều gì về chứng chỉ nào là hợp lệ.

Kết thúc bằng việc ghi vào ghi chú thay đổi vùng, liên kết, resolver và các tên bạn đã xác minh. Khi đó người tiếp theo thêm bản ghi sẽ biết không gian tên nào có thẩm quyền cho nhóm máy khách đó.

Bài viết liên quan