DNS Profile

Use the DNS Profile to configure various DNS parameters and ACLs. Always assign an DNS profile to SPP.

All DNS Profile parameters can be used with symmetric or asymmtric traffic.

You can create a maximum of 64 DNS Profiles.

DNS Anomalies Feature Control

Use the DNS Anomalies Feature Control section to configure DNS traffic anomaly detection. DNS Anomalies (and DNS Feature Controls) cannot be used in SPPs that contain devices such as Firewalls, Proxies, Gateways, mail servers that produce encrypted DNS packets destined for port 53 on their cloud services. For example, FortiGate firewalls by default send encrypted DNS packets to FortiGuard UDP Port 53. The FortiGuard DNS port can be modified to UDP port 8888 which is recommended but other products maynot be modifiable.

FortiDDoS interprets these encrypted DNS packets as anomalies and drops them. This can result in no Internet access for any LAN-based client.

Devices sending encrypted packets should be isolated in a separate SPP with DNS Anomaly and Feature Controls disabled.

In order to discover if these devices exist in the SPP and identify the IP addresses of the devices, in Detection Mode, enable all DNS anomalies. In Log & Report > Log Access > DDoS Attack Log: Top Attacks widget, with the direction set to Outbound, look for DNS Anomaly drops across a wide range of anomalies. If you are seeing Outbound DNS Anomaly drops, drill down (using page icon to the right of Attack description) to see the detailed attack logs. Drill down further to see the Protected IPs. These will be the devices sending encrypted DNS. Move these IP addresses to a separate SPP and disable all DNS Anomalies and Features for that SPP.

DNS Feature Controls

Use this section to configure DNS feature controls. For an overview of DNS features, see Understanding FortiDDoS DNS attack mitigation.

There are two network conditions where most DNS Feature controls must be disabled:

• If the FortiDDoS appliance is operating in Asymmetric traffic mode and cannot see both directions of the DNS traffic. See Understanding FortiDDoS Asymmetric Mode for more information.
• In SPPs that contain Firewalls, Proxies, Gateways, mail servers or other equipment that generates encrypted DNS packets.

The DNS Resource Record Type

The DNS Resource Record Type ACL allows blocking of any number of DNS Resource Record Types by QTYPE number. The DNS QTYPE field allows 65,536 TYPES of which fewer than 100 are defined and less are in common use.

The following Qtypes can be blocked:

• Known Qtypes which are not needed (for example: ALL/ANY=255)
• Deprecated Qtypes (for example: NULL=10)
• Undefined Qtypes (for example: 32770-65279)

DNS Resource Record Type ACLs are defined in numeric ranges. A single ACL entry has DNS Resource

Record Type Start = DNS Resource Record Type End.

