This is a project [1] I've been working on for a little while and I'm interested in your feedback and point of view.
Many of us would have verified a domain name by pasting a string into a DNS TXT record. Some providers ask us to store this DNS TXT record at a domain using a DNS label like "_provider" e.g. _provider.yourdomain.com, and some providers ask that you do it at the zone apex (God help us [2]).
The Domain Verification protocol stores a DNS TXT record at a DNS name derived from a hashed "verifiable identifier" (think email, telephone, DID), enabling anyone that can prove control over the verifiable identifier to prove authority for the domain name.
For example, the domain verification record giving the email address user@example.com authority over the domain dvexample.com can be seen with this terminal command:
dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT
The record can specify what type of services the authorised party is allowed to use (e.g. SEO, Storage, Advertising) or specify an exact provider (ads.google.com), you can also specify an expiry date.
The benefits of this approach are:
- Domain owners can grant time-limited, granular permissions for third parties to verify a domain
- Every service provider could use the same verification record
- Once a domain owner creates a verification record by following instructions from one service provider, that same record could be used by other service providers
- Domain registrars could set these records up on behalf of users, perhaps even upon domain registration (with registrant opt-in). This would provide domain registrants with a fast lane for signing up to services like Google Ads, Facebook Ads, Dropbox, whatever
I'm still working on licensing but creating these records will always be free. I hope to find service providers that see significant upside in reducing friction for user onboarding that are willing to pay to license it.
Worked example: Let's say you want to authenticate the user with the email user@example.com with the domain dvexample.com, these are the steps:
1. HASH(user@example.com) -> 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
2. Store Domain Verification record at: 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com
3. TXT record determines permissions and time limit:
@dv=1;d=Example user emali;e=2025-01-01;s=[seo;email];h=4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
BTW, if you're interested the syntax of that DNS record is a compact data serialisation format I created especially for DNS [3].
Thanks for taking a look,
Elliott
1. https://www.domainverification.org
2. dig target.com TXT
3. https://www.compactdata.org
(edit: formatting)
Why would I want to have to validate someone’s phone or email address (not free), when I could use a standard way simply instructing my user to add a particular TXT record.
This reeks of NIH.
If I understand your argument correctly, you are saying:
"I'm Facebook, why would I go to the trouble of asking my users to create a Domain Verification record and verifying their email? Especially when this record would then benefit my competitors like Google and Microsoft!?"
I think there are a few angles to consider here:
1. There's no additional cost to verification for most service providers, since verification of email and phone is part of the onboarding process.
2. Licensing – if there are lots of domains with Domain Verification records, then there are benefits to Facebook in being able to automatically verify domains (if the DV record has already been setup by another service provider). By licensing the verification technology they could be required to instruct users to create these records.
3. The implementer may actually be a domain registrar like GoDaddy because it will improve the experience for their domain registrants and reduce support overhead for people trying to verify domains with service providers.
If the Verifiable Identifier is not salted first, and the attacker is determined to match a particular domain to a hash in a rainbow table of hundreds of millions of email addresses / phone numbers, then the answer is yes.
So worst case scenario, this could be a way for a bad actor (e.g. a state) to track down the journalist that runs a blog that's critical of a regime. However, people like that would not opt-in to a Domain Verification record in the same way that they don't opt in to having their details published to the website / WHOIS. So I don't think this is a real risk.
The bigger rainbow table risk is mitigated by the hash being used in the DNS label.
As an example, if the hashed verifiable identifier was simply stored in TXT at: _dv.example.com
Then it would be trivial to harvest e.g. 100m Domain Verification records and then match those hashes against a rainbow table (e.g. 500m hashed emails). However, since the hash is used in the label so you would need to run 500m DNS queries per domain (one for each rainbow table hash).
Sure, you could use your GPU to generate hashes for 500m email addresses / phones (if they weren't already pre-generated) but then what?
You'd need to then run a DNS check against a target domain – this would introduce 15-300ms DNS check overhead, per hash and you'd get blocked in seconds by your ISP / DNS resolver.
Even if you managed it, it would only reveal an association between a domain and email address, it wouldn't brute force anything. You'd still need to prove control over that email/phone.
You can even remove the chance of an association being revealed through salting but that introduces a dependency, more info on the website.
https://www.godaddy.com/engineering/2019/04/25/domain-connec...
Domain connect allows providers to request fine grained access to domain records, and for customers to allow/disallow those records, for a limited period of time. This not only addresses domain verification but also configuration of complex configurations like spf and max records.
It works, and works well, and is supported by all the major domain providers.
Source? The domainconnect.org website certificate is revoked (great sign for trusting it) but it's a standard created by GoDaddy two years ago.
I can't imagine "all the major domain providers" all supporting it so quickly.
IONOS, one of the providers, only lists four companies supporting this standard as a whole, DNS or service provider: https://www.ionos.com/help/domains/glossary-important-terms-...
> IONOS, one of the providers, only lists four companies supporting this standard as a whole, DNS or service provider
The way Domain Connect works is that the registrars have to "onboard" templates for each service provider that wants to use the protocol. So the registrars get to choose whose templates they want to use. So this could just be a list of the providers IONOS have onboarded.
A company doing interesting things with Domain Connect and in this space more broadly is worth a mention: Entri [1]
However the fact that you need to go to every domain provider to get your template manually approved makes this completely useless, what even is the point? This barely adds any security too since I can just use each provider's official API and create whatever records I want this way.
It's really sad because the protocol is designed for auto discovery but then does a 180 by having this manual step.
Both are run by really good guys that’ll answer any questions you’ve got.
Our Record Creator tool [3] integrates with Domain Connect, so if you want to setup a Domain Verification record for a domain with a registrar that's onboarded with Domain Connect, it will simplify the TXT record creation.
> Domain connect allows providers to request fine grained access to domain records, and for customers to allow/disallow those records, for a limited period of time.
From memory, the async flow enables this but I've not seen permission control available to customers in the way you describe. Can you point me at a screenshot or blog post?
As far as I've seen, these parts of the protocol have not been implemented particularly well anywhere. I'd say this is partly because the Async flow is far more complicated than the more basic flow, which most registrars and service providers adopted.
> This not only addresses domain verification but also configuration of complex configurations like spf and max records.
In my view, simplifying the setup of SPF, MX, A, CNAME records is where Domain Connect really shines.
As far as domain verification goes, I would argue that the two solutions are attacking a similar problem (friction for users creating DNS records) but in quite different ways:
Domain Connect simplifies the creation of the DNS TXT records that all service providers currently ask you to create.
In contrast, the Domain Verification protocol:
- Allows you to setup and manage multiple records - Enables permission based access - Enables time-limited access - Most importantly, it reduces the amount of DNS records you have to create since the first one you setup can be used in onboarding with future service providers. - It's far simpler to implement, once email verification is taken care the actual Domain Verification check is five lines of code.
> It works, and works well, and is supported by all the major domain providers.
You're right that registrar adoption is quite high, which is because it was a GoDaddy and 1&1 (now IONOS) initiative but when I last checked it wasn't implemented at Google, Facebook and many of the others larger providers for domain verification (to be clear: neither is my solution!!!)
1. https://github.com/Domain-Connect/spec/blob/master/Domain%20... (http://www.domainconnect.org currently failing with cert expiry)
The beauty of verifying with a changing bit of information (which is basically what is happining now) is that you only prove ownership once and the proof can't be stolen by someone who doesn't own the domain but received your proof.
Maybe I didn't understand correctly how it works. But if I understand it correctly that is actually rather dangerous. Supplying the proof to an untrustworthy party should not allow them to re-use this proof for other services.
> If I understand correctly, you need to submit the verifiable identifiers (email address and optional salt) to the party where you need to verify.
The verifiable identifier is the email/telephone number, we do not consider the salt a verifiable identifier. Let's put the salt to one side for a moment, because that complicates matters and introduces a dependence.
> That means you need to trust said party to not abuse this information to verify your domain with other services which use the same verification method.
A service provider having your email address doesn't give them any more opportunity to claim your domain than they already have. They still have to verify control over that email address.
> the proof can't be stolen by someone who doesn't own the domain but received your proof.
The email (or salt) isn't the proof that someone has authority for a domain, verifying control over that email address through usual email confirmation links etc, is the proof.
A domain registrant is already providing service providers with their "verifiable identifier" (email or phone) when they sign up for a service – e.g. Google Ads, Facebook etc and these service providers already verify these identifiers with emails containing confirmation links and SMS codes.
The current process is that they tell Google/Facebook the domain and then Google ask you to create a TXT record
This is an interesting attack vector for the current state-of-the-art.
However, you could argue that someone could do the same with the Domain Verification protocol by providing a seemingly useful tool to create a Domain Verification record but secretly hashing the email of the attacker rather than the domain registrant. Since it's hashed (for privacy reasons) there's no way for a normal end-user to realise that.
`dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT` returns: ;; ANSWER SECTION: 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com. 0 IN TXT "@dv=1;d=Example user emali;e=2025-01-01;s=[seo;email;marketing;storage;security];p=[serviceprovider1.com];sn=[service.serviceprovider.com];h=4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg"
There's a typo in "Example user emali".
These simple mistakes don't engender confidence in the proposal.
I moved the spec to /docs/spec very recently and forgot to update that link on homepage – fixed now.
"Emali" is a new typo for me, will fix that in the DNS record, thanks.
As far as I can see, this system doesn’t prove that the email address controls the domain now; it proves that it controlled the domain at the time it was set up.
So, for example, a disgruntled employee who had this set up would be able to “prove” that they controlled a domain until the records are deleted, right? Even after they’ve left, and no longer have access to the network. It’s a feature of this system that it’s “set and forget”.
It’s hard to imagine checking the DNS, of all things, when an employee is off-boarded.
This is a really good point, thanks.
For a single service provider who has already done verification, this is no different to:
"this system doesn’t prove that the party that setup the TXT record controls the domain now; it proves that it controlled the domain at the time it was set up."
Which is the current state of the art.
However, let's say a disgruntled ex-employee wanted to claim their ex-employer company domain with a new service provider. The service provider could use the old verification record that their previous employer might have overlooked to delete (likely using a personal email address).
Compared to the state-of-the-art, I suppose this would be the same as not terminating this user account for your domain registrar – they could log in and cause havoc.
I totally recognise that it would be more obvious for a company to delete the registrar user account than it would be to remove some obscure DNS records but if over time this was recognised as the best way to manage authentication for domains then it would become more obvious.
> It’s hard to imagine checking the DNS, of all things, when an employee is off-boarded.
There would need to be tools to manage domain verification and these would ideally be offered by domain registrars.
I'd also argue that if you're granting employees access to things using their personal email then you're going to hit a bunch of snags. I'll give this one more thought.
While I agree, I’d argue that the by-far numerical majority of companies don’t have sufficient internal controls to prevent someone from using whatever email they like when creating a dns record for some service. Actually, I even doubt that email gets turned off reliably.
It doesn’t generally matter, since the email address still validates the user’s identity to the same level, but in this case there is a chain of trust that isn’t necessarily trustworthy.
OTOH - a standard for domain verification is a good idea. perhaps it just needs to have an expiry date on it. It would be less convenient, but at least people could start to build tools around it.
_dv.example.com
Reveals domain-wide settings like:
1. All verification must have expiry date.
2. Max expiry 1 year
3. Only verify emails for users @ example.com and example.org
Interested in anyone's ideas around this.
They say the hardest part is that users don’t know how to adjust their DNS, and then the solution proposed is adding a DNS record?
There are already standards (IETF RFC) why is this better than those?
2. Records could be created automatically upon domain registration (with opt-in)
The current IETF standards don't enable either of the above.
That seems like a reduced security posture to me (maybe worthwhile to some).
What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems.
In your system the auth relies on the operator of the email address or phone number. In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole.
Your domain is verified by each service provider using the protocol, so it's not really possible for a service you're not using to consider the domain verified already.
Of course, it is possible for an attacker to try to verify your domain name with a new service provider by entering your email on user signup / domain verification and claiming to be you. This would as you say prompt the service provider to send a verification email, but that's what would happen today anyway if an attacker attempted to sign you up to a new service.
> What you are proposing provides DNS based authentication, but not necessarily authorization in contrast to current systems.
Could you elaborate here for me?
> In your system the auth relies on the operator of the email address or phone number.
In the case where a domain already has a Domain Verification record, then that's correct. In the case where a Domain Verification record does not already exist then it relies on someone with access to DNS.
> In situations where you have a NOC or other tier 1 team that normally wouldn’t have access to create TXT records this presents a security hole.
Sorry, I'm sure I'm being dense but could you provide an example of the sort of security hole you're seeing here.
I think one challenge always faced is dns propagation, creating your record and walking away and waiting (sometimes) hours for it to be recognized. Your method gives an ability to create a number of records in advance with different security restrictions so that’s nice, but requires a lot of thought and even more time adding records in your DNS.
So whats the actual verification process look like? You give the SP the subdomain generated and they query TXT records from there? how does the actual verification work here and when/how does the user receive an email?
> So whats the actual verification process look like? You give the SP the subdomain generated and they query TXT records from there? how does the actual verification work here and when/how does the user receive an email?
1. You sign up to service provider like Google Ads
2. They verify your email as part of normal onboarding
3. You tell them you own example.com (no need to give them a subdomain)
4. They run a Domain Verification check using your already verified email (they hash your email and run a DNS query based on that hash)
a) If the check passes, your domain is verified
b) If the check fails, they could invite you to verify another email (back to step 4)
a) instruct you to create a DV record; or
b) default to current domain verification method (store a random string in DNS)> Does this mean this service doesn't work if you use unique email addresses for different services?
It wouldn't work "out of the box".
The DNS record is stored at a DNS location based on the hash of the email, so you would need to:
a. Setup a domain verification record for each email (not that realistic); or
b. Use an email address specifically for domain verification (a different one to your unique user email) and consider any non-verification emails to be spam
Immediate thoughts are that the spec could encourage service providers to run two checks if the email address include a tag, given the email:
example+tag@gmail.com, they first check for a Domain Verification record for example+tag@gmail.com, then tag@gmail.com
However, this would seem to introduce an attack vector for users with email providers that don't recognise tagging.
I'll give this some more thought, thanks a lot for bringing it up – exactly why I'm here.
This protocol offers additional functionality and less friction.
1. dig target.com TXT
Most users will be using letsencrypt anyway, so at a minimum this adds friction by forcing (most) users to implement two protocols?
DNS-01 is unique per service provider.
I don't think domain registrants care about protocols, they care about how many things they've got to do with their DNS.
With DNS-01 and older methods it was based on, there's friction for each service provider. With the Domain Verification protocol there's friction first time only.
Sorry if I've misunderstood something here. If so, please forgive me and elaborate to help me understand.
Because when those domains become defunct or expire, anybody recognizing what they were could grab them and inject malicious code into all the websites with the broken widgets embedded (we've seen this happen with crypto miners, etc)
This kind of a mechanism (along with domainconnect) could work - but it would also need the browsers (perhaps with a plugin?) to verify a domain on embedded components before rendering them.
That would add a lot of DNS lookups though.
Overall a good effort. Would be good to see something along these lines gather some traction.
If I understand correctly, let’s say a popular CDN was no longer maintained and the domain expired, eg popularcdn.com - you’re looking for a way to use a dns record lookup to verify that the domain (and cdn) is still controlled by who you think it is?
I guess for scripts this can be dealt with using integrity hashes but that’s version specific. So this would be a security check at a domain level?
I guess the hard part would be that any CDN hijacker could copy the DNS TXT record when they hijack it.
They're actually easier at the subdomain level, because you can keep asking for <rand>._dv.example.com to prevent cache hits, all the while spamming back NS delegation answers for _dv to the cache servers with a long TTL.
DNSSEC of course solves that, but a lot of people are going to roll their eyes at that solution and a lot of things don't support it.
Just curious.
Interested to explore how a cache poisoning attack might be easier on a Domain Verification protocol TXT record compared to a DNS-01 TXT record.
Given the scenario: an attacker is attempting to claim a domain (example.com) with service provider (SP1) who uses a DNS revolver (DR1) I don’t immediately see how the subdomain approach makes a cache poisoning attack easier.
Couldn’t the attacker similarly keep asking DR1 for <rand>._acme-challenge.example.com and spam back NS delegation answers for _acme-challenge.example.com, with the goal that upon cache poisoning success, they could fraudulently claim example.com with SP1?
I may have overlooked something here, if so please explain.
With either method, DNSSEC would definitely seem the solution as you’ve suggested.
I think a solution here in the validation space is just avoiding the caching server altogether. If the validating server does something like dig +trace, it avoids this problem, especially if it prefers TCP.
Personally I think I'd prefer to decouple my email / phone / etc from the ownership of some credential / identifier. To me it's cognitively simple that I have a domain name, and to prove that I control the domain I have to make some change to the domain. When I say (type) it out loud it does feel a bit archaic, but to me it's simple.
It would be convenient if by clicking a validation link or something sent to my email (to prove I controlled the email in the domain) I could verify ownership. But: What about something like AWS Route53. A fairly complicated "enterprise" system for authorization is in place allowing certain team members to make changes to a DNS record in AWS. The people in the organization will change over time, the list of who "owns" a domain might be ever changing. Of course the organization itself might own the domain, but perhaps there isn't a clear single email address to assign ownership to. If the Domain Verification spec required everything to render down to a single email address or phone number or whatever, it feels like it adds potentially complicated questions to how do you distill AWS access down to an email address or phone number? It just feels like the actual service validating the DNS info is potentially taking on a lot of responsibility / complexity with implementation.
I really appreciate this comment, thanks.
> Personally I think I'd prefer to decouple my email / phone / etc from the ownership of some credential / identifier
I was expecting a lot more of the HN crowd to say this and I understand it. I think technical people who find DNS TXT trivial, could prefer the extra layer – creating a new record for each service provider (btw, you could still do that by specifying a provider in the Domain Verification record).
Ideally this solution would help those that hit friction (or insurmountable problems) creating DNS TXT records, because the records would be setup simply through the Domain Registrar.
> If the Domain Verification spec required everything to render down to a single email address or phone number or whatever, it feels like it adds potentially complicated questions to how do you distill AWS access down to an email address or phone number?
It doesn't. You can have as many Domain Verification records as you like, each with different permissions and expiry dates.
> It just feels like the actual service validating the DNS info is potentially taking on a lot of responsibility / complexity with implementation.
Implementation is incredibly simple – once email verification is dealt with, you could do it in 5-10 lines of code (hash, dns query, parse record).
I agree that service providers could consider it an increase in responsibility but I think that's a trade off with better onboarding.
Even if centralization of domain validation is something you care about, I wouldn't want that centralization to happen by a project for a company focused on collecting data about businesses.
> Let's Encrypt together with tools like Cerbot have brought easy to use proof of domain ownership to countless sites. Why wouldn't services that want to verify domain ownership use that?
I think the answer to this question, is the same as the answer to:
"Why don't service providers already use LE and Certbot to verify domains, instead of DNS TXT records?"
I don't immediately see how it would be possible for a service provider like Google or Facebook to use Certbot or LE to verify domains for users. Could you explain that? I see how they could use the same methods (HTTP-01 and DNS-01) but that's what service providers are already doing.
If it's possible in some way I haven't considered, I'd guess it's not used because by service providers because it creates more friction than current methods.
> Even if centralization of domain validation is something you care about
Could you explain how you consider this centralised when these records are stored in DNS?
> I wouldn't want that centralization to happen by a project for a company focused on collecting data about businesses.
I think you're talking about my company NUM Technology Ltd [1] and our laughably ambitious plan to organise all public data about all businesses into machine-readable format via DNS. You're right this involves collecting data, but only public data on the web. Consider it as a way to fetch a particular piece of data from Common Crawl in 15ms.
2. https://www.numprotocol.com
Both sites in urgent need of an update.
>> Why not just make a browser plugin that scrapes the screen when the user is presented a txt record to add? Reducing the security of DNS registrars is probably not the solution.
> Lots of reasons, the main one being that this would require every domain registrant to download a plugin which would then somehow need to integrate with a DNS provider.
There are other solutions [1] for simplifying the creation of verification (and other DNS records).