Show HN: Automatic Domain Verification
domainverification.orgThis is a project I've been working on for a little while and I'm interested in your feedback and point of view.
The Domain Verification protocol stores a DNS TXT record at a DNS name derived from a hashed "verifiable identifier" (email, telephone, DID), enabling anyone that can prove control over the verifiable identifier to prove authority for the domain name, whilst preserving the privacy of the authorised party.
Once setup, the record enables automatic domain verification for any service provider.
This record could be automatically setup by domain registrars upon domain registration (with registrant opt-in) creating a fast lane for verification with service providers many new small businesses use (eg Google Ads, Facebook, Office365, Dropbox, etc).
=====
Many of us would have verified a domain name by pasting a string into a DNS TXT record. These methods are currently being discussed and standardised at the IETF [2].
Let's Encrypt's DNS-01 method [3] is probably considered the state of the art. The differences between DNS-01 and Domain Verification protocol are:
- DNS-01 requires a new TXT record for each service provider. With Domain Verification Protocol, multiple service providers can use the same record.
- Instructions to setup a DNS-01 TXT record are instigated by the service provider, whereas a Domain Verification Protocol record can be setup independently by a user or a domain registrar. They could even pre-populated by a registrar upon domain registration (with registrant opt-in)
- There’s no concept of permissions in DNS-01, the act of creating the record gives the user full access for the domain with the service provider. With Domain Verification protocol multiple records can be setup, limited permissions could be setup for different third parties. For example give a marketing agency authentication to claim the domain on social media but nowhere else.
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:
a. HASH(user@example.com) -> 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
b. Store Domain Verification record at: 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com
c. TXT record determines permissions and time limit:
@dv=1;d=Example user email;e=2025-01-01;s=[seo;email];h=4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg
Thanks for taking a look,
Elliott
1. https://news.ycombinator.com/item?id=35827952
2. https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-ver...
3. https://letsencrypt.org/docs/challenge-types/
=====
Quick sidebar:
This was originally submitted to HN under the title "Show HN: Make domain verification as easy as verifying an email or phone number" 3 days ago [1]. It was doing really well (#3 on front page) then totally disappeared from front page and went to bottom of page 1 of Show HN.
After an email exchange with dang (incredibly helpful as always), he explained that it got flagged with the "overheated discussion detector" and it turned out I caused this by diligently responding to every comment as fast as my fingers would type because I wanted to keep engagement going. Helpfully dang took the flag off it about 12 hours later after our email exchange, but understandably the momentum was lost.
So I feel like it kinda got killed, just as it was picking up pace and as the US west coast was waking up. So I am humbly reposting it with a modified description based on the comments of the last post. I like it. My feedback would be a simpler approach, ditching the hash. Why not just encourage people to put their email address in plain text in a DNS record? If they want anonymity, they can fall back to the way verification is done today. If they want convenience, they can broadcast their email&DNS link. For example, I own "BreckYunits.com" and my email address is listed throughout my site. I wouldn't be giving up any privacy by putting that in a DNS record. Sure, some people will exaggerate the fear risk (usually the ones selling a security product), but I'm of the old school opinion that we should advocate good behavior and admonish bad behavior on the web and build a more civil world. > Why not just encourage people to put their email address in plain text in a DNS record? My reading is that it's because the purpose of the effort is to compel Google, Facebook, etc. license this proprietary protocol from the creator. I don't personally understand what the moat is since DNS- or file-based verification is a basic feature of all services that need to validate domain control. Oh and to prevent what happened last time (the post getting flagged as an overheated discussion), I'm going to close the laptop and come back to this in a few hours! So if you ask a question, I'm not ignoring you – I'll respond later. This is neat. >For example give a marketing agency authentication to claim the domain on social media but nowhere else. How does it prevent them from claiming it elsewhere? html tag is setting Thanks for the heads up and I'm sorry about that, I can't seem to recreate it in Firefox at the moment but I'll get to the bottom of it. Are you in automatic/dark/light mode? Your Firefox version would be a big help too if you were happy to share that. In the meantime, you can see the spec here: https://gitlab.com/NUMTechnology/Domain-Verification/docs/-/... Sooo, apparently in a clean browser without extensions this does not happen. I tracked down this to a problem with Vimium [0], when I disable it the webpage displays correctly. Essentially, the issue is that Vimium's stylesheet also set the --fg variable. While your website sets it to #000000 or something like that, Vimium sets it to #FFFFFF and for some reason that interferes with the webpage. Alas, one more reason for me to stay with SCSS haha. Even more interesting is that the same issue does not happen on a Chromium browser with Vimium with the exact same stylesheet, meaning the global stylesheet pollution only happens on Firefox. Anyway, I would say this is not a problem with your website but rather with my (beautiful) Vimium stylesheet [1]. Still, you could fix this issue by converting these CSS variables to SCSS ones, so they are hard-coded variables on runtime, or perhaps by using !important to make sure it's not overwritten. The stylesheet I'm using is not the default but rather a fork of a pretty specific one, so I'll also make the changes there to stop using CSS variables. By the way, since you asked I'm running Firefox 112.0.2 (64-bit), Red Hat fedora - 1.0 build, although it's not related to Firefox at all. edit: just prefixed all css variables in the stylesheet with an identifier and everything is working now :) Server is responding back with an 500 Internal Server Error. HN hug of death maybe? Thanks for the heads up, home page or any page in particular? It’s ok for me but I’ll check the logs. It’s just a basic fly.io setup at the moment but it should be more than capable of dealing with the traffic - just html (and htmx) front end and Sinatra back end. It stood up pretty well to the traffic last time.
so text on the webpage is appearing as white-on-white for me, at least on Firefox. color: var(--fg)