DNS-only là một trạng thái quen thuộc trong Cloudflare, nhưng khi được áp dụng ở phạm vi toàn account, mức độ ảnh hưởng sẽ lớn hơn rất nhiều. Thay vì chỉ thay đổi một bản ghi riêng lẻ, việc bật DNS-only toàn account có thể khiến nhiều domain, subdomain, API endpoint và hệ thống production cùng lúc đi thẳng về origin server, bỏ qua lớp reverse proxy của Cloudflare.
Với doanh nghiệp đang dùng Cloudflare cho CDN, WAF, DDoS protection, bot protection hoặc rule xử lý request tại edge, đây là một thao tác cần được kiểm soát bằng governance và runbook rõ ràng. LionTech khuyến nghị các doanh nghiệp Enterprise không nên xem DNS-only toàn account như một nút bật/tắt đơn giản, mà nên đưa vào kế hoạch incident response có điều kiện kích hoạt, phân quyền, checklist kiểm tra và quy trình rollback cụ thể.
Cơ chế bật DNS-only toàn account, đưa traffic đi thẳng về origin và làm giảm các lớp bảo vệ như cache, WAF, DDoS.
1. DNS-only toàn account trên Cloudflare là gì?
Trong Cloudflare, một DNS record có thể ở trạng thái Proxied hoặc DNS-only. Khi record được proxy, Cloudflare sẽ trả về Cloudflare anycast IP và traffic HTTP/HTTPS đi qua mạng lưới reverse proxy của Cloudflare. Khi record ở trạng thái DNS-only, DNS query sẽ trả về IP thật của origin server, đồng nghĩa traffic đi trực tiếp từ người dùng đến origin. Cloudflare cũng lưu ý rằng DNS-only record có thể làm lộ origin IP, khiến origin dễ bị nhắm trực tiếp hơn.
Ở cấp account, cơ chế Enforce DNS-only cho phép bypass reverse proxy của Cloudflare trên tất cả zone trong account bằng một hành động. Theo Cloudflare, khi bật setting này, Cloudflare sẽ phản hồi DNS query cho các record đang proxied bằng origin IP thay vì Cloudflare anycast IP. Đây là cơ chế “break-glass” dành cho incident response, không phải cấu hình vận hành hằng ngày.
Nói ngắn gọn: DNS-only toàn account là thao tác đưa traffic của nhiều hệ thống đi thẳng về origin, thay vì đi qua lớp bảo vệ và tối ưu của Cloudflare.
2. Vì sao DNS-only toàn account là thao tác rủi ro cao?
Với một record riêng lẻ, DNS-only có thể chỉ ảnh hưởng đến một service nhỏ. Nhưng ở cấp account, phạm vi tác động có thể bao gồm nhiều website, API, hệ thống nội bộ, landing page, môi trường staging hoặc production đang dùng chung account Cloudflare.
Điểm rủi ro nằm ở chỗ: nhiều doanh nghiệp không chỉ dùng Cloudflare để quản lý DNS, mà còn dùng Cloudflare như một lớp bảo mật và hiệu suất quan trọng. Khi bỏ qua reverse proxy, các lớp này có thể không còn nằm trên luồng traffic thực tế.
3. Các rủi ro chính khi bật DNS-only toàn account
3.1. Lộ origin IP trên diện rộng
Rủi ro đầu tiên và quan trọng nhất là origin IP bị lộ. Khi DNS-only được bật, truy vấn DNS có thể trả về IP thật của máy chủ gốc. Cloudflare khuyến nghị proxy các record khi có thể để ẩn origin IP và cung cấp DDoS protection; đồng thời cần rà soát các DNS-only record để tránh chứa thông tin origin IP.
Khi origin IP bị lộ, attacker có thể thử truy cập trực tiếp vào server, bỏ qua Cloudflare. Điều này đặc biệt nguy hiểm nếu doanh nghiệp đang phụ thuộc vào Cloudflare để lọc request độc hại, chặn bot, giảm tải DDoS hoặc áp dụng rule bảo mật.
Các hệ thống dễ bị ảnh hưởng gồm:
- Website thương mại điện tử có lưu lượng lớn.
- API backend đang được bảo vệ bằng WAF rule.
- Admin/CMS endpoint được che sau Cloudflare.
- Origin server chưa hardening đầy đủ.
- Hạ tầng dùng chung IP cho nhiều service.
3.2. Mất caching và tăng tải origin
Khi traffic đi qua Cloudflare proxy, một phần nội dung có thể được cache tại edge, giúp giảm số request về origin và cải thiện tốc độ tải. Cloudflare cũng mô tả proxied traffic được hưởng lợi từ cache mặc định, giúp tăng hiệu suất và giảm tổng số request về ứng dụng.
Khi bật DNS-only toàn account, lớp cache này không còn nằm trên đường đi của request. Điều đó có thể khiến origin phải xử lý nhiều traffic hơn bình thường.
Hệ quả có thể gặp:
- CPU/RAM trên origin tăng đột biến.
- Database chịu nhiều query hơn.
- Static assets không còn được phân phối qua edge cache.
- Thời gian phản hồi tăng tại các khu vực xa origin.
- Chi phí hạ tầng origin tăng nếu phải scale gấp.
Với website có traffic lớn, việc mất cache không chỉ là vấn đề hiệu suất, mà còn có thể trở thành rủi ro availability.
3.3. Không còn WAF trên luồng traffic trực tiếp
Cloudflare WAF cung cấp khả năng bảo vệ ứng dụng web trước lỗ hổng phổ biến và cho phép tạo custom rules để kiểm soát request. Tuy nhiên, các rule WAF này chỉ có ý nghĩa khi traffic đi qua Cloudflare.
Khi DNS-only toàn account được bật, request đi trực tiếp đến origin. Nếu origin không có lớp WAF riêng hoặc không có rule tương đương tại load balancer/application gateway, ứng dụng có thể mất một lớp bảo vệ quan trọng.
Các rủi ro thường gặp:
- Request độc hại không còn bị lọc tại edge.
- Rule chặn path nhạy cảm không còn tác dụng.
- Bot hoặc scanner có thể tiếp cận origin trực tiếp.
- Header-based security rule phụ thuộc Cloudflare có thể không hoạt động.
- Log bảo mật tại Cloudflare không còn phản ánh đầy đủ traffic HTTP/HTTPS.
3.4. Giảm hiệu quả DDoS mitigation
Một trong những lợi ích lớn khi proxy traffic qua Cloudflare là giúp chặn DDoS trước khi request đến origin. Cloudflare nêu rõ rằng khi traffic được proxy, Cloudflare có thể tự động ngăn DDoS attack trước khi chúng chạm đến ứng dụng và origin server.
Khi DNS-only được bật, traffic có thể đi trực tiếp về origin IP. Nếu attacker biết hoặc lấy được origin IP, họ có thể tấn công thẳng vào hạ tầng gốc, khiến doanh nghiệp khó tận dụng đầy đủ năng lực hấp thụ traffic của Cloudflare.
Điều này đặc biệt quan trọng với các doanh nghiệp có:
- Website public có lượng truy cập lớn.
- Hạ tầng origin đặt tại một region duy nhất.
- Load balancer chưa có DDoS protection riêng.
- Firewall origin chưa giới hạn nguồn truy cập.
- Ứng dụng nhạy cảm với traffic spike.
3.5. Sai lệch analytics, log và monitoring
Khi traffic đi qua Cloudflare, doanh nghiệp có thể sử dụng log, analytics, security events và các chỉ số edge để theo dõi hệ thống. Nhưng với DNS-only, Cloudflare không còn nhìn thấy đầy đủ HTTP/HTTPS request đi thẳng đến origin. Cloudflare cũng lưu ý rằng với DNS-only record, Cloudflare không thể cung cấp HTTP/HTTPS analytics cho các request đó mà chỉ có DNS analytics.
Điều này có thể gây khó khăn trong incident response:
- Security team không thấy đủ request ở Cloudflare dashboard.
- Log tại origin tăng mạnh nhưng thiếu ngữ cảnh edge.
- Dashboard hiệu suất bị lệch so với traffic thực tế.
- Alert dựa trên Cloudflare HTTP analytics có thể không kích hoạt.
- Việc truy vết request độc hại trở nên khó hơn.
3.6. Rủi ro SSL/TLS và cấu hình origin
Nhiều hệ thống được thiết kế với giả định traffic sẽ đi qua Cloudflare trước khi đến origin. Khi chuyển sang DNS-only, người dùng có thể kết nối trực tiếp đến origin, nên certificate, TLS version, redirect, HSTS, SNI và cấu hình web server tại origin phải sẵn sàng.
Nếu origin chỉ được cấu hình để nhận traffic từ Cloudflare, hoặc dùng certificate không phù hợp cho truy cập trực tiếp, người dùng có thể gặp lỗi kết nối.
Các vấn đề thường gặp:
- Certificate tại origin hết hạn hoặc không đúng hostname.
- TLS version/cipher không tương thích.
- Redirect loop do rule được đặt ở Cloudflare.
- Origin firewall đang chỉ allow Cloudflare IP.
- App phụ thuộc header do Cloudflare thêm vào.
4. Bảng tổng hợp rủi ro và cách kiểm soát
Rủi ro | Tác động chính | Cách chuẩn bị an toàn |
Lộ origin IP | Origin có thể bị truy cập trực tiếp | Hardening origin, firewall, rate limit, không để service nhạy cảm public |
Mất cache/CDN | Origin tăng tải, tốc độ giảm | Kiểm tra capacity, autoscaling, cache nội bộ, load test |
Mất WAF | Request độc hại có thể đến app trực tiếp | Có rule bảo vệ tại origin/load balancer, kiểm tra endpoint nhạy cảm |
Giảm DDoS mitigation | Origin dễ chịu traffic trực tiếp | Chỉ allow nguồn hợp lệ, có upstream protection, theo dõi traffic spike |
Sai lệch analytics | Khó điều tra sự cố | Bật log tại origin, SIEM, APM, centralized logging |
Lỗi SSL/TLS | Người dùng gặp lỗi bảo mật/kết nối | Kiểm tra certificate, TLS config, SNI, redirect trước khi bật |
Sai quy trình thao tác | Bật nhầm, quên rollback | Governance, API token giới hạn, approval, runbook rõ ràng |
Bảng này cho thấy vấn đề không chỉ nằm ở DNS. Khi bật DNS-only toàn account, doanh nghiệp đang thay đổi đường đi của traffic, kéo theo ảnh hưởng đến bảo mật, hiệu suất, logging và quy trình vận hành.
5. Checklist trước khi bật DNS-only toàn account
Trước khi đưa Enforce DNS-only hoặc bất kỳ cơ chế DNS-only diện rộng nào vào incident response plan, doanh nghiệp nên chuẩn bị checklist theo ba lớp: kỹ thuật, bảo mật và vận hành.
5.1. Checklist kỹ thuật
- Xác định account Cloudflare nào sẽ bị ảnh hưởng.
- Liệt kê toàn bộ zone và record đang proxied.
- Phân loại record production, staging, API, admin, static assets.
- Kiểm tra origin IP tương ứng với từng hệ thống.
- Xác nhận origin có thể nhận traffic trực tiếp.
- Kiểm tra SSL/TLS certificate tại origin.
- Kiểm tra redirect rule, cache rule, transform rule và origin rule đang phụ thuộc Cloudflare.
- Đánh giá capacity của origin nếu mất cache.
- Chuẩn bị rollback để khôi phục proxy sau sự cố.
5.2. Checklist bảo mật
- Kiểm tra origin firewall, security group và access control.
- Đảm bảo service nhạy cảm không public trực tiếp.
- Kiểm tra rate limit tại origin hoặc load balancer.
- Rà soát rule WAF quan trọng đang chạy ở Cloudflare.
- Xác định rule nào cần thay thế tạm thời ở origin.
- Bảo vệ API token dùng để bật/tắt setting.
- Chỉ cấp quyền thao tác cho nhóm được phê duyệt.
- Kiểm tra log truy cập origin và security event sau khi bật.
5.3. Checklist monitoring và logging
- Bật log đầy đủ tại load balancer, web server và application.
- Đảm bảo APM có thể theo dõi latency/error rate trực tiếp tại origin.
- Có dashboard riêng cho origin traffic.
- Có alert khi CPU, RAM, bandwidth, 5xx hoặc DB load tăng bất thường.
- Đánh dấu thời điểm bật/tắt DNS-only trong hệ thống monitoring.
- Đảm bảo SIEM hoặc log pipeline nhận dữ liệu từ origin.
5.4. Checklist vận hành
- Xác định rõ ai có quyền bật DNS-only toàn account.
- Xác định điều kiện nào được phép kích hoạt.
- Yêu cầu ticket sự cố hoặc approval trước khi bật.
- Có người chịu trách nhiệm quan sát hệ thống trong suốt thời gian bật.
- Có thời gian tối đa được phép duy trì trạng thái DNS-only.
- Có bước xác nhận trước khi rollback.
- Có báo cáo post-incident sau khi hoàn tất.
6. Use case: Doanh nghiệp cần cô lập lỗi nhưng không muốn tạo thêm rủi ro
Một doanh nghiệp vận hành nhiều website và API trên cùng một Cloudflare account gặp lỗi production bất thường. Một số request từ người dùng bị timeout, nhưng đội kỹ thuật chưa xác định được lỗi đến từ Cloudflare rule, cache, origin, load balancer hay application.
Trong tình huống này, DNS-only toàn account có thể giúp kiểm tra nhanh đường traffic đi trực tiếp về origin. Tuy nhiên, nếu bật ngay mà không chuẩn bị, doanh nghiệp có thể khiến origin IP bị lộ, cache bị bỏ qua, WAF không còn tác dụng và origin chịu tải đột ngột.
Cách tiếp cận an toàn hơn là đưa thao tác này vào runbook:
- Xác nhận sự cố ảnh hưởng diện rộng.
- Kiểm tra origin capacity và trạng thái SSL/TLS.
- Đảm bảo firewall không chặn traffic hợp lệ.
- Tạm thời tăng monitoring tại origin.
- Kích hoạt DNS-only theo quy trình đã được phê duyệt.
- So sánh error rate, latency và log giữa hai trạng thái.
- Tắt DNS-only sau khi có đủ dữ liệu điều tra.
- Ghi nhận nguyên nhân và cập nhật runbook.
Điểm cốt lõi là không dùng DNS-only toàn account như một phản xạ tức thời, mà dùng nó như một bước kiểm tra có kiểm soát trong quá trình incident isolation.
So sánh luồng Proxied có bảo vệ edge với luồng DNS-only dùng tạm thời để cô lập sự cố origin.
7. Governance: Vì sao Enterprise cần quy trình rõ ràng?
Ở quy mô Enterprise, một thao tác hạ tầng nhỏ có thể ảnh hưởng đến nhiều team: DevOps, security, backend, marketing website, data, customer support và cả người dùng cuối. Vì vậy, bật DNS-only toàn account không nên phụ thuộc vào kinh nghiệm cá nhân của một kỹ sư, mà cần có governance rõ ràng.
7.1. Những câu hỏi governance cần trả lời
- Ai được quyền kích hoạt DNS-only toàn account?
- Kích hoạt trong trường hợp nào?
- Có cần approval từ security hoặc infrastructure lead không?
- Thời gian tối đa được phép duy trì là bao lâu?
- Ai chịu trách nhiệm theo dõi hệ thống sau khi bật?
- Khi nào phải rollback?
- Log thao tác được lưu ở đâu?
- Sau sự cố, ai cập nhật lại runbook?
7.2. API token và phân quyền
Vì Enforce DNS-only là thao tác cấp account, API token cần được kiểm soát nghiêm ngặt. Không nên dùng token có quyền quá rộng hoặc lưu token trong script thiếu bảo mật.
Doanh nghiệp nên:
- Dùng API token có quyền tối thiểu cần thiết.
- Lưu token trong secret manager hoặc vault.
- Không chia sẻ token qua chat/email.
- Có quy trình rotate token định kỳ.
- Thu hồi token ngay khi nghi ngờ rò rỉ.
- Theo dõi audit log liên quan đến thao tác cấu hình DNS.
8. Runbook đề xuất khi cần bật DNS-only toàn account
Một runbook tốt không chỉ ghi “bật/tắt ở đâu”, mà phải mô tả đầy đủ điều kiện, người chịu trách nhiệm, bước kiểm tra và rollback.
8.1. Trước khi bật
- Xác nhận sự cố và mức độ ảnh hưởng.
- Xác định mục tiêu của việc bật DNS-only.
- Kiểm tra origin health.
- Kiểm tra capacity và autoscaling.
- Kiểm tra SSL/TLS.
- Kiểm tra firewall và access control.
- Thông báo cho các team liên quan.
- Bật chế độ theo dõi tăng cường.
8.2. Trong khi bật
- Ghi nhận thời điểm kích hoạt.
- Theo dõi error rate, latency, bandwidth và origin load.
- Kiểm tra log bảo mật tại origin.
- So sánh hành vi người dùng trước và sau khi bật.
- Không thay đổi thêm nhiều cấu hình song song nếu không cần thiết.
- Chuẩn bị rollback nếu có dấu hiệu rủi ro.
8.3. Sau khi tắt
- Xác nhận traffic đã quay lại luồng proxy bình thường.
- Kiểm tra WAF, cache, DDoS protection và rule tại edge.
- Đối chiếu log Cloudflare và origin.
- Kiểm tra có origin IP nào bị public ngoài ý muốn không.
- Tổng hợp timeline sự cố.
- Cập nhật runbook dựa trên bài học thực tế.
9. Có nên dùng DNS-only toàn account thường xuyên không?
Không nên.
DNS-only toàn account nên được xem là một cơ chế khẩn cấp hoặc kiểm tra có kiểm soát, không phải mô hình vận hành mặc định. Trong điều kiện bình thường, các website và ứng dụng public nên tiếp tục được proxy qua Cloudflare nếu doanh nghiệp đang cần cache, WAF, DDoS mitigation, bot protection và khả năng ẩn origin IP.
Chỉ nên dùng DNS-only toàn account khi:
- Có mục tiêu kỹ thuật rõ ràng.
- Origin đã được chuẩn bị để nhận traffic trực tiếp.
- Có approval từ người chịu trách nhiệm.
- Có monitoring đầy đủ.
- Có thời gian rollback cụ thể.
- Có post-incident review sau đó.
10. Kết luận: DNS-only toàn account cần đi kèm governance và runbook
Bật DNS-only toàn account trên Cloudflare có thể hữu ích trong một số tình huống khẩn cấp, đặc biệt khi doanh nghiệp cần bypass reverse proxy để cô lập lỗi hoặc kiểm tra origin. Tuy nhiên, thao tác này cũng có thể làm lộ origin IP, mất cache, mất WAF, giảm hiệu quả DDoS mitigation và khiến monitoring bị sai lệch.
Với doanh nghiệp Enterprise, điểm quan trọng không chỉ là “có dùng được tính năng hay không”, mà là dùng trong điều kiện nào, ai được phép dùng, kiểm tra gì trước khi bật và rollback ra sao. Một runbook rõ ràng sẽ giúp đội kỹ thuật phản ứng nhanh hơn nhưng vẫn kiểm soát được rủi ro.
Nếu doanh nghiệp đang vận hành nhiều domain, nhiều ứng dụng hoặc nhiều môi trường production trên Cloudflare, LionTech có thể hỗ trợ rà soát cấu hình hiện tại, xây dựng governance và thiết kế runbook incident response phù hợp với mô hình vận hành thực tế.
Liên hệ với LionTech tại:
- SDT: (+84) 98 269 1932
- Email: support@liontech.vn
- Website: liontech.vn
- Fanpage: facebook.com/liontech.vn
- Linked In: company/liontech-vn
Được gắn thẻ bởi:
