DNS & DNSSEC
The Domain Name System turns names into addresses, and almost every service fails visibly when it breaks. Authoritative servers publish the answers for a domain; recursive resolvers look them up for users and cache the result. We design both sides: where the zones are hosted, how many independent providers answer for them, and which resolvers a company's devices use.
What we do
- Authoritative zone design across two or more independent providers
- DNSSEC signing, DS publication and safe key rollover
- Recursive resolver deployment with validation and encrypted transport
- DoH and DoT rollout for managed devices
- Anycast and health-checked traffic steering
- Split-horizon DNS for internal and external views
- Email authentication records (SPF, DKIM, DMARC) kept correct
- DNS logging and monitoring for outages and abuse
DNSSEC (RFC 4033 to 4035) adds data origin authentication and integrity, so a resolver can check that an answer was signed by the zone's owner and not altered on the way. Signing has to be run carefully: key rollover, parent DS records and expiry monitoring are where outages come from. Encrypted transport, DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858), protects queries from eavesdropping between a device and its resolver.
Availability comes from anycast, announcing the same service address from many sites so queries land at the nearest healthy one, and from health-checked traffic steering. This work connects to our BGP, DDoS and email authentication practices, because SPF, DKIM and DMARC all live in DNS.
Leading platforms we work with
- BIND
- Knot DNS
- PowerDNS
- Unbound
- NSD
- Cloudflare DNS
- Amazon Route 53
- NS1
Platforms and practices
- Authoritative DNS
- Recursive resolvers
- DNSSEC signing and key rollover
- DNS over HTTPS (DoH)
- DNS over TLS (DoT)
- Anycast DNS
- Split-horizon (internal and external) zones
- Traffic steering and health checks
- Response rate limiting
- DNS monitoring and logging
References
- RFC 4033: DNS Security Introduction and Requirements
- RFC 8484: DNS Queries over HTTPS (DoH)
- RFC 7858: DNS over TLS
- ISC BIND 9
- Knot DNS
- PowerDNS
- NLnet Labs Unbound
- NLnet Labs NSD
- Cloudflare DNS documentation
- Amazon Route 53 DNSSEC signing
- IBM NS1 Connect
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use DNS & DNSSEC for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageDoes DNSSEC encrypt DNS queries?
No. DNSSEC (RFC 4033 to 4035) provides origin authentication and integrity, so a resolver can tell that an answer was signed by the zone owner and not altered. It does not hide the query. Privacy between a device and its resolver comes from DNS over HTTPS or DNS over TLS.
What is the main risk of turning on DNSSEC?
Outages from operations, not from the cryptography. A missed key rollover, a wrong DS record at the parent or an expired signature makes validating resolvers reject the whole domain. Rollover procedures and expiry monitoring are the controls, so we set them up before signing.
Why use two or more DNS providers?
One provider failing, or being attacked, takes the domain with it, and every service that depends on a name goes dark. Zones served by independent providers keep answering. The cost is keeping the zone data and DNSSEC keys consistent across both, which has to be planned.
What is the difference between DoH and DoT?
Both encrypt queries between a device and its resolver. DNS over TLS (RFC 7858) uses a dedicated port, which makes it easy to identify and manage. DNS over HTTPS (RFC 8484) travels inside ordinary HTTPS. For company devices we choose one and enforce it by policy.
How does anycast help DNS?
Announcing the same service address from many sites lets queries land at the nearest healthy one, and it spreads attack traffic across nodes. It suits DNS because most queries are single UDP packets. It does not replace capacity at each site.
Why does DNS matter for email security?
SPF, DKIM and DMARC records all live in DNS. A stale or wrong record can send your own mail to spam or let others spoof your domain. Keeping those records correct and monitored is part of running DNS properly.