elliottinvent

I'm working on a couple of projects that are along these lines:

- 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

Wait til you see the Twitter account:

https://twitter.com/htmx_org

all it does is do simple things by adding attributes to html elements

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/

Very active, helpful community on Discord [1] and a #htmx-2-dev channel for discussion on this very topic

1. https://htmx.org/discord

Admittedly I didn’t get that [1] far, thanks for pointing it out. I read the first half but he lost me at conversational dynamics (I mainly come here for the comments).

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

It was recently explained to me:

Introverts charge their battery in solitude and discharge it socialising. Extroverts the opposite.

If only all properties were pitched expertly by the vendor, like the “never ending property” [1]

With high end 70s chintz and cheese production values.

1. https://m.youtube.com/watch?v=kynbFDou6GI&feature=youtu.be&c...

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

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.

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.

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.

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.

* https://www.dnshelper.com

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

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

Hop on the Discord, a very active and collaborative community: https://htmx.org/discord

I think the point is that by using HTMX your site can degrade gracefully for non-JS users.

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

True, but well designed houses that have natural places for the things a well functioning home needs, are far easier to keep clean and tidy.

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

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

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

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.

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/

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

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

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

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.