Category: Domain Name Service


Configuring DNSSEC With Terraform and AWS Route 53

Why Enable DNSSEC?

The Domain Name Service (or DNS) has been apart of the internet since the 1980’s by combinging names to IP addresses together. Though there have been a few blog posts about DNS, we never discussed how to provide authentication to the responses you receive. Providing DNS services without authentication could lead someone to a rogue or spoofed internet site. This is where DNSSEC comes in.

A common attack vector against DNS servers is known as DNS Cache Poisoning. This happens when an attacker is allowed to send updates to zone files which do not belong to them. For instance, if I were allowed to send updates to a DNS server that belongs to Google, I could then point destination traffic to a host in my possession. I would then be able to set up sites which look identical to those of Google and steal your username and password, or capture what you look up online.

What DNSSEC Is Not

The activation of DNSSEC on your domain provides authenticity of the zone records, it does not provide confidentiality. DNSSEC does not encrypt your DNS traffic to and from the resolver. To provide encryption you must use the DNS over HTTPS (DOH), or DNS over TLS (DOT) protocol. These protocols protect your online privacy by encrypting DNS traffic to the resolver. This prevents Internet Service Providers (ISP) from sniffing your traffic.

You can also combine DOH/DOT and DNSSEC which will provide privacy and authenticity of the resolver. This is a new concept and only a few DNS providers are performing this type of service.

Getting Started

First you need to check if your Top Level Domain (TLD) supports DNSSEC.

If you own a .com domain, you are able to activate DNSSEC. For other TLD’s, please check the ICANN website.

Creating the KMS Key and Policy

The following is a template which can be used to create the KMS key and JSON policy. This will create an ECDSA P256 asymmetric key with sign and verify capabilities. Remember, DNSSEC does not provide privacy so all we need is to sign and verify the domain.

