DNS riêng của Azure qua VPN: điểm cuối resolver hay forwarder
Cả hai thiết kế đều trả lời các vùng riêng qua đường hầm. Hãy so sánh điểm cuối vào được quản lý với một VM forwarder, rồi kiểm tra đường đi phải tồn tại trong cả hai trường hợp.
Một máy chủ tại chỗ truy cập VM Azure bằng địa chỉ riêng nhưng vẫn không phân giải được tên máy chủ riêng của nó, khiến người ta đi tìm một đường hầm hỏng. Đường hầm vẫn tốt. Cái thiếu là một ranh giới DNS: không gì ở phía tại chỗ biết rằng một vùng riêng cụ thể của Azure phải được một resolver bên trong VNet trả lời. Hai thiết kế lấp khoảng trống đó, và chúng khác nhau ở thứ bạn vận hành cuối cùng, không phải ở việc các truy vấn có hoạt động hay không.
Đường hầm chở truy vấn, không chở hiểu biết về vùng
Kết nối site-to-site cho các gói tin một tuyến đường giữa hai mạng. Nó không nói cho máy chủ DNS tại chỗ biết không gian tên nào thuộc Azure hay địa chỉ nào phải trả lời, nên truy vấn hoặc đi ra internet và quay về rỗng, hoặc không bao giờ rời resolver cục bộ.
Bản sửa có hai nửa dễ tách. Một nửa là resolver bên trong VNet nhận các truy vấn đến qua đường hầm. Nửa kia là forwarder có điều kiện ở phía tại chỗ gửi đúng một không gian tên tới resolver đó. Không nửa nào tự hoạt động.
Giả sử vùng là cloud.corp.example cho phần còn lại của giải thích này, và coi mọi địa chỉ là ví dụ.
Tùy chọn A: điểm cuối vào được quản lý
Azure DNS Private Resolver cung cấp một điểm cuối vào nhận truy vấn DNS từ bên ngoài VNet. Bạn triển khai nó trong một subnet được ủy quyền riêng, liên kết vùng riêng với VNet đó và ghi lại địa chỉ vào mà dịch vụ gán.
Trên máy chủ DNS tại chỗ, bạn tạo forwarder có điều kiện cho đúng không gian tên hướng tới địa chỉ đó:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Quy trình DNS lai của Microsoft ghi lại cả liên kết vùng và bước forwarder. Đường được quản lý không để lại phần mềm DNS nào phải vá, và địa chỉ điểm cuối vẫn ổn định trong suốt vòng đời tài nguyên.
Cái giá là bạn giờ sở hữu một tài nguyên resolver, ủy quyền subnet và chi phí của nó, những thứ có thật ngay cả khi lượng truy vấn rất nhỏ.
Tùy chọn B: một VM forwarder bên trong VNet
Thiết kế cũ chạy phần mềm DNS trên một VM thông thường trong VNet: Windows DNS, BIND hoặc dnsmasq, với vùng riêng hoặc lưu trữ cục bộ hoặc chuyển tiếp tới resolver của Azure tại 168.63.129.16. Forwarder có điều kiện tại chỗ trỏ tới địa chỉ riêng của VM đó.
Tùy chọn này quen thuộc với các nhóm đã vận hành máy chủ DNS, và có thể mang thêm logic như ghi log hoặc câu trả lời split-horizon. Nó cũng thừa hưởng mọi nghĩa vụ vận hành của một máy chủ DNS: vá lỗi, phiên bản thứ hai để sẵn sàng, giám sát và đường dựng lại khi VM bị thay và địa chỉ của nó thay đổi.
Một máy chủ VNet thông thường không phải proxy DNS cho tới khi dịch vụ được cài và được phép trả lời các máy khách đó, và đó chính là bước người ta bỏ qua khi nhân bản một VM.
Cái nào hợp với vận hành của bạn
So sánh không phải về thiết kế nào nhanh hơn. Mà là bạn có muốn vận hành phần mềm DNS hay không, và lượng truy vấn có biện minh cho một tài nguyên được quản lý tính phí theo điểm cuối và theo truy vấn hay không.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Dù hàng nào quyết định, quy tắc forwarder tại chỗ vẫn như nhau. Đây là phần phải tồn tại trong cả hai thiết kế, và cũng là phần hay thiếu nhất khi ai đó báo rằng phân giải hoạt động từ bên trong Azure nhưng không từ văn phòng.
Kiểm tra đường đi theo thứ tự
Xác nhận vùng được liên kết với VNet chứa resolver, và forwarder tại chỗ nêu không gian tên chứ không phải miền cha. Một forwarder cho corp.example sẽ không khớp với cloud.corp.example trừ khi chính resolver ủy quyền, và sự không khớp tạo ra một câu trả lời phủ định sạch sẽ trông như bản ghi bị thiếu.
Sau đó kiểm tra truy vấn có tới điểm cuối không: nguồn tại chỗ cần tuyến đường tới địa chỉ resolver và đường quay về, và cổng 53 cho cả UDP lẫn TCP nên được cho phép ở nơi chính sách cho phép. NSG không thể cung cấp bản ghi vùng bị thiếu, và một vùng đúng cũng không thể trả lời truy vấn không bao giờ tới.
Giữ FQDN được yêu cầu bên cạnh resolver bạn chọn khi chẩn đoán, và tách một lần hết thời gian chờ khỏi một câu trả lời phủ định. Hết thời gian chờ là vấn đề tuyến đường hoặc chính sách. Câu trả lời phủ định nghĩa là truy vấn đã tới và không gian tên không khớp. Thứ tự công việc: liên kết vùng, thêm forwarder có điều kiện, mở cổng 53 cả hai chiều, thử một tên từ tại chỗ, và chỉ sau đó mới xem quyền của chính ứng dụng.