Bạn dựng máy chủ thứ ba, cần các máy liên lạc với nhau bằng tên thay vì bằng IP, rồi tìm kiếm "private DNS VPS". Ba kết quả trả về và chúng không thống nhất. Một là thiết lập Android mã hóa các truy vấn trên điện thoại của bạn. Một là hướng dẫn cPanel để gắn thương hiệu cho nameserver của một tên miền. Một là tài liệu AWS về private hosted zone. Ngày 20 tháng 7 năm 2026, Cloudflare đã đưa Internal DNS ra bản phát hành chính thức và mô tả nó là "đôi khi cũng được gọi là DNS riêng", nên giờ đây sự trùng lặp tên gọi còn đến từ cả các nhà cung cấp hạ tầng.
Thuật ngữ này bị dùng quá tải. Bài viết này tách bạch các nghĩa khác nhau, rồi tập trung vào nghĩa mạng VPS: một vùng DNS nội bộ cho giao tiếp giữa các máy chủ. Đến cuối bài, bạn có thể xác định mình cần hệ thống nào, quyết định liệu hệ thống máy chủ của bạn có cần DNS riêng hay không, và tránh những sai lầm thiết kế phổ biến.
Tóm tắt nhanh
- "DNS riêng" chỉ ít nhất ba hệ thống không liên quan đến nhau: một vùng DNS nội bộ cho mạng máy chủ, tính năng mã hóa DNS-over-TLS của Android, và các nameserver gắn thương hiệu của cPanel. Bài viết này dùng thuật ngữ theo nghĩa thứ nhất: một vùng DNS nội bộ cho mạng VPS.
- Vùng DNS riêng của VPS là một không gian tên nội bộ giới hạn trong mạng, ánh xạ các tên máy như
db.internal.example.comsang các IP riêng. Bản ghi của nó không được công bố trong DNS công cộng. - Với một vài máy chủ có IP ổn định,
/etc/hostslà thực sự đủ. Một máy chủ DNS nội bộ mới đáng công sức khi hệ thống mở rộng, IP thay đổi liên tục, hoặc các dịch vụ cần phân giải tên đáng tin cậy. - Với hầu hết mạng VPS chạy thật, hãy dùng một tên miền phụ mà bạn sở hữu, chẳng hạn
internal.example.com. Chỉ dùng không gian tên .internal cho một hệ thống tách biệt, nơi bạn chấp nhận được việc trùng tên giữa các mạng, việc quản lý chứng chỉ bằng CA riêng và cách xử lý DNSSEC đặc biệt. Tránh .local, vốn được mDNS giữ chỗ.
Bài viết này không đề cập đến điều gì
Bài viết này chỉ giới hạn ở nghĩa mạng VPS của DNS riêng. Bài không đề cập các cách dùng không liên quan phía người dùng cuối và thương hiệu hosting:
- Cấu hình thiết lập DNS riêng hoặc DNS-over-TLS của Android trên điện thoại.
- Thiết lập nameserver riêng trong cPanel cho một thương hiệu hosting.
- Hướng dẫn cài đặt đầy đủ cho BIND 9, Unbound, dnsmasq hay CoreDNS. Phần triển khai ở đây chỉ dừng ở mức tham khảo, không phải cấu hình từng bước.
- Các resolver mã hóa dành cho người dùng cuối như 1.1.1.1 hay NextDNS, ngoài việc phân biệt chúng với nghĩa mạng.
"DNS riêng" thực sự nghĩa là gì?
"DNS riêng" không phải là một hệ thống duy nhất. Thuật ngữ này chỉ ít nhất ba thứ không liên quan: một vùng DNS giới hạn trong mạng, phân giải tên máy nội bộ bên trong mạng VPS hoặc VPC; tính năng mã hóa DNS-over-TLS của Android; và các nameserver có thẩm quyền mang thương hiệu riêng của cPanel. Bài viết này nói về cái đầu tiên, tức vùng nội bộ mà các máy chủ của bạn truy vấn để tìm thấy nhau. Còn có cách dùng thứ tư lỏng lẻo hơn: các resolver công cộng được mã hóa và tiếp thị là "riêng tư".
Bốn nghĩa này chỉ chung nhau cái tên, ngoài ra không có gì khác:
| Hệ thống | Cái gì là | Ai dùng | Điều nó không làm |
|---|---|---|---|
| Vùng DNS nội bộ (VPS/VPC) | Không gian tên giới hạn trong mạng, phân giải tên máy nội bộ thành IP riêng | Người vận hành VPS, đội DevOps, nền tảng đám mây | Bản thân nó không mã hóa truy vấn và không công bố bản ghi trong DNS công cộng |
| DNS riêng của Android | Một tùy chọn DNS-over-TLS mã hóa các truy vấn của thiết bị trên cổng 853 (từ Android 9) | Người dùng điện thoại và máy tính bảng | Không tạo ra tên máy nội bộ hay vùng riêng |
| Nameserver riêng của cPanel | Nameserver có thẩm quyền mang thương hiệu riêng cho một tên miền (ns1.yourbrand.com) | Nhà cung cấp web hosting và đại lý | Không tạo ra không gian tên riêng cho giao tiếp giữa các máy chủ |
| Resolver mã hóa dành cho người dùng cuối | Các resolver công cộng được tiếp thị vì quyền riêng tư của truy vấn (1.1.1.1, NextDNS) | Cá nhân muốn riêng tư khi tra cứu tên miền | Tự nó không tạo ra vùng có thẩm quyền nội bộ |
Thông báo phát hành chính thức Internal DNS của Cloudflare là một ví dụ được quản lý và cập nhật cho nghĩa thứ nhất, đồng thời là một lý do khiến sự trùng lặp tên gọi trở nên rõ ràng: một nhà cung cấp hạ tầng giờ đây dùng "DNS riêng" như từ đồng nghĩa với DNS nội bộ trong tài liệu ra mắt. Hệ thống mà họ mô tả, gồm Gateway Resolver cùng Internal Authoritative DNS cho khách hàng Enterprise, thuộc đúng loại hệ thống mà bạn tự dựng trên một cụm VPS, chỉ khác là được quản lý sẵn.
Điểm rút ra của phần này: các hệ thống chính được gọi là "DNS riêng" chỉ chung nhau cái nhãn, chứ không chung chức năng. Hãy xác định rõ nghĩa trước khi làm theo bất kỳ hướng dẫn cài đặt nào.
DNS riêng hoạt động thế nào trên mạng VPS?
Vùng DNS riêng của VPS là một không gian tên giới hạn trong mạng, được phục vụ bởi một resolver mà các máy chủ của bạn được cấu hình để sử dụng. Nó ánh xạ các tên máy nội bộ như db.internal.example.com sang các IP riêng trong dải mà bạn kiểm soát. Các bản ghi không được công bố trong DNS công cộng, dù truy vấn có thể đi qua một đường hầm riêng hoặc một control plane DNS được quản lý trước khi tới resolver. Chính sự tách biệt đó là cốt lõi khác biệt giữa DNS riêng và DNS công cộng: giao thức thì giống nhau, nhưng mức độ hiển thị của vùng và phạm vi truy cập thì khác.
Ba thành phần đảm nhiệm công việc này. Một máy chủ có thẩm quyền hoặc nguồn dữ liệu vùng giữ vùng nội bộ cùng các bản ghi của nó. Một resolver trả lời các truy vấn mà máy chủ của bạn gửi đi. Và các bản ghi A cùng AAAA của vùng ánh xạ tên máy nội bộ sang địa chỉ riêng, nên app.internal.example.com trỏ tới tầng ứng dụng, còn db.internal.example.com trỏ tới cơ sở dữ liệu. Các loại bản ghi khác có thể cung cấp bí danh hoặc thông tin dịch vụ. Khi vùng và đường đi tới resolver được cấu hình đúng, resolver sẽ trả lời truy vấn nội bộ ngay tại chỗ thay vì gửi nó lên gốc của DNS công cộng.
Các nền tảng đám mây gắn việc này với mạng thay vì với từng máy, và đó là một mô hình tham chiếu hữu ích. Private hosted zone của AWS Route 53 chỉ hoạt động khi VPC bật cả enableDnsHostnames lẫn enableDnsSupport ở giá trị true, và resolver sẽ trả lời từ vùng riêng cho mọi VPC mà bạn liên kết với nó. Vùng riêng của Google Cloud được giới hạn trong các mạng VPC đã được ủy quyền, và trong thứ tự phân giải tiêu chuẩn của VPC chúng được kiểm tra trước DNS công cộng, trừ khi một chính sách máy chủ đi ra làm thay đổi đường đi. Hãy đọc những ví dụ đó như minh họa cho mô hình, chứ không phải hướng dẫn theo nền tảng: một máy chủ DNS nội bộ do bạn tự quản lý cũng cùng ý tưởng ấy, chỉ là chạy trên VPS của chính bạn.
Giữ vùng đó ngoài DNS công cộng mới chỉ là một nửa công việc. Hãy gắn dịch vụ DNS vào một giao diện mạng riêng, hoặc giới hạn cổng 53 trên cả UDP lẫn TCP chỉ trong mạng riêng hay VPN của bạn. Đừng phơi dịch vụ đệ quy ra internet công cộng; bởi một resolver mở có thể bị lợi dụng trong các cuộc tấn công khuếch đại DNS.
Vùng riêng và vùng công cộng dùng chung một mô hình bản ghi và bộ nhớ đệm DNS. Bản ghi mang giá trị TTL, và các resolver có bộ nhớ đệm thường dùng lại một câu trả lời cho tới khi TTL đó hết hạn, dù thiết lập riêng của từng resolver có thể thay đổi thời gian đệm thực tế. Hành vi này được nói tới trong hướng dẫn trỏ tên miền về VPS của chúng tôi, bao gồm kiến thức cơ bản về lan truyền DNS và TTL, nên ở đây không giải thích lại.
Khi nào mạng VPS của bạn thực sự cần DNS riêng?
Với hai hoặc ba máy chủ tĩnh, /etc/hosts là thực sự đủ. Một máy chủ DNS nội bộ mới đáng công sức khi hệ thống mở rộng, IP thay đổi thường xuyên, hoặc ứng dụng cần cơ chế khám phá dịch vụ đáng tin cậy. Yếu tố quyết định thực sự là độ phức tạp vận hành, chứ không phải một con số máy chủ cố định.
/etc/hosts là một bảng ánh xạ tĩnh từ tên máy sang IP, vốn đã có sẵn trên mọi máy Linux. Nó không cần daemon hay tệp vùng, nhưng các bản sao cũ hoặc lệch nhau là những kiểu hỏng rất thật. Hãy thêm IP riêng của từng máy chủ vào tệp này, giữ các bản sao đồng bộ, và các máy sẽ tìm thấy nhau bằng tên. Với một cụm máy nhỏ và ổn định thì đó là câu trả lời đúng, còn với tay sang BIND 9 chỉ thêm một daemon phải bảo trì mà chẳng được gì.
Cách này hết đường xoay xở trong ba tình huống. Khi bạn thêm và bớt máy chủ liên tục, việc giữ một tệp tĩnh nhất quán trên mọi máy trở thành công việc thủ công mệt mỏi. Khi IP thay đổi vì tự động mở rộng, dựng lại máy, hay nhà cung cấp cấp phát lại, tệp đó lặng lẽ trở nên lỗi thời. Và khi container hoặc môi trường chạy tách biệt không thừa hưởng các mục của máy chủ, ánh xạ ấy thôi không còn phổ quát. Chỉ cần một trong số đó là đã có yếu tố quyết định thực sự. Riêng số lượng máy chủ chỉ là phép ước lượng thô, không phải tín hiệu thật.
Điểm rút ra của phần này: yếu tố quyết định là mức độ biến động vận hành, chứ không phải số lượng máy chủ. Một cụm mười máy đứng yên hoàn toàn có thể sống với /etc/hosts; còn một cụm ba máy dựng lại mỗi đêm thì có lẽ không nên.
Xây dựng trên VPS Linux với quyền root, NVMe và sức mạnh AMD EPYC.
Xem các gói LinuxNên chạy máy chủ DNS nào: BIND 9, Unbound, dnsmasq hay CoreDNS?
Hãy chọn theo hình dạng hệ thống của bạn. dnsmasq hợp với những mạng nhỏ muốn một DNS nhẹ và, khi cần, cả DHCP từ cùng một daemon. Unbound là một resolver đệ quy gọn nhẹ có kiểm định, đồng thời trả lời được một vùng cục bộ khiêm tốn. BIND 9 mang lại năng lực có thẩm quyền lẫn đệ quy rộng nhất, kèm bề mặt cấu hình lớn nhất. CoreDNS hợp với các hệ thống container và Kubernetes, nơi DNS là một phần của việc khám phá dịch vụ.
| Công cụ | Vai trò | Tốt nhất cho | Đánh đổi |
|---|---|---|---|
| BIND 9 | Đầy đủ cả có thẩm quyền lẫn đệ quy | Hệ thống cần chức năng DNS rộng và kho tài liệu tham khảo dồi dào | Bề mặt cấu hình rộng nhất và độ phức tạp vận hành cao nhất |
| Unbound | Resolver đệ quy hoặc chuyển tiếp, có hỗ trợ vùng cục bộ và kiểm định DNSSEC | Hệ thống nhỏ cần đệ quy cùng một vùng nội bộ tĩnh khiêm tốn | Dữ liệu vùng cục bộ thì đơn giản; hành vi có thẩm quyền phức tạp nên xử lý qua auth-zone hoặc một máy chủ có thẩm quyền riêng |
| dnsmasq | DNS nhẹ kèm luôn DHCP | Cụm máy nhỏ và tĩnh, hoặc mạng kiểu LAN cần thêm cả DHCP | Ít tính năng hơn khi hệ thống và vùng lớn dần |
| CoreDNS | Máy chủ DNS dựa trên plugin | Hệ thống dùng container, Kubernetes và nặng về khám phá dịch vụ | Linh hoạt, nhưng hành vi phụ thuộc vào chuỗi plugin bạn cấu hình |
Logic chọn lựa rất ngắn. Nếu bạn cần một resolver nhỏ dựa trên tệp kiểu hosts, hoặc dù sao cũng đang cấp phát DHCP, dnsmasq giúp bớt đi một bộ phận phải trông coi. Nếu điều bạn cần chủ yếu là một resolver có kiểm định, chuyển tiếp ra ngoài và trả lời một vùng nội bộ khiêm tốn, Unbound cung cấp đúng tập tính năng hẹp đó mà không cần triển khai đầy đủ BIND 9. Nếu bạn cần toàn quyền có thẩm quyền, khả năng ủy quyền, và kho tài liệu lớn nhất để bấu víu lúc ba giờ sáng, BIND 9 vẫn là lựa chọn an toàn dù bề mặt cấu hình rộng hơn. Nếu DNS vốn đã là một phần của ngăn xếp khám phá dịch vụ trên container hay Kubernetes, CoreDNS gặp nó ngay tại đó. Quy tắc chung: chạy thứ nhỏ nhất đủ bao được hình dạng hệ thống của bạn.
Với hệ thống chạy thật, đừng để một thực thể DNS duy nhất là con đường duy nhất tới mọi tên nội bộ. Hãy chạy ít nhất hai thực thể DNS có thể trả lời cho vùng đó, đặt chúng ở những miền hỏng hóc tách biệt khi khả thi, và cấu hình cho máy khách tiếp cận được cả hai. Nếu không, chỉ một sự cố DNS cũng đủ khiến các dịch vụ đang khỏe mạnh trông như đã chết.
Nên đặt tên miền nội bộ thế nào: .internal, .local hay một tên miền phụ?
Với hầu hết mạng VPS chạy thật, hãy dùng một tên miền phụ mà bạn sở hữu, chẳng hạn internal.example.com. Chỉ dùng không gian tên .internal cho một hệ thống tách biệt, nơi bạn chấp nhận được việc trùng tên giữa các mạng, việc quản lý chứng chỉ bằng CA riêng và cách xử lý DNSSEC đặc biệt. Tránh .local, vốn được mDNS giữ chỗ.
Vấn đề của .local rất cụ thể. RFC 6762 dành cho các tên kết thúc bằng .local một cách xử lý riêng trong Multicast DNS, nên một vùng unicast trên BIND 9 hay Unbound dùng cùng hậu tố có thể xung đột với hành vi mDNS trên thiết bị Apple và các hệ thống bật mDNS khác. Hãy dùng một không gian tên khác thay vì trông cậy vào các cách chữa cháy riêng cho từng máy khách.
Mẹo: Nếu bạn thừa hưởng một vùng nội bộ .local, hãy coi nó là nợ kỹ thuật. Một số máy khách gửi truy vấn .local tới mDNS thay vì tới máy chủ DNS unicast của bạn, điều này có thể tạo ra những lỗi khác nhau tùy máy khách hoặc trông như chập chờn.
Hội đồng quản trị ICANN đã giữ chỗ vĩnh viễn cho .internal khỏi việc ủy quyền trong gốc DNS công cộng vào tháng 7 năm 2024, sau một khuyến nghị trước đó của SSAC. Theo thiết kế, các tên nằm dưới nó sẽ không phân giải được qua DNS toàn cầu. Đi kèm là những đánh đổi: tên .internal không duy nhất trên toàn cầu, các tổ chức chứng thực công cộng không được kỳ vọng cấp chứng chỉ cho chúng, và các resolver kiểm định DNSSEC dựa trên neo tin cậy toàn cầu sẽ không phân giải được. Nếu bạn cần HTTPS trên .internal, hãy tính đến việc tự vận hành một CA riêng.
Ở đây cần tách bạch hai chuyện. Quyết định giữ chỗ của ICANN là chung cuộc. Tách biệt với nó là một Internet-Draft đang hoạt động, draft-davies-internal-tld-06, công bố ngày 6 tháng 5 năm 2026 nhằm ghi lại không gian tên này và so sánh nó với cách đánh địa chỉ riêng theo RFC 1918. Nó vẫn là một Internet-Draft đang trong quá trình soạn thảo chứ chưa phải RFC đã ban hành, nên hãy mô tả .internal là một TLD dùng riêng do ICANN giữ chỗ, không phải một chuẩn của IETF.
Với hầu hết các cụm VPS, một tên miền phụ thuộc tên miền bạn kiểm soát là lựa chọn mặc định an toàn hơn. ISC khuyến nghị dùng cấu trúc phân cấp tên miền phụ, chẳng hạn một tên miền phụ nội bộ thuộc tên miền của chính bạn, thay vì duy trì hai phiên bản tách rời và thiếu sót của cùng một vùng cha, một cho nội bộ và một cho công cộng. Đây không phải chuyện phong cách: nó ngăn đúng cái lỗi ở phần tiếp theo.
Điểm rút ra của phần này: quyết định về không gian tên sẽ theo bạn rất lâu. Một tên miền phụ do bạn kiểm soát là mặc định cho hầu hết môi trường chạy thật, vì nó giữ được tính duy nhất toàn cầu và hoạt động với PKI công cộng. Hãy dùng .internal khi một không gian tên riêng tách biệt phù hợp hơn và bạn chấp nhận những đánh đổi về DNSSEC, chứng chỉ và trùng tên của nó.
DNS split-horizon và những sai lầm làm hỏng nó
DNS split-horizon trả về câu trả lời khác nhau cho cùng một tên máy tùy vào ai hỏi: IP riêng từ bên trong, IP công cộng từ bên ngoài. Nó hỏng nhiều nhất là do bẫy NXDOMAIN trong cùng một tên miền, các resolver thay thế đi vòng qua khung nhìn dự định, và những đường DNS trong container không tới được máy chủ trên dòng như mong đợi. Làm đúng chuyện này phụ thuộc vào ba thứ cùng lúc, chứ không phải một.
Bẫy NXDOMAIN chính là kiểu hỏng mà ISC cảnh báo trực tiếp. Nếu các máy chủ nội bộ của bạn có thẩm quyền với tên miền cha, nhưng bản vùng trên đó lại thiếu một bản ghi công cộng như máy www, thì một máy khách nội bộ truy vấn tên ấy sẽ nhận NXDOMAIN dù vùng công cộng vẫn có bản ghi đó. Vùng nội bộ đang giữ thẩm quyền và không quay lại hỏi DNS công cộng cho tên miền cha. Đây đúng là lý do vì sao cách phân cấp tên miền phụ ở phần đặt tên lại là thiết kế mà ISC ưa dùng.
Mẹo: Trước khi trỏ máy chủ của bạn vào một cấu hình split-horizon trên cùng một tên miền, hãy thử phân giải một tên công cộng quen thuộc của tên miền đó từ bên trong mạng. Nhận về NXDOMAIN cho một tên vốn phân giải bình thường từ bên ngoài chính là dấu hiệu của cái bẫy này.
Còn ba cái bẫy nữa rất dễ bỏ sót. Một resolver thay thế được cấu hình trên máy chủ hoặc trong container có thể đi vòng qua sự phân tách này; tùy cách resolver được cài đặt, nó có thể bị hỏi sau khi hết thời gian chờ hoặc bị hỏi song song, nên câu trả lời có thể khác nhau. Container trên bridge mặc định của Docker nhận một bản sao cấu hình DNS của máy chủ khi khởi động, còn container trên các mạng tùy chỉnh thì hỏi resolver tích hợp của Docker tại 127.0.0.11. Resolver đó chuyển tiếp các truy vấn ra ngoài tới những máy chủ DNS đã cấu hình cho máy chủ hoặc container, nên hành vi split-DNS phụ thuộc vào cấu hình của Docker và máy chủ chứ không chỉ riêng tệp resolver bên trong container. Nếu một dịch vụ nội bộ nằm sau một reverse proxy như Trình quản lý Proxy Nginx, việc kiểm định chứng chỉ có thể thất bại khi chứng chỉ không bao gồm tên máy được yêu cầu, hoặc khi máy khách không tin cậy CA đã cấp nó. Chỉ riêng việc dùng một chứng chỉ khác ở bên trong thì không phải là lỗi. Đây là những lỗ hổng cấu hình, không phải lỗi của công cụ.
Máy khách từ xa cũng có thể gặp đúng lỗi này khi một VPN tự vận hành không đẩy hoặc định tuyến các truy vấn DNS tới resolver nội bộ đã định.
Còn có khía cạnh bảo mật nữa. Nếu tên máy nội bộ và IP riêng rò rỉ vào các bản ghi DNS công cộng, bạn đã phơi một phần sơ đồ đặt tên và đánh địa chỉ nội bộ cho bất kỳ ai truy vấn. Split-horizon tồn tại một phần là để giữ tấm bản đồ đó ở bên trong, và một vùng công cộng cấu hình sai sẽ lặng lẽ phá bỏ điều đó.
Điểm rút ra của phần này: những trục trặc của split-horizon là bẫy cấu hình, không phải khiếm khuyết của công cụ. Sự đúng đắn phụ thuộc vào kỷ luật đặt tên, vào việc biết mỗi máy khách thực sự hỏi resolver nào, và vào việc khoanh vùng cho đúng, chứ không nằm ở một thiết lập đơn lẻ nào.
Kết luận: Chọn thiết kế DNS riêng phù hợp
Giờ bạn đã phân biệt được mình thực sự đang nói tới hệ thống "DNS riêng" nào. Với mạng VPS, đó là vùng DNS nội bộ, chứ không phải thiết lập DNS-over-TLS của Android hay các nameserver có thẩm quyền gắn thương hiệu. Nếu hệ thống của bạn nhỏ và ổn định, /etc/hosts vẫn là một lựa chọn có thể bảo vệ được. Nếu không, hãy dùng một tên miền phụ do bạn sở hữu làm không gian tên mặc định, chọn máy chủ DNS nhỏ nhất vừa với hệ thống, và giữ cho quyền truy cập, dự phòng cùng ranh giới vùng nội bộ so với công cộng thật rõ ràng. Chỉ dùng .internal khi một không gian tên tách biệt phù hợp hơn và bạn chấp nhận những đánh đổi về chứng chỉ, DNSSEC và trùng tên của nó.
Câu hỏi thường gặp
DNS riêng của Android có giống máy chủ DNS riêng trên VPS không?
Không. DNS riêng của Android là một tính năng DNS-over-TLS (mã hóa truy vấn trên cổng 853, có từ Android 9) nhằm bảo vệ truy vấn của thiết bị khi truyền đi. Máy chủ DNS riêng trên VPS thì phân giải tên máy nội bộ thành IP riêng trong phạm vi một mạng. Một bên mã hóa truy vấn, bên kia tạo ra không gian tên nội bộ. Chúng giải quyết những vấn đề không liên quan.
DNS riêng khác DNS công cộng ở chỗ nào?
DNS riêng chỉ mở một vùng cho những máy khách được phép trong một mạng, một VPN hay một môi trường đám mây cụ thể. DNS công cộng thì công bố các bản ghi mà mọi resolver trên internet đều truy vấn được. Cả hai dùng cùng những loại bản ghi DNS và cùng mô hình bộ nhớ đệm; khác nhau ở chỗ ai chạm tới được vùng đó và bản ghi của nó hiển thị ở đâu.
DNS riêng khác DNS mã hóa ở chỗ nào?
Các giao thức DNS mã hóa như DoT và DoH bảo vệ truy vấn DNS khi truyền đi. DNS riêng theo nghĩa mạng thì tạo ra một không gian tên giới hạn trong mạng dành cho các tên nội bộ. Mã hóa thay đổi cách một truy vấn di chuyển; còn vùng riêng thay đổi những tên nào tồn tại và ai phân giải được chúng.
Dùng .internal cho tên máy nội bộ có an toàn không?
Có, nhưng kèm điều kiện. ICANN đã vĩnh viễn loại .internal khỏi việc ủy quyền công cộng vào tháng 7 năm 2024, nên bạn có thể phục vụ nó trên một resolver riêng. Tuy vậy, nó không duy nhất trên toàn cầu, các tổ chức chứng thực công cộng không được kỳ vọng cấp chứng chỉ cho nó, và những bộ kiểm định DNSSEC dựa vào neo tin cậy toàn cầu sẽ không phân giải được. Với hầu hết mạng VPS chạy thật, một tên miền phụ do bạn sở hữu là mặc định an toàn hơn.
Bản ghi DNS riêng có dùng cùng TTL và cách lưu đệm như DNS công cộng không?
Có. Vùng riêng và vùng công cộng dùng chung mô hình lưu đệm dựa trên TTL: bản ghi mang giá trị TTL, và các resolver có bộ nhớ đệm thường dùng lại câu trả lời cho tới khi giá trị ấy hết hạn. Thiết lập riêng của từng resolver vẫn có thể thay đổi thời gian đệm thực tế. Xem lan truyền DNS và cách hoạt động của TTL để hiểu cơ chế bên dưới.
Thảo luận
Bình luận
Đăng nhập để tham gia thảo luận.