Last September, I attended the first-ever Mongolian Network Operators’ Group (mnNOG) meeting in Ulaanbaatar. A highlight for me was the Network Security and Packet Analysis workshop.
Read: Locals learning from locals is a hit in Mongolia
I am responsible for the DNS and web hosting of a local Internet Service Provider in Mongolia, so anything security-related to these areas always catches my interest.
Securing our network, and the information and communication of our customers, has always been a challenge. One particular area that needs to be vulnerability-free is our company website, which has an online store and customer login section that customers can access to control their services, and our subdomains, which we use for our web-hosting service. To secure this, we have secured our domain name using Domain Name Security Extensions (DNSSEC) — a set of security extensions I learned about during the workshop.
First step: Know the facts
The most essential part of deploying DNSSEC was to understand what it is and how it works. It can be a little confusing at first, but once you understand the concept of Public Key Infrastructure (PKI) — a fundamental component of DNSSEC and how it operates — you are halfway to implementing it.
From my experience, deploying DNSSEC on the authoritative server was not complicated. Nor was it for the recursive server — for that you only, technically, need two rows in your configuration file.
Securing the recursive server in your service network provides you and your customers a lot of reliability and protection. It checks every domain the customer asks, which prevents DNS-related cybercrime. I used this step-by-step guide published by the Internet System Consortium (ISC).
Challenges
The only obstacle I’ve faced was our network’s DNS structure. Those who developed it built two separate authoritative DNS servers to secure connections between two DNS servers.
This structure has various disadvantages, including issues with synchronization, which became prevalent when deploying DNSSEC. This is because you need to generate a Key Signing Key (KSK) and a Zone Signing Key (ZSK) for your soon-to-be-signed domain for both servers, which is not possible. Even if you copy and paste your keys, you would get two different signatures.
Learn more about KSKs and ZSKs. Register for the APNIC Academy DNSSEC Webinar Course
To overcome this, I had to rebuild our DNS servers from scratch into master-slave — this was an essential part of being able to deploy DNSSEC. I plan to write about this in a future post.
Lessons learned
My three top lessons for others considering deploying DNSSEC on their networks are:
- Make sure to let your supervisors know how important deploying DNSSEC is. Not everyone knows the DNS is the protocol that has zero security concepts. That’s why you need DNSSEC and PKI in every transaction in and out of your DNS server if you really want a secure network. Especially if you’re a service provider.
- Always be aware of when you need to change your keys. You can’t use the same keys for a long period because hackers know what they do, so schedule your key generating time. We call it a ‘key rollover’ and it needs to be done once a year, at max.
- Consider your signed domain as a dynamic zone if you configure your signing procedure as automatic. A rule you must understand is you can’t just edit your zone file manually; you need to freeze it before you do rndc freeze *domain name*. Otherwise, it could lead to a zone reload fail resolving error from all over the world. I know this because I’ve been through it 🙂.
Overall the process has been fun and educational.
Before I attend the workshop at MNNOG, I didn’t have much of an understanding about DNSSEC, and why we should secure our domain and network. At first it seemed challenging but now look at me. *\o/* I even improved our company DNS structure.
Nyamkhand Buluukhuu is a System Administrator of the Technical Planning Department at MobiCom Corporation LLC.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.