By Jeff Ebeling - CISSP, CCSP Advanced Technology Specialist, Skyhigh Security
April 11, 2022 7 Minute Read
Use of “domain age” is a feature being promoted by various firewall and web security vendors as a method to protect users and systems from accessing malicious internet destinations. The concept is to use domain age as a generic traffic filtering parameter. The thought is that hosts associated with newly registered domains should be either completely blocked, isolated, or treated with high suspicion. This blog will describe what domain age is, how domains are created and registered, domain age value, and how domain age can be used most effectively as a compliment to other web security tools.
Domain Age Feature Definition
The sites and domains of the internet are constantly changing and evolving. Through the third quarter of 2021 an average of over 40,000 new .net and .com domains were registered per day according to Verisign. https://www.verisign.com/en_US/domain-names/dnib/index.xhtml If the domain of a target host is known that domain has a registration date available for lookup from various sources. Domain age is a simple calculation of the time between initial domain registration and the current date.
A domain age feature is designed for use in policy control, where an administrator can set a minimum domain age that should be necessary to allow access to a given internet destination. The idea is that since domains are so easy and cheap to establish, new domains should be treated with great care, if not blocked outright. Unfortunately, with most protocols and implementations, domain age policy selection is a binary decision to allow or block. This is not very useful when the ultimate destinations are hosts, subdomains, and destination addresses that can be rapidly activated, changed, and deactivated without ever changing the domain age. As a result, binary security decisions based solely on domain name or domain age will naturally result in both false positives and false negatives that are detrimental to security, user experience, and productivity.
Domain Registration
IANA (Internet Assigned Numbers Authority) is the department of ICANN (Internet Corporation for Assigned Names and Numbers) responsible for managing the registries of, protocol parameters, domain names, IP addresses, and Autonomous System Numbers. IANA manages the DNS (Domain Name System) root zone and TLDs (Top Level Domains like .com, .org, .edu, etc.) and registrars are responsible for working with the Internet Registry and IANA to register individual subdomains within the top-level domains.
Details of the registration process and definitions can be found on the IANA site (iana.org). Additional details can be found here: https://whois.icann.org/en/domain-name-registration-process This location includes the following statement:
“In some cases, a person or organization who does not wish to have their information listed in WHOIS may contract with a proxy service provider to register domain names on their behalf. In this case, the service provider is the domain name registrant, not the end customer.”
This means that service providers, and end customers are free to register a domain once and reuse, reassign or sell that domain without changing the registration date or changing any other registration information. Registrars can and do auction addresses creating a vast market for domain “squatters and trolls.” An attacker can cheaply purchase an established domain of a defunct business or register a completely new legitimate sounding domain and leave it unused for weeks, months or years. For example, as of this writing airnigeria.com is up for sale on godaddy.com for just $65 USD. The domain airnigeria.com was originally registered in 2003. IANA and the registrars have no responsibility or control over usage of domains.
Determining Domain Age
Domain age is determined from the domain record in the Internet Registry managed by the registry operator for a TLD. Ultimately the registrar is responsible for the establishment of a domain registration and updating related data. The record in the registry will have an original creation date but that date doesn’t change unless the registration for a specific domain expires, and the domain name is re-registered. Because of this, domain age is an extremely inaccurate measure of when an individual destination became active.
And what if only the destination IP address is known at the time of the filtering decision? This could be the case for filtering the first packet sent to a specific destination (TCP SYN or first UDP packet of some other network or transport level protocol). One way to get the domain for the destination would be a reverse DNS lookup, but the domain for the host may not match the domain that was originally submitted for resolution, so what value is domain age there?
For example, www.skyhighsecurity.com can currently resolve to 34.111.16.149 which reverse resolves to 149.16.111.34.bc.googleusercontent.com. While the skyhighsecurity.com domain was registered on 2018-12-14, googleusercontent.com was registered on 2010-09-14. Both are long established domains. While this destination is in the well-established skyhighsecurity.com domain, and is hosted on the well-established googlecontent.com domain, this doesn’t provide any indication of when the www.skyhighsecurity.com, or 34.111.16.149 destination became active, or the risk of communicating with that IP address. Domain age becomes even less useful when we consider destinations hosted in the public cloud (IaaS and SaaS) using the providers’ domains.
Obtaining the wrong domain and therefore wrong domain age from reverse lookup could be somewhat mitigated by tracking the DNS queries of the client and attempting to map those domains back to the requested destination IP. However, doing this would also be dependent on having full visibility into all DNS requests from the client, and assumes that the destination IP address was determined using standard DNS or by the system providing the domain age filtering.
Challenges with Using Domain Age as a Generic Filter Criteria
Even if the correct domain for the transmission can be established, and the domain age can be accurately retrieved, there are still issues that should be considered.
Registrars are free to maintain, change, and reassign established domains to any customer, and resellers can do the same. This greatly diminishes the usefulness of domain age as a stand-alone filtering parameter because a malicious actor can easily acquire an existing well-established domain with a neutral or even positive reputation. A malicious actor can also register a new domain long before it is put into use as a command and control or attack domain.
Legitimate and perfectly safe sites are constantly being registered and established in many cases within days or even hours of being put into use. When using domain age as filter criteria there will always be a tradeoff between high false positive and high false negative rates.
It should also be noted that domain age provides little value relative to when an individual hostname record was created within a domain. Established domains can have an almost infinite number of subdomains and individual hosts within those domains, and there is no way to accurately determine hostname age or even when the name was associated with an active IP. All that could possibly be determined is that the destination hostname is part of a domain that was registered at some earlier date.
The bottom line is that domain age is not nearly granular or substantive enough to make a useful filtering decision on its own. However, domain age could provide some limited security value in the complete absence of more specific criteria, provided the false positive rate and false negative rate associated with the selected recency threshold can be tolerated. Domain age can provide supplemental value when combined with other more definitive filter criteria for example protocol, content type, host category, host reputation, host first seen, frequency of host access, web service attributes, and others.
Domain Age in the Context of HTTP/S and Proxy Based Filtering
More specific criteria are always available when the HTTP protocol is in use. HTTP and HTTPS filtering is most effectively handled via explicit or transparent proxy. If the protocol is followed (enforced by the device or service), information cannot be transferred, and a compromise or attack cannot be initiated, until after TCP connection establishment.
Given that the traffic is being proxied, and HTTPS can be decrypted, accurate Fully Qualified Domain Names (FQDNs) for the host, URL path, and URL parameters can be identified and verified by the proxy for use in filtering decisions. The ability to lookup information on the FQDN, full URL path, and URL parameters provides much more valuable information relative to the history, risk level, and usage of the specific site, destination, and service independent of the domain or the domain’s date of registration Such contextual data can be further enhanced when the proxy associates the request with a specific service and its data security attributes (such as type of service, intellectual property ownership, breach history, etc.).
Industry leading web proxy vendors maintain extensive and comprehensive databases of the most frequently used sites, domains, applications, services, and URLs. The Global Threat Intelligence and Cloud Registry databases used by Skyhigh Security associate sites, domains, and URLs with geolocation, category, service, service attributes, applications, data risk reputations, threat reputations and more. As a side benefit, lack of an entry in the databases for a specific host, domain, service, or URL is an extremely strong, and much more accurate, indication that the site is newly established or little used and therefore should not be inherently trusted. Such sites should be treated with caution and blocked or coached or isolated (the latter two options are uniquely available with proxied HTTP/S) based on those criteria, regardless of domain age.
Skyhigh Security Secure Service Edge (SSE) provides all the above functionality and includes remote browser isolation (RBI) for uncategorized, unverified, and otherwise risky sites. This virtually eliminates the risks of browsers or other applications accessing uncategorized sites, without adding the complications of false positives and false negatives from a domain age filter.
When using HTTP/S, hostname age, or even first and/or last hostname seen date could provide additional value, but domain age is pretty much useless when the FQDN and more specific site or service-related information is available. Best practice is to block, isolate, or at a minimum, coach unverified sites and services without regard to domain age. Allowing unverified sites or services based on domain age adds significant risk of false negatives (risky sites and services being allowed simply because the domain was not recently registered). Generically blocking sites and services based on domain age alone would lead to over-blocking sites that have established good reputations and should not be blocked.
Conclusion
Domain age can be somewhat useful for supplementing filter decisions in situations where no other more accurate and specific information is available about the destination of a network packet. When considering use of domain age for HTTP/S filtering, it is an extremely poor substitute for a more comprehensive threat intelligence and service database. If the decision is made to deviate from best practice and allow HTTP/S connections to unverified sites, without isolation, then domain age can provide limited supplemental value by blocking unverified sites that are in newly registered domains. This comes at the expense of a false sense of security and much greater risk of false negatives when compared to the best practice of using comprehensive web threat intelligence, performing thorough request and response analysis, and simply blocking, isolating, or coaching unverified sites.
For further information on Skyhigh Security’s holistic and effective solutions for system and data protection, please visit our Security Service Edge landing page.
Back to Blogs