resource "aws_kms_key" "domaindnssec" {
  customer_master_key_spec = "ECC_NIST_P256"
  deletion_window_in_days  = 7
  key_usage                = "SIGN_VERIFY"
  policy = jsonencode({
    Statement = [
        Action = [
        Effect = "Allow"
        Principal = {
          Service = ""
        Sid      = "Allow Route 53 DNSSEC Service",
        Resource = "*"
        Action = "kms:CreateGrant",
        Effect = "Allow"
        Principal = {
          Service = ""
        Sid      = "Allow Route 53 DNSSEC Service to CreateGrant",
        Resource = "*"
        Condition = {
          Bool = {
            "kms:GrantIsForAWSResource" = "true"
        Action = "kms:*"
        Effect = "Allow"
        Principal = {
          AWS = "*"
        Resource = "*"
        Sid      = "IAM User Permissions"
    Version = "2012-10-17"

Next, we define the zone and tie the keys to the zone for signature and verification.

data "aws_route53_zone" "example" {
  name = ""

resource "aws_route53_key_signing_key" "dnssecksk" {
  name = ""
  hosted_zone_id =
  key_management_service_arn = aws_kms_key.dnssecksk.arn

resource "aws_route53_hosted_zone_dnssec" "example" {
  depends_on = [
  hosted_zone_id = aws_route53_key_signing_key.dnssecksk.hosted_zone_id

Verify That DNSSEC Is Working

Use dig to verify that DNSSEC is working on the domain. To get started use the following command:

dig +short +dnssec

Note that the resolver being used must be capable of providing DNSSEC look ups. To verify, run the dig command against a known DNSSEC service provider like Cloudflare.

$ dig +short +dnssec @
A 13 2 300 20220104184526 20220102164526 34505 T+hHkJPzWpqYHlh9qkTz9/YUzdOdOlmj5WhDytndJTEqqd9v3KJDz+Qx L1iV2ZhgvSUnV/YhPC4ccIJitS2y8A==

Now commit your code and you are all set.

BIND Response Policy Zones

Domain Name Service

Accessing resources across the internet is done through the use of IP addresses. When trying to access your email, Google for searching, or your favorite social media outlet, you are making a connection to the their IP address. The Domain Name Service (DNS) converts a name to an IP, allowing you to easily remember your favorite website. For instance, DNS will covert to How could we use BIND and DNS to thwart the bad guys?

Response Policy Zones

One of the best, unknown features of BIND is its use of Response Policy Zones (RPZ). RPZ’s allow an administrator to re-write a DNS query and send it back to the user. In the example above, when a user goes to access Amazon, DNS converts a name to a number. Once the web browser knows that number, it then reaches out to the server to access its resources. What if we were to manipulate that number, or make it where Amazon did not exist to our users?

This is where the functionality of RPZ’s come in. By configuring BIND to receive a DNS recursive lookup and manipulate the response back to the user, you can effectively stop users from accessing malicious sites.

Let us look at the recent privacy and security concerns related to Zoom. Due to its popularity and ease of use, the Zoom video conferencing service has not become a front runner. Not only has Zoombombing, where an uninvited user gains access to your video sharing stream, become a headache for the service but so has phishing websites. Recently, URL’s listed as and have sprung up. These websites are used to phish a users Zoom credentials. We can use RPZ’s to block company personnel or home users from accessing those websites, mitigating the attack.

How Do RPZ’s Work?

When properly configured, a BIND RPZ file will return a different IP address than the one that is published on the internet. The following will return a valid IP address for


Non-authoritative answer:

The query responded with the IP address of

What does a RPZ response look like?


** server can’t find NXDOMAIN

From the example above, the response changed from to NXDOMAIN. This means that the response came back with nothing, making the phish server non-existent.

DNS Architecture

Deploying a local BIND DNS server for an organization can be quite daunting. There are a multitude of options available within the configuration of the service. Though secure configurations are extremely important, one must not overlook how to architect its set up within a network. Architecting the service correctly from the start will ease configuration headaches further down the road.

Network Segmentation

Network segmentation must be considered when standing up new systems. Segmentation is performed through the use of a firewall or proxy device which restricts network traffic. This restriction provides necessities by blocking unused protocols, access to network ports, and access from systems and services outside of the segment.

To segment services properly, an organization can either segment individual systems from each other or by creating a Community Of Interest (COI). A COI is the combination of like systems within a network segment. For example, a DNS COI is the creation of a network segment where all of the organization’s DNS servers reside. Though this is not as secure as segmenting each DNS server away from each other, this is more secure than placing all systems within the same, flat, network segment. Architectural diagram is shown below:

Primary DNS

When deploying any DNS service, whether it is BIND or a different system, the primary DNS server must be as secure as possible. The primary server is the source of all your DNS naming information. If someone were to gain access to this server, or if the system is misconfigured, they would have the possibility to change DNS records which would allow the attacker to redirect users to phishing sites. This is why an organization must deploy two or more secondary servers.

Hidden Primary

In a hidden primary configuration, the primary DNS server is never exposed to anyone. The organization configures its DHCP server to advertise the secondaries and not the primary. Firewall rules restrict DNS traffic to only the secondary servers and disallow anyone from accessing the server outside of the IT department. This is to limit the exposure of the primary server. By not advertising the primary server, it further reduces the amount of information gathered by a potential attacker.

Secondary DNS

As the primary server is never advertised to the users, or the public, the secondary servers are exposed. These servers receive naming information from the primary server and are configured to allow lookups. Firewalls or DNS proxies must be configured to only allow DNS traffic to traverse the network and limit the number of requests, preventing certain types of attacks.

The hidden master architectural concept is not something new, however it is not well known. By limiting the exposure of the master server, allowing users to only access the secondaries, prevents a number of attacks an organization could face. This is an important initial step when planning for an initial DNS deployment, or redeployment, of the service. Getting this right starting out will help secure the rest of the configuration down the road.

Svart Hal: The DNS Firewall

With the unprecedented circumstances we as a society are facing, we have begun to transition from on-premise to a remote workforce. Though this transition is exciting to some, it can truly bring undue stress to an organization, its workforce, and IT infrastructure. Organizations that are new to a remote workforce struggle to ensure that their employees are practicing good cyber hygiene while at home. Ensuring that data is backed up and secured, employees using work devices instead of personal devices when working, and maintaining updated software and antivirus. Many of these systems are automated, pushing software and updates and may not be able to communicate with an employee end point remotely.

Many organizations have an on-premise security stack where all traffic is funneled through. This would include all traffic which travels to and from the business network. A security stack could have a firewall, IDS/IPS, web filtering, antivirus mitigations, VPN, etc. While many organizations have these protections in place, it does not protect a remote workforce without the enforcement of every employee connecting to the VPN. This too places undue strain on the corporate network. Organizations which terminate a VPN connection on the perimeter firewall place additional stress on the device. Every encrypted connection placed on the firewall requires additional CPU and memory to encrypt/decrypt the connection.

Due to the additional strain on the network, companies have opted to have employees only connect to the VPN when accessing internal resources. While this frees up firewall resources, this places a significant burden on ensuring that employees are protected from security threats. As organizations scramble to better protect their remote employees they tend to lose sight of the big picture. The question ultimately becomes, “How can I protect our employees from security risks and do this in a cost effective manner?”

One way of protecting employees is through the use of a DNS firewall. Typical firewalls only block source/destination, port, and protocol traffic. A DNS firewall is synonymous with web filtering, taking care of blocking malicious URLs, protecting the employee from accessing websites which could push malware to the end point. There are plenty of utilities one can use to block these types of attacks. Pi-Hole and OpenDNS provide free and paid services to help mitigate these types of attacks.

I have been working on a project, called Svart Hal, which takes advantage of ISC BIND’s Response Policy Zones (RPZ). In the coming days I will post how an individual or organization can take advantage of the use of RPZ and the scripts which are provided free and Open Source. Users will be able to utilize this set up to save on the cost of spending hundreds or even thousands of dollars on traditional web filtering services. For those currently using RPZ with BIND, and looking for a inexpensive ways to protect your users, please take advantage.

Check out Svart Hal on GitHub

Continuous Battle Over Encryption And Your Privacy

Privacy vs. Services

The NCTA, CTIA, and US Telecom recently sent an open letter to congress with concerns over Google’s implementation of the DNS over HTTPS (DoH) protocol. The DoH protocol allows for encryption of DNS look ups providing additional privacy on the internet. In the letter the companies state that internet service providers provide functionality including, “(a) the provision of parental controls and IoT management for end users; (b) connecting end users to the nearest content delivery networks, thus ensuring the delivery of content in the fastest, cheapest, and most reliable manner; (c) assisting rights holders’ and law enforcement’s efforts in enforcing judicial orders in combatting online privacy, as well as law enforcement’s efforts in enforcing judicial orders in combatting the exploitation of minors.” (pg. 3).

Monopolizing on DNS

Another concern that was stated in the letter is that Google will be able to monopolize on the queries made to their DNS servers. As businesses or households use a particular DNS hosting provider, that provider has the ability to collect the IP address and DNS search results. This would allow that provider to mine the data it has collected and sell it to marketing firms. The companies also state that since all Google made devices would utilize Google’s DNS service, it would cause a single point of failure (That is why Google has two DNS servers; and

Another Attack Against Encryption

U.S. Attorney General William Barr has once again made a plea with tech giant Facebook to create a backdoor into its end-to-end encrypted messaging platforms (i.e. Facebook Messanger, WhatsApp). Barr is not alone, the United Kingdom and Australia have also come out against using such end-to-end encryption. They state that without a backdoor, law enforcement cannot perform their duties in capturing and prosecuting criminals in court. Yet, law makers do not understand that encryption algorithms are completely free and open source. Anyone can do a simple search online and discover the math behind popular, and albeit strongest, encryption we have today. If such backdoors were put in place, privacy advocates will certainly use other tools, like Signal, to protect their secrecy online.

Protecting Privacy online

There are many things that one can do to protect their privacy online. The Electronic Frontier Foundation has published a number of articles on how can maintain privacy. Their Surveillance Self-Defense is a well documented series of articles that you can use to protect your privacy and security while online. From enabling multifactor authentication, creating strong passwords, using password managers, to “Choosing the VPN That’s Right for You.”


Privacy and security professionals have been pushing for encryption of internet traffic for many years now. Not only has there been a significant push from the privacy community, search engine giants like Google almost force websites to use encryption to increase search engine optimization (SEO) to drive higher results. Though the costs of purchasing Transport Layer Encryption (TLS) can be quite expensive, open source projects such as Let’s Encrypt allow anyone to create a publicly acceptable TLS certificate for free. These certificates are accepted by major browsers, without throwing warnings, and protects the privacy of the user accessing the site. This only resolves half of the problem.
In a recent article released by the Electronic Frontier Foundation (EFF), DNS is one of the biggest internet privacy issues facing home and corporate users. In its current implementation, DNS relays queries in clear text. This allows Internet Service Providers (ISP’s), or anyone inline of your internet traffic, to look at DNS queries and begin to build a profile on you.

Why is this a problem?

Prior to accessing a website, regardless whether or not it uses encryption, your computer performs a DNS lookup to find the IP address of the website you are trying to access. For instance, a simple DNS request to look up where resides goes out over plain text for anyone to see. Then once the computer knows the IP address it is supposed to be access, the web browser makes a request to the website over a TLS connection.

A person sniffing the traffic may not at that point know the contents of the website you are looking at, the individual however does know that you accessed As you might imagine, this is a significant privacy issue where an ISP or the like can then build a profile on you and sell it to third party marketers which can then target ads.

Solving it on the individual level

There are plenty of tools out there that individuals can use to protect their internet traffic. From applications which can be loaded on a computer or smart device to the use of VPN’s and Tor, these can all protect a specific person. What if you wanted to protect a household or an organization? Use of individual applications would be cumbersome to have everyone use individual applications.

BIND with DNS-over-HTTPS

One such was to do this is to set up a Bind DNS server. This will allow everyone in the organization to perform DNS queries and have those queries safeguarded from data mining. However this still allows someone to sniff DNS queries as they are sent in clear text. To overcome this problem we need to install ‘cloudflared’ on the server. The cloudflared service will then perform DNS-over-HTTPS queries, encrypting your internet traffic from the Bind server to Cloudflare’s DNS resolvers. This prevents anyone from sniffing your DNS traffic, allowing for additional anonymity on the internet.

Getting your system ready

First you will need to install and configure Bind on your server. Once that is complete, download and install the [cloudflared][cloudflared] application on the server. After installation you will need to make one minor change to the forwarders section in your `named.conf.options` file. First, remove the comments in front of forwarders, these will be in the form of double forward slashes – //

Next, add the port number to the loopback IP address. The configuration will then look like:

`forwarders { port 54; };`

After that, load up Wireshark and take a look at the traffic. You should no longer see the DNS protocol being used as everything will be running over TLS.

Am I fully protected now?

No. Though you are one step closer, you still need to ensure that you are performing your due diligence when accessing websites on the internet. Be careful when accessing websites that do not use encryption, especially when typing in your username and password. Use multifactor authentication in addition to a password manager and always double check the website you are accessing.

CloudFlare’s DNS Over HTTPS Service

How does DNS work?

Protecting your privacy online is a hot topic for many. Though many websites have transitioned from HTTP to HTTPS, allowing web traffic to be secured, this does not protect your overall privacy. The internet still relies on older protocols to ensure you are accessing the right website or other online resources.

DNS, or the Domain Name Service, is one of those protocols we rely heavily on everyday. Every internet connected device has at least one IP address. DNS allows you to type in and it resolves the IP address associated to it. One of the biggest issues with DNS is that it is one of those legacy protocols we rely on everyday. It has no built in security and runs completely in clear text. This allows your Internet Service Provider, or anyone capable of capturing internet traffic, to see what websites you access. This means that even if you are accessing a HTTPS website, others can still see your internet history.

Why is this bad?

As we continue on in the digital age, our internet history is being used against us. Website cookies, internet searches, and DNS queries are being sold to marketing companies. Everything you do is being bought and sold to a number of companies and marketing firms. These companies then take this information and use targeted ads in order to get you as the consumer to purchase online goods and services. There have been steps made to discourage and even eliminate this type of intrusion into our privacy however they have not been totally adopted due to complexity.

Protecting your online privacy

Using HTTPS over HTTP is a great first step in protecting the security and privacy of your internet traffic. The next step is to look at protecting the privacy and security of your DNS queries too. Many online DNS services provide this level anonymity and security. CloudFlare’s DNS over HTTPS is one such service that provides this level of protection. Their privacy policy states that under no circumstances will they ever sell your internet searches to outside third party companies. Quad9 by IBM states the same information in their privacy policy too. However just setting your DNS settings to either of these services is not enough. Your router or computer will still send clear text DNS queries without additional configuration.

CloudFlare offers a number of different ways to protect your online searches. If you are looking to just configure the service on your local machine, instructions and downloads can be found at their Downloads page. Quad9 offers the same level of integration.

If you are looking to provide DNS over HTTPS for your entire household or business your in luck as well. There are simple ways to get this configured so that everyone can take advantage. Different types of routers, including pfSense, can be configured to run DNS over HTTPS. To do so, you can utilize Untangle and configure it to run DNS over port 853. The configuration will be placed into the custom option area and will look like this:

name: "."
forward-ssl-upstream: yes
forward-addr: 2606:4700:4700::1111@853
forward-addr: 2606:4700:4700::1001@853

Once that is in place, and you have saved your configuration, you will now have an additional sense of privacy and security while online.

Powered by WordPress & Theme by Anders Norén