Securing Government websites with DNSSEC

It is no secret that Government websites are lucrative targets for hostile organisations looking to exploit their credibility, as these websites serve as trusted repositories of information that the public use on a daily basis. With the rise of scams and increasingly sophisticated website spoofing techniques, it is vital that website addresses and URLs are accurate, as they serve as waypoints to lead you to the correct destination, or the correct information in the case of websites. In a way, these website addresses are like the street addresses that we use to navigate around a city. However, imagine if someone were to maliciously change the street signs overnight, leading people to the wrong part of the city and causing disruptions to people rushing for work the next morning. This is the kind of chaos that malicious actors want to create with the Domain Name System (DNS), which is the address book of the Internet, by exploiting weaknesses of DNS to bring you to malicious websites.

Hence, DNS Security Extensions, or DNSSEC for short, is vital to ensure that this does not happen. DNSSEC is akin to a vigilant cybersecurity patrol unit that works around the clock to validate the authenticity of the digital addresses you visit, much like a diligent city planner going around the city to ensure that all street signs are accurate and have not been tampered with. DNSSEC provides the assurance that the information the public accesses on the website is legitimate and have not been tampered with, which is especially important even for static websites, as any compromise in their integrity could mean misinformation being disseminated and a loss in public trust.

Earlier in August this year, I had the opportunity to explore how we can enable DNSSEC to over 500 Government websites hosted by the Isomer team at Open Government Products. This was part of an earlier mandate by the Cyber Security Agency (CSA) to ensure compliance with the recommendations outlined in the Internet Hygiene Portal.

Why enabling DNSSEC is so difficult

DNSSEC addresses one of the fundamental flaws of DNS, which is the lack of authentication. When you enter an address in your browser, the computer will utilise DNS to translate that human-readable string into a numerical IP address that is used to communicate over the Internet. As DNS is a distributed system, it is susceptible to malicious attacks such as DNS cache poisoning, in which an attacker may “poison” a particular DNS resolver’s cache by populating it with the wrong DNS entries, thereby redirecting DNS queries to a malicious website. With DNSSEC, digital signatures and cryptographic keys are used to ascertain the authenticity of a particular DNS record, and the computer performing the DNS query will confirm that the site’s security keys matches those on record. If the keys do not match, DNSSEC will flag those discrepancies and the user will be prevented from accessing the malicious website.

However, DNSSEC adoption remains very low among the major Internet websites today, as it is challenging to implement DNSSEC together with Content Delivery Networks (CDNs). CDNs operate by having multiple servers in various different locations serving the same content, and each server needs to respond to the DNS queries as if they are the origin. This conflicts with DNSSEC’s need for consistent, cryptographically signed responses. Given that record signing is slow, CDN providers can’t readily change the IP address of a DNS record and digitally sign the record with each query, leading to the low adoption rate of DNSSEC as many websites depend on CDNs. As Isomer is hosted on various CDN providers like AWS CloudFront, this adds a significant blocker to the adoption of DNSSEC and compliance with the recommendations provided by the Internet Hygiene Portal.

Introducing the DNS indirection layer

As DNSSEC operates on a chain of trust starting from the root servers, having any part of the chain broken means that DNSSEC cannot be enabled for the domain. All .gov.sg domains are DNSSEC-signed, which means that all Government websites have the potential to be DNSSEC-signed, but because we rely on CDN providers, the CNAME to the CDN provider introduces a broken link in the chain and prevents DNSSEC from being enabled for the website.

To work around the limitations that the CDN providers face, we decided to implement a DNS indirection layer to bypass the use of the *.cloudfront.net domain. Typically, this is how an agency would configure their website (response from dig):

;; ANSWER SECTION:
www.agency.gov.sg.		240	IN	CNAME	somegibberishstring.cloudfront.net.
somegibberishstring.cloudfront.net. 60 IN	A	54.192.150.16
somegibberishstring.cloudfront.net. 60 IN	A	54.192.150.73
somegibberishstring.cloudfront.net. 60 IN	A	54.192.150.129
somegibberishstring.cloudfront.net. 60 IN	A	54.192.150.6

Notice that because the somegibberishstring.cloudfront.net domain was used, and *.cloudfront.net is not DNSSEC-signed, it results in the website not being DNSSEC-signed. Instead, we introduced a DNS indirection layer by letting agencies point their domains to a specific domain that we control (and we know is DNSSEC-signed), then pointing that domain to the underlying CloudFront IP addresses. That is (response from dig):

