Hi HN,<p>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.<p>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]).<p>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.<p>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:<p>dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT<p>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.<p>The benefits of this approach are:<p>- Domain owners can grant time-limited, granular permissions for third parties to verify a domain<p>- Every service provider could use the same verification record<p>- 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<p>- 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<p>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.<p>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:<p>1. HASH(user@example.com) -> 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg<p>2. Store Domain Verification record at:
4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com<p>3. TXT record determines permissions and time limit:<p>@dv=1;d=Example user emali;e=2025-01-01;s=[seo;email];h=4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg<p>BTW, if you're interested the syntax of that DNS record is a compact data serialisation format I created especially for DNS [3].<p>Thanks for taking a look,<p>Elliott<p>1. <a href="https://www.domainverification.org" rel="nofollow">https://www.domainverification.org</a><p>2. dig target.com TXT<p>3. <a href="https://www.compactdata.org" rel="nofollow">https://www.compactdata.org</a><p>(edit: formatting)
If I understand correctly, you need to submit the verifiable identifiers (email address and optional salt) to the party where you need to verify. 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.<p>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.<p>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.
On the home page, "For more detailed information take a look at the specification." links to <a href="https://www.domainverification.org/spec" rel="nofollow">https://www.domainverification.org/spec</a> which is a 404.<p>`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"<p>There's a typo in "Example user emali".<p>These simple mistakes don't engender confidence in the proposal.
So - there is a solution for this already that is widely adopted and perfect for this use case:<p><a href="https://www.godaddy.com/engineering/2019/04/25/domain-connect/" rel="nofollow">https://www.godaddy.com/engineering/2019/04/25/domain-connec...</a><p>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.<p>It works, and works well, and is supported by all the major domain providers.
Doesn’t this have the problem that the verifiable identifier has a different lifecycle to the DNS entry?<p>As far as I can see, this system doesn’t prove that the email address controls the domain <i>now</i>; it proves that it controlled the domain at the time it was set up.<p>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”.<p>It’s hard to imagine checking the DNS, of all things, when an employee is off-boarded.
I’m struggling to understand how this makes any sense given the creators own argument.<p>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?<p>There are already standards (IETF RFC) why is this better than those?
This seems like a nice option to have, and I appreciate the thought put into it.<p>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.<p>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've been thinking for some time about a mechanism that could be used to assert control over a domain that has a lot of third-party backlinks to it, as in widgets, ad networks, javascript etc.<p>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)<p>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.<p>That would add a lot of DNS lookups though.<p>Overall a good effort. Would be good to see something along these lines gather some traction.
Sorry maybe I haven't looked in detail enough, e.g. in Belgium telephone numbers have 10 digits, so you need a table of 10 billion hashes (far less in practice due to the structure of a telephone number) if you're using a telephone number, that's probably not hard to achieve. Then you look up the hash for the domain you want to hijack and try to register that domain in the service you're signing up to (with your fake / looked up telephone number).
Any regards to cache poisoning attacks?<p>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.<p>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.<p>Just curious.
I like the idea. Your description on the website is missing the explanation that the final step is the service provider verified the records via email/sms.<p>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.<p>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?
A deleted question, that I had typed out a response for but couldn't submit because it was deleted (in case it helps anyone):<p>>> 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.<p>> 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.<p>There are other solutions [1] for simplifying the creation of verification (and other DNS records).<p>1. <a href="http://www.domainconnect.org/" rel="nofollow">http://www.domainconnect.org/</a>
Noticed this is from the same uk firm that created a denser alternative of json called modl, now called <a href="https://www.compactdata.org/" rel="nofollow">https://www.compactdata.org/</a>
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? Cerbot already has integrations for tons of DNS registries and if that's not available then all you need to do is put a special secret file in the .well-known directory.<p>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.
I forgot to mention, verifiable identifiers can optionally be salted before hashing but this introduces a dependency on the creator of the domain verification record to share the salt.
Question for the community. Email verification is easy. The provider sends you an email, you click the link in that email, and the process is complete. When it comes to domain verification, what if the provider sends an email to the address listed in the domain's WHOIS? It seems much easier than dealing with DNS records, but I may be overlooking something obvious here.
I like the concept, but it would probably be better to have some sort of cryptographic solutions, where the public key and permissions are stored in the DNS entry and the private key is used to generate a signature so the service can validate.
Wouldn't it be simpler to just build on the acme challenges?<p><a href="https://letsencrypt.org/docs/challenge-types/" rel="nofollow">https://letsencrypt.org/docs/challenge-types/</a>