Direct answer: what is FortiGate DNS Filtering?
FortiGate DNS Filtering is a DNS-layer security and access-control capability available through Fortinet’s FortiGuard security services and supported FortiGate configurations. It evaluates DNS requests so the firewall can allow, monitor, block, or redirect access according to domain reputation, FortiGuard category ratings, locally defined domain rules, and other configured controls. Organisations should consider it when they want to stop access to malicious or disallowed domains earlier in the connection process and add DNS visibility to a broader firewall policy. Before proceeding, confirm the exact FortiGate appliance or virtual firewall, FortiOS release, subscription entitlement, DNS traffic path, encrypted DNS requirements, policy categories, reporting needs, and how the DNS Filter profile will be applied.
What it does
DNS is involved before most users reach websites, cloud applications, update services, remote platforms, and internet-hosted APIs. A DNS Filter profile gives FortiGate a control point at that early stage. Depending on the selected FortiGuard service, FortiOS release, and configuration, the firewall can use domain ratings and categories, local domain entries, botnet command-and-control information, and related DNS inspection functions to determine how requests should be handled. This does not replace every other web or threat-control layer; it complements them by applying decisions while a domain name is being resolved.
Who it suits
The capability may suit organisations running FortiGate at an internet edge, branch, school, retail site, campus, shared office, hospitality environment, healthcare facility, industrial support network, or distributed enterprise. It is especially relevant where IT teams want central security policy for domain categories, an additional control against malicious infrastructure, or clear visibility into DNS queries crossing the firewall. It is less useful when DNS traffic bypasses the firewall or when encrypted DNS is allowed without an inspection strategy. The design should therefore be based on the actual DNS architecture rather than simply enabling a profile and assuming all name resolution will be covered.
Business problems DNS-layer controls can help address
Phishing and malicious domains
Attackers often depend on domain names to host phishing pages, malware infrastructure, staging systems, or command services. DNS filtering adds a control that can stop access to a rated or explicitly blocked domain before the user reaches the destination.
Unwanted domain categories
Organisations can apply acceptable-use policy at the domain level for selected categories. Category choices should reflect business requirements, regulatory obligations, user groups, and the risk of blocking legitimate services.
Unknown device behaviour
DNS query logs can help reveal devices repeatedly requesting suspicious or unexpected domains. This can give network and security teams useful context when investigating endpoint compromise, misconfiguration, or shadow applications.
Policy consistency across sites
Distributed organisations may need repeatable DNS controls at many branches. Standardised profiles can help reduce ad-hoc filtering differences, provided management, exception handling, testing, and change governance are designed centrally.
Core capabilities in practical terms
FortiGate DNS Filtering suitability matrix
| Requirement | Suitable when | Confirm before activation |
|---|---|---|
| Block malicious domains early | DNS queries cross the FortiGate and the correct security service is active. | Subscription status, DNS path, profile attachment and rating-error behaviour. |
| Enforce domain categories | The organisation has an acceptable-use policy and clearly defined exceptions. | Category selection, business-critical exceptions and test groups. |
| Inspect encrypted DNS | DoH or DoT must be controlled and supported FortiOS inspection is part of the design. | Inspection mode, SSL/SSH inspection, certificates, application compatibility and policy scope. |
| Standardise branch policy | Multiple sites use compatible FortiGate policy and management practices. | Template ownership, central management, local exceptions and change control. |
| Add DNS visibility | Security teams need query logs for investigation and policy tuning. | Log destination, retention, privacy policy, alerting and operational ownership. |
Service and deployment information
| Topic | FortiGate DNS Filtering / FortiGuard DNS Filtering Service |
| Main purpose | DNS-layer threat protection, domain reputation and category policy, local domain control, and DNS visibility. |
| Suitable platforms | Supported FortiGate deployments; exact behaviour depends on appliance, virtual model, FortiOS version, entitlement, and configuration. |
| Licensing guidance | Current Fortinet ordering information places DNS Filtering within Web & DNS Security. It may be available through selected FortiGuard bundles or an individual service. Confirm the exact orderable subscription for the FortiGate model and term. |
| Typical policy elements | FortiGuard category actions, local domain rules, botnet C&C blocking, rating-error behaviour, safe search or related controls where supported. |
| Encrypted DNS | DoT and DoH inspection are supported in appropriate FortiOS configurations; inspection mode and SSL/SSH policy requirements must be validated. |
| Logging and reporting | DNS query logs and reporting depend on the chosen FortiGate logging design, local storage, FortiAnalyzer, FortiGate Cloud, or other supported log destination. |
| Configuration support | Profile planning, firewall-policy attachment, exception handling, testing, rollback preparation, and operational handover can be scoped with FourTeck. |
| Availability | Contact FourTeck for current UAE licensing, renewal, and service availability. Terms can vary by model, subscription, quantity, and vendor policy. |
Licensing, compatibility, and configuration dependencies
The DNS Filter menu may be visible on a FortiGate even though the intended FortiGuard category-based service still requires the correct entitlement. Current Fortinet ordering guidance shows DNS Filtering within the Web & DNS Security group and available through selected security bundles as well as individual service options. Because part numbers, bundles, terms, and model eligibility can change, the procurement team should not assume that a license used on one FortiGate model applies to another model or that an expired subscription continues to provide category ratings.
Configuration matters just as much as licensing. The firewall must actually see the DNS traffic that the organisation wants to control. Endpoints can use an internal DNS server, FortiGate as a resolver, public DNS, or encrypted DNS. Those designs create different enforcement points. DoH and DoT need specific inspection planning, and user devices or browsers may have their own secure DNS settings. A project should therefore map resolver locations, DNS forwarders, security policies, SSL/SSH inspection, certificates, exception requirements, and permitted external resolvers before the final policy is activated.
A category block also needs an operational process. Business-critical domains may be newly registered, miscategorised, or used by external vendors with shared infrastructure. Teams should define who can request an exception, how classification is checked, how temporary overrides are approved, how logs are reviewed, and what should happen if a FortiGuard rating service cannot be reached. FourTeck can include these dependencies in a configuration and support scope rather than treating DNS filtering as a one-click feature.
A practical deployment journey
Discover the DNS path
Document client resolvers, internal DNS servers, forwarders, public resolvers, guest networks, VPN users, and encrypted DNS behaviour. This establishes what traffic the FortiGate can inspect.
Validate entitlement
Check the FortiGate model, serial or virtual entitlement, FortiOS version, current service bundle, expiration date, and whether a new subscription or renewal is required.
Design policy
Choose category actions, local domain entries, block behaviour, rating-error handling, logging, user groups, exceptions, and any secure DNS inspection requirements.
Pilot and test
Apply the profile to a controlled user or VLAN group first. Verify allowed sites, blocked domains, business exceptions, DoH/DoT behaviour, logs, and user-facing block responses.
Roll out with governance
Expand coverage, monitor false positives, define exception ownership, document the configuration, and connect DNS events to the organisation’s support or incident process.
Category-based control without turning every web decision into a URL rule
One reason businesses evaluate FortiGate DNS Filtering is the ability to make an early decision on a domain before the destination is contacted. FortiGuard category-based filtering uses Fortinet’s domain rating information so administrators can assign policy actions to categories rather than manually maintaining long lists of domains. This can reduce the operational burden for broad classes of content or known-risk infrastructure, but it should still be implemented with business context. A category that is appropriate to block for general office users may need a different action for security researchers, marketing teams, students, guests, or a controlled laboratory environment.
A careful design normally starts with visibility and monitoring rather than a large number of aggressive blocks. Security teams can review which categories appear in normal traffic, identify business dependencies, then move selected categories into stricter actions. This is particularly important for cloud services that use changing domains or shared platforms. It also gives the organisation time to establish a process for temporary exceptions and misclassification requests. The aim is not to create a long deny list; it is to make domain policy predictable, understandable, and supportable.
When DNS filtering is used alongside FortiGate Web Filter, application control, antivirus, intrusion prevention, and other security profiles, each control has a different inspection point. DNS filtering works at name resolution, while web filtering can provide more detailed handling of HTTP and HTTPS destinations. A combined design can therefore be useful where the organisation wants both early domain blocking and more granular control at the web layer. The exact combination should be chosen according to the threats, user experience, subscription coverage, and inspection performance expected from the FortiGate model.
Encrypted DNS requires a deliberate policy
Traditional DNS is easy for a firewall to identify because queries usually use well-known ports and protocols. Modern devices and browsers may instead use DNS over TLS or DNS over HTTPS. These methods improve privacy for DNS transport, but they can also change how enterprise filtering and visibility work. Fortinet documents support for DNS inspection with DoT and DoH in supported FortiOS configurations, yet the firewall policy inspection mode, SSL/SSH inspection profile, certificate trust, and application behaviour must all be considered.
A common planning mistake is to enable a DNS Filter profile while allowing browsers to resolve names through external encrypted DNS services that are not inspected. In that situation, administrators may see fewer standard DNS queries than expected and may wrongly assume that the category policy is unreliable. The correct response is to map which clients can use secure DNS, decide whether enterprise-managed resolvers should be required, determine whether approved DoH/DoT traffic will be inspected, and define how unsupported or unauthorised resolver traffic should be handled.
Inspection must also respect application compatibility, privacy obligations, certificate deployment, remote-user behaviour, and support boundaries. Some applications may fail when TLS inspection is applied, while unmanaged devices may not trust an enterprise CA certificate. These factors should be tested on a small user group before any broad change. FourTeck can help separate the DNS policy objective from the technical enforcement method so the organisation does not overcomplicate its firewall simply to achieve basic domain control.
DNS visibility can improve investigation and operational control
DNS logs can reveal patterns that are difficult to see from firewall session logs alone. Repeated queries to suspicious domains, requests for newly observed infrastructure, bursts of unusual subdomains, or devices contacting domains unrelated to their normal role may provide useful context during an investigation. A DNS Filter deployment can therefore be more valuable when the organisation knows where the logs will be stored, who will review them, and how they will be correlated with endpoint, firewall, VPN, and identity events.
The logging design should match the environment. A small branch may need basic FortiGate logging and occasional review, while a multi-site organisation may require central logging, longer retention, searchable event history, alerting, and integration with a security operations process. FortiAnalyzer, FortiGate Cloud, or other supported logging architectures may be relevant depending on the customer’s platform and licenses. Retention requirements should also consider privacy and internal policy because DNS queries can reveal user and device activity.
Visibility is most useful when it leads to action. Administrators should define what counts as a high-priority DNS event, which team owns follow-up, whether an endpoint should be isolated, when a domain should be placed into a local block list, and how a false positive is handled. Without those steps, a firewall can collect large numbers of DNS records without improving response. FourTeck can help include logging and operational ownership in the deployment plan instead of treating them as an afterthought.
Where FortiGate DNS Filtering can fit
Corporate internet gateways
Apply domain reputation and category controls to employee internet traffic at the perimeter while maintaining exceptions for business-critical SaaS and cloud services.
Distributed branches
Standardise DNS policy across branches where FortiGate appliances already provide internet access, VPN connectivity, and security inspection.
Education and training networks
Support acceptable-use controls for student, guest, and staff networks while preserving a clear process for research, learning resources, and category exceptions.
Retail and hospitality
Separate staff, guest, payment, operational, and IoT network requirements so DNS policy is appropriate to each segment rather than identical everywhere.
Remote access environments
Extend policy to users whose traffic is routed through supported FortiGate VPN or secure-access designs, subject to split-tunnel, resolver, and endpoint settings.
Security investigations
Use DNS query evidence as one data source when investigating compromised devices, suspicious callbacks, or unusual domain activity.
Integration and operational considerations
DNS filtering should be designed as part of the network rather than as an isolated profile. Internal Active Directory DNS servers, split-horizon DNS, VPN users, guest Wi-Fi, SD-WAN branches, public cloud workloads, SaaS applications, and security appliances can all influence the path a DNS query takes. If internal clients use a corporate DNS server, the FortiGate may see queries from the server rather than the original endpoint depending on topology. That affects how logs are interpreted and which security policy should carry the DNS Filter profile.
The relationship with web filtering also matters. DNS filtering makes decisions at domain resolution, while URL filtering can act on web requests with greater destination detail. Application control may identify resolver applications or circumvention tools, and SSL inspection can influence encrypted traffic visibility. For some environments a simple DNS policy is sufficient; for others the controls should be layered. The design should not duplicate rules without a reason because overlapping blocks can make troubleshooting difficult.
Change management is another integration point. DNS is a foundational service, so an overly broad block can disrupt authentication, updates, APIs, cloud management, payment services, voice platforms, and other dependencies. A production rollout should include test users, baseline logs, an exception process, rollback steps, maintenance windows where required, and named owners for approval. FourTeck can include these items in a configuration or migration scope.
Questions to resolve before requesting a quotation
This determines the correct subscription family, supported feature set, upgrade considerations, and inspection capabilities.
Identify FortiGate DNS, internal resolvers, public DNS, cloud resolvers, guest resolvers, and browser-based secure DNS.
Malware blocking, acceptable-use categories, botnet prevention, child-safety controls, research visibility, or a combination may require different policy choices.
Define who can approve an allow entry, how long temporary exceptions last, and how miscategorised domains are reviewed.
Encrypted DNS changes the inspection design and may require SSL/SSH inspection, proxy-based policy handling, certificate deployment, or endpoint restrictions.
Some customers need licensing only; others need assessment, configuration, pilot testing, documentation, troubleshooting, renewal guidance, and ongoing support coordination.
Procurement and deployment checklist
- Exact FortiGate model or virtual appliance edition
- Current FortiOS version and upgrade plan
- Existing FortiGuard bundle and expiration date
- Required subscription term and quantity
- DNS resolver and forwarding architecture
- Categories to allow, monitor, block, or redirect
- Local domain allow and block requirements
- DoH and DoT handling requirements
- SSL/SSH inspection and certificate implications
- Logging destination and retention requirement
- Pilot group, testing plan, and rollback process
- Configuration, documentation, training, or support scope
How FourTeck can assist
FourTeck can help customers move from a broad requirement such as “block dangerous domains” to a practical FortiGate configuration and quotation. Assistance can include reviewing the existing firewall model, identifying the current FortiGuard coverage, checking whether a renewal or different bundle is appropriate, mapping DNS traffic flow, planning filter categories, documenting local domain exceptions, and deciding how encrypted DNS should be treated.
Where implementation support is required, the scope can include profile creation, firewall-policy attachment, pilot testing, exception tuning, log verification, documentation, and handover. Migration from another DNS filtering product or from a basic static block list may also require discovery of current policies and business exceptions before any new profile is activated.
For broader Fortinet requirements, buyers can review FourTeck firewall products, explore security services and implementation support, or discuss a complete Fortinet firewall requirement.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for the required DNS Filtering subscription, FortiGuard bundle, renewal, or configuration service. Licensing can depend on the FortiGate model, hardware or virtual platform, selected term, service bundle, entitlement status, and current vendor ordering policy.
Delivery and project coordination can be discussed after the exact requirement is confirmed. Installation or configuration should be included in the quotation where required rather than assumed to be part of a license purchase. For assistance, use the FourTeck contact page.
Dubai, Abu Dhabi, Sharjah, and Ajman coverage
Businesses operating in Dubai, Abu Dhabi, Sharjah, and Ajman can discuss FortiGate DNS Filtering licensing, renewal, configuration, and project planning with FourTeck through one combined requirement. A multi-site customer should provide the FortiGate model at each location, current FortiOS version, subscription status, DNS topology, user or device segmentation, required category policy, and whether each site is managed locally or centrally. This helps avoid a quotation that assumes every branch has the same firewall or licensing need. Configuration and delivery coordination can then be planned around the actual site list and project scope. Availability may vary according to model, license term, quantity, and vendor lead time, so current options should be confirmed before a rollout date is committed.
GCC Availability
FourTeck can assist organisations planning FortiGate DNS Filtering across GCC environments where firewall models, subscriptions, and deployment practices may differ by branch or country. A regional project may include the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain, or Oman, but the important starting point is the exact technical requirement rather than the country list. Buyers should share each FortiGate model, the requested FortiGuard service or bundle, required term, quantity, current entitlement, deployment location, DNS architecture, and whether configuration or migration support is expected.
Product availability, licensing eligibility, electronic entitlement delivery, physical firewall lead times, service visits, project scope, and vendor ordering rules can vary by country, model, quantity, and requirement. FourTeck can help review the bill of materials, compare an individual service with a wider FortiGuard bundle where appropriate, coordinate quotation details, and plan the configuration scope. Customers with a Kuwait requirement can also review FourTeck Kuwait technology support. Confirm the destination country and required timeline before assuming regional availability or a fixed implementation schedule.
Africa Availability
Organisations in Africa evaluating FortiGate DNS Filtering can work with FourTeck on model review, licensing guidance, configuration planning, renewal requirements, and wider Fortinet procurement. The correct approach depends on the destination, FortiGate platform, quantity, subscription region, support requirement, and whether the project is a new installation or an update to an existing firewall estate. Buyers in East Africa, West Africa, Southern Africa, or Central Africa should provide the exact device model and current entitlement rather than assuming that a subscription from another deployment can be reused.
Availability and fulfilment can depend on vendor lead time, the orderable license for the model, shipping arrangements if hardware is also required, local power or regulatory needs for appliances, and the scope of installation or remote assistance. FourTeck can help businesses in markets such as Kenya and Uganda review the requirement and coordinate suitable next steps. Regional resources are available through FourTeck Africa. Share the destination country, quantity, preferred deployment schedule, support expectations, and any migration requirements so the quotation reflects the actual project.
Related options to consider with DNS Filtering
FortiGate NGFW appliances
A new DNS filtering requirement may be part of a wider firewall refresh. Model sizing should consider inspected traffic, VPN use, users, interfaces, and growth.
FortiGuard URL Filtering
DNS and web filtering operate at different layers. URL filtering may be useful where more granular web destination control is required.
FortiGuard UTP or Enterprise bundle
A wider security bundle may be more appropriate when DNS Filtering is only one of several required services. Confirm current bundle contents and model eligibility.
FortiGate configuration services
Policy planning, SSL inspection, pilot testing, logging, migration, and documentation can be scoped separately from the subscription.
What buyers usually need to know before enabling DNS Filtering
The first question many teams ask is whether FortiGate DNS Filtering is simply another name for web filtering. It is not. DNS filtering acts on the domain lookup that usually happens before a web connection is made. Web filtering acts later and can make decisions using web-specific information. In a practical deployment, DNS filtering is valuable because it can prevent resolution of a known malicious or disallowed domain before the client reaches the service. Web filtering remains useful when the organisation needs more granular decisions related to websites, URLs, encrypted web traffic, and acceptable-use policy. Some customers use both, while others need only one layer. The right choice depends on how much control, visibility, and subscription coverage are required.
Not necessarily. A DNS Filter profile can inspect DNS traffic that traverses the relevant firewall policy, and FortiGate can also provide DNS services in some designs. The important point is that the firewall must see the DNS request in a way that the configured inspection method can evaluate. If clients send DNS directly to external resolvers, or use encrypted DNS that bypasses inspection, the effective coverage can differ from a design where all endpoints use an internal resolver that forwards through the firewall.
FortiGuard category-based DNS filtering and related reputation services depend on the appropriate entitlement. Fortinet’s current ordering guide groups DNS Filtering under Web & DNS Security and shows it in selected bundles as well as an individual service option. Static local domain rules are a separate concept from live FortiGuard ratings. Buyers should confirm the exact subscription for the FortiGate model and the intended term rather than relying on a generic license description.
Another common question concerns encrypted DNS. Browsers and operating systems increasingly support DoH or DoT. These protocols do not make DNS filtering impossible, but they change the inspection path. Fortinet documents DNS inspection for DoT and DoH in supported FortiOS configurations, and its technical guidance links that capability to SSL/SSH inspection and compatible policy handling. That means an enterprise may need to decide whether it will allow approved encrypted resolvers, inspect them, force managed endpoints to use corporate resolvers, or block unauthorised resolver applications. These decisions affect privacy, certificates, application compatibility, and support effort.
Buyers also ask what happens when a domain is wrongly categorised. No category database should be treated as infallible. Business cloud services change, third-party providers move infrastructure, newly registered domains may be legitimate, and a shared hosting platform can contain both acceptable and risky content. The operational answer is to create an exception workflow. A user or application owner should be able to report a blocked domain, IT should confirm whether the site is required and safe, and the security team should decide whether to create a local override or request reclassification. Temporary exceptions should have an owner and review date where possible.
Pricing questions are more complicated because DNS Filtering is tied to the FortiGate model and subscription term. A small appliance and a large enterprise firewall do not normally use the same orderable license, and a buyer may choose a standalone Web, DNS & Video filtering subscription or a broader bundle depending on the environment. A useful quotation request therefore includes the exact model, serial entitlement status if available, current bundle, expiration date, requested term, and whether the customer needs only licensing or also configuration. Without that information, a market price found for another FortiGate model is not a reliable budget figure.
Deployment questions should go beyond “which categories should we block?” A stronger design asks which users, VLANs, sites, devices, and resolver paths are in scope; how guest traffic differs from corporate traffic; what happens to VPN users; which domains are already on local allow lists; how logs will be retained; and who owns daily exceptions. It should also test the effect on software updates, identity providers, cloud management, payment gateways, collaboration platforms, and any custom application that depends on external DNS. A small pilot reduces the risk of discovering these dependencies after a wide rollout.
For organisations already using FortiGate, the most efficient path is often a configuration and entitlement review before buying anything. The review can reveal whether the required service is already included, whether the subscription has expired, whether the firewall sees the necessary DNS traffic, and whether a wider security bundle is a better fit than a standalone service. FourTeck can help turn that review into a defined bill of materials, configuration scope, and rollout plan so the customer knows exactly what is being licensed and how it will be used.
Practical decisions to make before you turn it on
Should we use DNS Filtering if Web Filter is already enabled?
Possibly. DNS filtering can stop a domain at the lookup stage, while web filtering provides controls later in the web connection. The two can complement each other, but they should not be enabled simply to duplicate the same block. Review the threat objective, desired granularity, FortiGuard subscription, and troubleshooting complexity. If the main need is broad malicious-domain prevention, DNS filtering may add useful early enforcement. If the organisation needs page-level or web-category control, web filtering remains important.
What should we do about public DNS and browser DoH?
First decide the approved resolver architecture. If corporate devices should use internal DNS, document and enforce that policy. If public resolvers are allowed, verify that their traffic still traverses the intended FortiGate security policy. If DoH or DoT is allowed, determine whether the FortiGate will inspect it, whether managed endpoints will trust the inspection certificate, and which applications may require exceptions. Do not assume that a standard port-53 rule will govern all modern DNS traffic.
How do we avoid blocking a critical SaaS service?
Use a pilot group, review logs before enforcing broad categories, and maintain a controlled exception process. List essential identity, productivity, finance, voice, security, update, and management services before rollout. Where a domain is required for business, confirm the reason and scope of the exception rather than creating a permanent global allow rule without review. Cloud applications change frequently, so the process should remain available after deployment.
What information does FourTeck need for an accurate quote?
Provide the exact FortiGate model, quantity, current FortiOS version, existing FortiGuard bundle, subscription expiry, desired term, and whether this is a new license, renewal, or change of bundle. If configuration is required, add the number of sites, DNS resolver design, user or device segments, expected category policy, encrypted DNS requirements, logging platform, and whether remote or on-site coordination is preferred. This allows the quotation to separate licensing from technical services.
Can the same profile be copied to every branch?
Only when the branches have compatible requirements. A common baseline may be sensible, but guest networks, schools, retail stores, engineering sites, call centres, and corporate offices can have different business exceptions and DNS paths. Central management can help standardise policy, yet each site still needs validation. A good branch template separates global controls from location-specific exceptions and records which team owns those changes.
What happens if the FortiGuard rating service is unavailable?
FortiOS provides configurable handling for rating errors, and category-based filtering depends on live rating services while static domain rules can have different behaviour. The organisation should decide in advance whether an unrated or rating-error condition should fail open or fail closed for the affected policy, based on business risk and continuity requirements. This choice should be tested, documented, and reviewed as part of the firewall change process.
Why businesses contact FourTeck for this requirement
The difficult part of DNS filtering is rarely the existence of a profile. Buyers need to know whether the firewall has the right entitlement, whether the DNS traffic actually follows the expected path, whether encrypted DNS is covered, which categories are safe to enforce, how business exceptions will be managed, and how the change will be tested without disrupting cloud applications. FourTeck can help clarify those questions before the purchase or configuration is finalised.
Assistance can also cover the bill of materials when a new FortiGate appliance, support contract, or broader FortiGuard subscription is part of the project. For existing environments, the focus may be renewal, policy review, troubleshooting, migration from another DNS filtering platform, or improvement of logging and reporting. The objective is to match the licensing and service scope to what the customer actually needs rather than assume that every FortiGate deployment should use the same profile.
Learn more about FourTeck firewall solutions in Dubai or contact the team with the model, subscription term, quantity, and deployment details for a tailored review.
Frequently asked questions
Is FortiGate DNS Filtering a separate appliance?
No. It is a DNS-layer security capability used with supported FortiGate deployments and FortiGuard services. The required entitlement, FortiOS version, and configuration should be confirmed for the specific firewall.
Does FortiGate DNS Filtering require a subscription?
FortiGuard category-based DNS filtering and live reputation functions require the appropriate service entitlement. Current Fortinet ordering guidance includes DNS Filtering within selected FortiGuard bundles and individual service options. Confirm the exact license for the model and term.
Can DNS Filtering block a malicious domain before a website opens?
Yes, when the DNS query is inspected and the domain matches a configured block decision, the firewall can stop or redirect the resolution before the client establishes the normal connection to that domain.
What is the difference between FortiGate DNS Filter and Web Filter?
DNS Filter works on domain-name resolution, while Web Filter applies controls to web traffic and can provide more granular handling of web destinations. They can be used together when both DNS-layer and web-layer policy are required.
Can FortiGate inspect DNS over HTTPS or DNS over TLS?
Supported FortiOS configurations provide inspection for DoH and DoT, but the design can depend on firewall policy inspection mode, SSL/SSH inspection, certificates, and application behaviour. Validate the exact FortiOS release and policy before rollout.
Can FourTeck configure DNS Filtering on an existing FortiGate?
Configuration assistance can be scoped for an existing firewall, including entitlement review, DNS path discovery, profile design, policy attachment, exception planning, testing, logging verification, and documentation.
What information is needed for a FortiGate DNS Filtering quote?
Share the FortiGate model, quantity, current subscription or bundle, expiry date if known, required term, FortiOS version, and whether you need licensing only or configuration, migration, and support services as well.
Is FortiGate DNS Filtering available in the UAE?
Contact FourTeck to confirm current UAE licensing or renewal availability. The correct option can depend on the FortiGate model, term, entitlement status, quantity, and current vendor ordering policy.
What happens if the FortiGuard category service is unavailable or expired?
Category-based filtering depends on live FortiGuard rating services, while static local domain rules can behave differently. FortiOS provides configurable handling for rating errors, so the organisation should define and test the preferred fail-open or fail-closed behaviour for its policy.
Plan the license and policy before activation
Send FourTeck your FortiGate model, current subscription, required term, DNS design, and desired security outcome. The team can help confirm the appropriate licensing route, configuration scope, and UAE quotation.