;; ANSWER SECTION:
www.agency.gov.sg.		240	IN	CNAME	agency-gov-sg.hostedon.isomer.gov.sg.
agency-gov-sg.hostedon.isomer.gov.sg. 60 IN	A	54.192.150.16
agency-gov-sg.hostedon.isomer.gov.sg. 60 IN	A	54.192.150.73
agency-gov-sg.hostedon.isomer.gov.sg. 60 IN	A	54.192.150.129
agency-gov-sg.hostedon.isomer.gov.sg. 60 IN	A	54.192.150.6

The hostedon.isomer.gov.sg domain is DNSSEC-signed and hosted on AWS Route 53. Thus, the chain of trust is not broken and the agency domain is DNSSEC-signed! This was all done using a single DNS record change on the agency’s end, with no site downtime.

How the DNS indirection layer works

You might be wondering how I got the IP addresses above, and whether this is a significant maintenance burden due to the changing IP addresses on CloudFront. In reality, this DNS indirection layer does not add any additional complexity for engineers, as it is automatically handled by AWS.

On AWS Route 53, each indirection domain record is created as an ALIAS A and ALIAS AAAA record. This is a non-standard DNS record provided by AWS Route 53 to allow creation of A and AAAA records pointing to a domain name. In this case, two records were created on AWS Route 53:

AWS Route 53 then automatically resolves the somegibberishstring.cloudfront.net record to the underlying IPv4 (for A record) and IPv6 (for AAAA record) addresses, which is then returned to the user upon each DNS query. Thus, no additional maintenance burden was added to the engineers, except to initially create the two records above for the agency to use, and if the underlying CloudFront domain changes. This infrastructure is also handled automatically by Pulumi, and the repository is publicly viewable.

Thus, with this indirection layer, we allow the agency to have their agency website DNSSEC-signed, and yet still benefit from having it hosted on a CDN provider. However, of course, this method requires that you use CloudFront as a CDN. It would not work if you have another CDN provider, as you would not be able to know the underlying IP addresses that the CDN provider uses.

What about CloudFlare?

CloudFlare is another CDN provider that uses a different method for responding to DNS queries, which makes it possible for websites to be both DNSSEC-signed and also benefit from having a CDN. It was an alternative that was considered, but due to the significantly higher costs involved ($300 per month on CloudFlare vs $0.50+ per month on AWS Route 53), the method was not further considered for use by Isomer.

Nonetheless, if you are considering CloudFlare, I recommend using their partial CNAME setup if you do not have your entire domain’s DNS hosted on CloudFlare DNS (as is the case with most Government agencies), although note that it would require you to be on at least their Business plan. When you host your website on CloudFlare, CloudFlare will pull a copy of the site from the underlying source and stores that copy on their servers. Thus, when users visit your site, they would retrieve a cached copy from CloudFlare without ever accessing the underlying source. On the DNS level, CloudFlare abstracts away the source site and will only point users to the CloudFlare servers, an example is shown below (response from dig):

;; ANSWER SECTION:
www.agency.gov.sg.		240	IN	CNAME	www.agency.gov.sg.cdn.cloudflare.net.
www.agency.gov.sg.cdn.cloudflare.net.	300	IN	A	104.21.32.179
www.agency.gov.sg.cdn.cloudflare.net.	300	IN	A	172.67.153.50

The partial CNAME setup works in a similar manner to how the DNS indirection layer works, but this time it is CloudFlare that is handling the DNS indirection layer. Thus, you can set up your partial hosted zone on CloudFlare and direct CloudFlare to pull from the source site that you specify. Since cloudflare.net is also DNSSEC-signed, this allows an unbroken chain of trust and your website would be DNSSEC-signed as well.

However, do take note that you will need to make use of CloudFlare’s Advanced Certificate Manager in order to automatically provision SSL certificates for your partial DNS setup. As of time of writing, it costs about $10 per month per hosted zone, which can be an exorbitant cost if you are managing a large number of sites like Isomer does.

Conclusion

Having DNSSEC is absolutely vital in our inter-connected era where the peace of mind that comes from having this functionality is invaluable, especially for public institutions like the Government. However, having this added security may come at a cost to performance. Nonetheless, there seems to be some developments to DNSSEC, such as using ECDSA to perform live signing. We can only hope that having DNSSEC signing gets less expensive in terms of monetary and computational costs, and move towards a better and more secure Internet.

Disclaimer: The views and opinions expressed in this blog post are solely those of the author and do not necessarily reflect the official policy or position of any Singapore Government agency or entity. The content provided is for informational purposes only and is not meant to be an endorsement or representation by any government entity or otherwise. While every effort has been made to ensure the accuracy and completeness of the information presented in this article, the author acknowledges that there may be errors, omissions, or inconsistencies herein. Feedback and corrections are very much welcomed.