Trong hầu hết mô hình triển khai Cloudflare, reverse proxy là lớp trung gian quan trọng giúp website và ứng dụng được bảo vệ, tối ưu hiệu suất, cache nội dung và ẩn origin IP khỏi Internet công khai. Tuy nhiên, trong một số tình huống khẩn cấp, doanh nghiệp có thể cần tạm thời bỏ qua lớp proxy này để đưa traffic đi thẳng về origin server, phục vụ việc cô lập lỗi, kiểm tra hạ tầng hoặc xử lý sự cố ngoài dự kiến.
Đó là lý do Account-level Enforce DNS-only được xem như một “kill switch” DNS ở cấp tài khoản. Đây là cơ chế API-only cho phép doanh nghiệp nhanh chóng buộc toàn bộ các bản ghi proxied trong account hoạt động như DNS-only mà không cần chỉnh từng record thủ công. Với những hệ thống quan trọng, LionTech khuyến nghị tính năng này nên được đặt trong một kế hoạch incident response rõ ràng, thay vì chỉ xem như một nút bật/tắt kỹ thuật khi có sự cố.
Cơ chế tắt reverse proxy cấp account, chuyển DNS sang origin IP khi cần xử lý sự cố khẩn cấp.
1. Account-level Enforce DNS-only là gì?
Account-level Enforce DNS-only là một thiết lập ở cấp account của Cloudflare, cho phép bypass reverse proxy của Cloudflare trên tất cả zone trong cùng tài khoản chỉ bằng một hành động. Khi được bật, Cloudflare sẽ phản hồi truy vấn DNS của các bản ghi đang proxied bằng origin IP address hoặc CNAME target thật, thay vì trả về Cloudflare anycast IP như bình thường.
Điểm quan trọng là tính năng này không sửa trực tiếp cấu hình DNS record. Các record vẫn có thể đang ở trạng thái proxied trong dashboard, nhưng ở lớp phục vụ DNS tại edge, Cloudflare sẽ ép chúng hoạt động như DNS-only. Khi tắt setting này, hành vi proxy ban đầu có thể được khôi phục mà không cần bật lại từng record riêng lẻ.
Nói cách khác, đây không phải là một cách cấu hình DNS hằng ngày, mà là một cơ chế “break-glass” dùng trong tình huống đặc biệt: khi doanh nghiệp cần chuyển hướng traffic ra khỏi lớp reverse proxy của Cloudflare thật nhanh để phục vụ xử lý sự cố.
- Vì sao tính năng này được gọi là “kill switch” DNS?
Trong vận hành hệ thống, “kill switch” thường được hiểu là một cơ chế can thiệp nhanh để tạm dừng, vô hiệu hóa hoặc chuyển hướng một lớp xử lý nào đó khi có rủi ro. Với Cloudflare, Account-level Enforce DNS-only đóng vai trò như một kill switch cho lớp reverse proxy.
Thay vì phải vào từng zone, tìm từng DNS record và chuyển từng bản ghi từ “Proxied” sang “DNS-only”, đội vận hành có thể dùng API để áp dụng override ở cấp account. Điều này đặc biệt hữu ích với doanh nghiệp có nhiều domain, nhiều subdomain, nhiều môi trường production, staging, API hoặc microservices chạy cùng lúc.
Tuy nhiên, vì phạm vi tác động rất rộng, tính năng này cũng tiềm ẩn rủi ro lớn nếu dùng sai thời điểm. Khi bật Enforce DNS-only, origin IP có thể được trả trực tiếp cho người dùng, đồng nghĩa nhiều lớp bảo vệ và tối ưu của Cloudflare sẽ không còn nằm trên luồng traffic HTTP/HTTPS.
2. Cách Cloudflare proxy hoạt động trước khi bật Enforce DNS-only
Để hiểu rõ tính năng này, cần phân biệt hai trạng thái phổ biến của DNS record trong Cloudflare: Proxied và DNS-only.
Khi một bản ghi ở trạng thái Proxied, Cloudflare đứng giữa người dùng và origin server. Người dùng truy cập website thông qua Cloudflare anycast IP, sau đó Cloudflare mới chuyển tiếp request về máy chủ gốc. Nhờ đó, doanh nghiệp có thể tận dụng các lớp bảo vệ và tối ưu như CDN, cache, WAF, DDoS protection, bot mitigation, SSL/TLS và các rule xử lý request.
Ngược lại, khi một bản ghi ở trạng thái DNS-only, Cloudflare chỉ đóng vai trò phân giải DNS. Truy vấn DNS sẽ trả về IP thật của origin server, còn traffic HTTP/HTTPS sẽ đi trực tiếp từ người dùng đến origin, không đi qua mạng lưới reverse proxy của Cloudflare.
So sánh Proxied, DNS-only và Enforce DNS-only
Tiêu chí | Proxied | DNS-only thông thường | Account-level Enforce DNS-only |
Cách hoạt động | Traffic đi qua Cloudflare reverse proxy | DNS trả origin IP, traffic đi thẳng tới origin | Ép toàn account trả origin IP cho các record đang proxied |
Phạm vi áp dụng | Theo từng DNS record | Theo từng DNS record | Cấp account |
Có dùng CDN/cache không? | Có | Không | Không, trong thời gian setting được bật |
Có dùng WAF/Bot/DDoS layer 7 không? | Có | Không | Không, với traffic đi thẳng origin |
Có ẩn origin IP không? | Có, nếu cấu hình đúng | Không | Không |
Cách bật/tắt | Dashboard hoặc API theo record | Dashboard hoặc API theo record | API-only |
Mục đích phù hợp | Vận hành production thông thường | Dịch vụ không cần proxy hoặc không hỗ trợ proxy | Incident response, kiểm tra sự cố, bypass khẩn cấp |
Bảng trên cho thấy Account-level Enforce DNS-only không thay thế cấu hình DNS thông thường. Nó là một cơ chế override tạm thời, phù hợp với đội ngũ hạ tầng, DevOps, SRE hoặc security team trong các tình huống cần phản ứng nhanh.
3. Account-level Enforce DNS-only hoạt động như thế nào?
Về bản chất, Enforce DNS-only không đi vào từng zone để đổi trạng thái “đám mây cam” thành “đám mây xám”. Thay vào đó, nó hoạt động ở cấp account setting.
Khi setting này được bật:
- Các bản ghi A, AAAA, CNAME đang proxied sẽ được Cloudflare phục vụ như DNS-only tại edge.
- DNS response sẽ trả về origin IP hoặc CNAME target thật.
- HTTP/HTTPS traffic sẽ không còn đi qua Cloudflare reverse proxy.
- Các record gốc không bị chỉnh sửa trong cấu hình DNS.
- Khi tắt setting, hành vi proxy ban đầu có thể được khôi phục theo trạng thái record trước đó.
Theo tài liệu Cloudflare, chỉ các record phục vụ phân giải IP như A, AAAA và CNAME mới có thể được proxy; các loại record khác như MX hoặc TXT vốn đã luôn là DNS-only.
- Vì sao Cloudflare thiết kế tính năng này ở dạng API-only?
Việc chỉ cho phép thao tác qua API giúp giảm rủi ro bật nhầm trên dashboard. Đây là tính năng có phạm vi ảnh hưởng rất lớn, nên không phù hợp để đặt như một nút thao tác phổ thông cho mọi người dùng trong giao diện quản trị.
API-only cũng phù hợp hơn với quy trình incident response chuyên nghiệp. Doanh nghiệp có thể tích hợp hành động này vào runbook, automation script, hệ thống phê duyệt nội bộ hoặc quy trình break-glass có kiểm soát.
Ví dụ, thay vì để bất kỳ quản trị viên nào bật/tắt thủ công, doanh nghiệp có thể quy định:
- Chỉ một nhóm kỹ thuật nhất định có API token phù hợp.
- Mỗi lần kích hoạt phải có ticket sự cố.
- Hành động bật/tắt được log lại.
- Sau khi bật phải có checklist kiểm tra origin, firewall, SSL và monitoring.
- Sau khi xử lý xong phải có bước khôi phục proxy và đánh giá hậu sự cố.
4. Khi nào doanh nghiệp có thể cần bật Enforce DNS-only?
Không phải sự cố nào cũng cần dùng đến Account-level Enforce DNS-only. Trong nhiều trường hợp, các công cụ khác của Cloudflare như WAF rule, Page Rule, Cache Rule, Origin Rule, Load Balancing, Health Check hoặc cấu hình DNS theo từng record đã đủ để xử lý vấn đề.
Tính năng này chỉ nên được cân nhắc khi doanh nghiệp thật sự cần bypass Cloudflare reverse proxy ở phạm vi rộng.
Một số tình huống có thể cân nhắc
Tình huống | Vì sao có thể cần Enforce DNS-only? | Lưu ý quan trọng |
Cần xác định lỗi đến từ Cloudflare layer hay origin | Bypass proxy giúp kiểm tra traffic đi trực tiếp về origin | Phải bảo đảm origin chịu được tải và được bảo vệ |
Sự cố cấu hình proxy ảnh hưởng nhiều zone | Áp dụng cấp account nhanh hơn chỉnh từng record | Cần kiểm soát phạm vi và thời gian bật |
Cần route traffic trực tiếp trong quá trình khẩn cấp | Giảm phụ thuộc vào lớp reverse proxy để cô lập sự cố | Có thể mất WAF, cache, CDN và bảo vệ layer 7 |
Kiểm tra hệ thống failover hoặc DR | Cho phép đánh giá khả năng origin phục vụ trực tiếp | Không nên thử nghiệm trên production nếu chưa có kế hoạch |
Sự cố automation làm sai proxy config trên nhiều zone | Override tạm thời trong khi khôi phục cấu hình | Cần rollback sau khi xử lý xong |
Điểm cần nhấn mạnh là Enforce DNS-only không tự động “sửa lỗi”. Nó chỉ thay đổi đường đi của traffic. Nếu origin server đang yếu, chưa được hardening hoặc firewall chỉ cho phép traffic từ Cloudflare IP, việc bật tính năng này có thể làm phát sinh lỗi mới.
5. Rủi ro khi bật Account-level Enforce DNS-only
Vì tính năng này đưa traffic đi thẳng về origin, doanh nghiệp cần hiểu rõ các rủi ro trước khi đưa vào quy trình vận hành.
5.1. Origin IP có thể bị lộ
Khi record hoạt động như DNS-only, DNS response sẽ trả về IP thật của origin. Điều này làm mất lợi ích ẩn origin IP mà nhiều doanh nghiệp đang tận dụng khi dùng Cloudflare proxy.
Nếu origin IP bị lộ, attacker có thể cố gắng truy cập trực tiếp vào server, bỏ qua các lớp kiểm soát đang được áp dụng ở Cloudflare edge. Vì vậy, trước khi dùng Enforce DNS-only, doanh nghiệp cần bảo đảm origin vẫn có firewall, rate limit, access control và monitoring phù hợp.
5.2. Mất lớp bảo vệ reverse proxy
Khi traffic không còn đi qua Cloudflare, các lớp bảo vệ và tối ưu ở tầng proxy sẽ không còn được áp dụng cho luồng truy cập đó. Điều này có thể ảnh hưởng đến:
- WAF rule
- Bot protection
- DDoS protection ở layer 7
- Cache/CDN
- Transform Rule
- Redirect Rule chạy tại edge
- Header modification
- Một số rule bảo mật hoặc routing phụ thuộc Cloudflare proxy
Nếu hệ thống đang phụ thuộc mạnh vào các rule tại Cloudflare edge, việc bật Enforce DNS-only có thể khiến ứng dụng hoạt động khác so với bình thường.
5.3. Origin server có thể bị quá tải
Khi dùng Cloudflare CDN/cache, một phần request được xử lý tại edge, giúp giảm tải cho origin. Nếu bypass proxy, toàn bộ request có thể đi trực tiếp về máy chủ gốc. Với website có lưu lượng lớn, điều này có thể khiến origin tăng tải đột ngột.
Doanh nghiệp cần kiểm tra trước:
- Origin có đủ tài nguyên CPU/RAM/network không?
- Có autoscaling hoặc load balancer phía sau không?
- Có rate limit ở origin không?
- Có cơ chế caching nội bộ không?
- Database có chịu được traffic tăng bất thường không?
5.4. Vấn đề SSL/TLS và certificate
Khi traffic đi qua Cloudflare, doanh nghiệp có thể dùng nhiều chế độ SSL/TLS khác nhau giữa client, Cloudflare và origin. Nhưng khi traffic đi trực tiếp tới origin, certificate tại origin phải hợp lệ với người dùng cuối.
Nếu origin chỉ dùng certificate nội bộ, certificate hết hạn hoặc cấu hình TLS không tương thích, người dùng có thể gặp lỗi bảo mật trên trình duyệt. Đây là lý do SSL/TLS cần nằm trong checklist trước khi bật Enforce DNS-only.
6. Use case 1: Bypass nhanh Cloudflare proxy để cô lập lỗi production
Một doanh nghiệp vận hành nhiều website thương mại điện tử qua Cloudflare nhận thấy một số request checkout bị lỗi không ổn định. Đội kỹ thuật cần xác định lỗi đến từ ứng dụng gốc, load balancer, rule tại edge hay một cấu hình proxy nào đó.
Nếu chỉ có một vài record bị ảnh hưởng, đội kỹ thuật có thể chuyển DNS-only theo từng record. Nhưng nếu sự cố lan rộng trên nhiều zone hoặc nhiều subdomain, thao tác thủ công sẽ mất thời gian và dễ sai sót.
Trong trường hợp này, Enforce DNS-only có thể được dùng như một bước trong runbook khẩn cấp:
- Xác nhận sự cố ảnh hưởng diện rộng.
- Kiểm tra origin có sẵn sàng nhận traffic trực tiếp.
- Kích hoạt Enforce DNS-only qua API.
- Theo dõi error rate, latency, request volume và log tại origin.
- So sánh hành vi khi traffic đi trực tiếp với khi đi qua Cloudflare.
- Tắt Enforce DNS-only sau khi đã cô lập được nguyên nhân.
- Khôi phục proxy và ghi nhận bài học sau sự cố.
Giá trị của use case này không nằm ở việc “tắt Cloudflare”, mà nằm ở khả năng tạo một đường kiểm chứng nhanh để xác định sự cố đang nằm ở lớp nào trong kiến trúc.
7. Use case 2: Kiểm tra kế hoạch disaster recovery cho nhiều domain
Với doanh nghiệp có nhiều domain, nhiều hệ thống chạy trên cùng Cloudflare account, kế hoạch disaster recovery không nên chỉ dừng ở việc backup dữ liệu. Doanh nghiệp cũng cần biết điều gì xảy ra nếu traffic không còn đi qua lớp proxy như bình thường.
Enforce DNS-only có thể được đưa vào một bài kiểm tra DR có kiểm soát, không nhất thiết chạy trên toàn bộ production ngay từ đầu. Ví dụ, doanh nghiệp có thể thử nghiệm trên một nhóm zone ít rủi ro, một môi trường staging hoặc một khoảng thời gian bảo trì đã thông báo trước.
Mục tiêu của bài kiểm tra gồm:
- Origin có truy cập trực tiếp được không?
- Firewall có đang chặn toàn bộ request ngoài Cloudflare IP không?
- Certificate tại origin có hợp lệ không?
- Ứng dụng có phụ thuộc header từ Cloudflare không?
- Redirect, cache, security rule có bị ảnh hưởng không?
- Monitoring có nhận diện đúng traffic direct-to-origin không?
Qua đó, doanh nghiệp sẽ biết hệ thống có thật sự sẵn sàng cho tình huống break-glass hay không. Đây là cách tiếp cận chủ động hơn so với việc chỉ phát hiện vấn đề khi sự cố đã xảy ra.
Luồng xử lý sự cố khi bypass reverse proxy, đưa traffic đi trực tiếp về origin IP qua DNS-only.
8. Checklist trước khi đưa Enforce DNS-only vào incident response plan
Vì đây là tính năng có tác động lớn, doanh nghiệp không nên chờ đến lúc có sự cố mới bắt đầu tìm hiểu. Thay vào đó, nên xây dựng checklist rõ ràng từ trước.
8.1. Checklist kỹ thuật
- Xác định account, zone và nhóm hệ thống chịu ảnh hưởng.
- Kiểm tra danh sách record đang proxied.
- Đánh giá origin nào có thể nhận traffic trực tiếp.
- Đảm bảo origin có certificate hợp lệ.
- Kiểm tra firewall, security group, allowlist và rate limit tại origin.
- Xác định rule nào đang phụ thuộc Cloudflare proxy.
- Kiểm tra năng lực chịu tải của origin nếu mất cache/CDN.
- Chuẩn bị lệnh API bật/tắt và quy trình rollback.
- Thiết lập monitoring cho DNS response, error rate, latency và origin load.
8.2. Checklist vận hành
- Quy định ai có quyền kích hoạt.
- Quy định khi nào được phép kích hoạt.
- Yêu cầu ticket hoặc biên bản sự cố trước khi bật.
- Ghi log người thao tác, thời gian thao tác và lý do thao tác.
- Có người chịu trách nhiệm theo dõi sau khi bật.
- Có bước xác nhận trước khi tắt và khôi phục proxy.
- Có báo cáo post-incident sau khi hoàn tất xử lý.
8.3. Checklist bảo mật
- Không dùng API token quá rộng quyền nếu không cần thiết.
- Giới hạn quyền API theo vai trò.
- Bảo vệ API token bằng secret manager hoặc vault.
- Không lưu token trong script công khai.
- Có cơ chế thu hồi token nếu nghi ngờ rò rỉ.
- Kiểm tra log truy cập API định kỳ.
- Đảm bảo origin không phụ thuộc hoàn toàn vào Cloudflare để chống truy cập trái phép.
9. Doanh nghiệp có nên bật sẵn Enforce DNS-only không?
Câu trả lời là không nên bật sẵn. Đây không phải là một trạng thái vận hành mặc định, mà là một công cụ khẩn cấp.
Trong điều kiện bình thường, phần lớn website và ứng dụng nên tiếp tục đi qua Cloudflare proxy để tận dụng các lớp bảo vệ và tối ưu. Enforce DNS-only chỉ nên được dùng khi có lý do rõ ràng, có người chịu trách nhiệm, có checklist kiểm tra và có kế hoạch khôi phục.
Cách tiếp cận hợp lý là:
- Không bật mặc định.
- Không giao quyền API rộng cho quá nhiều người.
- Không dùng thay cho cấu hình DNS theo từng record.
- Không dùng nếu origin chưa sẵn sàng nhận traffic trực tiếp.
- Chỉ đưa vào runbook incident response với điều kiện kích hoạt rõ ràng.
10. Kết luận: Enforce DNS-only mạnh, nhưng phải có quy trình
Account-level Enforce DNS-only là một tính năng nhỏ về mặt giao diện, nhưng có ý nghĩa lớn trong vận hành hệ thống Cloudflare ở quy mô doanh nghiệp. Nó cho phép bypass reverse proxy trên toàn account trong tình huống khẩn cấp, giúp đội kỹ thuật nhanh chóng cô lập sự cố, kiểm tra origin hoặc thực hiện một phần kế hoạch disaster recovery.
Tuy nhiên, đây cũng là tính năng có rủi ro cao nếu dùng thiếu kiểm soát. Việc trả origin IP trực tiếp có thể làm mất lớp bảo vệ reverse proxy, ảnh hưởng đến WAF, cache, bot protection, SSL/TLS, routing rule và năng lực chịu tải của origin. Vì vậy, Enforce DNS-only không nên được xem là một thao tác đơn lẻ, mà cần nằm trong một incident response plan được thiết kế trước.
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ợ đánh giá cấu hình hiện tại, xây dựng kịch bản ứng phó sự cố và thiết kế quy trình sử dụng Cloudflare an toàn hơn trong các tình huống khẩn cấp.
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:
