- 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

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

3. https://www.num.uk

4. https://www.numprotocol.com

https://twitter.com/htmx_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/

1. https://htmx.org/discord

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.

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.

Comments URL: https://news.ycombinator.com/item?id=35864114

Points: 27

# Comments: 9

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

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

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:

1. https://www.compactdata.org

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