DNS có thể bị thay đổi trái phép mà web server, database và application vẫn hoàn toàn bình thường. Chỉ cần một A, CNAME, MX hoặc NS record bị sửa, traffic có thể bị chuyển sang hạ tầng khác trước khi người dùng chạm tới hệ thống thật.
CISA mô tả một chuỗi tấn công phổ biến: attacker chiếm credential của tài khoản có quyền thay đổi DNS, sau đó sửa A, MX hoặc NS record để chuyển web hoặc email traffic sang hạ tầng do attacker kiểm soát. ICANN cũng cảnh báo việc maliciously reconfigure DNS có thể gây gián đoạn vận hành, thiệt hại tài chính và uy tín. Nguồn: CISA — Mitigate DNS Infrastructure Tampering và ICANN SAC040.
Bối cảnh và dấu hiệu đầu tiên
Giả sử website đang hoạt động bình thường qua CDN hoặc origin cố định. Không có deploy, không thay hosting, nhưng người dùng ở một số mạng bắt đầu bị chuyển tới một IP hoặc hostname khác. Nội bộ kiểm tra server vẫn thấy CPU, PHP, database và application health đều ổn.
Đây là lúc cần kiểm tra authoritative DNS trước khi tiếp tục debug application. Nếu DNS đã bị đổi, toàn bộ lớp phía sau có thể vẫn khỏe nhưng người dùng không còn được dẫn tới đúng hệ thống.
Những tín hiệu cần điều tra ngay
- A/AAAA/CNAME/MX/NS record khác baseline nhưng không có change request.
- Public resolver trả IP khác với cấu hình dự kiến.
- Website hoặc email bị chuyển hướng trong khi origin vẫn healthy.
- DNS provider/registrar có login hoặc change event ngoài giờ.
- TTL, nameserver hoặc record ownership thay đổi bất thường.
- TLS certificate hoặc HTTP response từ đích mới không khớp hệ thống chính thức.
Investigation: xác minh DNS đã bị sửa ở đâu
Bước 1: read-back authoritative DNS
Không nên chỉ nhìn giao diện DNS provider. Cần query authoritative nameserver để xác định record mà Internet thực sự đang nhận: A, AAAA, CNAME, MX, NS, TXT và TTL liên quan. Sau đó so sánh với baseline known-good hoặc snapshot gần nhất.
Nếu authoritative DNS đã sai nhưng control panel vẫn đúng, cần xem thêm delegation, secondary DNS hoặc nameserver path. Nếu authoritative DNS đúng nhưng public resolver vẫn trả giá trị cũ, vấn đề có thể nằm ở cache/TTL chứ chưa chắc là unauthorized change.
Bước 2: kiểm tra change history và account access
Đối chiếu thời điểm DNS thay đổi với login history, API token usage, registrar/DNS provider audit log và change ticket. Một record thay đổi trái phép thường đi kèm một trong các tín hiệu: session lạ, API token bị dùng ngoài baseline, recovery method bị đổi hoặc account mới được cấp quyền.
ICANN khuyến nghị liên hệ registrar ngay nếu registration information hoặc domain control bị thay đổi không được phép; unauthorized access vào registrar account có thể là tiền đề cho việc sửa nameserver hoặc DNS configuration. Nguồn: ICANN — Unauthorized Transfers and Changes.
Bước 3: xác định phạm vi traffic bị ảnh hưởng
Không phải mọi DNS record đều có impact giống nhau. A/AAAA/CNAME có thể chuyển website hoặc API; MX có thể chuyển email; NS có thể chuyển toàn bộ quyền trả lời zone. Cần xác định chính xác record nào bị sửa và các dịch vụ nào phụ thuộc vào record đó.
CISA lưu ý attacker có thể sửa A, MX hoặc NS để redirect và intercept web/email traffic. Vì vậy impact assessment nên kiểm tra cả website, API, email, TLS, CDN/WAF routing và các flow xác minh phụ thuộc DNS. Nguồn: CISA.
Khi nào có thể xác nhận unauthorized DNS change?
Không nên kết luận chỉ vì một resolver trả kết quả lạ. Cần nối được DNS state với bằng chứng thay đổi và owner confirmation.
- Authoritative record khác baseline hoặc approved configuration.
- Không có change ticket/owner xác nhận thay đổi.
- Audit log cho thấy login, API call hoặc change event không hợp lệ.
- Traffic thực tế bị redirect sang đích ngoài kiểm soát hoặc sai hạ tầng.
- Sau khi restore record và revoke access trái phép, DNS state và traffic trở lại bình thường.
Remediation: khôi phục DNS và khóa đường tái xâm nhập
Containment và restore
- Snapshot toàn bộ zone và change history trước khi sửa nếu vẫn còn quyền truy cập.
- Reset credential, revoke session/API token đáng ngờ và bật MFA cho account quản trị DNS/registrar.
- Restore record theo baseline known-good; ưu tiên authoritative source và change approval rõ ràng.
- Kiểm tra NS/delegation nếu attacker có thể đã thay nameserver.
- Liên hệ registrar/provider support ngay nếu account hoặc domain control đã bị chiếm.
ICANN khuyến nghị tăng bảo vệ cho registration account và theo dõi các thay đổi domain; CISA khuyến nghị review DNS records, đổi password cho DNS accounts và bật MFA để giảm nguy cơ tái diễn. Nguồn: ICANN — Protecting Domain Accounts và CISA.
Khôi phục dịch vụ phải tính đến TTL và cache
Sau khi sửa authoritative record, một số resolver vẫn có thể giữ giá trị cũ cho tới khi TTL hết hạn. Vì vậy cần theo dõi authoritative answer và nhiều public resolver trong giai đoạn propagation, thay vì coi việc bấm “Save” trong control panel là hoàn tất.
Xem thêm Domain/DNS bị thay đổi trái phép, Audit DNS Record và DNS Change Management để chuẩn hóa snapshot, restore, read-back và rollback.
Validation sau remediation
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Authoritative DNS | Khớp baseline known-good |
| Public resolvers | Hội tụ về record đúng sau TTL |
| Website/API | Traffic về đúng origin/CDN |
| Email/MX | Mail flow về đúng provider |
| Registrar/DNS account | Password mới, MFA bật, token/session sạch |
| Audit log | Không còn unauthorized change event |
| Monitoring | Alert được kích hoạt nếu record lệch baseline |
Bài học vận hành và bước tiếp theo
- DNS là control plane quan trọng; application health không phản ánh DNS integrity.
- Authoritative read-back quan trọng hơn chỉ nhìn control panel.
- MFA và least privilege cho registrar/DNS account là baseline tối thiểu.
- Zone snapshot và change history giúp phân biệt lỗi vận hành với compromise.
- TTL ảnh hưởng recovery time sau khi record đã được sửa.
- DNS change monitoring nên theo dõi A/AAAA/CNAME/MX/NS và không chỉ một record website.
Để phát hiện sớm thay đổi trái phép, triển khai DNS Change Monitoring và cảnh báo khi authoritative records lệch khỏi baseline hoặc thay đổi ngoài maintenance window.