Domain security is not something we think of much, yet so many of the things we worry about are associated with domains: phishing, malware attacks and spam to name a few.  Any number of other things rely on the Domain Name System (DNS) and recognisable domain names to work, but DNS is often something that is difficult to manage. How do you know that one of your company's domains isn’t doing something it shouldn’t be doing? How do you know somebody isn’t out there trying to serve up something nasty to your customers with a domain that looks suspiciously like yours?

A domain by itself isn’t that important. They’re not hackable, or exploitable (even though DNS has plenty of issues) so why do we care if a $10 domain is pwnt? The real cost is trust. Trust in specific domains, trust in the words in those domains and ultimately trust in your company.

With that in mind here are four problems with domains and some points for consideration.

Problem One: There are too many gosh darn domains on this gosh darning plane!

So I did some in-depth research, which took me as far as this article from the register. Turns out I didn’t need to look far to get an idea of how many Top Level Domains (TLD, such as .com or .net) currently exist out on the internet - there’s roughly 1000. That’s a lot.

What’s the problem here? Scale. For every domain you own, such as somecompany.com, there’s hundreds of TLDs that can be purchased for your company. This by itself isn’t a problem, but domain registrars and marketing companies often subtly, and not so subtly, push for purchasing additional TLDs, using the pretext that somebody else might buy somecompany.cc or somecompany.wtf and in doing so, encroach on your precious brand. It doesn’t help that some of these TLDs, such as .sucks and .xxx, have inherent negative connotations - somebody might do something really bad with either of those that could cause issues for your brand. The largest issue with lots of TLDs is the phishing risk as they can potentially confuse your customers, making it harder for them to tell if the email has really been sent from you.

The other problem when it comes to domain names is variations on a theme. Marketing teams love to lock away every possible word combination that could possibly have anything to do with a business, although I will say, it is their job. As more and more domains are used as channels to make it to your company, or specific business units, there are more points of compromise in the trust your customers may have in you. Take for example a bank that has the following domains:

• Genericbank.com - the main website;
• Onlinebanking.com - A domain that points to online banking for generic bank;
• Worlds-best-financial-services.com - A vanity domain that points back to Genericbank.com; and
• Otherbank.com - A bank that generic bank bought a long time ago that redirects to genericbank.com.

What I’m going to say is going to be contentious, but maybe organisations that do this should focus on their main domain, in this case genericbank.com. Everything else is optional and weakens trust. Now your customers trust 4 domains, and now you have to police 4 different domains for phishing and cyber/typosquatting (the practice of buying visually similar domains, or the same domain with a different TLD).

There are often reasons to buy additional domains, such as for internal services, special promotions, or for acquired subsidiaries. Additionally, there are reasons to buy a domain and sit on it, such as denying competitors or domain speculators from getting hold of a domain that may be useful to you or impact your brand if misused.

Two simple tests that can help you decide if you should buy a new domain:

• What are the “boundaries of trust” for this domain? Is it for a completely separate line of business, or will it be heavily associated with your primary brand? If a domain is “isolated” in terms of association with your brand, it poses less risk; and
• How likely will customers be to build trust in this new domain? I’m talking about the sort of trust that will have them click on a phishing link without checking. For example, a marketing campaign that only lasts for a few weeks poses less of a risk then one of the fancy word-association domain names, like the “worlds-best-financial-services" example above.  

Problem Two: Domains pointing to the strangest of places.

If we continue down the domain-name rabbit hole we hit our next layer of challenge. DNS records. If somecompany.com is your main domain then mail.somecompany.com is an example of a record. Lifecycle management of domain records is something that can easily be overlooked. This can lead to old DNS records for your domains that might need some maintenance.

Some of the problems with DNS record sprawl can be:

• Domains pointing at shared hosting providers or anywhere that an IP address may be re-used, may end up pointing at somebody else’s stuff. I had this happen to me a few years back when I had a domain pointed at a VPS server that I stopped using. The server was deleted and the IP re-assigned to another server used to host a website about racing. Queue a confused Reece until he realised he’d forgotten to clean up old DNS records;
• Domains may also be left pointing at old, legacy or unmanaged infrastructure, especially development and test. While not directly a DNS problem, DNS can be one of the easy ways for an attacker to discover what you have available on the Internet. Unmanaged, or poorly managed DNS can make it easier for an attacker to find attackable things, while making it harder for you to find them first; and
• Domains pointing at third party services are also a problem, especially when they're not customer facing and that third party is none too good at security. The issue becomes even worse if the domain is fully delegated or a subdomain is delegated out to the third party. If the vendor is compromised then your domain is compromised.

Problem Three: Domain Email Security

Like all great standards, DNS ends up with standards on standards on standards. For example, take records that relate to email security. Back in the day you just needed to configure your Mail Exchange (MX) records and you were good to go, but MX only solves for the problem of where your email traffic is meant to go, and says nothing about validating the source of email traffic, so then we have Sender Policy Framework (SPF), DomainKeys Identified Mail DKIM and Domain-based Message Authentication, Reporting & Conformance  (DMARC) - all DNS record types designed to ensure the integrity of email. These can all help control risks relating to phishing, but unless you are aware of their existence they can easily be overlooked.  

Common challenges in this space:

• Domains set up for email may not include any of the security record types, leaving the domain open for phishing and spam;
• SPF and DMARC records may have been implemented, but with weak policies in place, often because of the perceived risk that they stop customers from receiving emails;  
• It is quite common to use mail providers and marketing companies to handle outbound email. They often suggest SPF records that effectively delegate control to them to then define the allowed IP addresses that can send email.  However it is important to understand that they are in full control of SPF for that domain. Depending on the provider (if they have points-of-presence all around the world, for example) you may need to do this anyway; and
• Using sub-domains for email. These may often be set up to get around restrictions using the base domain for certain email functions, or in the name of improved security.  However this can also confuse recipients and train them in to accepting emails from a number of different domains for your company, including increase phishing risk.

One thing to note with email DNS, it's the sending IP addresses that tend to be blacklisted, and not the sending domain. Organisations like Spamhaus keep track of bad IP ranges, and there are plenty of services on the internet that will tell you how ‘trustworthy’ a given IP address is.

This is good news if an attacker has forged emails using your domain in the past but watch out if you run your own email infrastructure, use shared infrastructure or lower-tier email providers, as they may be using IPs with poor email reputation.  

Problem Four: Domain administration

The final challenge often faced with domains is administration, especially if you have a lot of domains spread over a bunch of different providers. This can especially be a problem if you don't have a centralised process and policy for managing domains, or if your centralised process is bypassed because it is too arduous.

Some of the problems here can include:

• Too many providers in too many places, making it hard to track down domain owners, and in some cases, stop a domain from expiring because the person who had access to renew has quit the company;
• Not changing the provider name servers to something you control. This isn't an issue with all providers (for example Amazon is pretty good), however some providers will point domains without any DNS records at parking services to generate some income;
• Domain owners not being kept up to date, which can make it hard to find who needs to authorise the renewal for a domain, or even worse, you can't find the right person to authorise the decommissioning of a domain. This can also amplify the first point. If you have too many different relationships, even with the same Domain Registrar, then there can be issues stopping domains from expiring; and
• Provider security, like domain privacy, or transfer and deletion protection of specific domains often not being used. If you pick the right provider these are often free. It is important to note that some TLD's don't allow for these features, such as .in not allowing domain privacy and .com.au not allowing transfer protection features.  

That's enough on understanding the problems with domain management in a company.  In my next post I’ll suggest some options for dealing with these problems.