‘Hijacking’ of DNS Records from Network Solutions
UPDATE: This blog post is related to the redirection of domain name servers that occurred back in June 2013. This post is NOT related to the ongoing activity occuring July 16, 2013. Cisco TRAC is currently analyzing the ongoing issues with Network Solutions’ hosted domain names and has more information available here.
Multiple organizations with domain names registered under Network Solutions suffered problems with their domain names today, as their DNS nameservers were replaced with nameservers at ztomy.com. The nameservers at ztomy.com were configured to reply to DNS requests for the affected domains with IP addresses in the range 220.127.116.11/24. Cisco observed a large number of requests directed at these confluence-network IP addresses. Nearly 5000 domains may have been affected based on passive DNS data for those IPs.
Hijacking of a domain name’s DNS records is one of the worst attacks an organization can suffer. You literally have lost control over your domain. Network Solutions, having been the original registrar for .com, .net, and .org domain names, is quite an attractive target for attackers. Originally it was unclear whether the issue was the result of an attack or a misconfiguration. It turns out the problem was both attack-related and also the result of a misconfiguration. Network Solutions issued a statement claiming, “In the process of resolving a Distributed Denial of Service (DDoS) incident on Wednesday night, the websites of a small number of Network Solutions customers were inadvertently affected for up to several hours.”
Interestingly, several of these domains were setup under different nameservers at ztomy.com. For example, the domain usps.com was pointed to the DNS nameservers ns1621.ztomy.com and ns2621.ztomy.com. Yelp had their nameservers changed to ns1620.ztomy.com and ns2620.ztomy.com. Fidelity, meanwhile, was pointed at ns1622.ztomy.com and ns2622.ztomy.com. However, the fact that so many domains were displaced in such a highly visible way supports Network Solutions’ claim that this was indeed a configuration error.
TRAC recommends anyone who has a domain registered with Network Solutions verify that their DNS nameservers are pointed at the correct location. TRAC also recommends network administrators check the logs from their network devices for connections to the 18.104.22.168/24 subnet. Organizations need to carefully consider how they would swiftly identify unauthorized modifications to their DNS records and how they would react to such a situation.
Thank you to Henry Stern, Martin Lee, Mary Landesman and Gregg Conklin for their assistance writing this post.