Show HN: DNS-based alternative to the web for structured data

People have now wrapped DNS RR in TLS, then in HTTP and they are thinking about putting DNS RR into HTTP headers or into HTML tags.

https://www.potaroo.net/ispcol/2020-06/row.html

In the late 2000's I took the oppsoite approach, because back then, DNS, i.e., traditional 512K UDP packets, was much faster for data retrieval than TCP/SSL/HTTP. TLS has gotten quite fast but using UDP is still faster, that's why we see UDP-based "reliable transport" protocols like (lesser known) CurveCP and (better known) QUIC. I put the content into the DNS RR instead of putting the DNS RR, e.g., IP address, into the content.

Retrieving content, e.g., a web page, has become a two-step process, thanks to DNS. It could be a one step process if we used IP addresses instead of names; I still do this where possible. However to use names, first we have to get the IP address (step 1), and only then can we retrieve the content (step 2). If we combine the IP address with the content then we can eliminate a step.

Putting everything into DNS instead of into web pages gives more control to the user, IMO. Web browsers are controlled by companies that rely on the survival of the online ad industry. DNS software does not have this problem.

I feel the same way, the record editor is pretty esoteric and reminds me of schema.org really. For any hope of adoption by small business I think it needs to be something registrars buy into with a more user-focused interface which is more like "describe your business to us" than "populate our data format". Large corps, DNS is surprisingly often managed by marketing departments, and you're going to find them asking questions like "so we can't advertise our complementary services to someone looking for our phone number? we can't style it? Why would we want that? We can't track conversion?" All of these are probably positives to the user, but in direct conflict with the interests of the people actually in control of the domain.

edit/ of course the only way around this is for apple and google to make it mandatory to appear in their mobile dialer app or something, but google at least will never do that because in the "way things are" example we can see many, many user-unfriendly situations that are great for google's metrics and revenue

In MODL [1] graves are used to quote strings since DNS implementations vary in how they handle escaped double quotes. That said, the record editor should have escaped it if you entered it into an input field so I'll take a look at this, thanks for highlighting it.

We're united in our love for DNS and terse text formats and I agree that most people don't care about either. However, that's the point of the NUM Server service [2] – it's a front end to create and manage NUM records.

Early next year we're going to populate the DNS with millions of NUM records for businesses based on their company website. So once the data is in DNS and developers start to consume it and build interesting things with it, we hope that companies will want to claim their record and that's where we can make money – from NUM record hosting, as protocol adoption grows.

Licensing for all NUM libraries is Apache 2.0, there's no charge or limitations on records from our NUM Server service, we just ask that a link is provided where a business can claim their populated record.

1. https://www.modl.uk 2. https://app.numserver.com

> * But the DNS can support responses of up to 65535 bytes over TCP, which servers are required to support*

Requirements are only as effective as their enforcement...

Interestingly, Google Cloud DNS has a fixed limit of 1012 characters per resource record (counting the quote marks that separate fixed length 255 char TXT strings). They claim you can have 10,000 resource records in a resource record set, so over 10mb of data.

I think DoH is an important development here – our "NUM Record Viewer" makes all queries over DoH but of course you need to load a web app to run the queries.

I'm hoping browsers will support custom DNS queries at some point. There was some talk of it being supported in Chromium a couple of years ago but it got shelved I think. Hopefully creative uses of the DNS like NUM will encourage them to consider it again.

NUM looks to me like a great improvement over the defacto 'status quo' of DNS, Search Engines, and 'Site Sifting' for useful info.

I do have some concerns about the plan to make the owners of various domains that much easier to locate and/or name in lawsuits, as at least here in the US, I could see that info being rather easily abused, along with the initial focus on 'contacts' (see my further comments/concerns below).

That said, given you asked for feedback/suggestions, and what looks to me the focus and high level of usefulness of NUM, especially on streamlining the overall process for 'inter-entity transactions' (whether personal, commercial, or whatever) I believe that a rather useful 'module' (and likely better yet, some number of modules), I would see as Services, Products, and/or Solutions.

Each of those can be seen as either Standard or Custom or perhaps even involve both (ie, a standard Solution for xyz market typically includes abc standard products as well as def custom services or whatever)

This could easily include info about various products, as well as entire 'product lines', along with direct connect to marketing/sales materials and/or contacts, list/actual pricing, specific support resources, whether contacts and/or documentation (manuals) and/or even ways or sites that their organization prefers for handling certain interactions (phone calls, texts, chat, or even say direct (and perhaps non-disclosed) 'click to connect' methods, whereby entering a 'client id' (or having some security certificate) that then perhaps creates a direct connection, or maybe provides a custom 'menu' of options directly available, or whatever, might become possible

Also, given that many companies, groups, governments could also likely use something like this Internally as well, perhaps create the ability to 'federate' the NUM info (both up and down).

Taking that to the next logical step, there could be NUM data/records flagged for different 'audiences'

These 'audience' entries then could be used to auto-magically publish 'internal', 'external', 'vendor', 'client', 'employee', or whatever type records in appropriate places and ways, in NUM, thus helping to maintain appropriate access, security, permissions, etc.

I do really like the option to include public keys as well, as that opens up avenues to directly and easily establish programmatic methods for fully encrypted communications, transactions, file transfers, and whatever else.

In fact, using an organizational public key, along with an employee-designated key (plus whatever other factors) could then be used to instantly create say a Wireguard connection to whichever resources (perhaps including additional NUM/DNS records, data, etc) that that individual has been provided with access to, thus creating a fairly easy way to establish 'Zero Trust', yet fully functional [net]work environments, allowing equal access, no matter where one might happen to be located

That could simultaneously allow for a reduced, if not single, set of security protocols/parameters per organization, and given that simplification effectively tends to increase overall organizational security, similar to how Wireguard is seen as so revolutionary, due to it's simplicity when compared to legacy VPN technologies

That said, I do believe that, additionally, especially for personal contacts/sites/details, and/or organizational units, there really ought to be methods (put) in place to allow for some level of anonymous yet authenticated access, such that NUM doesn't inadvertantly disclose info that ends-up creating yet more 'attack surface' for 'bad actors'

A simple example might be what happens by 'scraping' sites, winnowing down that info, and then publishing it (in clear text).

That would of course be done in an effort to 'help', though I could see that rather easily causing inadvertent complexities, or even outright disasters, especially given how much 'less than skilled' disclosure of info, whether at the individual/family level or at various organizational entities/levels, I have seen happening time and again on Many web-sites world-wide.

Those bits of info Currently tend to be obscured by exactly the nature of how the web has developed (and that NUM seems to be well positioned to address and effectively resolve moving forward) and Yet, at the same time, taking all those juicy bits of info, boiling them all down, and 'canning' them, such that Any script kiddie could then (far more easily And programmatically) utilize all that 'condensed goodness' to then target Anyone or Any group just about Anywhere, simply using NUM's (assuming publicly accessable) data, could well cause some unintended back-lash, if not handled with care.

I do realize that this last one could be an area where there is no simple answer, at least not yet, and I believe I would be remiss if I didn't mention my concerns here as well