Domain & DNS Management
Domain and DNS Security Measures Don’t Work
Why Organizations are Vulnerable Despite Security Measures
The first weeks of 2019 saw a number of global domain and DNS security threat alerts issued by respected organizations. A state-sponsored DNS hijacking exploit threatening both public and private sector organizations has been widely reported by Homeland Security’s NCCIC and the UK’s NCSC. Both cite credible private research from FireEye and Cisco’s Talos group.
This threat isn’t the only one in play, nor is it the first. Similar domain hijacking mischief was recently reported involving the infamous hacker Spammy Bear. Reports show that GoDaddy’s DNS service was compromised allowing attackers to take control of DNS on domains owned by major brands including Mastercard, ING Bank, Hilton International, and DigiCert. In all, over 4,000 domains have been compromised in 600 organizations!
Domain and DNS network compromises have occurred repeatedly for many years, and appear to be accelerating. DNS industry experts invariably respond to these reports with best practice recommendations. Respected security analyst KrebsonSecurity has weighed in with details and recommendations, as has Akamai. Despite many recommendations from experts, DNS breaches persist. Why aren’t recommended threat mitigation tactics working?
There are several reasons. In short, most best practice recommendations, though well intended, are impractical in real world implementation on disconnected, legacy registrar and DNS systems operated in silos. Let’s take a look at a comprehensive list of best practices, recently published by a number of respected authorities and examine their respective weaknesses.
Domain and DNS Threat Mitigation Practices
Weaknesses and Barriers to Success
1. Implement 2FA/MFA password controls on domain registrar and DNS services
The problem is, organizations have an average of 36 active DNS services, each with its own admin access. Applying and enforcing uniform password controls across so many platforms is impractical.
2. Review access to Domain Name Registrars
Many organizations have multiple registrars, business entity-registrants and internal stakeholders. Staff turnover, M&A and other factors create ongoing changes. Managing access permissions between registrar systems operated across multiple management groups simply does not happen.
3. Review DNS roles and responsibilities
Limiting permissions to “least access” doesn’t reflect organizational reality, which is a departmental matrix of cross-supporting roles. Limiting permissions can create organizational friction, stifling business agility. Speed vs. security is an unhappy trade-off. As a result, permissions expand without oversight.
4. Update all Domain Registration information
Standardizing your registrant, technical, administrative, and billing contacts is good practice. Having multiple registrars, multiple registration entities and departments and multiple domain settings can hugely complicate matters.
5. Review (audit) and maintain your Zone File records
Few organizations do this well (or at all!) because it’s hard. Most companies have 10-20 resource records per domain, and thousands on their principal domains. For 1,000 domains, there’s really no efficient way to maintain a 24/7 real-time watch over all resource records. It’s costly at best and impossible at worst.
6. Monitor Name Server and DNS access
Server access logs are standard practice. But putting access logs on every DNS provider you have isn’t easy or in some cases even possible.
7. Manage your Zone File changes with a version controlled master record
This is a highly impractical idea, which is like saying “make sure you have good change management by having good change management.” You either have a change management system or you don’t. Having a policy and keeping a “master record” is ineffective.
8. Implement DNSSEC
ICANN, Homeland Security, and NCSC all recommend it, but over 70% of all organizations have yet to implement. Those that have, struggle to maintain DNSSEC over the domain lifecycle. DNSSEC administrative overheads and DSKEY rollovers are a pain to manage.
9. Implement DMARC, SPF and DKIM
DMARC reduced phishing-prone email traffic in the US government by over 95%, yet most private sector organizations have yet to implement this proven measure. DMARC and SPF need to be on every active domain, but administrative management overhead on DNS security settings impedes adoption.
10. TLS Certificate Transparency Monitoring
DNS hijackers often register bogus certificates on the appropriated domains. Experts recommend that domain owners follow cert transparency practices and monitor all TLS certs 24/7. While definitely good practice, it’s better to lock down every domain with start of authority (SoA) and DNSSEC to prevent the hijacking in the first place.
Ok, So if these 10 best practice recommendations for improved DNS network security don’t really work, then what will?
Implement a domain and dns change management control system
Stop trying to address these exposures by projects and people power. The only way to truly lock down your domain and DNS network is to place it under a single-point of access and control system. That means:
- Consolidate domains to a single, corporate registrar with enterprise level access controls
- Consolidate your DNS providers to a single, robust, anycast service, and a secondary (backup) DNS service
- Implement system-based, automated DNS security (DNSSEC, DMARC, SPF and TLS cert admin controls that fully integrate with the registrar
- Move to an integrated, centralized, domain and DNS change management control system
These four measures can eliminate the barriers to implementing the best practices that experts recommend. They will not only address security and compliance weaknesses endemic to enterprise domain and DNS operations, they will also reduce your costs. Traditional DNS management practices powered by IT staff resources and disconnected systems are simply not working. To make them work requires more effort and cost than most organizations are willing to commit. The result: continued DNS network exposure and compromises.