- Domain Verification Protocol [1][2] – proving authority over a domain. This is an application of our broader technology (still in development) where the domain can represent any thing (not just a company, e.g. an asset).
- NUM [3][4] a way to store structured data in DNS so that the domain name is the unique key to make a telephone call, GPS locate, make a payment, etc
The usual response to concepts for storing anything in DNS is MITM attacks but these can be mitigated. See DNSSEC, DNS over HTTPs, DNS over TLS.
Email in my profile, you're welcome to reach out to discuss.
1. https://www.domainverification.org
It’s extending html to make the most of http by adding some simple attributes.
Like all great things - the building blocks are simple, but the possibilities of what you can build with them is vast.
I think this is really well dealt with in the “opportunities” to extend html in this chapter of the Hypermedia Systems book: https://hypermedia.systems/extending-html-as-hypermedia/
The battery analogy was a good way for me to understand my own experience and seemed like progress from the traditional definitions of introvert and extrovert.
1. “Balance not batteries” https://www.vipshek.com/blog/interaction#balance-not-batteri...
Introverts charge their battery in solitude and discharge it socialising. Extroverts the opposite.
With high end 70s chintz and cheese production values.
1. https://m.youtube.com/watch?v=kynbFDou6GI&feature=youtu.be&c...
In the meantime, you can see the spec here: https://gitlab.com/NUMTechnology/Domain-Verification/docs/-/...
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.
https://domainverification.org
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...
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.
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.
Both are run by really good guys that’ll answer any questions you’ve got.
A site for a project of mine [1] is built with HTMX and operates more or less the same for JS and no-JS users.
I’m aiming to add some bells and whistles for JS users but the version you see there is more or less the experience non-JS users gets too:
_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 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 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.
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.
> 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]
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)
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.
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.
This protocol offers additional functionality and less friction.
1. dig target.com TXT