DNS Security là gì? 8 lớp bảo vệ DNS quan trọng

DNS Security là tập hợp các kiểm soát bảo vệ tính toàn vẹn, tính sẵn sàng và mức độ tin cậy của hệ thống phân giải tên miền. DNS không chỉ trả lời “domain này trỏ tới IP nào”; nó còn ảnh hưởng tới website, email, API, CDN, dịch vụ SaaS và nhiều policy security khác. Một lỗi hoặc thay đổi trái phép ở DNS có thể tác động tới toàn bộ tổ chức dù application và server vẫn sạch.

NIST SP 800-81 Rev. 3, xuất bản tháng 3/2026, xem DNS là một thành phần quan trọng trong security posture và đưa ra hướng dẫn cho authoritative DNS, recursive DNS, DNSSEC, encrypted DNS và DNS logging. Bài này dùng góc nhìn đó để xây một mô hình DNS Security thực tế cho website và doanh nghiệp.

DNS Security là gì?

DNS Security là việc bảo vệ DNS infrastructure, DNS data và quy trình vận hành DNS khỏi thay đổi trái phép, giả mạo, gián đoạn, misconfiguration và abuse. Mục tiêu gồm bảo đảm dữ liệu DNS đúng nguồn, không bị sửa ngoài ý muốn, dịch vụ DNS vẫn khả dụng và hoạt động DNS đủ quan sát để phát hiện bất thường.

DNS Security không chỉ là DNSSEC

DNSSEC giải quyết tính xác thực và toàn vẹn của DNS data đã ký, nhưng DNS Security rộng hơn nhiều. Nó còn gồm access control tại DNS provider, authoritative server hardening, redundancy, record inventory, change control, logging, monitoring, protective DNS và vận hành resolver.

Authoritative DNS và recursive DNS khác nhau thế nào?

Vai trò	Nhiệm vụ	Rủi ro chính
Authoritative DNS	Cung cấp record chính thức cho zone/domain	Unauthorized change, outage, DNSSEC lỗi, misconfiguration
Recursive DNS	Truy vấn thay client và cache kết quả	Poisoning, abuse, privacy leakage, malicious-domain access

Hai vai trò cần control khác nhau. Website owner thường tập trung vào authoritative DNS của domain, còn doanh nghiệp cũng cần quan tâm recursive resolver mà user/device sử dụng.

Những rủi ro DNS phổ biến

Unauthorized DNS record change

Nếu account DNS provider bị chiếm hoặc quyền thay đổi quá rộng, attacker có thể sửa A/AAAA/CNAME/MX/TXT và đưa traffic hoặc mail sang hệ thống khác. Đây là rủi ro identity/change-control chứ không phải lỗi protocol DNS thuần túy. Failure mode thực tế xem DNS bị thay đổi trái phép gây Traffic Redirect.

Nameserver change ngoài ý muốn

Thay authoritative nameserver có thể chuyển toàn bộ authority của zone sang provider khác. Vì vậy nameserver change cần được theo dõi ở cả registrar và DNS layer.

DNS misconfiguration

Record sai, TTL không phù hợp, CNAME chain bất thường, zone không đồng bộ hoặc DS/DNSKEY mismatch có thể gây outage mà không có attacker. DNS Security phải bao gồm reliability và change discipline, không chỉ chống tấn công. Xem các failure mode cụ thể tại DNS Misconfiguration.

Cache poisoning và forged response

DNS truyền thống không có cơ chế xác thực dữ liệu mạnh ở mọi bước. DNSSEC được thiết kế để resolver có thể phát hiện DNS data đã ký bị sửa hoặc giả mạo trong chain of trust.

Dangling DNS và dependency bị bỏ quên

Record trỏ tới tài nguyên cloud/SaaS đã xóa có thể tạo dangling dependency và trong một số nền tảng dẫn tới subdomain takeover. Inventory và decommission process phải xóa DNS record cùng với resource. Xem cách phân biệt condition và exploit tại Dangling DNS là gì?. Case Subdomain Takeover từ Dangling DNS Record minh họa vì sao claimability phải được xác minh trước khi nâng finding từ stale dependency lên takeover risk.

DDoS hoặc outage tại DNS provider

Nếu authoritative DNS không khả dụng, client có thể không tìm được website dù origin vẫn hoạt động. Redundancy, provider architecture và monitoring là một phần của availability planning.

8 lớp kiểm soát DNS Security nên có

1. Inventory toàn bộ zone và record quan trọng

Biết domain nào, subdomain nào và record nào đang tồn tại. Với mỗi record quan trọng nên biết owner, mục đích, dependency, provider và quy trình decommission. Inventory giúp phát hiện record “không ai nhận” và giảm shadow DNS. Một workflow kiểm chứng thực tế nằm trong Audit DNS Record.

2. Least privilege cho DNS admin

Không để mọi operator có quyền sửa toàn bộ zone nếu provider hỗ trợ role/scope chi tiết. Admin account cần MFA, recovery control và review quyền định kỳ. API token dùng automation cũng phải được quản lý như secret đặc quyền.

3. Change control và rollback

Mỗi thay đổi quan trọng nên có before-state, intended change, owner, change window và rollback. Với record có ảnh hưởng website/email, read-back sau write là bắt buộc; API trả 200 không đủ nếu DNS public vẫn chưa phản ánh đúng.

4. Authoritative DNS redundancy và availability

Authoritative service cần kiến trúc chịu lỗi phù hợp với criticality. Nếu tự vận hành, tránh đặt tất cả authoritative server trong cùng failure domain. Nếu dùng managed provider, cần hiểu SLA, Anycast/redundancy model và escalation path thay vì mặc định “cloud là luôn available”.

5. DNSSEC khi vận hành được lifecycle

DNSSEC giúp resolver kiểm tra data origin authentication và data integrity cho DNS data đã ký. Nhưng cần quản lý DNSKEY, DS, rollover và migration. DNSSEC cấu hình sai có thể làm validation fail, vì vậy triển khai phải có verification và rollback. Xem quy trình triển khai và kiểm tra tại DNSSEC là gì?.

6. Logging và monitoring

NIST SP 800-81r3 nhấn mạnh vai trò DNS logging trong vận hành an toàn. Với authoritative DNS, theo dõi record/nameserver change, account activity và health. Với recursive DNS, log có thể hỗ trợ threat detection nhưng cần cân bằng privacy, retention và access control. Xem cách xây baseline và alert tại DNS Change Monitoring.

7. Protective DNS cho client/enterprise

Protective DNS dùng recursive resolver/policy để chặn hoặc cảnh báo truy cập tới domain độc hại. CISA vận hành Protective DNS cho khối liên bang Mỹ và mô tả khả năng blocking, alerting và visibility dựa trên DNS query. Đây là control phía client/recursive, khác với bảo vệ authoritative zone của domain.

8. Decommission record cùng dependency

Khi xóa cloud app, CDN route, SaaS site hoặc storage bucket, phải review DNS record liên quan. Decommission resource nhưng quên DNS tạo dangling record và attack surface kéo dài.

DNSSEC, DoH/DoT và Protective DNS có thay thế nhau không?

Không. Chúng giải quyết các vấn đề khác nhau:

DNSSEC: xác thực và bảo vệ integrity của DNS data đã ký.
DoH/DoT: mã hóa transport giữa client/resolver hoặc giữa các thành phần hỗ trợ, giúp giảm quan sát/chỉnh sửa trên đường truyền ở đoạn được mã hóa.
Protective DNS: áp dụng policy/threat intelligence để chặn domain độc hại.

Một tổ chức có thể cần nhiều lớp cùng lúc. Mã hóa DNS không xác minh authoritative data; DNSSEC không tự chặn phishing domain; Protective DNS không bảo vệ registrar account.

DNS logging nên theo dõi gì?

Authoritative DNS

Login/admin activity.
Record create/update/delete.
Nameserver hoặc zone-setting change.
DNSSEC/DS/key lifecycle event.
Health, latency, error rate nếu provider expose.

Recursive DNS

Query volume và anomaly.
Blocked malicious domains.
NXDOMAIN spike hoặc unusual TLD/domain pattern.
Resolver health và upstream failure.

Không phải mọi DNS log đều phải giữ lâu. Retention cần dựa trên incident-response need, privacy và cost.

TTL có phải là security control không?

TTL chủ yếu là caching/operational parameter, không phải security control độc lập. TTL thấp có thể giúp thay đổi propagate nhanh hơn trong một số tình huống nhưng tăng query load; TTL cao có thể làm rollback/change mất thời gian hơn ở cache. Nên chọn TTL theo operational requirement thay vì một con số “chuẩn security”.

Cách audit một DNS zone

Xác định authoritative nameserver và DNS provider.
Export/inventory record hiện tại.
Gắn owner và purpose cho record quan trọng.
Review admin user, MFA, role và API token.
Review zone change log và notification.
Kiểm tra A/AAAA/CNAME/MX/TXT/CAA/NS quan trọng.
Tìm dangling hoặc stale dependency.
Kiểm tra DNSSEC state, DS và validation nếu dùng.
Review redundancy/availability.
Ghi baseline để dùng cho monitoring và incident recovery.

Nếu DNS bị thay đổi trái phép nên làm gì?

Đầu tiên bảo toàn evidence: timestamp, current/previous records, account log, registrar status và notification. Sau đó contain credential/session có liên quan, xác minh nameserver/zone từ nguồn đáng tin cậy và khôi phục record theo baseline đã xác nhận. Không nên “sửa bằng trí nhớ” khi đang incident.

Sau recovery cần review root cause: registrar compromise, DNS admin compromise, API token, vendor access hay change lỗi. Nếu chỉ sửa record mà không đóng đường vào ban đầu, incident có thể lặp lại.

DNS Security khác Domain Security như thế nào?

Domain Security tập trung rộng hơn vào ownership, registrar, transfer, recovery và delegation. DNS Security tập trung vào zone, record, authoritative/recursive infrastructure và quy trình DNS. Hai lớp giao nhau ở nameserver, provider access và DNSSEC nhưng không đồng nhất.

Nếu website chạy WordPress, xem thêm bảo mật DNS & Domain cho WordPress để áp dụng vào stack cụ thể.

Checklist DNS Security 15 điểm

Biết authoritative DNS provider.
Có inventory zone/record.
Có owner cho record critical.
DNS admin bật MFA.
Review role/user/token.
Change có before-state và rollback.
Bật audit log/notification nếu hỗ trợ.
Monitor nameserver change.
Monitor record critical.
Review stale/dangling record.
Review authoritative redundancy.
Kiểm tra DNSSEC nếu triển khai.
Quản lý DS/DNSKEY lifecycle.
Review recursive/protective DNS cho enterprise client.
Có DNS incident runbook.

Nếu cần rà soát xuyên suốt registrar, DNS, subdomain và certificate lifecycle trong một checklist, xem Domain & DNS Security Checklist.

Nguồn kỹ thuật tham khảo

Kết luận

DNS Security là tổ hợp của identity security, change control, authoritative reliability, DNSSEC, logging, monitoring và resolver protection. Không có một setting đơn lẻ nào khiến DNS “an toàn”.

Điểm quan trọng là phân biệt đúng vai trò: authoritative zone cần bảo vệ integrity/availability và quyền thay đổi; recursive resolver cần bảo vệ client và query path; Domain Security cần bảo vệ ownership/registrar. Khi các lớp này được quản trị cùng nhau, DNS mới trở thành một control plane có thể tin cậy.