Settings	Guidelines for use with SPPs that contain Firewalls, Proxies, Gateways, Email servers and other outbound generators of DNS Queries.	Guidelines for Symmetric traffic (or Asymmetric where FortiDDoS sees all traffic)	Guidelines for Asymmetric Mode, where FortiDDoS does not see all traffic.
Match responses with queries (DQRM)	Many Firewalls, including FortiGates, send encrypted SSL-over-UDP DNS Queries to destination UDP port 53. FortiDDoS sees these as DNS anomalies and drops them, preventing Internet access for users behind the firewall or other proxy devices. SSL-over-UDP DNS Queries do not meet any RFC but our experience is that they are standard industry practice for many firewalls, proxies, gateways, mail servers and other equipment that uses cloud services to detect malicious domains. FortiGate specifically can move the FortiGuard DNS Query port from 53 to 8888 and this is recommended if possible. However, in many cases, the equipment is unknown or is not capable of changing the Queries from UDP port 53. In this case, the Firewall or other equipment sending these encrypted DNS Queries should be isolated in a separate SPP with all DNS anomalies and DNS Feature controls disabled.	Enable/disable the DNS query response match (DQRM) table. Enable on all SPPs that do not carry encrypted DNS Queries.	Disable. DQRM depends on seeing both Queries and Responses. If these are not seen, DQRM will have unexpected results and may block users from the Internet.
Allow only valid queries under flood (LQ)		Enable/disable the legitimate query (LQ) table. LQ should normally be enabled ONLY on SPPs containing public Recursive or Authoritative DNS servers. It has little value for SPPs sending outbound Queries like firewalls and proxies.	Disable. The LQ table is populated based on seeing an r-code=0, 'good' DNS Response. This may not be available with asymmetric traffic.
Validate TTL for queries from the same IP under flood		Enable/disable the time-to-live (TTL) table. TTL validation should normally be enabled ONLY on SPPs containing public Recursive or Authoritative DNS servers. It has little value for SPPs sending outbound Queries like firewalls and proxies.	Disable. The TTL table is populated based on seeing an r-code=0, "good" DNS Response. This may not be available with asymmetric traffic.
DNS UDP Anti-spoofing Method inbound/outbound		Enable/disable anti-spoofing checks for inbound and outbound UDP DNS traffic. This can be used for all types of services. See firewall notes in second column.	Enable inbound if this leg of the traffic might see inbound DNS Queries
DNS flood mitigation mode inbound/outbound		Specify the antispoofing method if the source IP address is not already in the legitimate IP table (LIP): Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53. TC=1 reduces the amount of inbound traffic, particularly for Authoritative DNS servers. If you are protecting authoritative servers, use this. This is recommended for protecting Recursive servers. DNS Query Retransmission—Drop packets and test for valid retransmission. A valid client is expected to retransmit the Queries within preset time windows. DNS Query Retransmission reduces the amount of outbound traffic generated by FortiDDoS. If your outbound traffic is limited, use this.	Enable as for normal traffic suggestions.
Generate response from cache under flood		Enable/disable DNS caching. Generally, more valuable for DNS Authoritative servers and may assist Recursive servers under attack. No valid for outbound gateways, firewalls, etc.	Disable. Cache is created from outbound Responses which may not be seen.
Force TCP or forward to server when no cache response available		If DNS caching is enabled ('Generate Response From Cache Under Flood' setting above), one of the following behaviors must be configured: Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53. Use with Authoritative DNS Servers. Forward to Server—Forward the DNS query to the DNS server. Use with Recursive Servers If DNS caching is disabled, this setting is hidden and by default it will forward the DNS query to the DNS server.	Enable TC=1 if seeing inbound traffic.
Duplicate query check before response		Enable/disable checks for repeated queries from the same source. If enabled, under non-flood conditions, the system checks and drops repeated UDP/TCP queries from the same source if it sends them at a rate greater than 3 per second. Under flood conditions, the duplicate query check is done for TCP and not for UDP.	Enable if seeing inbound traffic.
Block identified sources		Enable/disable source IP address blocking periods for violators of any DNS-protection feature (ACL, anomalies, or flood meters). Disabled by default. DNS floods are often spoofed, so we do not recommend blocking an identified source to avoid punishing legitimate clients. Instead, we recommend you rely on the other DNS protection methods. They make packet-by-packet determinations and are not prone to false positives The configuration is open, allowing you to enable source blocking if you want to experiment with it in your network. If enabled, when a threshold is reached, packets are dropped and the identified sources are subject to the Blocking Period for Identified Sources configured on the Global Settings > Settings page. Layer 7 > DNS > Query Per Source > DNS Query Per Source Egress Max Packet Rate/Sec Layer 7 > DNS > Suspicious Sources > Packet Track Per Source Egress Max Packet Rate/Sec	Disable
Restrict DNS Queries to Specific Subnets		Enable/disable restriction to DNS queries from unwanted sources from the Internet. This feature allows service providers to protect their recursive or open DNS resolvers. In a typical deployment, the service provider will keep their open resolvers on the 'LAN' or the protected side of FortiDDoS and their own customers will be on the Internet side. On the Internet side, there will also be rogue DNS clients who send unwanted DNS query floods. To ensure that the DNS queries are only allowed from the service provider’s customers, the service provider must add those subnets into the Restricted Subnets list. By restricting the DNS queries to specific subnets, the service provider can avoid responding to unwanted queries and thus protecting DNS infrastructure from getting overloaded.	Optional. But disable on outbound leg if installed there. For this reason, this feature is not recommended for HA pairs where one system is on primary inbound and one is on primary outbound. See Fortinet support for more details
DNS Fragment		Enable/disable checks for DNS packets.	Enable if seeing inbound traffic.
Domain Reputation		Enable/disable domain reputation. If enabled, domain names in DNS query and response will used to match items in the Domain reputation database file. Domain Reputation updated through FortiGuard.	Enable if seeing inbound traffic.
DNS Resource Record Type ACL		Config range number of Resource Record Type.	Enable if seeing inbound traffic.

To configure with CLI:

config ddos spp dns profile

edit <dns profile name>

set dns-headeranomaly-feature-control {illegal-flag-combination invalid-op-code sp-equals-dp}

set dns-queryanomaly-feature-control {qr-bit-set null-query qdcount-not-one-in-query ra-bit-set}

set dns-responseanomaly-feature-control {qclass-in-reply qtype-in-reply qr-bit-not-set qd-count-not-one-in-response}

set dns-bufferoverflow-anomaly-feature-control {long-name-length long-label-length tcp-message-long udp-message-long}

set dns-exploitanomaly-feature-control {premature-end-of-packet class-not-in zone-transfer pointer-loop empty-udp tcp-buffer-underflow}

set dns-infoanomaly-feature-control {enable/disable}

set dns-dataanomaly-feature-control {extraneous-data long-ttl invalid-class-type short-name-length}

set dns-authentication-direction {none inbound outbound inbound-outbound}

set dns-flood-mitigation-mode-inbound {TC-equal-one dns-retransmission}

set dns-flood-mitigation-mode-outbound {TC-equal-one dns-retransmission}

set match-response-with-queries {enable/disable}

set validate-ttl-for-queries-from-the-same-ip {enable/disable}

set generate-response-from-cache-under-flood {enable/disable}

set allow-only-valid-queries-under-flood {enable/disable}

set source-blocking-in-dns {enable/disable}

set duplicate-query-check {enable/disable}

set force-tcp-or-forward-to-server {forcetcp/forward-to-server}

set aggressive-aging-incomplete-request {enable/disable}

set dns-fragment {enable/disable}

set domain-reputation {enable/disable}

config dns-resource-record-type-acl

edit <rule name>

set dns-resource-record-type-start <1-65535>

set dns-resource-record-type-end <1-65535>

next

end

next

end