The Developer's Guide to Domain Verification
Domain verification is an important measure for establishing security and trust between providers and organizations. This blog examines best practices to consider when building in-house as well as a simple alternative that WorkOS provides.
Domain verification is a crucial security measure for SaaS providers, ensuring that services are securely delivered to the legitimate owners of a domain. It’s implemented in a number of use cases like verifying ownership for organization-level functionality, supporting the use of custom domains for hosted features, and enabling service providers to send emails on behalf of their customers.
Several methods exist for validating domains. Domain Name System (DNS) validation requires directly altering TXT records in DNS configuration. Email-based validation requires responding to an email sent to the domain. HTTP-based verification relies on updating content hosted at the domain.
Of these, DNS-based validation is frequently recommended for its resilience to common attack vectors. Email confirmation is susceptible to phishing attacks, while HTTP-based verification can be exploited via vulnerabilities in an organization’s web servers. While DNS-based validation is arguably the most secure, there are a number of practices to follow when taking this approach.
Don’t place TXT records on the root domain
Crowded TXT record can also cause fragmentation in DNS responses that occurs when the size of the response exceeds the maximum transmission unit (MTU) size of the network path, typically 512 bytes. When DNS responses are fragmented, it leads to increased vulnerabilities for several reasons:
- Increased exposure to interception: Fragmented packets are easier to intercept and manipulate. Attackers can potentially reassemble the fragments incorrectly or inject malicious fragments. This could lead to cache poisoning attacks, where false DNS information is inserted into the cache of the resolving server or client.
- Increased complexity of reassembly and Denial of Service (DoS) attacks: The process of reassembling fragmented packets is resource-intensive. Attackers can exploit this by sending a flood of fragmented packets, leading to a DoS condition where legitimate requests cannot be processed due to the excessive load on reassembling these fragments.
- Increased Latency and Performance Impact: Fragmentation often results in a higher number of packets being transmitted, which increases network load and latency. This can degrade performance of DNS resolution, and in cases of high network traffic or intentional flooding, it can lead to service disruptions.
Use underscore prefix labels
The naming convention in validation records, particularly the use of application-specific underscore-prefixed labels, is important for several reasons:
Generate secure random tokens
When generating random tokens used in DNS challenges, two there are two primary recommendations:
The first is to use 128 bits of entropy when generating the token. This is the recommended threshold for thwarting guessing or brute-force attacks. The more random and unpredictable the value, the more secure it is against attempts to forge or predict the token in a malicious way.
Specify expiration metadata
Clear guidance on when DNS validation record should be removed is crucial for DNS configuration and security.
Alternative Solution: Choosing WorkOS
Rather than building and maintaining support for domain verification from scratch, a simpler solution is to use WorkOS Domain Verification. With quick API integration, developers can offer a self-serve flow that IT Admins can follow to prove domain ownership through DNS TXT records. There are several reasons why this is the preferred route:
- Domain Verification relieves developers from dealing with the intricacies of the DNS protocol and parsing responses, thus freeing up engineering time for more impactful work.
- Developers can select from various delivery mechanisms to provide Admin Portal links to customers, guiding them through the verification process specific to their DNS provider in just minutes.
- Since domain configuration changes can take up to 48 hours to propagate, Domain Verification actively monitors DNS changes and issues a Webhook notification upon successful validation.
Domain Verification supports all domain name system providers with tailored setup instructions for the following providers with more coming soon:
- AWS Route 53
- Google Domains
In the coming months, we will launch additional Domain Verification features to streamline the developer workflow:
- More verification methods such as WHOIS-based email, constructed email, email to DNS TXT contact, and manual verification
- Tailored setup instructions for more providers
- Optional continuous verification, requiring IT admins to complete verification on a regular basis
- Audit logs containing DNS response and proof of domain validation
To get started, check out the Domain Verification docs.