DNS Security Solutions & Services

DNS Security Solutions & Services

BT DNS security solutions


The domain name system (DNS) is a key requirement for nearly every IP network application, from web browsing, email, to multi-media applications and more. DNS provides the lookup and translation services from name to IP addresses that are used by computers to communicate. DNS is very effective and scalable and most people take DNS for granted given its proven reliability. However, its essential function and decentralised architecture can attract attackers who want to exploit the architecture and rich data store.

BT DNS security solutions An attack that renders the DNS service unavailable or which manipulates the integrity of the data contained within DNS can effectively bring a network down. As a side effect of its necessity, DNS traffic is generally permitted to flow freely through networks, exposing networks to attacks that leverage this freedom of communications.


Our DNS security solutions include the following core components:

  • DNS firewall – Sapphire appliances support DNS firewall functions to block or redirect DNS query responses based on dynamically updated domain block lists provided by the BT DNS Firewall Service or user systems. The DNS firewall provides an effective means to block malware attempts to locate Internet resources and export sensitive information and to detect malware affected devices within your network.
  • Threat detection – like many network services, DNS suffers from several threat vulnerabilities. Our threat detection capabilities enable detection and reporting of such threats as malformed packets, DNS tunneling, protocol abnormalities. Sapphire appliances support the detection and logging of such events for remediation.
  • Response rate limiting (RRL) – Diamond IP enables configuration of response rate limiting to prevent the effective use of your DNS servers in a targeted reflector style DoS / DDoS attack. This also includes protections and controls against pseudo-random subdomain attacks.
  • DNS security extensions (DNSSEC) – digital signing of zones enables authentication of zone information and data integrity verification. Diamond IP supports configuration of DNSSEC validation of signed resource records and Sapphire Sx appliances support automated DNSSEC signing management of zone information.
  • Network access – access control lists (ACLs) at the network interface level and at the DNS application level provide granular permit and deny controls. Our denial of service rules support rate limiting of incoming packets based on user-specified criteria to protect against DoS / DDoS attacks. Sapphire appliances support anycast addressing to effectively disseminate DoS / DDoS attacks.
  • Sapphire appliance security – our appliances are built from the ground up with a proprietary hardened operating system and kernel. Our appliances operate core services within jailed environments and restrict users, permissions and the file system.

Related videos

Is your network security missing something?

The domain name system (DNS) is used for every Internet Protocol (IP) connection to web servers, email servers and so on, providing the vital linkage between the user-entered “www” name and its IP address your computer needs to connect. Yet securing DNS is often overlooked. This webinar arms you with details of various forms of DNS attacks and approaches you may employ to mitigate risks to your DNS and your network as a whole.

Improving network security with DNS firewalls

Malware has menacingly emerged as a critical threat to enterprise networks, infecting user laptops, mobile phones and even Internet of Things (IoT) devices. Malware may be installed using a variety of methods and if successfully installed on a device that is trusted within the confines of an enterprise network, it may have access to sensitive information. The installed malware may likely use DNS to identify the current IP address of the attacker’s external destination for exfiltration of the information. A DNS firewall can protect your network and to help identify such infected devices. As malware attempts to locate its command and control center for instructions or software updates using DNS, a DNS firewall can identify such queries and apply corresponding query response policies.

Secure your DNS, secure your network

DNS has proven extremely effective and scaleable in practice and most people take DNS for granted given this and its proven reliability. However, its essential function and decentralised architecture serve to attract attackers seeking to exploit the architecture and its rich data store for sinister activities. For example, you’ve probably heard about the recent DDOS attack on Dyn thanks to the Mirai malware. This webinar discusses that attack and other DNS attack vulnerabilities and how you can protect yourself to improve your overall network security.

The Easy Way to Deploy DNSSEC.

The domain name system (DNS) provides the lookup and translation services from name to IP addresses that are used by computers to communicate. DNSSEC provides a means for you to improve the reliability of your resolved DNS data. Those users trying to reach your website by querying your DNS data can validate your signatures and confidently cache your resolution data for your DNS namespace. These benefits do come with an administrative cost in terms of managing zone keys and signatures. Fortunately several automation techniques are available to streamline administrative requirements.

  • Is your network security missing something?
    Is your network security missing something?
  • Improving network security with DNS firewalls
    Improving network security with DNS firewalls
  • Secure your DNS, secure your network
    Secure your DNS, secure your network
  • The Easy Way to Deploy DNSSEC.
    The Easy Way to Deploy DNSSEC.
Show more Show less


DNS security

