\n BlueFox Security is a blog about networking, cybersecurity, and IT.\n It shares practical insights, technical guides, and real-world experiences around\n secure infrastructure, modern networks, and everyday IT challenges.\n
\nWhen a FortiGate is in factory-default state, FortiOS can provide a range of TCP and UDP ports to support management, updates, registration, logging, VPN, high availability, and integration with other Fortinet products. However, the most important takeaway is this: many of these ports are not active, visible, or relevant by default. They typically only appear when the corresponding feature is actually being used.
This distinction matters. The diagram is best understood not as a static list of permanently open ports, but as a functional communication map that shows which protocols FortiOS may use depending on the enabled services and deployment design.
Key point: The TCP and UDP ports shown in the overview are not necessarily exposed by default. Many of them only become visible or relevant when the associated FortiOS function is configured and actively used.
During initial deployment, staging, troubleshooting, proof-of-concept testing, or after a factory reset, it is important to understand which communications a FortiGate may require. Without that visibility, teams often run into issues such as:
At the same time, security teams should avoid jumping to the conclusion that every documented port equals a permanent attack surface. In many cases, the communication is feature-driven, outbound, or only used internally between Fortinet components.
The provided image places FortiGate at the center and maps communications to surrounding systems and services. On the left-hand side, the diagram highlights interactions with components such as FortiAP-S, FortiAuthenticator, FortiClient, FortiGuard, FortiManager, FortiPortal, third-party servers, and general management functions. On the right-hand side, the diagram adds integrations including FortiAnalyzer, FortiToken, FortiGate Cloud, FortiCloud, FortiManager, and FortiSandbox.
One of the biggest misconceptions in firewall reviews is to assume that every port listed in a vendor communication matrix is always open and listening. That is not an accurate reading of this FortiGate overview.
Instead, the image illustrates the broader set of communications FortiOS may use under certain conditions:
That makes the diagram especially useful for planning and troubleshooting, but potentially misleading if interpreted as a simple list of permanently active listeners.
Basic management functions commonly rely on TCP/80 and TCP/443. These ports may be used for web administration, API access, portal-related features, policy override functions, and SSL-based management workflows.
In practice, TCP/443 appears repeatedly across the diagram because it is used for multiple FortiOS capabilities beyond the GUI alone.
As soon as remote connectivity is enabled, traditional VPN-related protocols become relevant:
A factory-default FortiGate is capable of supporting these functions, but the ports only matter operationally once the corresponding VPN services are configured and used.
The image also references HA-related connectivity, including specialized HA heartbeat EtherTypes (0x8890, 0x8891, 0x8893) as well as TCP/703 and UDP/703. For Azure scenarios, the diagram additionally shows UDP/730 for unicast heartbeat and UDP/53 for DNS.
This is a strong reminder that HA deployments require more than just basic management access. Cloud-specific HA designs may also introduce additional dependencies.
FortiGate systems can interact with a broad set of FortiGuard and cloud-backed services. The image includes examples such as TCP/541, UDP/9443, UDP/53, UDP/8888, TCP/53, TCP/8888, TCP/443, TCP/80, TCP/25, TCP/9582, and TCP/8890.
Depending on enabled services, these may support antivirus and IPS updates, cloud app database access, licensing, firmware workflows, central analysis, mail services, quarantine actions, contract validation, and virus sample uploads.
The diagram shows communication paths to FortiAnalyzer, FortiGate Cloud, FortiClient Cloud, and FortiSandbox. Ports such as TCP/514, TCP/443, and TCP/541 appear in this context, depending on the service being used.
This highlights another architectural point: even a reset device is designed to fit into a larger ecosystem of monitoring, reporting, management, and cloud-assisted security services.
Authentication-related integrations significantly expand the communication matrix. The image includes the following examples:
These ports become relevant only when FortiGate is integrated with identity providers, endpoint compliance checks, SSO frameworks, or captive portal workflows.
For new FortiGate deployments, the image communicates four practical lessons:
A FortiGate in factory-reset state is not simply a box with a few administrative ports. It is a platform built to support a wide range of security, management, cloud, logging, authentication, and high-availability functions. The communication overview in the image is therefore best understood as a map of potential FortiOS interactions.
The key conclusion is straightforward:
Many of the TCP and UDP ports shown are not visible or active by default. They typically become relevant only when the corresponding function is enabled and used.","content_text":"FORTIGATE IN FACTORY RESET: UNDERSTANDING TCP AND UDP PORTS IN FORTIOS\n\nWhen a FortiGate is in factory-default state, FortiOS can provide a range of TCP\nand UDP ports to support management, updates, registration, logging, VPN, high\navailability, and integration with other Fortinet products. However, the most\nimportant takeaway is this: many of these ports are not active, visible, or\nrelevant by default. They typically only appear when the corresponding feature\nis actually being used.\n\nThis distinction matters. The diagram is best understood not as a static list of\npermanently open ports, but as a functional communication map that shows which\nprotocols FortiOS may use depending on the enabled services and deployment\ndesign.\n\n> Key point: The TCP and UDP ports shown in the overview are not necessarily\n> exposed by default. Many of them only become visible or relevant when the\n> associated FortiOS function is configured and actively used.\n\n\nWHY THIS MATTERS\n\nDuring initial deployment, staging, troubleshooting, proof-of-concept testing,\nor after a factory reset, it is important to understand which communications a\nFortiGate may require. Without that visibility, teams often run into issues such\nas:\n\n * failed device registration,\n * missing FortiGuard updates,\n * FortiManager or FortiAnalyzer connectivity problems,\n * VPN setup failures,\n * HA synchronization issues,\n * authentication or FSSO malfunctions,\n * or firewall rules that are too restrictive for intended features.\n\nAt the same time, security teams should avoid jumping to the conclusion that\nevery documented port equals a permanent attack surface. In many cases, the\ncommunication is feature-driven, outbound, or only used internally between\nFortinet components.\n\n\n\n\n\nWHAT THE DIAGRAM SHOWS\n\nThe provided image places FortiGate at the center and maps communications to\nsurrounding systems and services. On the left-hand side, the diagram highlights\ninteractions with components such as FortiAP-S, FortiAuthenticator, FortiClient,\nFortiGuard, FortiManager, FortiPortal, third-party servers, and general\nmanagement functions. On the right-hand side, the diagram adds integrations\nincluding FortiAnalyzer, FortiToken, FortiGate Cloud, FortiCloud, FortiManager,\nand FortiSandbox.\n\n\nEXAMPLES VISIBLE IN THE IMAGE\n\n * Web administration: TCP/80, TCP/443\n * Remote IPsec VPN: UDP/500, UDP/4500, ESP (IP 50)\n * Remote SSL VPN: TCP/443\n * HA synchronization: TCP/703, UDP/703, special HA EtherTypes 0x8890, 0x8891,\n 0x8893\n * FortiGuard: TCP/541, UDP/9443\n * FortiManager: TCP/541, TCP/542, TCP/443\n * FSSO / identity-related functions: TCP/8000, TCP/8001, UDP/1812, UDP/1813,\n TCP/1700, TCP/443\n\n\nTHE MOST IMPORTANT PRINCIPLE: FEATURE-DEPENDENT PORT USAGE\n\nOne of the biggest misconceptions in firewall reviews is to assume that every\nport listed in a vendor communication matrix is always open and listening. That\nis not an accurate reading of this FortiGate overview.\n\nInstead, the image illustrates the broader set of communications FortiOS may use\nunder certain conditions:\n\n * Some ports are only used when a specific feature is configured.\n * Some communications are outbound rather than inbound.\n * Some are only relevant in clustered, cloud, or centrally managed deployments.\n * Some exist solely for integration with other Fortinet components.\n\nThat makes the diagram especially useful for planning and troubleshooting, but\npotentially misleading if interpreted as a simple list of permanently active\nlisteners.\n\n\n\n\n\nKEY COMMUNICATION AREAS\n\n\n1. MANAGEMENT AND ADMINISTRATIVE ACCESS\n\nBasic management functions commonly rely on TCP/80 and TCP/443. These ports may\nbe used for web administration, API access, portal-related features, policy\noverride functions, and SSL-based management workflows.\n\nIn practice, TCP/443 appears repeatedly across the diagram because it is used\nfor multiple FortiOS capabilities beyond the GUI alone.\n\n\n\n\n\n2. VPN SERVICES\n\nAs soon as remote connectivity is enabled, traditional VPN-related protocols\nbecome relevant:\n\n * IKE: UDP/500\n * NAT Traversal: UDP/4500\n * ESP: IP protocol 50\n * SSL VPN: TCP/443\n\nA factory-default FortiGate is capable of supporting these functions, but the\nports only matter operationally once the corresponding VPN services are\nconfigured and used.\n\n\n\n\n\n3. HIGH AVAILABILITY AND CLUSTER COMMUNICATION\n\nThe image also references HA-related connectivity, including specialized HA\nheartbeat EtherTypes (0x8890, 0x8891, 0x8893) as well as TCP/703 and UDP/703.\nFor Azure scenarios, the diagram additionally shows UDP/730 for unicast\nheartbeat and UDP/53 for DNS.\n\nThis is a strong reminder that HA deployments require more than just basic\nmanagement access. Cloud-specific HA designs may also introduce additional\ndependencies.\n\n\n\n\n\n4. FORTIGUARD, LICENSING, AND SECURITY SERVICES\n\nFortiGate systems can interact with a broad set of FortiGuard and cloud-backed\nservices. The image includes examples such as TCP/541, UDP/9443, UDP/53,\nUDP/8888, TCP/53, TCP/8888, TCP/443, TCP/80, TCP/25, TCP/9582, and TCP/8890.\n\nDepending on enabled services, these may support antivirus and IPS updates,\ncloud app database access, licensing, firmware workflows, central analysis, mail\nservices, quarantine actions, contract validation, and virus sample uploads.\n\n\n\n\n\n5. LOGGING, REPORTING, AND CLOUD INTEGRATION\n\nThe diagram shows communication paths to FortiAnalyzer, FortiGate Cloud,\nFortiClient Cloud, and FortiSandbox. Ports such as TCP/514, TCP/443, and TCP/541\nappear in this context, depending on the service being used.\n\nThis highlights another architectural point: even a reset device is designed to\nfit into a larger ecosystem of monitoring, reporting, management, and\ncloud-assisted security services.\n\n\n\n\n\n6. IDENTITY, AUTHENTICATION, AND FSSO\n\nAuthentication-related integrations significantly expand the communication\nmatrix. The image includes the following examples:\n\n * LDAP: TCP/UDP 389\n * RADIUS: UDP/1812\n * RADIUS Accounting: UDP/1813\n * RADIUS Disconnect: TCP/1700\n * FSSO: TCP/8000, TCP/8001\n * Captive Portal: TCP/443\n * Policy Authentication / Override: TCP/1000, TCP/8008, TCP/8010, TCP/1003\n * Compliance and Security Fabric: TCP/8013\n\nThese ports become relevant only when FortiGate is integrated with identity\nproviders, endpoint compliance checks, SSO frameworks, or captive portal\nworkflows.\n\n\n\n\n\nWHAT THIS MEANS FOR NEW DEPLOYMENTS\n\nFor new FortiGate deployments, the image communicates four practical lessons:\n\n 1. Factory default does not mean “only a few standard ports.” FortiOS is\n already prepared for a broad range of features and integrations.\n 2. Port lists must be interpreted in context. The real relevance of a port\n depends on the feature set in use.\n 3. Network segmentation and egress filtering require planning. Restrictive\n rules can quickly break registration, updates, HA, logging, or centralized\n management.\n 4. Scans and audits should be interpreted carefully. Documented communication\n paths are not the same as permanently listening services.\n\n\nBEST PRACTICES\n\n * Enable only the functions you actually need.\n * Define port access based on real feature usage, not on generic assumptions.\n * Restrict management access as tightly as possible.\n * Document outbound requirements for FortiGuard, registration, updates, and\n cloud services.\n * Consider VPN, HA, and authentication dependencies early in the design phase.\n * Review communication matrices as operational design references, not as a raw\n list of exposed services.\n\n\nCONCLUSION\n\nA FortiGate in factory-reset state is not simply a box with a few administrative\nports. It is a platform built to support a wide range of security, management,\ncloud, logging, authentication, and high-availability functions. The\ncommunication overview in the image is therefore best understood as a map of\npotential FortiOS interactions.\n\nThe key conclusion is straightforward:\n\n\n\n\n> Many of the TCP and UDP ports shown are not visible or active by default. They\n> typically become relevant only when the corresponding function is enabled and\n> used.","image":"https://media-cdn.bluefox-security.ch/bluefox-security-ch/production/images/item-2b86b8c06e13e7eba5463467ccee9927.jpg","banner_image":"https://media-cdn.bluefox-security.ch/bluefox-security-ch/production/media/image-90082cc80ff6a8e716dd881c3eea4751.jpg","date_published":"2026-06-15T14:14:11.838Z","_microfeed":{"is_audio":false,"is_document":false,"is_external_url":false,"is_video":false,"is_image":true,"web_url":"https://bluefox-security-ch.pages.dev/i/fortigate-in-factory-reset-understanding-tcp-and-WUfWt4RIeSg/","json_url":"https://bluefox-security-ch.pages.dev/i/WUfWt4RIeSg/json/","rss_url":"https://bluefox-security-ch.pages.dev/i/WUfWt4RIeSg/rss/","guid":"WUfWt4RIeSg","status":"published","itunes:episodeType":"full","date_published_short":"Mon Jun 15 2026","date_published_ms":1781532851838}},{"id":"rwn7dln_d_V","title":"FortiGuard DNS vs. Third-Party DNS: Why New Deployments Should Look Beyond FortiGuard’s Resolver","url":"https://blog.bluefox-security.ch/i/rwn7dln_d_V/","content_html":"
FortiGate offers strong DNS security capabilities, but that does not automatically make FortiGuard’s own DNS service the best default resolver choice for every new deployment.
When administrators evaluate DNS in a FortiGate environment, two different functions are often mixed together: DNS security enforcement and recursive DNS resolution. FortiGate provides DNS-layer protection through features such as DNS Filter, FortiGuard category-based filtering, botnet C&C domain blocking, static domain filters, safe search enforcement, and external block lists. At the same time, Fortinet also supports secure DNS connectivity over DNS over TLS (DoT) to FortiGuard secure DNS when FortiGuard Anycast is enabled.
The key point is that these are not the same architectural decision. You can absolutely use FortiGate as the policy enforcement and inspection layer without making FortiGuard’s own recursive DNS or secure DNS endpoints your primary resolver. That distinction is important because it allows organizations to keep FortiGate’s DNS security controls while still choosing a different upstream resolver for better resilience, privacy posture, or performance.
Recommendation: For most new deployments, use a third-party recursive DNS provider such as Cloudflare or Quad9, while keeping FortiGate DNS filtering enabled as the local enforcement layer.
Recursive DNS is foundational infrastructure. If the resolver path becomes unstable, users experience failed or delayed name resolution regardless of how strong the firewall policy is. Fortinet’s public DoT status page for FortiGuard secure DNS shows that the service has had recent incidents, including a DNS DoT query outage on May 28, 2026, and the page also shows that some regions had less than 100% uptime over the previous 60 days. That does not mean FortiGuard is unusable, but it does raise a valid operational concern when designing greenfield deployments.
In other words, FortiGuard security intelligence may be valuable, but upstream DNS resolution itself should still be chosen with reliability and operational independence in mind. Treating these as separate design decisions gives you more flexibility and reduces the chance that a FortiGuard Anycast or DoT issue will directly affect core DNS availability.
A stronger design for new deployments is to let a specialized resolver provider handle recursive DNS, while the FortiGate remains responsible for DNS inspection, policy enforcement, and logging. Because FortiGate DNS filtering operates on DNS traffic traversing the firewall or on the FortiGate’s own interface-based DNS service, you do not need to use FortiGuard’s resolver to benefit from FortiGate’s DNS security features.
This hybrid model gives you the best of both worlds: a dedicated upstream DNS service for stability and performance, plus FortiGate-based enforcement for local control and visibility. For most organizations, that is easier to operate, easier to troubleshoot, and easier to justify architecturally.
Cloudflare’s public resolver at 1.1.1.1 is positioned around speed, privacy, and easy deployment. Cloudflare documents support for both DoH and DoT, and it also offers 1.1.1.1 for Families variants that can block malware or malware plus adult content. Cloudflare states that these filtered variants use the same privacy commitments as the standard 1.1.1.1 resolver.
Cloudflare also has one of the strongest public performance stories. DNSPerf’s public resolver rankings currently place Cloudflare at the top of its published performance list, making it a strong candidate for organizations that care about low latency and broad global coverage.
Quad9 is a Swiss-based nonprofit focused on privacy and security. Its main secure resolver at 9.9.9.9 blocks domains associated with malware, phishing, scams, and other malicious activity. Quad9 supports DoT, DoH, and DNSCrypt, and it also provides DNSSEC validation on its secure services.
Quad9’s privacy position is especially attractive for organizations that want their resolver choice to align with a stronger data-minimization approach. Quad9 states that it does not log end-user IP addresses and highlights its Swiss legal jurisdiction as part of its privacy model.
For most new FortiGate deployments, the most balanced architecture is:
FortiGuard DNS is valuable as a DNS security and filtering layer, but third-party DNS should usually be the default recommendation for new deployments.
FortiGate should remain the platform for inspection, logging, and enforcement. Upstream recursive DNS should be provided by a specialized resolver such as Cloudflare or Quad9, depending on whether your priority is performance or security-first privacy.
Last reviewed: June 2026
","content_text":"FORTIGUARD DNS VS. THIRD-PARTY DNSFORTIGUARD DNS VS. THIRD-PARTY DNS: WHY NEW\nDEPLOYMENTS SHOULD LOOK BEYOND FORTIGUARD’S RESOLVER\n\nFortiGate offers strong DNS security capabilities, but that does not\nautomatically make FortiGuard’s own DNS service the best default resolver choice\nfor every new deployment.\n\nWhen administrators evaluate DNS in a FortiGate environment, two different\nfunctions are often mixed together: DNS security enforcement and recursive DNS\nresolution. FortiGate provides DNS-layer protection through features such as DNS\nFilter, FortiGuard category-based filtering, botnet C&C domain blocking, static\ndomain filters, safe search enforcement, and external block lists. At the same\ntime, Fortinet also supports secure DNS connectivity over DNS over TLS (DoT) to\nFortiGuard secure DNS when FortiGuard Anycast is enabled.\n\nThe key point is that these are not the same architectural decision. You can\nabsolutely use FortiGate as the policy enforcement and inspection layer without\nmaking FortiGuard’s own recursive DNS or secure DNS endpoints your primary\nresolver. That distinction is important because it allows organizations to keep\nFortiGate’s DNS security controls while still choosing a different upstream\nresolver for better resilience, privacy posture, or performance.\n\n\n\n\nRecommendation: For most new deployments, use a third-party recursive DNS\nprovider such as Cloudflare or Quad9, while keeping FortiGate DNS filtering\nenabled as the local enforcement layer.\n\n\nWHY THE RESOLVER CHOICE MATTERS\n\nRecursive DNS is foundational infrastructure. If the resolver path becomes\nunstable, users experience failed or delayed name resolution regardless of how\nstrong the firewall policy is. Fortinet’s public DoT status page for FortiGuard\nsecure DNS shows that the service has had recent incidents, including a DNS DoT\nquery outage on May 28, 2026, and the page also shows that some regions had less\nthan 100% uptime over the previous 60 days. That does not mean FortiGuard is\nunusable, but it does raise a valid operational concern when designing\ngreenfield deployments.\n\nIn other words, FortiGuard security intelligence may be valuable, but upstream\nDNS resolution itself should still be chosen with reliability and operational\nindependence in mind. Treating these as separate design decisions gives you more\nflexibility and reduces the chance that a FortiGuard Anycast or DoT issue will\ndirectly affect core DNS availability.\n\n\n\n\n\nFORTIGUARD DNS: STRENGTHS AND WEAKNESSES\n\n\nPROS\n\n * Native integration with FortiGate security policies and security profiles.\n * Support for DNS-layer controls such as FortiGuard category-based filtering,\n botnet C&C domain blocking, static domain filtering, safe search enforcement,\n DNS translation, and external IP block lists.\n * Operational simplicity for Fortinet-centric environments where administrators\n want enforcement and visibility in a single platform.\n * Support for secure DNS over TLS when FortiGuard Anycast is enabled.\n\n\nCONS\n\n * Dependency on FortiGuard Anycast-backed secure DNS availability if used as\n the main upstream resolver path.\n * Recent public incident history on Fortinet’s DoT status page shows that\n outages and regional availability issues do occur.\n * Less flexibility than choosing a dedicated public recursive DNS provider\n whose primary mission is resolver performance, privacy, or threat blocking.\n\n\nWHY THIRD-PARTY DNS IS OFTEN THE BETTER DEFAULT\n\nA stronger design for new deployments is to let a specialized resolver provider\nhandle recursive DNS, while the FortiGate remains responsible for DNS\ninspection, policy enforcement, and logging. Because FortiGate DNS filtering\noperates on DNS traffic traversing the firewall or on the FortiGate’s own\ninterface-based DNS service, you do not need to use FortiGuard’s resolver to\nbenefit from FortiGate’s DNS security features.\n\nThis hybrid model gives you the best of both worlds: a dedicated upstream DNS\nservice for stability and performance, plus FortiGate-based enforcement for\nlocal control and visibility. For most organizations, that is easier to operate,\neasier to troubleshoot, and easier to justify architecturally.\n\n\n\n\n\nCLOUDFLARE: BEST FOR PERFORMANCE AND SIMPLICITY\n\nCloudflare’s public resolver at 1.1.1.1 is positioned around speed, privacy, and\neasy deployment. Cloudflare documents support for both DoH and DoT, and it also\noffers 1.1.1.1 for Families variants that can block malware or malware plus\nadult content. Cloudflare states that these filtered variants use the same\nprivacy commitments as the standard 1.1.1.1 resolver.\n\nCloudflare also has one of the strongest public performance stories. DNSPerf’s\npublic resolver rankings currently place Cloudflare at the top of its published\nperformance list, making it a strong candidate for organizations that care about\nlow latency and broad global coverage.\n\n\n\n\n\nCLOUDFLARE PROS\n\n * Very strong public performance reputation.\n * Simple deployment with clear DoH and DoT support.\n * Optional malware blocking and family-safe filtering variants.\n * Documented privacy commitments backed by independent assessment.\n\n\nCLOUDFLARE CONS\n\n * The default service is primarily a fast, clean recursive resolver rather than\n a security-first resolver by default.\n * If stronger DNS-layer blocking is desired, administrators must deliberately\n choose the filtered variants instead of the standard addresses.\n\n\nQUAD9: BEST FOR SECURITY-FIRST AND PRIVACY-FOCUSED DEPLOYMENTS\n\nQuad9 is a Swiss-based nonprofit focused on privacy and security. Its main\nsecure resolver at 9.9.9.9 blocks domains associated with malware, phishing,\nscams, and other malicious activity. Quad9 supports DoT, DoH, and DNSCrypt, and\nit also provides DNSSEC validation on its secure services.\n\nQuad9’s privacy position is especially attractive for organizations that want\ntheir resolver choice to align with a stronger data-minimization approach. Quad9\nstates that it does not log end-user IP addresses and highlights its Swiss legal\njurisdiction as part of its privacy model.\n\n\n\n\n\nQUAD9 PROS\n\n * Security-first default behavior with malicious-domain blocking built into the\n main service.\n * Strong privacy posture and Swiss nonprofit governance model.\n * Support for DoT, DoH, DNSCrypt, and DNSSEC validation.\n\n\nQUAD9 CONS\n\n * A more opinionated security-first service can occasionally introduce false\n positives or exception-handling overhead.\n * It is generally chosen more for privacy and security than for having the\n strongest public latency benchmark story.\n\n\nRECOMMENDED APPROACH FOR NEW DEPLOYMENTS\n\nFor most new FortiGate deployments, the most balanced architecture is:\n\n\n\n\n * Use Cloudflare if your priority is performance, simplicity, and easy\n encrypted DNS rollout.\n * Use Quad9 if your priority is security-first blocking and stronger privacy\n posture.\n * Keep FortiGate DNS filtering enabled so the firewall remains your enforcement\n and visibility layer.\n * Avoid making FortiGuard secure DNS / DoT the default upstream dependency for\n every deployment unless you have validated the service stability for your\n regions and requirements.\n\n\nFINAL VERDICT\n\nFortiGuard DNS is valuable as a DNS security and filtering layer, but\nthird-party DNS should usually be the default recommendation for new\ndeployments.\n\nFortiGate should remain the platform for inspection, logging, and enforcement.\nUpstream recursive DNS should be provided by a specialized resolver such as\nCloudflare or Quad9, depending on whether your priority is performance or\nsecurity-first privacy.\n\n\nSOURCES\n\n * FortiGuard DNS DoT Status\n * Fortinet Documentation – DNS over TLS\n * Fortinet Documentation – Configuring a DNS Filter Profile\n * Cloudflare 1.1.1.1 Resolver Documentation\n * Quad9 Documentation\n * Quad9 FAQ\n * DNSPerf Public Resolver Performance\n\nLast reviewed: June 2026","image":"https://media-cdn.bluefox-security.ch/bluefox-security-ch/production/images/item-d9b8803cc8af9d0aa66aa0cbc67aec68.png","date_published":"2026-06-15T11:16:41.555Z","_microfeed":{"web_url":"https://bluefox-security-ch.pages.dev/i/fortiguard-dns-vs-third-party-dns-why-new-deploy-rwn7dln_d_V/","json_url":"https://bluefox-security-ch.pages.dev/i/rwn7dln_d_V/json/","rss_url":"https://bluefox-security-ch.pages.dev/i/rwn7dln_d_V/rss/","guid":"rwn7dln_d_V","status":"published","itunes:episodeType":"full","date_published_short":"Mon Jun 15 2026","date_published_ms":1781522201555}}],"_microfeed":{"microfeed_version":"0.1.2","base_url":"https://bluefox-security-ch.pages.dev","categories":[{"name":"Business"},{"name":"Education","categories":[{"name":"How To"}]},{"name":"Technology"}],"subscribe_methods":[{"name":"RSS","type":"rss","url":"https://bluefox-security-ch.pages.dev/rss/","image":"https://bluefox-security-ch.pages.dev/assets/brands/subscribe/rss.png","enabled":true,"editable":false,"id":"Jt50PTobYqy"},{"name":"JSON","type":"json","url":"https://bluefox-security-ch.pages.dev/json/","image":"https://bluefox-security-ch.pages.dev/assets/brands/subscribe/json.png","enabled":true,"editable":false,"id":"0GXyXOWaktE"}],"description_text":"WELCOME TO BLUEFOX SECURITY\n\nBlueFox Security is a blog about networking, cybersecurity, and IT. It shares\npractical insights, technical guides, and real-world experiences around secure\ninfrastructure, modern networks, and everyday IT challenges.","copyright":"©2026","itunes:type":"episodic","items_sort_order":"newest_first"}}