Audit DNS record là quá trình kiểm kê, xác minh và đánh giá từng record DNS quan trọng để biết record nào còn cần thiết, record nào sai hoặc stale, ai là owner và thay đổi nào có thể ảnh hưởng website, email hoặc dịch vụ phụ thuộc. Một DNS zone “đang resolve bình thường” chưa chắc đã an toàn: record cũ, CNAME trỏ tới tài nguyên đã xóa, MX/TXT không còn dùng hoặc DS/DNSKEY lệch đều có thể tạo rủi ro.
Bài này tập trung vào một workflow audit thực tế cho authoritative DNS: inventory → classify → validate → risk → remediation → read-back. Mục tiêu là tạo evidence đủ để sửa có kiểm soát, không phải xóa record chỉ vì “trông lạ”.
Audit DNS record là gì?
Audit DNS record là việc đối chiếu DNS state hiện tại với intended architecture và ownership để phát hiện misconfiguration, stale dependency, quyền thay đổi quá rộng và rủi ro vận hành. NIST SP 800-81 Rev. 3 nhấn mạnh DNS hygiene, authoritative DNS security và giảm misconfiguration như một phần của DNS security posture.
Trước khi audit cần khóa phạm vi gì?
1. Zone nào nằm trong scope?
Ghi rõ apex domain, subdomain zone delegated riêng, authoritative provider và nameserver. Không nên mặc định một account DNS chứa nhiều zone thì tất cả đều thuộc cùng audit.
2. Record nào được xem là critical?
Ít nhất nên đánh dấu record phục vụ website, API, email, CDN, authentication, certificate issuance, SaaS verification và delegated subdomain. Criticality giúp ưu tiên review và quyết định change approval.
3. Evidence lấy từ đâu?
Ưu tiên export từ authoritative provider, zone file, API read-only hoặc giao diện quản trị có timestamp. Public DNS query hữu ích để verify exposure nhưng không phải lúc nào cũng cho thấy toàn bộ private metadata, owner hoặc pending change.
Những record nào cần audit?
| Record | Mục đích thường gặp | Điểm cần kiểm tra |
|---|---|---|
| A / AAAA | Trỏ hostname tới IP | IP còn thuộc hệ thống? origin có hợp lệ? |
| CNAME | Alias tới hostname khác | Target còn tồn tại? có dangling dependency? |
| MX | Mail routing | Provider còn dùng? priority đúng? |
| TXT | SPF, verification, policy | Token cũ? scope quá rộng? owner? |
| CAA | Giới hạn CA được phép issue | Issuer còn đúng? policy có chủ đích? |
| NS | Delegation | Nameserver đúng provider? stale delegation? |
| DS | DNSSEC chain of trust | Có khớp DNSKEY/provider hiện tại? |
Workflow audit DNS record 8 bước
Bước 1: Export state hiện tại
Lưu bản snapshot zone trước khi đánh giá hoặc sửa. Snapshot nên có record name, type, value, TTL, proxied/routing state nếu provider có, timestamp và source. Đây là rollback evidence quan trọng.
Bước 2: Gắn owner và purpose
Mỗi record critical nên trả lời được “ai chịu trách nhiệm?” và “nó phục vụ dịch vụ nào?”. Record không có owner chưa chắc phải xóa, nhưng cần được xếp vào nhóm cần điều tra.
Bước 3: Validate target
Với A/AAAA kiểm tra IP/origin còn hợp lệ. Với CNAME kiểm tra target có tồn tại và tài nguyên đích còn được tổ chức kiểm soát. Với MX/TXT/CAA xác minh provider/policy hiện tại. Với CAA, xem thêm CAA Record là gì?.
Bước 4: Tìm stale và dangling record
Record trỏ tới tài nguyên SaaS/cloud đã deprovision là finding quan trọng. Microsoft mô tả dangling DNS là record trỏ tới resource không còn tồn tại và có thể tạo điều kiện cho subdomain takeover trên một số dịch vụ. Xem cách xác minh tại Dangling DNS là gì? và tình huống thực tế tại case Subdomain Takeover từ Dangling DNS.
Bước 5: Review TTL và change behavior
TTL không phải security score. Audit cần xem TTL có phù hợp operational requirement và rollback window hay không. TTL quá cao có thể làm recovery chậm; quá thấp tăng query load và không tự tạo thêm security.
Bước 6: Review DNSSEC dependency
Nếu zone dùng DNSSEC, kiểm tra DS ở parent và DNSKEY ở authoritative provider. Migration hoặc key rollover sai sequence có thể gây SERVFAIL với validating resolver.
Bước 7: Review quyền thay đổi
Audit record không nên tách khỏi access control. Ghi user/role/API token nào có thể thay zone, MFA state và audit log nếu provider hỗ trợ.
Bước 8: Remediate có read-back
Mỗi fix nên có before-state, intended state, owner, change window và rollback. Sau write, kiểm tra cả provider state và public DNS state phù hợp với TTL. API 200 không đủ nếu record thực tế chưa đúng. Nếu thay đổi trái phép từng làm traffic bị redirect, đối chiếu thêm với case DNS bị thay đổi trái phép gây Traffic Redirect. Sau khi baseline sạch, dùng DNS Change Monitoring để phát hiện state drift.
Cách phân loại finding khi audit DNS
Unauthorized exposure
Record công khai tiết lộ service/hostname không cần thiết hoặc trỏ tới endpoint không còn intended. Cần đánh giá impact thực tế, không suy diễn rằng mọi hostname lộ ra đều là vulnerability.
Stale dependency
Record còn tồn tại nhưng service đích đã retire. Đây là finding phổ biến ở CNAME, TXT verification token và subdomain cũ.
Misconfiguration
Sai value, sai priority, duplicate/conflicting record, DS mismatch hoặc delegation không còn đúng. Severity phụ thuộc blast radius và khả năng gây outage/abuse.
Governance gap
Không có owner, không có change log, shared admin hoặc token không rõ nguồn. Đây là control weakness dù record hiện tại vẫn resolve đúng.
Audit TXT record cần chú ý gì?
TXT thường tích tụ nhiều token verification, SPF include, domain ownership proof và policy. Không nên xóa TXT chỉ vì không hiểu mục đích. Hãy truy ngược provider/service, owner và ngày tạo. Với token đã hết mục đích, xác minh service không còn phụ thuộc rồi mới remove.
Audit CNAME để tránh dangling DNS
CNAME là nơi dễ xuất hiện dependency tới SaaS/CDN/cloud. Nếu target hostname trả trạng thái cho thấy resource không tồn tại, cần kiểm tra khả năng người khác claim resource cùng identifier trên provider đó. Không phải mọi NXDOMAIN đều là takeover; phải xác minh claimability của nền tảng đích.
Audit MX và email DNS
MX cần khớp mail provider thực tế. TXT liên quan SPF/DKIM/DMARC cần được review theo email architecture, nhưng không nên gộp thành một “DNS security score”. Mục tiêu là biết record nào đang enforce policy và record nào chỉ còn legacy.
Audit NS và delegation
Kiểm tra authoritative nameserver tại parent và NS trong zone có phù hợp kiến trúc không. Với delegated subdomain, phải biết team/provider nào chịu trách nhiệm. Delegation tới nameserver đã bỏ có thể tạo outage hoặc security risk tùy tình huống.
Audit DS và DNSSEC
Nếu DS tồn tại ở parent, zone cần duy trì chain DNSSEC hợp lệ. DS cũ sau migration là failure mode nghiêm trọng vì validating resolver có thể coi zone là bogus. Xem chi tiết tại DNSSEC là gì?.
Checklist audit DNS record
- Export zone và timestamp.
- Xác minh authoritative nameserver.
- Gắn owner/purpose cho record critical.
- Review A/AAAA origin.
- Review CNAME target và dangling dependency.
- Review MX/TXT theo provider đang dùng.
- Review CAA policy.
- Review NS/delegation.
- Review DS/DNSKEY nếu có DNSSEC.
- Review TTL theo change/rollback need.
- Review user/role/API token.
- Review audit log/notification.
- Phân loại stale/misconfigured/governance finding.
- Tạo remediation plan có rollback.
- Read-back sau mọi thay đổi.
Để rà soát xuyên suốt registrar, DNS, subdomain và TLS trong một lượt, xem Domain & DNS Security Checklist.
Audit DNS record liên quan thế nào tới DNS Security?
DNS Security là lớp rộng gồm access control, authoritative availability, DNSSEC, logging, monitoring và resolver protection. Audit DNS record là hoạt động kiểm chứng state cụ thể của zone và dependency. Hai lớp bổ sung nhau nhưng không đồng nhất.
Ở lớp ownership/registrar, xem Domain Security là gì?.
Zone inventory & dependency template
Artifact dưới đây là mẫu inventory có thể copy sang CSV/Sheet; connector hiện không upload file CSV vào Media Library nên mình không giả là đã có file tải xuống. Các field này bám đúng workflow audit và dùng để ghi evidence thực tế.
zone,record_name,type,value,ttl,provider,service_purpose,business_owner,technical_owner,dependency,criticality,current_state,evidence_source,last_verified,change_ticket,remediation,rollback,final_state| Field | Cách dùng |
|---|---|
| zone / record_name / type / value / ttl | Snapshot DNS state hiện tại |
| provider | Authoritative DNS hoặc third-party dependency |
| service_purpose | Website, API, email, SaaS verification, certificate… |
| business_owner / technical_owner | Ai chịu trách nhiệm về dịch vụ và thay đổi |
| dependency | Origin, SaaS, CDN, cloud resource, parent/child DNSSEC… |
| criticality | Low / Medium / High theo impact thực tế |
| current_state | INTENDED / STALE / DANGLING / MISCONFIGURED / UNKNOWN |
| evidence_source | Provider export, API read-only, public DNS, ticket… |
| last_verified | Timestamp + timezone |
| change_ticket | Change/incident reference nếu có |
| remediation / rollback | Fix dự kiến và đường quay lại |
| final_state | PASS / FAIL / NEEDS_INVESTIGATION |
Khi dùng template, không điền owner hoặc dependency theo phỏng đoán. Trạng thái đúng khi thiếu bằng chứng là UNKNOWN hoặc NEEDS_INVESTIGATION.
Nguồn kỹ thuật tham khảo
- NIST SP 800-81 Rev. 3 — Secure Domain Name System Deployment Guide
- Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
Kết luận
Audit DNS record không phải việc “scan rồi xóa record lạ”. Một audit tốt phải có inventory, owner, intended architecture, evidence và rollback. Mục tiêu là biết chính xác record nào cần giữ, record nào stale, dependency nào có thể bị abuse và ai có quyền thay đổi.
Khi audit gắn với read-back và change control, DNS zone trở thành một asset có thể quản trị thay vì một danh sách record tích tụ theo thời gian.