Dangling DNS là trạng thái một DNS record vẫn tồn tại nhưng tài nguyên hoặc dịch vụ đích mà record trỏ tới đã bị xóa, deprovision hoặc không còn được tổ chức kiểm soát. Đây là một lỗi lifecycle/decommission phổ biến, đặc biệt với CNAME trỏ tới SaaS, CDN, cloud app hoặc hosting platform.
Dangling DNS chưa tự động đồng nghĩa với subdomain takeover. Để trở thành vulnerability, cần có thêm điều kiện: nền tảng đích cho phép một actor khác claim resource hoặc identifier tương ứng và phục vụ nội dung dưới hostname của tổ chức.
Hiểu Dangling DNS và điều kiện hình thành
Dangling DNS là gì?
Dangling DNS là DNS reference còn tồn tại sau khi dependency đích đã biến mất hoặc không còn thuộc quyền kiểm soát intended owner. Microsoft mô tả dangling DNS entry là record trỏ tới resource không còn available và cảnh báo trạng thái này có thể tạo khả năng subdomain takeover trên các dịch vụ phù hợp.
Ví dụ dangling DNS phổ biến
CNAME trỏ tới SaaS đã xóa
Ví dụ promo.example.com vẫn CNAME tới một hostname SaaS, nhưng project/site ở SaaS đã bị xóa. DNS vẫn tồn tại trong khi resource đích không còn.
CNAME trỏ tới cloud app đã deprovision
Cloud application, static site hoặc CDN distribution bị xóa trước nhưng DNS record không được cleanup.
A/AAAA trỏ tới IP không còn kiểm soát
IP cũ được release hoặc tái cấp phát. Đây cũng là stale dependency, nhưng takeover mechanics khác CNAME và cần đánh giá theo hạ tầng thực tế.
NS delegation tới zone đã bỏ
Delegated subdomain vẫn trỏ tới nameserver/service không còn được tổ chức quản lý. Risk phụ thuộc khả năng actor khác giành quyền đối với authoritative infrastructure đó.
Vì sao dangling DNS xuất hiện?
- Resource bị xóa trước DNS.
- Team ứng dụng và team DNS không dùng chung decommission checklist.
- Project thử nghiệm kết thúc nhưng record vẫn còn.
- Vendor/SaaS contract chấm dứt nhưng DNS owner không được thông báo.
- Migration sang provider mới nhưng record legacy không được cleanup.
- Không có inventory owner/dependency.
Dangling DNS khác stale DNS như thế nào?
Stale DNS là khái niệm rộng hơn: record cũ hoặc không còn intended. Dangling DNS nhấn mạnh việc record vẫn trỏ tới một dependency không còn tồn tại/được kiểm soát. Một stale TXT verification token có thể không phải dangling dependency; một CNAME tới app đã xóa thì phù hợp hơn với khái niệm dangling DNS.
Dangling DNS khác subdomain takeover như thế nào?
| Trạng thái | Ý nghĩa |
|---|---|
| Dangling DNS | DNS record còn, resource đích đã mất/không còn kiểm soát |
| Claimable dependency | Provider cho phép actor khác tạo resource chiếm identifier/hostname đích |
| Subdomain takeover | Actor thực sự kiểm soát nội dung/dịch vụ dưới subdomain của tổ chức |
Không nên báo finding “subdomain takeover” chỉ dựa trên NXDOMAIN hoặc error page. Cần evidence về claimability và, nếu kiểm thử được phép, xác minh an toàn theo Rules of Engagement. Xem workflow riêng tại Subdomain Takeover là gì?. Một case end-to-end để đối chiếu chuỗi evidence là Subdomain Takeover từ Dangling DNS Record.
Phát hiện và xác minh Dangling DNS
Cách phát hiện dangling DNS
1. Export toàn bộ CNAME và delegation
CNAME thường là nhóm ưu tiên vì phụ thuộc vào hostname third-party. Ngoài ra cần review NS delegation và A/AAAA tới external infrastructure.
2. Resolve target
Kiểm tra target có resolve, trả service signature gì và có còn resource intended không. Một target không resolve là signal cần điều tra, không phải kết luận vulnerability.
3. Đối chiếu cloud/SaaS inventory
DNS state phải được so với resource inventory. Nếu record có nhưng project/subscription/resource không còn, đó là bằng chứng mạnh cho decommission gap.
4. Xác minh ownership
Hỏi team/service owner liệu dependency có còn intended không. Không nên xóa record chỉ vì scanner báo “dangling”.
Claimability là gì và vì sao quan trọng?
Claimability là khả năng một actor khác tạo resource tại provider và nhận lại hostname/identifier mà DNS đang trỏ tới. Đây là bước phân biệt một dangling record chỉ gây lỗi với một dangling record có thể dẫn tới takeover.
Mỗi provider có allocation model khác nhau. Vì vậy fingerprint/error message chỉ là evidence hỗ trợ; cần xác minh behavior hiện tại của provider thay vì dùng danh sách signature cũ như proof tuyệt đối.
Có nên thử claim resource để xác minh?
Chỉ khi có authorization rõ trong security testing scope. Tự ý claim resource third-party có thể tạo traffic interception, ảnh hưởng user hoặc vượt phạm vi kiểm thử. Trong audit thông thường, có thể dừng ở mức evidence đủ mạnh: dangling record + provider behavior/documentation + owner confirmation.
Remediation và phòng ngừa Dangling DNS
Remediation dangling DNS an toàn
Trường hợp resource không còn cần
Xóa DNS record sau khi xác minh không còn dependency. Snapshot record trước khi xóa và read-back public DNS sau change.
Trường hợp resource vẫn cần
Khôi phục/provision resource đúng owner hoặc chuyển DNS sang endpoint mới. Không nên “xóa cho sạch” nếu application vẫn phụ thuộc hostname.
Trường hợp chưa rõ owner
Tạm xếp finding pending investigation. Với hostname critical, có thể cần containment phù hợp nhưng phải dựa trên impact và change authority.
Cách ngăn dangling DNS từ đầu
- Decommission checklist phải gồm DNS cleanup.
- Resource owner phải ghi các hostname phụ thuộc.
- Infrastructure as Code nếu phù hợp để quản resource và DNS cùng lifecycle.
- Periodic audit CNAME/NS/external IP.
- DNS change monitoring để phát hiện drift.
- Ownership tag cho record critical.
- Review vendor/SaaS offboarding.
- Không để test subdomain tồn tại vô thời hạn.
Monitoring dangling DNS như thế nào?
Periodic resolver check có thể phát hiện target biến mất, nhưng hiệu quả hơn khi kết hợp cloud resource events và DNS inventory. Ví dụ khi app/service bị delete, workflow decommission có thể tạo task bắt buộc review DNS.
Xem thêm DNS Change Monitoring để xây baseline và alert cho record quan trọng.
Đánh giá finding và evidence
Dangling DNS trong audit nên ghi evidence gì?
- Hostname và record type/value.
- Timestamp/query result.
- Target response hoặc resolution state.
- Resource inventory cho thấy dependency đã deprovision.
- Provider/service liên quan.
- Claimability evidence nếu được xác minh.
- Business owner và traffic criticality.
- Remediation/rollback plan.
Severity của dangling DNS phụ thuộc vào gì?
Severity cần dựa trên claimability, hostname trust, traffic, cookie scope, authentication flow, email/service dependency và khả năng abuse. Microsoft lưu ý takeover có thể dẫn tới phishing, cookie harvesting hoặc các rủi ro khác trên subdomain bị chiếm; nhưng không nên áp cùng severity cho mọi dangling record.
Dangling DNS liên quan thế nào tới DNS misconfiguration?
Dangling DNS là một dạng DNS misconfiguration gắn với lifecycle/decommission. Audit DNS record là cách tìm các record như vậy trước khi chúng trở thành incident.
Checklist dangling DNS
- Inventory CNAME.
- Inventory NS delegation.
- Review external A/AAAA.
- Resolve target.
- Đối chiếu resource inventory.
- Xác định owner.
- Kiểm tra claimability theo provider.
- Không tự ý claim nếu chưa authorized.
- Snapshot trước remediation.
- Delete/repoint record theo intended state.
- Read-back public DNS.
- Update decommission process.
Để rà soát Dangling DNS cùng các control registrar, DNS, subdomain và TLS khác, dùng Domain & DNS Security Checklist.
Mẫu output dig/CNAME và bảng claimability
Artifact dưới đây là mẫu để ghi evidence, không phải kết quả đã chạy trên hệ thống SecureWebOps.
# 1) Quan sát record hiện tại
dig +noall +answer sub.example.com CNAME
# 2) Resolve target của CNAME
dig +noall +answer target.vendor.example A
dig +noall +answer target.vendor.example AAAA
# 3) Ghi thêm authoritative answer khi cần đối chiếu
dig @authoritative-ns.example sub.example.com CNAME +noall +answer| Field | Evidence cần ghi |
|---|---|
| Hostname | FQDN đang audit |
| Observed record | Type, value và timestamp |
| Target state | Resolve/không resolve/service response |
| Resource inventory | Còn hay đã deprovision |
| Provider behavior | Tài liệu hoặc bằng chứng hiện tại về allocation/claimability |
| Owner confirmation | Intended / stale / unknown |
| Claimability | CONFIRMED / NOT_CONFIRMED / NOT_TESTED |
| Final classification | Dangling only / takeover risk / needs investigation |
| Remediation | Delete, repoint, restore resource hoặc investigate |
| Read-back | Observed state sau remediation |
Nguồn kỹ thuật tham khảo
- Microsoft Learn — Prevent dangling DNS entries and avoid subdomain takeover
- NIST SP 800-81 Rev. 3 — Secure Domain Name System Deployment Guide
Kết luận
Dangling DNS là dấu hiệu lifecycle bị đứt giữa DNS và resource. Bản thân record dangling chưa chứng minh takeover; finding chỉ nên nâng thành takeover risk khi có evidence rằng dependency có thể bị actor khác claim.
Biện pháp bền vững nhất là decommission DNS cùng resource, có owner/dependency inventory và audit định kỳ. Khi remediation, luôn snapshot và read-back thay vì xóa record theo scanner một cách máy móc.