> 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.
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.
They aren't?
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
I'm not trying to shoot this down so much as figure out what I'm missing here.