Why do I need to secure DNS?
DNS is foundational to the operation of your network. If DNS services are disrupted, your users will consider the network down and unusable. So securing DNS in and of itself is critical. But because DNS is foundational, DNS traffic is often freely permitted to flow from and to internal and external (Internet) destinations with little to no filtering. This security backdoor has attracted many attackers seeking to use DNS to locate resources within and outside your organisation and for carrying sensitive organisational information within DNS payloads as a form of DNS tunneling.
From what vulnerabilities is DNS exposed?
Like any network service, DNS is vulnerable to host level infiltration attacks, exploitation of operating system and DNS software vulnerabilities, denial of service (DoS) attacks, and distributed denial of service (DDoS) attacks. Attackers may attempt to manipulate DNS information to point popular web addresses including yours to imposter websites to collect personal or financial information from unsuspecting browsers. Attacks may also use DNS in the manner for which it was intended to gather IP addressing information for potential attack targets or by malware to locate a command and control centre for instructions or to export sensitive corporate information. In addition, poor server deployment design can expose a risk of unavailability of DNS services due to poor performance or lack of redundancy. Clearly, there are many risks and vulnerabilities which must be accounted for when deploying and managing DNS. You need to protect your DNS infrastructure and also be attentive to ill uses of DNS for ancillary attacks on other infrastructure or devices. Please consult our DNS security white papers and look for our book to help you secure your DNS.

DNS firewall

What is a DNS firewall?
A regular DNS server receives DNS queries from clients and obtains a query answer from another DNS server on the Internet, passing it back to the requesting client. A DNS firewall is a DNS server configured to perform normal DNS queries, but prior to responding to the client, it consults its firewall policy to determine whether to provide the retrieved answer unaltered, or to modify, drop or respond as ‘not found’. So a DNS firewall blocks query answers to certain domains or from certain clients, and answers obtained from certain DNS servers or IP addresses.
I have an Internet firewall, why do I need a DNS firewall?
Internet firewalls are traditionally boundary routers focused on stopping attacks from the internet reaching the interior of your network. A DNS firewall seeks to block outbound traffic originating within your network. For example, malware that has infected a device within your network may attempt to locate its command and control centre for instructions or to export sensitive data. But even if your Internet firewall filters and blocks outbound traffic, a recommended defense in depth approach using both firewalls helps reduce the probability of successfully traversing both firewalls.
What are malware, bots and botnets?
Malware is a portmanteau comprised of the terms ‘malicious software’. Malware is software that installs itself on a host machine for the purposes of disrupting the operation of the machine or of serving as a beachhead from which further malicious operations may be performed on the device or to other devices to which it has connectivity. When serving as a beachhead, the malware essentially becomes a programmable robot or bot for short. A collection of bots under the control of a single operator comprises a botnet which enables an attacker to utilise multiple bot resources for a coordinated attack.
How does a DNS firewall protect against bots?
Bots attempt to remain undetected so they can be controlled by the botnet operator for as long as possible. They may be programmed to check in occasionally for updated software or attack instructions. To locate the botnet command and control (C&C) centre, most bots use DNS. Many botnets operate from domain hosting providers or from IP address space of suspect reputation. As such, a DNS firewall helps to filter such queries based on recent reputation data to block malware queries to respective C&C centres. DNS firewalls also log query attempts to malware-infected devices may be identified and remediated.
Is a DNS firewall a panacea for malware protection?
Security experts would agree there is no panacea for any form of potential network attack. A DNS firewall is a strong component of a malware protection strategy and network security strategy in general. But a multi-faceted defense in depth approach provides for multiple detection points and attack barriers to minimise attack penetration. Our solutions include DNS firewall but also other defense mechanisms including DNSSEC, DNS ACLs, rate limiting, anycast addressing and more.
Do I need special hardware for a DNS firewall?
No, though you should make sure your DNS software supports it. Diamond IP Sapphire appliances as well as Internet Systems Consortium (ISC) BIND DNS servers, among others support DNS firewall functionality in the form of response policy zones (RPZ). Diamond IP offers a DNS firewall feed to automatically keep your DNS firewalls filters refreshed and updated using standard DNS protocol, regardless of your chosen DNS vendor.
How do I configure a DNS firewall?
A DNS firewall is typically configured by defining one or more response policy zones (RPZs) on your recursive / caching DNS servers. RPZs are special DNS zones which contain policies regarding how to respond to DNS queries and answers of specified criteria. These criteria or triggers, when defined in an RPZ correspond to a specified action governing how the DNS server should respond to the requesting client, e.g., to pass through, alter or drop the response. RPZs may be configured manually by one knowledgeable of RPZ resource record formatting. Customers may also simply subscribe to the Diamond IP DNS Firewall service to have automated policy updates sent to your DNS servers to maintain current block lists. Setup of our firewall feed is a breeze, with the setup of a zone and a transaction key. We send updates automatically to protect your network against malware.
What DNS response policy triggers can be defined?
Response policy triggers define the criterion on which to match a given query response; upon matching, the corresponding policy is applied. Triggers can be defined based on the following information in the DNS response:

- Querier IP address – the IP address of the device that issued the DNS query
- Query name – the name queried by the host
- Answer IP address – the IP address contained in the DNS query response
- DNS server name – the domain name of the responding DNS server
- DNS server IP address – the IP address of the responding DNS server
What policies can be applied to query response matching triggers?
The following actions can be programmed for the DNS server to perform on query responses based on matching triggers:

