I guess I don't understand how DNS records work around the problem of metered APIs, since DNS providers are not going to let you store e.g. every item of your inventory in separate TXT records. Also: DNS is much, much slower than an HTTP API, which can fetch arbitrary, specific collections of records for a single query.

I'm not trying to shoot this down so much as figure out what I'm missing here.

Thanks for your comment.

> DNS providers are not going to let you store e.g. every item of your inventory in separate TXT records

There are some industry-standard limits in Cloud DNS (10k zones per customer, 10k resource records [e.g. TXT] per zone). These limits would make it difficult to store a large inventory in DNS.

NUM could be used for inventory but as you say, an API would be more effective. NUM is designed for standardised use cases like contact data, where all companies store their data in the same way – making it easy for developers to consume.

We're trying to standardise this in DNS, instead of an API, for two reasons:

1. Any domain registrant can adopt it, relatively simply (although some providers have atrocious TXT record management) – they can delegate their NUM zone to us for easy management.

2. By using DNS, we can pre-populate huge amounts of this data (we do this from num.net) which makes the protocol useful from launch and helps overcome the chicken-and-egg problem. DNS caching helps us answer these queries, we can answer a billion DNS queries for $200 using standard Cloud DNS pricing. Once caching is factored in it's incredibly efficient.

It's possible DNS resolvers might refuse to cache (or even answer) NUM queries but we hope that doesn't happen.

> I'm not trying to shoot this down so much as figure out what I'm missing here.

I appreciate that, hopefully my answers above have helped

Have any of your test users been behind corporate firewalls yet? I ask because there are some corporate firewalls (Fortigate, PAN to name a couple) that will see excessive DNS requests as a denial of service attack. The response will depend on the security admins that set up the firewalls. This could lead to false positive DDoS blocks, alerts to security operations centers, discussions with employees about their DNS traffic and possibly some folks losing internet at work temporarily or active directory server outages. What are the max queries per second this implementation can trigger per client? If you expect any of your user-base to be behind corporate firewalls, I would suggest reaching out to Palo Alto Networks and show them your implementation and ask them to test it in their lab.

Thanks for your comment.

> Have any of your test users been behind corporate firewalls yet? I ask because there are some corporate firewalls (Fortigate, PAN to name a couple) that will see excessive DNS requests as a denial of service attack.

We've done some limited testing with this on a protocol level but there's lots more to do. This example site uses DoH which some firewalls just straight up block, in that case this site and associated client-side libraries wouldn't function at all.

If a connection to Cloudflare DoH is made successfully, then it's unlikely any of this traffic will be troubled by the firewall since it's just over HTTPS.

> What are the max queries per second this implementation can trigger per client?

This example implementation is only limited by the browser and Cloudflare. In the Barclays example link provided it's sending 56 DNS queries in around a second.

This is a pretty heavy implementation, a NUM lookup for a URL like num://numexample.com:1 only requires upto 2 DNS queries. The reason this implmentation is so heavy is that we're combining a whole bunch of records.

> since DNS providers are not going to let you store e.g. every item of your inventory in separate TXT records

They aren't?

I can't imagine dns providers would be cool with you storing a couple gb of records. You could of course host your own dns server... but you could also just host your own website.

There are pretty standard industry limits in Cloud DNS (AWS, Microsoft, Google):

10,000 DNS zones per customer

10,000 resource records per zone

Both can be increased by request

At scale, query costs work out at $200 USD to answer 1 billion uncached queries, depending on TTLs that might actually deliver tens or hundreds of billions of answers to users.

It's possible DNS providers and DNS resolvers (like Cloudflare, Google etc) might put limits in place. We're hoping not.

Since TXT records are best delivered when below 5kb, it's pretty tough to store a couple of gb of data in your domain using NUM but certainly possible. If NUM is a big success, DNS providers might decide to charge for DNS data transfer rather than individual queries.

Edit: line spacing

This won't work.

If companies cannot be bothered to make their websites user friendly in the first place, why would they do it in this new and obscure way?

It's like the episode on Dragon's Den where someone tried pitching a service that would call companies on your behalf, and would only call you to connect both ends when the music stops and a call center agent actually picks up the phone.

It's the job of the company to fix their long wait times, not of some 3rd party service, which may or may not work with a specific customer service number.

Thanks for your comment.

Companies don’t need to adopt the standard for their data to be in DNS. We’re populating DNS with public website data already. All *.uk domains will be populated in the next 10 days. Then we’ll roll it out further.

In the example provided it’s mainly for big companies with lots of phone numbers. But NUM is for any machine readable data for any company - small traders, pubs, restaurants and more.

FYI, it's trying to load a resource and hanging (in ff):

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://sentry.numops.com/api/28/envelope/?sentry_key=${key_.... (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).4

Thanks for the heads up here. This is for error reporting, which is kind of ironic – we'll take a look.

Sentry is an error collection service, so that's probably nothing.

But umm, why? Seems like you're in essence just using an https api to fetch dns data. So why not just use an https api and cut out the extra step?

The https api is Cloudlfare DNS-over-HTTPS (it could be any other provider) - is just the best method to use in browsers, backend services can use standard DNS.

Storing this stuff in DNS is what enables: - individual domain owners to adopt the standard - us to offer data free, unrestricted and unlimited forever

Since DNS is massively scalable and cached it’s well suited to this IMO. Much more so than a standard API.

I mean, it might make sense on the backend. After all, decentralized, highly scalable, key-value store is what DNS fundamentally is, and it has a long history of working well for that use case.

