Lưu ý: Tên các nhà cung cấp và dịch vụ được nhắc đến trong bài (như AWS Route 53, Mắt Bão, Cloudflare, Akamai…) chỉ nhằm mục đích ví dụ minh họa, không phải đánh giá, so sánh hay khuyến nghị sử dụng dịch vụ của bên nào.
DNS là gì? DNS (Domain Name System, hệ thống tên miền) là hệ thống phân giải tên miền dễ nhớ như kainetworks.vn thành địa chỉ IP như 103.x.x.x để thiết bị biết phải gửi gói tin đến đâu. Nếu bạn đang học CCNA, DNS xuất hiện trong phần IP Services và là dịch vụ bạn gặp mỗi lần mở một trang web. Bài này giải thích DNS là gì, nguyên lý hoạt động từng bước, dịch vụ DNS thuê từ nhà cung cấp (bản chất và các tính năng cần biết), và vì sao một sự cố DNS có thể làm hàng trăm dịch vụ ngừng hoạt động cùng lúc.
DNS là gì? Định nghĩa dễ hiểu
DNS là một cơ sở dữ liệu phân tán toàn cầu, lưu ánh xạ giữa tên (hostname, domain name) và thông tin tài nguyên như địa chỉ IPv4, IPv6, mail server. Thay vì một máy chủ duy nhất giữ toàn bộ dữ liệu, DNS chia thành nhiều tầng và nhiều máy chủ, mỗi nơi chỉ chịu trách nhiệm một phần.
Cách dễ hình dung là danh bạ điện thoại. Bạn nhớ tên “Minh”, điện thoại cần số. Danh bạ đổi tên thành số giúp bạn gọi được. DNS làm đúng việc đó cho Internet: bạn gõ tên, DNS trả về địa chỉ IP, rồi trình duyệt mới kết nối tới IP đó qua TCP hoặc UDP.
Về giao thức, DNS chạy trên UDP cổng 53 cho truy vấn thông thường và TCP cổng 53 khi bản tin lớn hơn hoặc khi đồng bộ vùng giữa các server (zone transfer). Đây là chi tiết thường gặp trong đề thi và khi viết ACL.
Tại sao cần DNS?
DNS giải quyết ba vấn đề thực tế mà nếu thiếu nó, Internet gần như không dùng được:
- Con người nhớ tên, máy dùng số. Không ai nhớ nổi hàng nghìn địa chỉ IP, trong khi một cái tên như
google.comthì dễ nhớ. Địa chỉ IPv6 dài 128 bit còn khó nhớ hơn nhiều. - IP có thể thay đổi, tên thì giữ nguyên. Khi bạn chuyển website sang server mới hoặc sang nhà cung cấp cloud khác, chỉ cần sửa bản ghi DNS. Người dùng vẫn gõ cùng một tên miền.
- Một tên có thể trỏ tới nhiều máy chủ. DNS cho phép trả về nhiều IP hoặc trả IP gần người dùng nhất. Đây là nền tảng của cân bằng tải và failover ở tầng DNS.
Ngoài ra, DNS không chỉ phục vụ web. Email dựa vào bản ghi MX để biết gửi thư tới đâu. Các cơ chế chống giả mạo email như SPF, DKIM, DMARC cũng lưu trong bản ghi TXT. Nói cách khác, gần như mọi dịch vụ Internet đều đi qua DNS trước khi bắt đầu kết nối thật sự.
Các thành phần chính của hệ thống DNS
DNS có cấu trúc phân cấp dạng cây. Đọc một tên miền từ phải sang trái là đi từ gốc xuống ngọn: trong www.kainetworks.vn., dấu chấm cuối cùng là root, vn là TLD, kainetworks là domain, www là host. Mỗi tầng chỉ biết tầng ngay dưới nó: root biết server của từng TLD, TLD biết server của từng domain, và authoritative server của domain biết bản ghi cụ thể.
| Thành phần | Vai trò | Ví dụ |
|---|---|---|
| DNS client (stub resolver) | Phần mềm trên PC, điện thoại gửi truy vấn ban đầu | Trình duyệt, hệ điều hành |
| Recursive resolver | Nhận truy vấn từ client, đi hỏi các server khác thay client và lưu cache | DNS của ISP, 8.8.8.8, 1.1.1.1 |
| Root name server | Biết server nào quản lý từng TLD. Có 13 địa chỉ root (A đến M), mỗi địa chỉ được nhân bản bằng anycast | a.root-servers.net |
| TLD name server | Quản lý các domain dưới một TLD | Server của .com, .vn, .org |
| Authoritative name server | Giữ bản ghi gốc của domain và trả lời chính thức | Route 53, DNS của Mắt Bão, Cloudflare |
Hai khái niệm cần phân biệt rõ khi ôn CCNA: recursive resolver là bên đi tìm câu trả lời giúp bạn, còn authoritative server là bên giữ câu trả lời.
Nguyên lý hoạt động của DNS: quá trình phân giải tên miền
Giả sử bạn gõ www.kainetworks.vn vào trình duyệt và chưa có gì nằm trong cache. Quá trình phân giải diễn ra như sau:
- Kiểm tra cache cục bộ. Trình duyệt, hệ điều hành và file
hostsđược xem trước. Nếu đã có IP, quá trình dừng tại đây. - Gửi truy vấn tới recursive resolver. PC gửi một truy vấn recursive (“hãy trả lời giúp tôi”) tới DNS server đã cấu hình, thường do ISP hoặc router cấp qua DHCP.
- Resolver hỏi root server. Nếu cache của resolver không có, nó hỏi root. Root không biết IP của
www.kainetworks.vnnhưng trả về địa chỉ các name server của TLD.vn. - Resolver hỏi TLD server. Server
.vntrả về danh sách authoritative name server của domainkainetworks.vn(bản ghi NS). - Resolver hỏi authoritative server. Đây là nơi giữ bản ghi thật. Nó trả về địa chỉ IP của
www.kainetworks.vncùng giá trị TTL. - Trả kết quả và lưu cache. Resolver trả IP cho PC và lưu vào cache trong thời gian TTL. PC cũng cache lại, rồi mới mở kết nối tới IP đó.
Ở các bước 3 đến 5, resolver dùng truy vấn iterative: mỗi server không tự đi hỏi tiếp mà chỉ “giới thiệu” server tiếp theo, resolver tự đi tiếp. Kết hợp lại, client gửi truy vấn recursive, resolver thực hiện chuỗi truy vấn iterative.
Cache và TTL: vì sao DNS nhanh
Nếu mỗi lần truy cập đều phải đi qua root, TLD và authoritative thì Internet sẽ rất chậm và các root server sẽ quá tải. Cache giải quyết điều này. Mỗi bản ghi có TTL (Time To Live) tính bằng giây, cho biết resolver được giữ bản ghi bao lâu trước khi hỏi lại.
TTL ngắn (ví dụ 60 giây) giúp thay đổi IP có hiệu lực nhanh, phù hợp khi sắp chuyển server hoặc dùng failover. Đổi lại, lượng truy vấn tăng lên. TTL dài (ví dụ 24 giờ) giảm tải nhưng sửa bản ghi xong phải chờ cache cũ hết hạn. Đây chính là lý do người ta nói “DNS cần thời gian propagate”: thực chất là chờ cache trên các resolver hết hạn, không phải bản ghi đang được sao chép đi khắp nơi.
Hai chữ cần nhớ khi gặp lỗi
- NXDOMAIN: domain không tồn tại.
- SERVFAIL: resolver không lấy được câu trả lời, thường do authoritative server không phản hồi hoặc cấu hình sai. Đây là lỗi bạn thấy nhiều nhất khi nhà cung cấp DNS gặp sự cố.
Các loại bản ghi DNS thường gặp
Một domain được mô tả bằng tập hợp các bản ghi (resource record) trong một zone. Bảng dưới là những loại bạn cần nắm cho CCNA và công việc thực tế.
| Bản ghi | Chức năng | Ví dụ |
|---|---|---|
| A | Tên → địa chỉ IPv4 | www → 203.0.113.10 |
| AAAA | Tên → địa chỉ IPv6 | www → 2001:db8::10 |
| CNAME | Bí danh trỏ sang tên khác | blog → www.kainetworks.vn |
| MX | Mail server nhận thư của domain, có độ ưu tiên | 10 mail.kainetworks.vn |
| NS | Name server có thẩm quyền của zone | ns1.provider.vn |
| TXT | Văn bản tự do, dùng cho SPF, DKIM, xác minh domain | v=spf1 include:... ~all |
| PTR | IP → tên (tra ngược) | 10.113.0.203.in-addr.arpa |
| SOA | Thông tin gốc của zone: server chính, serial, thời gian làm mới | Mỗi zone có đúng một bản ghi SOA |
Lưu ý: CNAME không thể đặt tại gốc của domain (zone apex, ví dụ kainetworks.vn không kèm www) vì apex đã phải chứa NS và SOA. Đây là lý do các nhà cung cấp cloud tạo ra loại bản ghi đặc biệt.
DNS server riêng của doanh nghiệp
Ngoài việc thuê authoritative DNS cho domain công khai, hầu hết doanh nghiệp còn dựng DNS server nội bộ (Windows Server DNS tích hợp Active Directory, BIND trên Linux, hoặc thiết bị chuyên dụng). Lý do thực tế:
- Tên nội bộ không nên công khai. Máy chủ file, máy in, ứng dụng nội bộ và đặc biệt là Active Directory (client tìm domain controller qua DNS) cần tên phân giải được trong mạng nhưng không cần lộ ra Internet.
- Cache dùng chung. Hàng trăm client cùng hỏi một DNS server nội bộ, câu trả lời được cache lại nên nhanh hơn và ít truy vấn ra ngoài hơn.
- Kiểm soát. Doanh nghiệp ghi log truy vấn DNS, chặn domain độc hại và ép mọi client dùng chung một điểm phân giải.
Một DNS server nội bộ thường đóng đồng thời hai vai trò: authoritative cho zone nội bộ của mình, và resolver/forwarder cho các tên bên ngoài.
Các khái niệm hay gặp khi triển khai:
- Forwarder: chuyển truy vấn tên bên ngoài tới DNS của ISP hoặc DNS công cộng, thay vì tự đi từ root.
- Conditional forwarder: chỉ chuyển truy vấn của một domain cụ thể tới một DNS server cụ thể, ví dụ domain của chi nhánh hoặc đối tác.
- Primary và secondary: nên có ít nhất hai DNS server cho cùng một zone. Secondary đồng bộ zone từ primary qua zone transfer (TCP 53), và tiếp tục trả lời khi primary hỏng.
- Split DNS (split-horizon): cùng một tên nhưng trả lời khác nhau tùy người hỏi: client nội bộ nhận IP private, người dùng Internet nhận IP public. Phần công khai thường vẫn đặt ở nhà cung cấp như Route 53 hoặc Mắt Bão.
- Giới hạn recursion: chỉ phục vụ client trong mạng nội bộ. DNS server mở recursion cho toàn Internet (open resolver) dễ bị lạm dụng để tấn công.
Client chỉ hỏi DNS server nội bộ. Tên thuộc zone nội bộ được trả lời ngay; tên bên ngoài được chuyển cho forwarder.
Client (PC, laptop) nhận thông tin DNS server bằng cách nào?
Một client không tự biết DNS server nằm ở đâu, nó phải được cấp thông tin này. Có bốn cách:
| Cách | Cơ chế | Thường dùng khi |
|---|---|---|
| DHCP (IPv4) | DHCP server gửi option 6 (DNS server) và option 15 (domain name) trong bản tin DHCP ACK, cùng IP và gateway | Mạng văn phòng, Wi-Fi, phổ biến nhất |
| Cấu hình tay (static) | Nhập trực tiếp trong cài đặt mạng của máy | Server, thiết bị mạng, lab |
| IPv6 | Router Advertisement kèm tùy chọn RDNSS, hoặc DHCPv6 | Mạng IPv6 hoặc dual-stack |
| PPPoE, VPN, di động | DNS server được nhận khi thiết lập kết nối (PPP với ISP, VPN client nhận từ VPN gateway) | Modem tại nhà, làm việc từ xa |
Trong doanh nghiệp, cách 1 gần như là bắt buộc. DHCP pool trên router hoặc DHCP server khai báo sẵn DNS server nội bộ, nên mọi máy kết nối mạng đều tự nhận đúng địa chỉ. Đặc biệt với máy join domain Active Directory, DHCP phải cấp DNS trỏ về DNS server nội bộ thì máy mới tìm được domain controller. Quá trình DHCP gồm bốn bước Discover, Offer, Request, ACK; DNS server được báo cho client trong bản tin ACK. Sau đó client dùng ngay địa chỉ vừa nhận để gửi truy vấn DNS.
Một lưu ý khi cấu hình: client thường hỏi DNS server thứ nhất trước, chỉ khi không trả lời mới thử server thứ hai. Nếu bạn trộn một DNS nội bộ với một DNS công cộng như 8.8.8.8 trong cùng danh sách, có lúc client hỏi nhầm server công cộng và không phân giải được tên nội bộ. Muốn dự phòng, hãy dùng hai DNS server nội bộ và để chúng forward ra ngoài.
Kiểm tra client đang dùng DNS nào: ipconfig /all trên Windows (dòng DNS Servers), resolvectl status hoặc cat /etc/resolv.conf trên Linux, scutil --dns trên macOS.
Thuê dịch vụ DNS từ nhà cung cấp: bản chất và những điều cần biết
Khi không tự chạy name server cho domain công khai, doanh nghiệp thuê dịch vụ DNS từ một nhà cung cấp: nhà cung cấp cloud, nhà cung cấp tên miền và hosting, hoặc công ty chuyên về DNS. Tên nhà cung cấp cụ thể không quan trọng bằng việc hiểu dịch vụ này nằm ở đâu trong hệ thống DNS và cần kiểm tra những gì trước khi chọn.
Bản chất: đây là Authoritative server
Dịch vụ DNS hosting (còn gọi là managed DNS) chính là authoritative DNS server do nhà cung cấp vận hành thay bạn. Bạn tạo zone và bản ghi trên giao diện hoặc API của họ. Tại registrar, bạn khai báo các name server (bản ghi NS) của nhà cung cấp. Từ đó, khi recursive resolver đi hỏi ở bước cuối của quá trình phân giải, chính server của nhà cung cấp trả lời.
| Vai trò trong hệ thống DNS | Ai vận hành | Có phải dịch vụ DNS thuê từ nhà cung cấp? |
|---|---|---|
| Root server | Các tổ chức quản trị hạ tầng Internet | Không |
| TLD server | Đơn vị quản lý TLD (registry), ví dụ .com, .vn |
Không. Registrar chỉ đăng ký tên miền và khai báo NS lên TLD |
| Authoritative server | Bạn tự chạy, hoặc thuê nhà cung cấp | Có, đây là dịch vụ DNS hosting |
| Recursive resolver | ISP, DNS công cộng, hoặc DNS server nội bộ | Không. Một số nhà cung cấp bán thêm resolver (ví dụ resolver cho mạng ảo trên cloud, DNS công cộng) nhưng đó là sản phẩm khác |
Các tính năng cần biết khi thuê dịch vụ DNS
Cùng giao thức DNS, các nhà cung cấp khác nhau ở phần tính năng xung quanh. Bảng dưới là danh sách để bạn đối chiếu khi chọn hoặc đánh giá một nhà cung cấp.
| Tính năng | Giải quyết vấn đề gì | Nên hỏi nhà cung cấp |
|---|---|---|
| Số lượng name server và anycast | Nhiều name server ở nhiều vị trí giúp không phụ thuộc một điểm. Anycast cho phép cùng một IP được quảng bá từ nhiều nơi, truy vấn đến nơi gần nhất và tấn công DDoS bị phân tán | Có bao nhiêu name server, đặt ở đâu, có anycast không, SLA cam kết bao nhiêu |
| Control plane và data plane | Data plane trả lời truy vấn, control plane là nơi bạn sửa bản ghi. Hai phần này có thể lỗi độc lập | Nếu portal hoặc API lỗi, bản ghi hiện có có tiếp tục được phục vụ không |
| Loại bản ghi hỗ trợ | Ngoài A, AAAA, CNAME, MX, TXT, NS còn cần SRV, CAA, PTR. Gốc domain không đặt được CNAME nên cần cơ chế thay thế | Có ALIAS, ANAME hoặc CNAME flattening không, có hỗ trợ SRV và CAA không |
| Health check và failover | Tự động đổi bản ghi sang endpoint khỏe khi endpoint chính lỗi | Health check chạy từ đâu, tần suất bao lâu, có tính phí riêng không |
| Chính sách định tuyến | Weighted, latency-based, geolocation, failover: trả IP khác nhau theo tỉ lệ, độ trễ hoặc vị trí người hỏi | Hỗ trợ những chính sách nào, kết hợp được với health check không |
| DNSSEC | Ký zone để resolver kiểm chứng câu trả lời không bị giả mạo | Có ký zone tự động không, quy trình đổi khóa và khai báo DS tại registrar ra sao |
| Secondary DNS và zone transfer | Dùng hai nhà cung cấp song song để tránh phụ thuộc một nơi, đồng bộ qua AXFR hoặc IXFR | Có làm primary hoặc secondary được không, có import và export zone file không |
| API, Terraform, phân quyền | Quản lý bản ghi bằng code, nhiều người cùng quản trị an toàn | Có API, provider Terraform, phân quyền theo vai trò, log thay đổi không |
| TTL tối thiểu và giới hạn | Một số nơi đặt TTL tối thiểu, giới hạn số bản ghi hoặc số truy vấn | TTL thấp nhất là bao nhiêu, giới hạn bản ghi mỗi zone, có tính phí theo lượng truy vấn không |
| Bảo vệ DDoS | DNS là mục tiêu tấn công phổ biến | Có bảo vệ DDoS mặc định, có giới hạn tốc độ truy vấn không |
| Private DNS (split-horizon) | Cùng tên miền trả IP riêng cho mạng nội bộ, IP public cho Internet | Có zone riêng cho mạng nội bộ không |
| Log và giám sát | Điều tra sự cố, phát hiện truy vấn bất thường | Có log truy vấn, metric, cảnh báo không |
| Quy trình chuyển đổi và hỗ trợ | Cần khi đổi nhà cung cấp hoặc xử lý sự cố | Cách chuyển zone, giờ hỗ trợ, kênh liên hệ khi có sự cố |
Nếu chỉ là website nhỏ, bạn cần sự ổn định và giao diện dễ dùng. Với hệ thống quan trọng, hãy ưu tiên SLA, failover, DNSSEC, API và phương án secondary DNS. Nhớ rằng nếu chỉ dùng một nhà cung cấp thì toàn bộ domain phụ thuộc vào họ, đó là lý do của phần tiếp theo.
Vì sao provider DNS gặp sự cố lại ảnh hưởng lớn đến vậy?
Khi một web server hỏng, chỉ một website bị ảnh hưởng. Khi DNS hỏng, máy chủ vẫn chạy bình thường nhưng không ai tìm thấy chúng. Có bốn lý do khiến tác động lan rộng:
- DNS là bước đầu tiên của mọi kết nối. Trước khi gửi gói tin đầu tiên tới một ứng dụng, thiết bị phải phân giải tên. Nếu authoritative server không trả lời, resolver trả về lỗi như SERVFAIL, và từ góc nhìn người dùng, dịch vụ “sập” dù hạ tầng phía sau còn nguyên.
- Tập trung rủi ro (shared fate). Một nhà cung cấp phục vụ hàng nghìn, hàng triệu zone. Lỗi ở một điểm sẽ kéo theo tất cả khách hàng cùng lúc. Một lần Akamai Edge DNS gặp sự cố, nhiều trang như Airbnb, UPS, HSBC, British Airways và mạng PlayStation đã cùng lúc không truy cập được, vì họ dùng chung nhà cung cấp.
- Phụ thuộc chồng phụ thuộc. Các dịch vụ nội bộ của chính nhà cung cấp cloud cũng tìm nhau bằng DNS. Khi tên của một dịch vụ lõi không phân giải được, mọi dịch vụ gọi tới nó đều lỗi theo.
- Cache khiến việc phục hồi chậm hơn việc sửa lỗi. Khi sửa xong, các resolver trên thế giới vẫn có thể còn giữ câu trả lời lỗi hoặc đang chờ thử lại. Lưu lượng retry đồng loạt còn tạo thêm tải cho hệ thống đang phục hồi.
Cách giảm rủi ro khi vận hành
- Dùng ít nhất hai nhà cung cấp DNS (primary và secondary), khai báo NS của cả hai tại registrar.
- Chọn TTL phù hợp: đủ ngắn cho các bản ghi cần failover, không quá ngắn để khỏi tăng tải truy vấn.
- Thiết kế đa vùng, tránh phụ thuộc cứng vào một region, ví dụ dùng endpoint theo vùng thay vì endpoint toàn cầu khi có thể.
- Giám sát DNS từ bên ngoài: theo dõi kết quả phân giải thật từ nhiều vị trí thay vì chỉ giám sát server.
DNS trong CCNA: cấu hình và kiểm tra trên Cisco IOS
Trong blueprint CCNA 200-301, DNS nằm cùng nhóm với DHCP ở mục IP Services, với yêu cầu giải thích vai trò của DHCP và DNS trong mạng. Ngoài lý thuyết, bạn cần làm được ba việc sau trên router Cisco.
1. Cấu hình router làm DNS client để phân giải tên khi dùng ping hoặc telnet:
Router(config)# ip domain-lookup Router(config)# ip name-server 8.8.8.8 1.1.1.1 Router(config)# ip domain-name kainetworks.vn
2. Khai báo tên tĩnh (giống file hosts), tiện cho lab khi chưa có DNS server:
Router(config)# ip host R2 10.0.0.2 Router# show hosts
3. Cấp DNS server cho client qua DHCP, để PC tự nhận địa chỉ DNS:
Router(config)# ip dhcp pool LAN10 Router(dhcp-config)# network 192.168.10.0 255.255.255.0 Router(dhcp-config)# default-router 192.168.10.1 Router(dhcp-config)# dns-server 8.8.8.8
Khi client và DHCP server nằm khác subnet, router dùng ip helper-address để chuyển bản tin DHCP Discover tới DHCP server.
Khi cần kiểm tra DNS từ máy trạm, dùng nslookup www.kainetworks.vn (Windows) hoặc dig www.kainetworks.vn (Linux, macOS). Nếu ping 8.8.8.8 thành công nhưng ping www.google.com báo lỗi phân giải, vấn đề nằm ở DNS chứ không phải đường truyền. Đây là cách phân tách lỗi nhanh mà đề thi và công việc thực tế đều hay dùng.
Một mẹo nhỏ: khi gõ nhầm lệnh trên router, IOS mặc định cố phân giải chuỗi đó như một tên host và treo vài chục giây. Trong lab, nhiều người tắt tạm bằng no ip domain-lookup. Với ACL và firewall, nhớ cho phép UDP và TCP cổng 53 nếu muốn DNS đi qua.
Câu hỏi thường gặp về DNS
DNS dùng cổng nào? UDP cổng 53 cho truy vấn thông thường, TCP cổng 53 cho bản tin lớn và đồng bộ zone giữa các DNS server.
DNS khác DHCP thế nào? DHCP cấp cấu hình IP (địa chỉ, gateway, địa chỉ DNS server) cho thiết bị. DNS dịch tên thành IP. Hai dịch vụ phối hợp: DHCP báo cho PC biết dùng DNS server nào.
Bản ghi A và CNAME khác nhau ở đâu? A trỏ tên trực tiếp tới một địa chỉ IPv4. CNAME là bí danh trỏ tới một tên khác, resolver phải phân giải tiếp tên đó. CNAME không đặt được tại gốc domain.
Vì sao sửa bản ghi DNS xong mà chưa thấy hiệu lực? Do cache. Các resolver giữ bản ghi cũ đến khi hết TTL. Giảm TTL trước khi chuyển server sẽ rút ngắn thời gian chờ.
Nếu DNS lỗi thì ping được IP không? Có. DNS chỉ ảnh hưởng bước tìm IP từ tên. Nếu bạn ping thẳng IP được mà ping tên không được, lỗi nằm ở DNS.
Nên dùng DNS của ISP hay DNS công cộng? Cả hai đều phân giải được. DNS công cộng như 8.8.8.8 hay 1.1.1.1 thường tiện làm dự phòng. Điều quan trọng hơn là cấu hình ít nhất hai DNS server để không phụ thuộc vào một điểm duy nhất.
Kết luận
DNS là “danh bạ” của Internet: nó biến tên miền thành địa chỉ IP thông qua chuỗi resolver, root, TLD và authoritative server, được tăng tốc bằng cache và TTL. Dịch vụ DNS của nhà cung cấp là cách bạn thuê phần authoritative này, còn các tính năng như alias, routing policy, health check, DNSSEC là giá trị gia tăng. Và vì mọi kết nối đều bắt đầu bằng một truy vấn DNS, một lỗi nhỏ ở bản ghi của dịch vụ lõi cũng đủ làm hàng chục dịch vụ ngừng hoạt động.
Nếu bạn đang ôn CCNA hoặc muốn hiểu mạng đủ sâu để vận hành hệ thống thật, hãy xem khóa học CCNA của KAI NETWORKS tại kainetworks.vn. Khóa học giúp bạn nắm các chủ đề như IP, DHCP, DNS, routing và switching một cách hệ thống, để bạn tự cấu hình và kiểm tra như các ví dụ trong bài.
