Locating Humans with DNS(landshark.io)
landshark.io
Locating Humans with DNS
https://landshark.io/2021/02/04/dns-for-humans.html
49 comments
Wow, this scenario is basically copied from the old PalmPilot ad:
https://m.youtube.com/watch?v=6bcTc8e2-6U
This is what I was thinking also. Tel was(is?) more or less locked down so you can only put contact info on the site itself, also.
It's a shame, because if this kind of thing had caught on, VoIP calls could be substituted for PSTN calls and the user wouldn't have to notice. Imagine calling amazon.com and getting their customer support line either via PSTN or via VoIP (provided you/they have e.g. SIP accounts, which obviously isn't a good assumption now but would sure be an easier transition in this hypothetical world).
Even better: imagine being able to set reverse DNS in this scenario. I call someone who doesn't have me in their address book, and their phone shows "<my nickname>.tel".
Even better: imagine being able to set reverse DNS in this scenario. I call someone who doesn't have me in their address book, and their phone shows "<my nickname>.tel".
It went as an unspoken, unquestionable assumption that telephony was the right model for data networking. - Van Jacobson
DNS is the only global scale example of a broadly functional directory service with decent degree of flexibility in its decentralization. The PSTN is the opposite: it uses carriers, national infrastructure and a plethora of relatively closed systems to achieve the same. Observe: national carrier mobile number portability hacks. It is amusing that, after so many years, directory services for telephones are still under discussion.
Looking around in 2021, it turns out that the complexity associated with running DNS means it has effectively slowly migrated to a smaller number of outsourced infrastructure providers, despite strong decentralization support in the protocol. To put it bluntly, it's more hassle than it's worth to run your own servers when you can outsource for ~free to globally distributed infrastructure that's professionally run and DoS resistant.
We might also note that most voice calls in the world are now placed through IP software services with centralized identifier directories and never touch PSTN at all. Turns out humans like free, free likes cheap-to-provide, and centralized means cheap-to-provide. Turns out the market values users, so funding is a non-issue.
It's sad that, as a result, the oldschool internet is being lost. But the internet was never inclusive, as it required too much technical nouse and good-behavioural assumption. Maybe the internet is just growing up. It's now the digital commons.
While I applaud the effort for this protocol, and I frankly would be the first to sign up for a contact infrastructure service that provided reliable and best-effort security integrations for all legacy channels (SMS, fax, PSTN, mail, VPN) ... I can't see this effort turning the tide. After all, we already have dynamic DNS registrations and IPv6 mobile features, neither of which has been broadly adopted. Instead, I think we will see these protocols co-opted commercially or ignored.
DNS is the only global scale example of a broadly functional directory service with decent degree of flexibility in its decentralization. The PSTN is the opposite: it uses carriers, national infrastructure and a plethora of relatively closed systems to achieve the same. Observe: national carrier mobile number portability hacks. It is amusing that, after so many years, directory services for telephones are still under discussion.
Looking around in 2021, it turns out that the complexity associated with running DNS means it has effectively slowly migrated to a smaller number of outsourced infrastructure providers, despite strong decentralization support in the protocol. To put it bluntly, it's more hassle than it's worth to run your own servers when you can outsource for ~free to globally distributed infrastructure that's professionally run and DoS resistant.
We might also note that most voice calls in the world are now placed through IP software services with centralized identifier directories and never touch PSTN at all. Turns out humans like free, free likes cheap-to-provide, and centralized means cheap-to-provide. Turns out the market values users, so funding is a non-issue.
It's sad that, as a result, the oldschool internet is being lost. But the internet was never inclusive, as it required too much technical nouse and good-behavioural assumption. Maybe the internet is just growing up. It's now the digital commons.
While I applaud the effort for this protocol, and I frankly would be the first to sign up for a contact infrastructure service that provided reliable and best-effort security integrations for all legacy channels (SMS, fax, PSTN, mail, VPN) ... I can't see this effort turning the tide. After all, we already have dynamic DNS registrations and IPv6 mobile features, neither of which has been broadly adopted. Instead, I think we will see these protocols co-opted commercially or ignored.
"Looking around in 2021, it turns out that the complexity associated with running DNS means it has effectively slowly migrated to a smaller number of outsourced To put it bluntly, it's more hassle than it's worth to run your own servers when infrastructure providers, despite strong decentralization support in the protocol."
The age-old elements of the protocol are still very reliable. I cannot agree with your conclusion that "its more hassle than its worth" to run DNS servers. Depends on the use case. DNS isn't just for companies. I use run DNS at home and I could not live without it. A third party provider would/could never offer the customised, creative solutions I created myself.
There is a learning curve but I think it is less than, say, email service. Maybe not. You can run DNS without third parties and IMO you should. I think the stuff it allows you to do is well worth it. I think the reason I spent the time to learn DNS is that it is very fast. Instant, short text response. Much more pleasant than what websites have turned into.
The old school is alive and well, but it does not need to hype anything, so what you see and hear is people hype-ing crap, not the good stuff that old, unsexy is much more reliable.
All the third party DNS services could go down and it would not affect me much at all, because I have so much stored DNS data. Most of the DNs traffic I produce never leaves the loopback. Makes the UX much faster.
The age-old elements of the protocol are still very reliable. I cannot agree with your conclusion that "its more hassle than its worth" to run DNS servers. Depends on the use case. DNS isn't just for companies. I use run DNS at home and I could not live without it. A third party provider would/could never offer the customised, creative solutions I created myself.
There is a learning curve but I think it is less than, say, email service. Maybe not. You can run DNS without third parties and IMO you should. I think the stuff it allows you to do is well worth it. I think the reason I spent the time to learn DNS is that it is very fast. Instant, short text response. Much more pleasant than what websites have turned into.
The old school is alive and well, but it does not need to hype anything, so what you see and hear is people hype-ing crap, not the good stuff that old, unsexy is much more reliable.
All the third party DNS services could go down and it would not affect me much at all, because I have so much stored DNS data. Most of the DNs traffic I produce never leaves the loopback. Makes the UX much faster.
A small team and I are working on this with NUM [0] - a way to store any kind of structured data for a domain or email address.
0. https://www.numprotocol.com
0. https://www.numprotocol.com
> a way to store any kind of structured data for a domain or email address.
This sounds a bit nutty until you realize that DNS is essentially an infinitely scalable eventually-consistent database.
This sounds a bit nutty until you realize that DNS is essentially an infinitely scalable eventually-consistent database.
To the author:
Add `overflow: auto` to `.content` to fix the overflow issue.
Source: https://twitter.com/bhathos/status/1357859138433413123
Add `overflow: auto` to `.content` to fix the overflow issue.
Source: https://twitter.com/bhathos/status/1357859138433413123
Thanks. I just pinged the theme author: https://twitter.com/handheld/status/1358121285625217024
Why create a new weird text format for locating a person, when you could use RP records (rfc1183) to provide an email address and a reference to a freeform text record.
> Why create a new weird text format for locating a person, when you could use RP records (rfc1183)
Because they aren't the same thing. RP records designate the person responsible for the domain, which may or may not be the person that the domain identifies.
RP records also assume the user has an email address. That's been a bad assumption for long time now.
Because they aren't the same thing. RP records designate the person responsible for the domain, which may or may not be the person that the domain identifies.
RP records also assume the user has an email address. That's been a bad assumption for long time now.
Precisely this. The DNS already supports exactly what he is proposing to instead do with some sort of JSON monstrosity.
JSON doesn't have anything to do with it. That was just the response from Cloudflare's DoH endpoint. The heart of the idea was using a SPF-ish TXT record.
Still, it would be better to use the existing RP record type (with included additional TXT link) than to make up YET ANOTHER overloading of TXT.
Blockchain powered DNS solutions also come with these kinds of specifications, e.g. the Ethereum Name Service[0] has an an additional specification[1] for "human-readable metadata" which means I can add my twitter handle and email address to my domain gilani.eth[3].
And this is on top of cryptocurrency addresses and other addresses.
[0]: ENS: https://ens.domains/
[1]: EIP 634: https://eips.ethereum.org/EIPS/eip-634
[2]: Gilani.eth: https://app.ens.domains/name/gilani.eth
And this is on top of cryptocurrency addresses and other addresses.
[0]: ENS: https://ens.domains/
[1]: EIP 634: https://eips.ethereum.org/EIPS/eip-634
[2]: Gilani.eth: https://app.ens.domains/name/gilani.eth
> Whatever you think about the situation, the fact is Parler the application got vaporized in a day, but Parler.com is still registered. The Pirate Bay is one of the most taken down sites in history, and thepiratebay.org is still registered.
Not the case for sci-hub
Not the case for sci-hub
Sci-hub was taken down by court order. While I don't like it, their case went through the legal system.
If you run email on your own domain, you get a lot of similar protections--you get to route your email to your provider of choice should anything happen.
IndieAuth[1] let's you use dns-as-identity too and extends it to support authentication.
I'd love to see more use of this but alas the internet has been trained that everything should be add-supported and otherwise free.
1: https://indieauth.com/
IndieAuth[1] let's you use dns-as-identity too and extends it to support authentication.
I'd love to see more use of this but alas the internet has been trained that everything should be add-supported and otherwise free.
1: https://indieauth.com/
User identity has always been a place for big tech to be deliberately divergent from open standards because identity is one of the underlying assets for freemium services.
In the case of pay for identity (like phone numbers) it was guarded as a potential source of additional revenue for multiplay offerings and micropayments.
A couple of decades along we’re sleepwalking into a time where our personal identity will become the property of big corporations that do not protect our privacy or interests.
Signal, WhatsApp, iMessage etc use phone numbers (and email with iMessage) as a not quite anonymous “lookup key” for an identity.
Perhaps now is the time to look at reinventing something like the ENUM RFC for persistent identity.
https://en.m.wikipedia.org/wiki/Telephone_number_mapping
A million years ago (before hotmail or gmail) I had a bigfoot.com email address that forwarded to your actual address - maybe there is a scope for a community funded modern equivalent now that allows the creation of genuine lifelong “email” identities.
In the case of pay for identity (like phone numbers) it was guarded as a potential source of additional revenue for multiplay offerings and micropayments.
A couple of decades along we’re sleepwalking into a time where our personal identity will become the property of big corporations that do not protect our privacy or interests.
Signal, WhatsApp, iMessage etc use phone numbers (and email with iMessage) as a not quite anonymous “lookup key” for an identity.
Perhaps now is the time to look at reinventing something like the ENUM RFC for persistent identity.
https://en.m.wikipedia.org/wiki/Telephone_number_mapping
A million years ago (before hotmail or gmail) I had a bigfoot.com email address that forwarded to your actual address - maybe there is a scope for a community funded modern equivalent now that allows the creation of genuine lifelong “email” identities.
In the cryptocurrency world there is the DNS based OpenAlias: https://openalias.org/ The format is extensible enough to be able to hold a wide range of information sets.
Why all the DNS funny business, just put your contact info on a website at (www.)landshark.io. No new standards needed, everyone already knows how to operate a website, and if you use a static site generator, hosting a website is essentially free.
Why bring HTTP into it? You need to do a DNS lookup on landshark.io anyway to get the A record.
I was building my own version of about me.
standard protocol like DNS makes lot of sense.
people should be able to publish link to public key as well.
and changes can also be captured in a blockchain .
some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
standard protocol like DNS makes lot of sense.
people should be able to publish link to public key as well.
and changes can also be captured in a blockchain .
some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
> I was building my own version of about me.
Do you have a link you can share?
> people should be able to publish link to public key as well.
There's a actually a standard for this: https://www.df7cb.de/blog/2007/openpgp-dns.html
I would prefer if you could just dump the whole key in DNS itself, but TXT records are limited to 255 bytes.
> and changes can also be captured in a blockchain .
What's your use case for wanting to know the delta over time?
> some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
I was mostly thinking in terms of "public" information. I can see wanting permissions for things like physical address.
Do you have a link you can share?
> people should be able to publish link to public key as well.
There's a actually a standard for this: https://www.df7cb.de/blog/2007/openpgp-dns.html
I would prefer if you could just dump the whole key in DNS itself, but TXT records are limited to 255 bytes.
> and changes can also be captured in a blockchain .
What's your use case for wanting to know the delta over time?
> some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
I was mostly thinking in terms of "public" information. I can see wanting permissions for things like physical address.
> I would prefer if you could just dump the whole key in DNS itself, but TXT records are limited to 255 bytes.
The article you've linked also mentions CERT RRs, which include keys themselves, and there's also DANE's OPENPGPKEY [1].
Besides, each string of a TXT record is limited, but they can consist of multiple strings, so whole keys can be stored in those as well (as it's done for DKIM records, for instance).
[1] https://tools.ietf.org/html/rfc7929
The article you've linked also mentions CERT RRs, which include keys themselves, and there's also DANE's OPENPGPKEY [1].
Besides, each string of a TXT record is limited, but they can consist of multiple strings, so whole keys can be stored in those as well (as it's done for DKIM records, for instance).
[1] https://tools.ietf.org/html/rfc7929
I'd rather advise to use Web Key Directory that is trivial to setup (have https and put a key file in one special location). WKD is also widely supported by OpenPGP software (including ProtonMail, GnuPG, OpenKeychain).
See: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
See: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
Back when RSA was still a munition, the 4 line Perl version of the algorithm was distribute as a DNS txt record. Hmmm.... or maybe it was DeCSS.
Edit: here’s DeCSS:
http://decss.zoy.org/
http://www.yak.net/fqa/126.html
I think RSA was distributed similarly.
Edit: here’s DeCSS:
http://decss.zoy.org/
http://www.yak.net/fqa/126.html
I think RSA was distributed similarly.
WebFinger is another option: https://webfinger.net/
I like this concept. It’ll be down to how you provide an interface for the non-nerd.
What I want is a single ID source which you can provide access to from multiple service providers that need certain components. I’ve just changed address and the nightmare of updating each individual service makes me want for a common framework that all bank, utility, retailers use.
What I want is a single ID source which you can provide access to from multiple service providers that need certain components. I’ve just changed address and the nightmare of updating each individual service makes me want for a common framework that all bank, utility, retailers use.
> It’ll be down to how you provide an interface for the non-nerd.
It would only work as part of a compelling product. Maybe something like this will show up in the next generation of censorship-resistant messaging apps.
It would only work as part of a compelling product. Maybe something like this will show up in the next generation of censorship-resistant messaging apps.
>it’s a shame we’d have to use some arcane protocol to query it
...does the author mean DNS? Literally spitting text at a server over UDP? As opposed to the comparatively simple json/js/tls/dns hybrid monstrosity which I’m sure would be the end result of his curl prototype.
...does the author mean DNS? Literally spitting text at a server over UDP? As opposed to the comparatively simple json/js/tls/dns hybrid monstrosity which I’m sure would be the end result of his curl prototype.
DNS _is_ arcane ("understood by few; mysterious") for the majority of developers, who've never had to directly interact with it. Whereas I'd bet good money that 99% of developers who've worked on web services for more than a year know how to use curl to hit a url.
Don't mistake "simple" for "widely-known".
Don't mistake "simple" for "widely-known".
This is exactly what I meant. Arcane != Hard.
The JSON response from the DoH server is btw a custom thing Google and Cloudflare do, but not part of the DoH standard.
Indeed. I think the particular media type is a little beside the point though as long as it is machine readable. Luckily HTTP has built in content negotiation so it's not a hard problem to deal with.
Then I don't get the proposed benefit of DoH here. curl + parsing a standard DNS response is not really easier than just using a DNS client.
Most developers have never touched a DNS response beyond requesting host name resolution. DoH makes it possible to request the information in a way familiar to far more developers.
But DoH is by no means a requirement. If you like the DNS protocol, then by all means have at it.
But DoH is by no means a requirement. If you like the DNS protocol, then by all means have at it.
Https is a benefit.
Curl + parsing is better because it decouples transportation from interpretation. Dnswalk and other clients that speak "native" DNS provide are monolithic, handling transportation, parsing, and more. And many of these concerns, like data transfer, are dealt with in an ad hoc way, when it might be preferable to always assume URL+DNS+TCP+HTTPS+GET=>JSON. As a one-size-fits-all transport mechanism, it's not bad at all.
Still not convinced? Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. In that world the indirection is in the wrong place, at the process invocation level. Luckily this doesn't apply to (most) APIs these days, although it does apply to certain areas of software, like embedded programming (or so I hear). But this is analogous to using a specific binary tool to interact with DNS vs HTTP.
Yes, I'm sensitive to the argument that we shouldn't abandon the other parts of the network stack, and forget that there is more to doing networked applications than just TCP+HTTP. But honestly, for practical reasons there should be very compelling reasons to "drop down" the stack and pick something like UDP+DNS for your application.
Still not convinced? Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. In that world the indirection is in the wrong place, at the process invocation level. Luckily this doesn't apply to (most) APIs these days, although it does apply to certain areas of software, like embedded programming (or so I hear). But this is analogous to using a specific binary tool to interact with DNS vs HTTP.
Yes, I'm sensitive to the argument that we shouldn't abandon the other parts of the network stack, and forget that there is more to doing networked applications than just TCP+HTTP. But honestly, for practical reasons there should be very compelling reasons to "drop down" the stack and pick something like UDP+DNS for your application.
> Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider.
I don't have to imagine it. It exists, and it was created by people who insisted on building ridiculously complex software stacks which have made it increasingly difficult to write your own stack. And the few open source stacks are slowly winnowed down because it becomes a feature arms race and eventually the last option standing is the "free" crippled version of some corporate developed library.
Sending and receiving a DNS UDP query, and extracting your RR of interest, takes a few dozen lines of C code. (Using TCP is just as easy if not easier.) Now imagine doing something so simple, but first having to build the SSL and HTTP stacks (or, shudder, QUIC). Nobody would do it. Everybody would just use the same piece of software.
This is exactly how we ended up with Chrome and an unimaginably empowered Google. And it was for the same reasons--"imagine how easy it will be for a web developer to implement feature FOO if we simply added feature FOO to the browser and he could just call do.FOO!"
I don't have to imagine it. It exists, and it was created by people who insisted on building ridiculously complex software stacks which have made it increasingly difficult to write your own stack. And the few open source stacks are slowly winnowed down because it becomes a feature arms race and eventually the last option standing is the "free" crippled version of some corporate developed library.
Sending and receiving a DNS UDP query, and extracting your RR of interest, takes a few dozen lines of C code. (Using TCP is just as easy if not easier.) Now imagine doing something so simple, but first having to build the SSL and HTTP stacks (or, shudder, QUIC). Nobody would do it. Everybody would just use the same piece of software.
This is exactly how we ended up with Chrome and an unimaginably empowered Google. And it was for the same reasons--"imagine how easy it will be for a web developer to implement feature FOO if we simply added feature FOO to the browser and he could just call do.FOO!"
>I don't have to imagine it. It exists.
Not sure what you mean, here. HTTP-based APIs have been really good, I think, for the world overall, and not just because exposing services this was allows you to tunnel arbitrary application data through firewalls!
Are the real blobs you're referring to the browser? I don't think that's fair, because a browser does far more than curl. And curl-level functionality is a lot simpler.
>a few dozen lines of C code...
...built and executed in a specific runtime environment. And since we are talking about distributed programs, by nature, you will be faced with solving all of those painful lessons we've learned about security, performance, and scale, but this time with your own custom starting assumptions.
I think it's quite fair to accept the "curl abstraction" (expressed in callback hell form as get(request, callback(response)) as a basic building block of your system, as opposed to doing something lower level.
Not sure what you mean, here. HTTP-based APIs have been really good, I think, for the world overall, and not just because exposing services this was allows you to tunnel arbitrary application data through firewalls!
Are the real blobs you're referring to the browser? I don't think that's fair, because a browser does far more than curl. And curl-level functionality is a lot simpler.
>a few dozen lines of C code...
...built and executed in a specific runtime environment. And since we are talking about distributed programs, by nature, you will be faced with solving all of those painful lessons we've learned about security, performance, and scale, but this time with your own custom starting assumptions.
I think it's quite fair to accept the "curl abstraction" (expressed in callback hell form as get(request, callback(response)) as a basic building block of your system, as opposed to doing something lower level.
There was a similar proposal a few months ago called NUM. Not sure what became of it:
https://www.num.uk/blog/announcing-num
HN discussion: https://news.ycombinator.com/item?id=24354559
https://www.num.uk/blog/announcing-num
HN discussion: https://news.ycombinator.com/item?id=24354559
Thanks for this, we commented at the same time - we’re refining the protocol and the language we use to store data in DNS. We’d love feedback and input on both.
With DNS there are a few problems:
* Your name, address, and other details are exposed in Whois DB linking all your details to a real name / address.
* You are subject to regulations on domain name use. For example if you have an .eu domain and you live in the UK, you had to either have a new address in the EU after brexit or abandon it.
* Your name, address, and other details are exposed in Whois DB linking all your details to a real name / address.
* You are subject to regulations on domain name use. For example if you have an .eu domain and you live in the UK, you had to either have a new address in the EU after brexit or abandon it.
Both of those are only true for some domains. There are a great many gTLDs that support whois privacy and also don't care where you are.
Why not using the very same username everywhere?
Usernames only exist in the service you register them in. I got my name on HN and GMail, but I was too late on Twitter. On the other hand, DNS is one giant global namespace. Someone else could register my name on TikTok, but they'll never be able to get landshark.io (as long as I keep paying the yearly bill...)
Because other people take it if you don't sign up in time...
Then your address book would have an entry like http://bob.tel/ which would always contain your contact's latest info.
It turns out that most normal people see a decaying address book as a feature, not a bug. If you are a meaningful contact - you'll send me new details. If not, the data can rot.
Telnic still offer this service - but I had a tel name since the start, and never saw anyone else use their features.
Here's their cheesy product marketing video from back in the day https://youtu.be/8jyB_7sh2S8