I just kind of assumed, the thing that's supposed to be cool here is using it in the web browser as a data storage backend for your entirely client-side app (since using dns simply as a key value store isn't particularly unique). And i don't think that usecase makes sense, since its all routed through a centralized https api translation layer anyways.

> us to offer data free, unrestricted and unlimited forever

Say what now? None of this is free. Half the bill is being footed by cloudflare, the other half by the domain owner. Using an api provided by someone else is not the same as offering something for free. You're not the party doing the offering.

> None of this is free.

The data that powers this website is offered free to developers.

> You're not the party doing the offering.

We're offering it through our DNS zone num.net.

> Half the bill is being footed by cloudflare

It's correct that Cloudflare are doing a fair bit of work here, but we're a mosquito on the arse of a bull.

If NUM gets broad adoption DNS resolvers might refuse to answer (or more likely refuse to cache) our answers but there's plenty of resolvers out there and if people are using NUM to fetch useful data there'll be a competitive edge to being the fastest DNS resolver to answer those queries.

edit: line spacing

Incidentally, it looks like Semantic Web is not dead but actually accelerating growth -thanks to current SEO practices abd Google showing semantic data within search results [1]

As for complicated , yeah, but business web platforms like Wix support those as part of SEO capabilities [2]. So you would you need the smb web dev platforms to support NUM to make it a reality?

1. http://webdatacommons.org/structureddata/#toc3

2. https://support.wix.com/en/article/adding-structured-data-to...

> it looks like Semantic Web is not dead but actually accelerating growth

IMO the general-purpose semantic web (not that used in academia) is only useful for huge companies like Google, with the engineering capacity to understand all the different types of data that might be found.

At times, it seems it's almost complex by design to keep smaller developers from being able to consume the data and build anything useful on top of it.

> So you would you need the smb web dev platforms to support NUM to make it a reality?

That would be cool but it's not required for NUM to be broadly adopted. We provide a tool, NUM Server [0], where you can publish and manage data using simple online forms after proving authority for your domain name.

The best angle for us on this point, is actually through domain name registrars that offer add-ons to domain name registration and through agencies (web design, social, etc).

0. https://app.numserver.com/tools/editor/add

> the general-purpose semantic web is only useful for huge companies like Google, with the engineering capacity to understand all the different types of data that might be found.

But easier than parsing the general web

This a very interesting assumption to tackle - how non-google players can leverage all those new semantic jsonlds? I'm pretty sure the barrier is lower to build a product aggregator or a product comparison site based on scraping the web. What else?

Brilliant. Stoked to give this a try. Clever path to radically low latency for some use cases.

Thanks very much, if you need any help or have any questions just let me know – reply here or email elliott[dot]brown[at]num.uk

> bypassing data hoarding web giants

but using cloudflare to resolve dns? hmm..

CloudFlare is just the resolver in this example. The data and the way to fetch is it just vanilla DNS. Pick a resolver, any resolver.

"All of the contact data on this website is fetched from DNS TXT files."

I found contact data for a number of companies in the Javascript files.

    {"object_display_name":"Organisation","name":"Co-op Insurance","slogan":"Car, Home, Travel, Pet and Life Insurance from Co-op","contacts":[
    {"object_display_name":"Organisation","name":"Columbus Direct","slogan":"Award Winning Travel Insurance for 30 Years","contacts":[
    {"object_display_name":"Organisation","name":"First Direct","slogan":"Online and telephone banking 24 7 365","contacts":[
    {"object_display_name":"Organisation","name":"Churchill","slogan":null,"contacts":[
    {"object_display_name":"Organisation","name":"MORE THAN","slogan":"Car, home, pet, life, travel and landlord insurance quotes","contacts":[
    {"object_display_name":"Organisation","name":"Saga","slogan":"Over 50s Insurance, Holidays, Money and Magazine","contacts":[
    {"object_display_name":"Organisation","name":"LV=","slogan":"Liverpool Victoria","contacts":[
    {"object_display_name":"Organisation","name":"Sheila\'s Wheels","slogan":"Car & Home Insurance with Style","contacts":[
    {"object_display_name":"Organisation","name":"Swiftcover","slogan":"Super Fast Car and Home Insurance","contacts":[
    {"object_display_name":"Organisation","name":"Barclays Bank","slogan":"A big world needs a big bank","contacts":[
    {"object_display_name":"Organisation","name":"Hastings Direct","slogan":"Car, Van, Bike and Home Insurance","contacts":[
    {"object_display_name":"Organisation","name":"Co-operative Bank","slogan":"For People with Purpose","contacts":[
    {"object_display_name":"Organisation","name":"Halifax UK","slogan":"Halifax makes it happen","contacts":[
    {"object_display_name":"Organisation","name":"Lloyds Bank","slogan":"By Your Side","contacts":[
    {"object_display_name":"Organisation","name":"Royal Bank of Scotland","slogan":"Enjoy better banking with RBS where people matter","contacts":[
    {"object_display_name":"Organisation","name":"Admiral","slogan":"Car, MultiCar and MultiCover Insurance Quotes","contacts":[
    {"object_display_name":"Organisation","name":"Aviva","slogan":"Insurance, Savings and Investments","contacts":[
    {"object_display_name":"Organisation","name":"AXA","slogan":null,"contacts":[

Thanks for highlighting this – it comes from company-api, which is built on top of the DNS: https://www.npmjs.com/package/company-api

Actually, I think this is a JSON object to populate the companies on the homepage. When you click one of these companies a NUM lookup is run on the domain name, then all contact data comes out of DNS.