Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Make domain verification as easy as verifying an email or phone number (domainverification.org)
86 points by elliottinvent on May 5, 2023 | hide | past | favorite | 63 comments
Hi HN,

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)




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.

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.


Thanks for taking a look and for your comments.

> 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


I think the difference here is that there is no way to MITM email verification because you get an email in your inbox directly from the service provider. There isn't any way to intercept that. But for domain verification, there is. Hostile service provider A could request ownership of domain X with some other service B. When you, the owner of domain X, go to register ownership of domain X with A, A can show you the information provided service provider B and end up stealing your domain with B.


> Hostile service provider A could request ownership of domain X with some other service B. When you, the owner of domain X, go to register ownership of domain X with A, A can show you the information provided service provider B and end up stealing your domain with B.

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.


On the home page, "For more detailed information take a look at the specification." links to https://www.domainverification.org/spec which is a 404.

`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.


How do syntax errors dissuade you from the proposal? Is not design separate from implementation? Is it not true that a well-designed specification, proposal, etc. can be poorly implemented?


If you got a job offer that was riddled with spelling mistakes and had the wrong name, would that inspire confidence in your future place of work? It's not a huge stretch of the imagination that small, obvious issues could mean larger, more complex issues lurking.


I'd say "riddled with spelling mistakes" is a bit strong in our example (I realise you weren't claiming that about the site).

I got it out early to get some feedback. The 404 spec link is a bad one (since fixed) but the typo in the DNS record is forgivable I think – very impressed anyone spotted that.


To be clear, my comment was directly addressing my parent's comment of

> How do syntax errors dissuade you from the proposal? Is not design separate from implementation?

I would not characterize your content as "riddled with spelling mistakes" and apologize if you read if that way.


Huge thanks for pointing these out.

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.


So - there is a solution for this already that is widely adopted and perfect for this use case:

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.


> 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-...


There is quite broad registrar support, some of the original people behind it at GoDaddy left for other projects and so I think the team have got some things to tidy up. It's been around much longer than a year though.

> 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]

1. https://www.entri.com/


I was very excited at discovering this protocol thinking it could solve a few pain points of our domain onboarding process.

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.


If you’re doing more than domain verification, there are a couple of other options you might want to consider [1][2].

Both are run by really good guys that’ll answer any questions you’ve got.

https://www.entri.com https://www.dnshelper


* https://www.dnshelper.com


Thanks for mentioning this protocol – I've been a fan of Domain Connect [1] for many years and referenced it in one of my earlier comments [2].

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)

2. https://news.ycombinator.com/item?id=35828772

3. https://domainverification.org/create-record


Doesn’t this have the problem that the verifiable identifier has a different lifecycle to the DNS entry?

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.


> 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.

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.


> 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.


Expiry dates are optional at the moment but perhaps the requirement for an expiry could be set at the domain level. For example a query to:

_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.


I’m struggling to understand how this makes any sense given the creators own argument.

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?


1. One record can be used by all service providers (set and forget)

2. Records could be created automatically upon domain registration (with opt-in)

The current IETF standards don't enable either of the above.


That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request.

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.


> That would imply if someone signs up for a service I am not using (with my verified domain), I am going to receive an email or other sort of verification request.

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.


My use of authorization was a bit vague.. what I meant is that with your scheme, you implicitly assume I want a particular application to be authenticated.

This leaves the user vulnerable to someone else launching accounts on providers they don’t use, that point to your verification record.

It’s much more secure to add a DNS record for each system (maybe even each instance/user) as you are explicitly authorizing access to that application via your domain.


This seems like a nice option to have, and I appreciate the thought put into it.

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.


> This seems like a nice option to have, and I appreciate the thought put into it.

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.


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.

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.


Interesting idea.

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.


This can also help to some extent: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...


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).


Thanks for taking a look. I think you might have missed an important part of this (perhaps I overlooked to explain this part more thoroughly) – the "verifiable identifier" (e.g. telephone number or email address) still needs to be verified by the service provider using usual onboarding methods. An attacker can't just guess the email or telephone to be able to claim the domain on the service.


Don’t you see then this accomplishes nothing for the implementer and instead makes them do more work in addition to still requiring the user to add a DNS record?

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.


The implementer being e.g. Facebook?

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.


Will an attacker be able to use rainbow tables to uncover emails or phone numbers from the publicly-available TXT record?


Great question, thanks.

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).


My GPU will reportedly do about 2.8 billion SHA-256 hashes per second, and it's already a few years old. With consumer hardware you can brute force this in seconds even without using heuristics (i.e. applying rules based on country prefixes).


I might have misunderstood you, but brute force what exactly?

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.


Any regards to cache poisoning attacks?

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.


Thanks for this really interesting feedback – especially that the subdomain method could create more opportunities for cache poisoning.

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'm not well versed in ACME but in DNS, unfortunately. Yes, it would have the same issue if it works as described. I've read a whitepaper on the subject I described and the time to poison cache goes way, way down. Basically, anyone could pull it off.

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.


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.

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?


Thanks for your feedback.

> 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)
5. If Domain Verification isn't ultimately successful, they can either:

  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? By that I mean example+tag@gmail.com, catch-all email addresses, Apple's and Mozilla's email anonymization services, and so on.


Really interesting point, thanks.

> 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.


A deleted question, that I had typed out a response for but couldn't submit because it was deleted (in case it helps anyone):

>> 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).

1. http://www.domainconnect.org/


Noticed this is from the same uk firm that created a denser alternative of json called modl, now called https://www.compactdata.org/


That’s correct, we have a couple of projects that use DNS TXT for storing data and JSON and TXT records are not a good fit. My description above references compactdata, which as you pointed out is the new name for MODL which uses to live at https://www.MODL.uk


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.

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.


Thanks for your question.

> 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.

1. https://www.num.uk

2. https://www.numprotocol.com

Both sites in urgent need of an update.


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.


WHOIS is largely useless now because of Privacy Protection Services, Proxy Registrants and GDPR. The WHOIS protocol itself is more or less entirely shut down in favour of RDAP [1].

1. https://www.icann.org/rdap


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.


I can see the appeal. However, this solution is to ease friction for the average domain owner trying to onboard with service providers. Historically, public/private keys and the man in the street rarely get along.


Wouldn't it be simpler to just build on the acme challenges?

https://letsencrypt.org/docs/challenge-types/


DNS-01 is a standardisation of the same methods service providers have been using for well over a decade. Ok they've started using subdomains instead of the apex [1], but really it's more of the same.

This protocol offers additional functionality and less friction.

1. dig target.com TXT


> This protocol offers additional functionality and less friction.

Most users will be using letsencrypt anyway, so at a minimum this adds friction by forcing (most) users to implement two protocols?


Do you mean LE or DNS-01?

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.


As a user of LE, you need to implement http or DNS (or tls) challenge - typically via a tool that takes a pointer to your provider (letsencrypt).

I claim that it would be less friction to simply use the same tool for verifying domain control (suplly facebook as the provider).

Ed: although thinking about it, existing tools for interfacing with LE probably do too much (create certificate requests) - so might not make that much sense to reuse the tools/clients as is.


this sounds great


Thanks very much! I've still got some work to do on it but I'm now at a stage where I need more people looking at it and giving feedback. Thanks for yours.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: