I want to start with a number: Zero.
Until August 2025, not a single Second Level Domain (SLD) under .BD — Bangladesh’s ccTLD — was protected by DNSSEC. Every DNS response for every .BD domain was unauthenticated. Every government portal, every university system, every bank. Approximately 50,000 domains. Millions of passive users…
Zero cryptographic protection.
This post describes the technical steps, operational challenges, and lessons learned from deploying DNSSEC at an economy-wide scale, and the people who made it possible.
Why it mattered
DNS was built on blind trust. A poisoned resolver cache can silently redirect a citizen to a fake bank. A hijacked DNS query can intercept a government login — invisibly. Bangladesh is not unfamiliar with the consequences. In 2016, Bangladesh Bank lost USD 81 million in a cyberattack where DNS was a key vector.
BTCL, Bangladesh’s largest telecommunications company and the operator of .BD, began to address this gap in early 2024.
In June 2024, APNIC delivered a three-day DNS/DNSSEC workshop in Bangladesh, attended by 28 participants. The session was led by Md. Abdul Awal, Senior Network Analyst and Technical Trainer at APNIC.
During this period, the BTCL domain team successfully completed DNSSEC deployment between the root zone and the .BD nameserver.
And then — progress stalled.
An economy-wide DNS blackout disrupted operations, halting momentum just as it began. Without the operational confidence to push forward beyond the initial deployment, the work stopped there. As it turned out, the confidence needed would come from an unexpected direction.
The workshop that changed everything
In May 2025, I attended the Phoenix Summit, where I met Philip Paeps (NSRC). His approach was simple but uncompromising: You learn by doing — and you start immediately.
On day one, I was completely lost. Every error felt like a dead end. The commands didn’t make sense, and I seriously considered quitting.
By day two, something began to shift. Patterns started to emerge. At 11 pm, I was still at my desk, debugging zone files and refusing to give up.
On day three, it all came together. The zone was signed. The Delegation Signer (DS) record was submitted. The chain of trust was validated. I earned the certificate.
Philip threw me into the deep sea with no life jacket, and that’s exactly what I needed. He gave me the confidence to realize I could do this. Then the question changed: Would I take it further, and do this on an economy-wide scale?
The answer was yes — but the path was not smooth.
Deploying DNSSEC in ac.bd
We were working with a signing stack that was functional, but not ideal. At the time, our authoritative nameservers were running BIND 9.9+, using auto-dnssec maintain with inline signing for the initial rollout. It was already on the borderline of being outdated, but upgrading wasn’t an option, so we kept moving forward with what we had.
We used separate Key Signing Key (KSK) and Zone Signing Key (ZSK) pairs, both generated with Algorithm 13 (ECDSA P-256 with SHA-256), which is compact, fast, and broadly supported:
- The KSK signed the DNSKEY Resource Record Set (RRset)
- The ZSK handled all other record sets
DS records, created as SHA-256 hashes of the KSK, were submitted to the parent zone to establish the chain of trust.
Every change was tested in a staging environment before touching production. We relied on:
- DIG CLI tool for real-time validation, troubleshooting and debugging
- DNSViz to visualize the chain of trust
- Verisign Labs DNSSEC Debugger to validate signatures and DS records at a granular level
To actually deploy DNSSEC on ac.bd, we needed a signed child zone to validate the full chain end-to-end. Khulna University of Engineering & Technology (KUET) signed kuet.ac.bd and provided its DS record, enabling the first end-to-end validation of the chain.
That’s when the ‘oh wait’ moments began — three of them, back-to-back.
First, the portal wasn’t ready. BTCL’s customer-facing system had no way to accept DS record submissions because no one had built that feature yet. So, we submitted the DS record manually, directly through an administrator. Not elegant, but effective. The portal caught up later.
Then came a ghost in the chain. DNSViz revealed a DS record in the parent zone pointing to a KSK that no longer existed: Algorithm 8, Key Tag 26044, marked as NON_EXISTENT. A deleted key whose fingerprint was still being trusted, but breaking validation. The fix was straightforward, but critical: Remove all stale DS records via the IANA portal.
Finally, there was the issue of SHA-1 and silent failures. Digest Type 1 (SHA-1) records were still present, even though they are no longer recommended under RFC 8624. At the same time, firewall rules were silently dropping UDP packets, which caused child zones to show errors even after they had been correctly signed. We fixed it by enforcing SHA-256-only DS records, correcting the firewall rules, and verifying EDNS0 support.
On 26 August 2025, kuet.ac.bd became the first .BD domain in history to achieve a complete, validated DNSSEC chain of trust from root to leaf.
Expanding to gov.bd and com.bd
The story didn’t end with ac.bd.
Next came gov.bd — government portals, citizen services, the highest stakes. quicksign.gov.bd became the first signed child. There were more operational challenges and many late nights. By September 2025, those challenges were resolved. The Bangladesh Computer Council led the way, stepping forward to sign multiple domains.
Then came com.bd, the commercial backbone: Banking and e-commerce. primebank.com.bd, a major financial institution, became a landmark validation of the chain. This phase was completed by November 2025.
Five SLDs are now signed — ac.bd, gov.bd, com.bd, net.bd, and org.bd.
Verification was done end-to-end. DNSViz reports a clean SECURE status across every level of the hierarchy, and the AD (Authenticated Data) flag is consistently observed in resolver responses from global vantage points, including Brisbane (BNE) and Sydney (SYD). With five major SLDs signed and validation complete, one DNSSEC chain of trust now spans .BD.
What comes next
There’s still more to improve. We plan to introduce NSEC3, which helps prevent others from easily listing all domain names in a zone. We’ll move to dnssec-policy to replace the older auto-DNSSEC maintain, making key management more reliable and easier to automate.
We also need a key rollover schedule to regularly replace cryptographic keys, and Hardware Security Module (HSM)-based storage to better protect the .BD private keys.
On the infrastructure side, anycast deployment for authoritative nameservers will make the system faster and more resilient by serving users from multiple global locations.
Most importantly, we need registrant education — so every .BD domain owner understands DNSSEC and can sign their own domain, completing the chain of trust.
Lessons learned
A willing first mover is worth more than any lab environment: KUET stepped forward on the very first call, volunteering to go first. Their willingness to sign kuet.ac.bd gave us a real child zone to test against. Without a live DS record to publish, we could not have validated the full chain before signing ac.bd. If you are planning a DNSSEC rollout, find one cooperative registrant willing to go first. A real, signed zone will teach you more than any testing tool ever can.
Tooling gaps will slow you down more than DNS complexity: Our biggest delay wasn’t key generation or zone signing, it was the absence of a DS record submission field in BTCL’s customer portal. The cryptographic work took hours; the portal gap took weeks to close. The lesson is straightforward: Audit your operational tooling before you begin. Ensure your registrar portal, Extensible Provisioning Protocol (EPP) implementation, and DS submission workflow are ready because those gaps, not the cryptography, will determine your pace.
DNSSEC failures are often networking problems, not cryptographic ones: For example, a stale root zone delegation record or a firewall silently dropping UDP packets. The lesson is clear: When DNSViz shows a broken chain, start with your networking and delegation records before touching your keys.
Validation tools are not optional: DNSViz gave us a clear, visual map of the chain of trust at every level. The Verisign DNSSEC Debugger provided per-record verification of DS and Resource Record Signature (RRSIG) data. Without them, we would have been debugging blind. Run these tools before and after every change — not just at the end.
Community support matters: No one deploys DNSSEC alone.
Acknowledgements
I have to name the people who helped make this a reality.
Through every error and every setback, one person picked up every call — even in the middle of the night: Md. Abdul Awal, Senior Network Analyst and Technical Trainer at APNIC. He led our first workshop and became our remote debugging partner throughout the entire deployment. I am running out of words to thank him for his patience, guidance, and relentless support.
Md. Anwar Parvez (BTCL) initiated the DNSSEC journey by establishing signing between the root zone and the .BD servers. Even after leaving the team two years ago, he continued to back us at every step without losing faith. Mostofa-Al Mahmud (Former DGM, Domain, BTCL) and the entire BTCL management team turned organizational intent into operational reality.
Masudur Rahman, Zakir Hossain, Alamgir Hossain, and the REVE Systems team automated DS record submission — a genuine game-changer for scalability. Md. Mahedi Hasan (University of Dhaka) was a steady and reliable presence through every crisis.
A. S. M. Shamim Reza (TheTeamPhoenix) and Philip Paeps (NSRC) gave me the hands-on DNSSEC confidence long before the economy-wide rollout began. And Bangladesh Network Operators Group (bdNOG) gave all of us a community where this kind of knowledge can move, grow, and take root.
Today, approximately three million .BD domain lookups per day are cryptographically authenticated. In practical terms, every government citizen service, every university portal, and every financial system resolving under a signed SLD now returns a tamper-evident, verifiable DNS response.
If I could go from knowing nothing to helping deploy DNSSEC for a ccTLD in under eighteen months, others can do this too.
Sign your zone.
Join your local NOG.
Ask for help, and the community will answer.
Joyeeta Sen Rimpee works in Domain and Email Operations at BTCL, where she leads DNS security and domain management for the .BD ccTLD. She was the primary implementer of DNSSEC across Bangladesh’s .BD SLDs in 2025.
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.