Đặt tên một rừng Active Directory mới - tại sao DNS chia tách không được khuyến nghị?

Hy vọng rằng tất cả chúng ta đều biết các đề xuất để đặt tên một rừng Active Directory là gì và chúng khá đơn giản. Cụ thể, nó có thể được tóm tắt trong một câu duy nhất.

Sử dụng tên miền phụ của một tên miền đã đăng ký, hiện có và chọn một tên miền sẽ không được sử dụng bên ngoài. Ví dụ: nếu tôi kết hợp và đăng ký hopelessn00b.comtên miền, rừng AD nội bộ của tôi sẽ được đặt tên internal.hopelessn00b.comhoặc ad.hopelessn00b.comhoặc corp.hopelessn00b.com.

Có rất nhiều lý do thuyết phục để tránh sử dụng tên miền "giả" hoặc tên miền nhãn đơn , nhưng tôi gặp khó khăn khi tìm lý do thuyết phục tương tự để tránh sử dụng tên miền gốc ( hopelessn00b.com) làm tên miền của mình và sử dụng tên miền phụ như corp.hopelessn00b.comthay thế . Thực sự, lời biện minh duy nhất tôi dường như có thể tìm thấy là việc truy cập trang web bên ngoài từ nội bộ yêu cầu A namebản ghi DNS và nhập www.trước tên trang web trong trình duyệt, điều này khá "meh" khi có vấn đề.

Vì vậy, tôi đang thiếu gì? Tại sao nó lại tốt hơn nhiều khi sử dụng ad.hopelessn00b.comlàm tên rừng Active Directory của tôi hopelessn00b.com?

Chỉ để ghi lại, đó thực sự là chủ nhân của tôi cần phải thuyết phục - ông chủ đang bán hàng rong và sau khi cho tôi đi trước để tạo một khu rừng AD mới được đặt tên corp.hopelessn00b'semployer.comcho mạng nội bộ của chúng tôi, anh ta muốn gắn bó với một khu rừng AD có tên hopelessn00b'semployer.com( giống như tên miền được đăng ký bên ngoài của chúng tôi). Tôi hy vọng rằng tôi có thể có được một số lý do hoặc lý do thuyết phục rằng thực tiễn tốt nhất là lựa chọn tốt hơn, vì vậy tôi có thể thuyết phục anh ấy về điều đó ... bởi vì nó có vẻ dễ dàng hơn việc bỏ cơn thịnh nộ và / hoặc tìm một công việc mới, ít nhất là cho khoảnh khắc. Ngay bây giờ, "Microsoft thực hành tốt nhất" và truy cập nội bộ trang web công cộng cho công ty của chúng tôi dường như không cắt giảm, và tôi thực sự , thực sự , thực sự hy vọng ai đó ở đây có điều gì đó thuyết phục hơn.

Rất nhiều đại diện để có được. Hãy đến với tôi quý giá.

Ok, do đó, tài liệu khá hay của Microsoft rằng bạn không nên sử dụng đường chân trời hoặc TLD được tạo thành như bạn đã liên kết với nhiều lần (hét to với blog của tôi!). Có một vài lý do cho việc này.

1. Các wwwvấn đề mà bạn đã chỉ ra ở trên. Khó chịu, nhưng không phải là một thỏa thuận phá vỡ.

2. Nó buộc bạn phải duy trì các bản ghi trùng lặp cho tất cả các máy chủ công khai cũng có thể truy cập được trong nội bộ, không chỉ www. mail.hopelessnoob.comlà một ví dụ phổ biến. Trong một kịch bản lý tưởng, bạn sẽ có một mạng vành đai riêng cho những thứ như mail.hopelessnoob.comhoặc publicwebservice.hopelessnoob.com. Với một số cấu hình, như một ASA với nội bộ và bên ngoài giao diện , bạn có nhu cầu bên trong-bên NAT hoặc split-horizon DNS nào nhưng đối với các tổ chức lớn hơn với một mạng vành đai hợp pháp nơi tài nguyên web phải đối mặt với bạn không phải là đằng sau một ranh giới NAT kẹp tóc - Điều này gây ra công việc không cần thiết.