- Pass the response through
- Drop the response
- Respond with ‘not found’ (NXDOMAIN)
- Respond with ‘no data’ (NODATA)
- Respond indicating truncated data to impel the query to be issued over TCP
- Local policy - e.g, redirect the querier to a captive portal for further investigation and remediation


What is DNSSEC?
DNS security extensions, DNSSEC, defined in RFCs 4033-4035, provide a means to authenticate the origin of resolution data within DNS and to verify the integrity of that data. It enables resolvers to validate that the resolution data received for a given zone was indeed published by the corresponding zone administrator and was not tampered with en-route. Thus, DNSSEC provides a means to detect packet interception, message ID guessing, and cache poisoning attacks. In fact, DNSSEC was acknowledged as the only comprehensive solution to the highly publicised Kaminsky cache poisoning DNS protocol vulnerability.
What is cache poisoning?
DNS resolvers and recursive caching servers maintain a cache of resolved resource records to improve resolution performance. If an attacker succeeds in corrupting a recursive server’s cache, the corrupted information may be provided to several users requesting the same or similar domain name information. Corrupting the cache requires an attacker to provide a seemingly legitimate query answer albeit with falsified resolution information in part or in total.
What is the Kaminsky vulnerability?
Dan Kaminsky was the Director of Penetration Testing at IOActive in 2008 at the time he identified a vulnerability which broadened the scope of cache poisoning attacks. Whereas typical cache poisoning attacks attempt to manipulate resource records within the answer section for a given destination, the Kaminsky attack seeks to manipulate cache via resource records populated within the Authority and / or Additional section(s), while remaining within the same bailiwick. This enables an attacker to repoint queries to its own name servers as authoritative for the target domain.

Let’s say an attacker wishes to target a popular domain, say ‘example.com’. A ‘standard’ cache poisoning attack may attempt to corrupt the cache for the www.example.com record. But if the attacker can essentially assume control of the example.com domain, they can provide falsified answers for the www record or any other record within the domain at will. Under the Kaminsky attack, the attacker initiates queries for random hostnames within the target domain, e.g. 1.example.com, www83932.example.com, etc. Such querying for domain names within the target bailiwick that are unlikely to already reside in cache should prompt the server to resolve these by querying other name servers. When such a query is initiated, the attacker may then start sending responses to the query each with varying destination UDP port numbers and transaction IDs in an attempt to provide a match to convince the recursive server of the seeming legitimacy of its response.
How can I defend against cache poisoning?
The definitive solution to cache poisoning attacks requires the authentication of each DNS query answer as having been published by the authoritative domain owner. DNS security extensions (DNSSEC) specifications provide for query answer authentication as well as data integrity validation to assure no manipulation of query answers in route to the validating resolver. DNSSEC also provides authentication of information that does not exist in the domain’s zone, or ‘authenticated denial of existence’. DNSSEC provides these features by digitally signing DNS data.

Additional measures include randomisation of the source UDP port and DNS header transaction ID fields within the outbound DNS query from your recursive servers. Query case randomisation may also hinder cache poisoning attempts.
How do I configure DNSSEC signing?
Most DNS server implementations support some level of automation for DNSSEC signing, including our Sapphire Sx series which offers fully automated key generation, signing and rollover. The full process is complex and we refer you to our DNSSEC white paper for full details, but in a nutshell, DNSSEC signing utilises asymmetric key cryptography.

DNS operations experience has shown its best if you create a pair of keys for each zone you’d like to sign, a zone signing key (ZSK) and key signing key (KSK). You’ll need to define a pair of key pairs for each zone you’d like to sign. Publish the public keys for your zone and sign with the corresponding private keys. DNSSEC signing utilities can handle the details of canonically ordering zone contents, applying denial of existence records and signing the zone. You’ll also need to inform your parent zone administrator of your public KSK to link you signed zone within the root chain of trust. Or you can deploy our Sx DNSSEC applances to automate this entire process.
How do I configure DNSSEC validation?
Configuring validation requires configuration of the DNS root zone’s public key, which serves as the DNSSEC trust anchor. All signed zone information can be linked up the DNS domain tree to the root trust anchor for validation, assuming all intermediate zones are also signed. As the root zone administrators roll over keys, your DNS server should be able to automatically detect this and update its trust anchor accordingly to maintain the integrity of DNSSEC validation.
Is there ongoing maintenance needed with DNSSEC?
Zone resource record sets have signature records (RRSIG) which indicate a signature validity start and end time. New signatures to replace expiring ones should be performed, and most implementations perform this automatically. Zone keys must also be changed periodically, but this process requires a ‘rollover’ interval where multiple keys are valid or cached given the distributed nature of DNS information dissemination. Various rollover processes have been defined, as highlighted in our DNSSEC white paper. Our Sapphire Sx DNSSEC appliances automate the key generation and rollover processes to minimize your maintenance requirements.

White papers

DNS Security Steps

DNS Security Steps

DNS vulnerabilities and defensive strategies.

DNS Firewalls

DNS Firewalls

Learn about DNS firewalls and how they work.

Intro to DNSSEC

Intro to DNSSEC

Secure DNS resolution with DNSSEC.