3. Hãy tưởng tượng kịch bản này - Bạn đang ở hopelessnoob.combên trong và bên ngoài. Bạn có một công ty mà bạn đang hợp tác với example.comhọ được gọi và họ làm điều tương tự - chia tách chân trời nội bộ với AD của họ và với không gian tên DNS có thể truy cập công khai của họ. Bây giờ, bạn định cấu hình VPN giữa các trang và muốn xác thực nội bộ để tin tưởng đi qua đường hầm trong khi có quyền truy cập vào các tài nguyên công cộng bên ngoài của họ để truy cập Internet. Điều đó là không thể nếu không có định tuyến chính sách phức tạp không thể tin được hoặc giữ bản sao của vùng DNS bên trong của riêng bạn - bây giờ bạn vừa tạo một bộ bản ghi DNS bổ sung để duy trì. Vì vậy, bạn phải đối phó với kẹp tóc ở cuối của bạn vàkết thúc của họ, định tuyến chính sách / NAT và tất cả các loại mánh khóe khác. (Tôi thực sự đã ở trong tình huống này với một AD mà tôi được thừa hưởng).

4. Nếu bạn đã từng triển khai DirectAccess , nó sẽ đơn giản hóa đáng kể các chính sách phân giải tên của bạn - điều này cũng có thể đúng với các công nghệ VPN đường hầm phân tách khác.

Một số trong số này là trường hợp cạnh, một số thì không, nhưng tất cả đều dễ dàng tránh được. Nếu bạn có khả năng làm điều này ngay từ đầu, cũng có thể thực hiện đúng cách để bạn không gặp phải một trong những điều này trong một thập kỷ.

Tuyên bố này: "Thực sự, lời biện minh duy nhất tôi dường như có thể tìm thấy là việc truy cập trang web bên ngoài từ bên trong yêu cầu bản ghi DNS SRV và nhập www. Trước tên trang web trong trình duyệt" là không đúng.

Điều đó có nghĩa là bạn cần giữ một bản sao của tất cả các hồ sơ công khai trong các máy chủ AD DNS của mình, điều này có thể gây ra sự cố, đặc biệt là nếu bạn không thực hiện đúng cách - bỏ lỡ một số, v.v. Nếu ai đó muốn truy cập ftp.company. nhưng bạn quên tạo bí danh trong DNS nội bộ (hoặc không tự động hóa nó đúng cách), mọi người trong nhà không thể truy cập trang FTP công cộng.

Điều này khá rõ ràng trong câu hỏi bạn liên kết đến: Windows Active Directory đặt tên thực tiễn tốt nhất?

Nếu việc duy trì nhiều bản sao của các vùng DNS của bạn là một vấn đề dễ dàng để bạn giải quyết chính xác, mãi mãi, thì tôi cho rằng bạn có thể làm những gì bạn muốn. Cho đến khi MS thay đổi một cái gì đó phá vỡ nó. Bạn chỉ có thể làm theo khuyến nghị của họ.

Tôi không quan tâm đầy đủ về đại diện để tạo ra một câu trả lời dài ngày hôm nay ... vì vậy tôi sẽ giữ nó ngắn gọn.

Tôi đã từng rất ổn với split-dns và thực hiện nó nhiều lần cho đến khi Evan và Mark thuyết phục tôi bằng cách khác. Thành thật KHÔNG phải là nó không thể được thực hiện ... nó có thể, và một số có thể vẫn ổn với nó (mặc dù chi phí chung và công việc được thực hiện cho nó).

Hai điều cụ thể đã xuất hiện từ nhiều năm trước đối với tôi mà kiên cố KHÔNG sử dụng nó:

1. Giống như bạn đã chỉ ra trong câu hỏi của mình, bạn chỉ đơn giản là không thể cho phép người dùng nội bộ truy cập trang web bên ngoài của bạn chỉ bằng tên miền. Đừng hỏi tại sao đó lại là một vấn đề lớn như vậy, nhưng chúng tôi đã có những người dùng nội bộ sẽ nhận được rằng chỉ gõ tên miền vào trình duyệt mà wwwkhông hiển thị trang web thực tế, vì bản ghi tên miền tương ứng với tên miền AD và không phải là tất cả để có được wwwvà không thể nội bộ.
2. Sự cố trao đổi - Exchange AutoDiscover có thể không nhận được certs và sẽ nhắc lỗi. Điều này có thể xảy ra cả bên trong VÀ bên ngoài. Điều này càng trở nên rõ ràng hơn khi chúng tôi bắt đầu có "Hộp thư bên ngoài rừng" trên Exchange Org của chúng tôi và họ không thấy DNS bên trong giống như chúng tôi có.

Mong rằng sẽ giúp.