5 ms·

Show HN: This website is hosted on DNS

13 points by zzem 3y ago

Hey HN! I'm excited to share something I've been working on: a way to set up and launch websites directly through the domain control panel. It allows anyone with a domain name to create, publish, and edit basic websites directly from the domain control panel without any traditional hosting providers or coding knowledge. This narrows the gap for non-technical people looking to publish simple personal and small business websites. This is also the first TWA (triweb application) on the triweb platform (https://triweb.com https://triweb.com) we are working on. Triweb currently has limited functionality, and this app is mostly just a showcase of how TWAs and triweb containers work. We have an exciting lineup of upcoming features and a unique, simple vision of the decentralized web without the overhyped web3 technologies. We hope that one day triweb will become a standard platform for local-first, browser-based decentralized web applications.

1vuio0pswjnm7 3y ago
About 16 years ago, I did a different experiment of hosting a website in DNS. I put small web pages into DNS TXT RRs. Thus, one only needed to make a DNS request over UDP to retrieve the web page, instead of a DNS request and then an HTTP request over TCP. tinydns allows one to put any data into RRs, including control characters. RRs can therefore contain MIME headers. Then I put dnscache in front of it. The result was a highly resilient website with compact pages.
Ringz 3y ago
Looks interesting! What are the advantages (besides the mentioned ones) and what are the disadvantages?
- zzem 3y ago
  I think the main advantage is the ease and speed of use for people who want a simple, business-card-like website or a holding/landing page. The main disadvantage is that due to the UI/UX of domain control panels, managing anything more than a few paragraphs of text gets messy really quickly. But that could be actually an advantage, as the DNS is not particularly well suited to serve large amounts of data, and the app itself is meant for small and simple websites.
  - coretx 3y ago
    Let's be honest here. The main advantage is to make use of someone else his resources. Since it's potentially degrading critical infrastructure and increasing the cost of market entry: Unethical.
    - zzem 3y ago
      Sorry, but I don't understand your point. How is this "degrading critical infrastructure" and "increasing the cost of market entry"? It's also not using someone else's resources - DNS hosting is a web service like any other. You pay for it either as a part of domain registration/renewal cost (when DNS hosting is included in the registrar's offer) or separately (e.g., Route53 or "Advanced DNS" offerings).
      - blamecanada 3y ago
        What you're not understanding is the way DNS works is the closest DNS server to you (usually your ISP unless you've configured it differently) usually caches the results and then serves those results for subsequent requests. So you are relying upon the server that is caching those results to serve your data. The intent of DNS TXT records was not to provide you with a content distribution network for free.
      - coretx 3y ago
        DNS is a Domain Name Service. Not a webservice.
plagiat0r 3y ago
Using DNS for this is a very bad idea. The format to convert those strings to html may be good, the storage (DNS) is the bad part, especially that you can host such small files for free usually.
- zzem 3y ago
  Using DNS for website content storage is indeed unconventional and somehow controversial, but I wouldn't say it is a bad idea per se. TXT records were designed to store arbitrary data (up to 4.000 bytes per single record) and the app is meant to be used for small websites with a few paragraphs of text, as managing anything bigger than through a domain control panel is rather painful.
  - coretx 3y ago
    Reminds me of using https://code.kryo.se/iodine/ https://code.kryo.se/iodine/ ( DNS tunnel ) and a empty prepaid card...
  - plagiat0r 3y ago
    I should elaborate more about why I believe this is a bad idea to use DNS as storage / content. First, because of a distributed nature of the DNS, clients do not directly fetch this data. Instead, resolvers and DNS forwarders do the work and cache it. Secondly, because displaying or converting this data to html requires a special website or a dedicated client, at which point this dedicated component should use a different storage than DNS. Whatever that may be, p2p, etc. Third, as the impact on the DNS ecosystem is problematic here. I will say something controversial by stating this: DNS had been designed in one goal, for you or your program to connect "to a string" that you or a string owner control and manage, as opose to connecting to a network address (IP) that you usually do not own, that can change at any time, and that it is meaningless and hard to remember. Over the years, this basic principle extend a bit with introduction of some policies being stored in the DNS that is meant to help the domain owner setting up some boundaries or policies, like SPF or CAA records. Storing website data is not something I would recommend. Again, you can argue that this "client" only prints TXT data to users that would not normally be able to access it (average internet browser user) but clearly it goes far beyond this, encouraging storing domain content (data) into a DNS. Fourth, security. Very few domains implements dnssec or curvedns and clients do not use DoH en masse. A mitm is a serious threat to the client rendering this data. Fifth, if this gains wide adoption (doubt it), resolvers will stop caching TXT records as a policy to save resources for crucial data, and the crucial data is A(dress) record(s). Because the purpose of the DNS on a high level view, is too make a connection between two programs or users. I know that's a simplification, but this is the core idea. Sure, it has reverse DNS mapings to assing a string onto a network address, but 99.99% of the time DNS job is to make connect() possible. So you connect() to Amazon using DNS, Amazon contacts payment processor using DNS, they connect() to Visa which connect() to your Bank and every connection in this payment processing chain use DNS to maka it possible and reliable.
Kharacternyk 3y ago
This is a nice PoC. For how long are TXT records usually cached? Triweb might not see the latest changes to the websites for quite some time.
- zzem 3y ago
  Thanks! The time for which TXT records are cached is determined by their TTLs. When publishing a DNS TXT record, you can usually set the TTL to be as low as 1 minute or even less, so any changes to the content would be picked up really quickly. (https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/ https://developers.cloudflare.com/dns/manage-dns-records/ref...)
  - Kharacternyk 3y ago
    I know that it's all configurable, what I meant is that some DNS providers may apply a long TTL by default, and it may be desirable to let users of Triweb know about this possible source of confusion.
    - zzem 3y ago
      The DNS name resolution is actually not done by your system or ISP, but by a DNS over HTTPs (DoH) service (Cloudflare 1.1.1.1 resolver). Cloudflare seems to be respecting the TTL as returned by the authoritative name server for your domain, so if you are able to specify a short TTL for a TXT record in your domain control panel, any changes made to the website should be live within that time.
      - Kharacternyk 3y ago
        > so if you are able to specify a short TTL for a TXT record in your domain control panel Triweb users are able to do that, but they don't necessarily know that they need to do that. For example, the Cloudflare DNS dashboard displays "auto" as a TTL by default, and one has no idea how many seconds "auto" is for a TXT record.
XCSme 3y ago
I don't understand how this is "decentralized", the first step is "Point your domain at a triweb relay server". Doesn't this make the triweb relay server the central authority?
- zzem 3y ago
  At the moment, it does, but we plan to release a Docker image of the relay server so that anyone would be able to spin his/her own relay or use any other existing public relay. The triweb platform is still a work-in-progress, and there is a lot left to be done, released, and documented. The Banner app is mostly just an early demo of how TWAs are built and how they may be deployed to domains, that I thought may be interesting to HN.
hunterbrooks 3y ago
Pretty cool, even if it's a bit of a toy. I'm no networking expert, but "without the need for web servers" isn't really correct because the DNS is a type of server, right?

13 points by zzem 3y ago

1vuio0pswjnm7 3y ago

About 16 years ago, I did a different experiment of hosting a website in DNS. I put small web pages into DNS TXT RRs. Thus, one only needed to make a DNS request over UDP to retrieve the web page, instead of a DNS request and then an HTTP request over TCP. tinydns allows one to put any data into RRs, including control characters. RRs can therefore contain MIME headers. Then I put dnscache in front of it. The result was a highly resilient website with compact pages.

Ringz 3y ago

Looks interesting! What are the advantages (besides the mentioned ones) and what are the disadvantages?

zzem 3y ago
I think the main advantage is the ease and speed of use for people who want a simple, business-card-like website or a holding/landing page. The main disadvantage is that due to the UI/UX of domain control panels, managing anything more than a few paragraphs of text gets messy really quickly. But that could be actually an advantage, as the DNS is not particularly well suited to serve large amounts of data, and the app itself is meant for small and simple websites.
- coretx 3y ago
  Let's be honest here. The main advantage is to make use of someone else his resources. Since it's potentially degrading critical infrastructure and increasing the cost of market entry: Unethical.
  - zzem 3y ago
    Sorry, but I don't understand your point. How is this "degrading critical infrastructure" and "increasing the cost of market entry"? It's also not using someone else's resources - DNS hosting is a web service like any other. You pay for it either as a part of domain registration/renewal cost (when DNS hosting is included in the registrar's offer) or separately (e.g., Route53 or "Advanced DNS" offerings).
    - blamecanada 3y ago
      What you're not understanding is the way DNS works is the closest DNS server to you (usually your ISP unless you've configured it differently) usually caches the results and then serves those results for subsequent requests. So you are relying upon the server that is caching those results to serve your data. The intent of DNS TXT records was not to provide you with a content distribution network for free.
    - coretx 3y ago
      DNS is a Domain Name Service. Not a webservice.

plagiat0r 3y ago

Using DNS for this is a very bad idea. The format to convert those strings to html may be good, the storage (DNS) is the bad part, especially that you can host such small files for free usually.

zzem 3y ago
Using DNS for website content storage is indeed unconventional and somehow controversial, but I wouldn't say it is a bad idea per se. TXT records were designed to store arbitrary data (up to 4.000 bytes per single record) and the app is meant to be used for small websites with a few paragraphs of text, as managing anything bigger than through a domain control panel is rather painful.
- coretx 3y ago
  Reminds me of using https://code.kryo.se/iodine/ https://code.kryo.se/iodine/ ( DNS tunnel ) and a empty prepaid card...
- plagiat0r 3y ago
  I should elaborate more about why I believe this is a bad idea to use DNS as storage / content. First, because of a distributed nature of the DNS, clients do not directly fetch this data. Instead, resolvers and DNS forwarders do the work and cache it. Secondly, because displaying or converting this data to html requires a special website or a dedicated client, at which point this dedicated component should use a different storage than DNS. Whatever that may be, p2p, etc. Third, as the impact on the DNS ecosystem is problematic here. I will say something controversial by stating this: DNS had been designed in one goal, for you or your program to connect "to a string" that you or a string owner control and manage, as opose to connecting to a network address (IP) that you usually do not own, that can change at any time, and that it is meaningless and hard to remember. Over the years, this basic principle extend a bit with introduction of some policies being stored in the DNS that is meant to help the domain owner setting up some boundaries or policies, like SPF or CAA records. Storing website data is not something I would recommend. Again, you can argue that this "client" only prints TXT data to users that would not normally be able to access it (average internet browser user) but clearly it goes far beyond this, encouraging storing domain content (data) into a DNS. Fourth, security. Very few domains implements dnssec or curvedns and clients do not use DoH en masse. A mitm is a serious threat to the client rendering this data. Fifth, if this gains wide adoption (doubt it), resolvers will stop caching TXT records as a policy to save resources for crucial data, and the crucial data is A(dress) record(s). Because the purpose of the DNS on a high level view, is too make a connection between two programs or users. I know that's a simplification, but this is the core idea. Sure, it has reverse DNS mapings to assing a string onto a network address, but 99.99% of the time DNS job is to make connect() possible. So you connect() to Amazon using DNS, Amazon contacts payment processor using DNS, they connect() to Visa which connect() to your Bank and every connection in this payment processing chain use DNS to maka it possible and reliable.

Kharacternyk 3y ago

This is a nice PoC. For how long are TXT records usually cached? Triweb might not see the latest changes to the websites for quite some time.

zzem 3y ago
Thanks! The time for which TXT records are cached is determined by their TTLs. When publishing a DNS TXT record, you can usually set the TTL to be as low as 1 minute or even less, so any changes to the content would be picked up really quickly. (https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/ https://developers.cloudflare.com/dns/manage-dns-records/ref...)
- Kharacternyk 3y ago
  I know that it's all configurable, what I meant is that some DNS providers may apply a long TTL by default, and it may be desirable to let users of Triweb know about this possible source of confusion.
  - zzem 3y ago
    The DNS name resolution is actually not done by your system or ISP, but by a DNS over HTTPs (DoH) service (Cloudflare 1.1.1.1 resolver). Cloudflare seems to be respecting the TTL as returned by the authoritative name server for your domain, so if you are able to specify a short TTL for a TXT record in your domain control panel, any changes made to the website should be live within that time.
    - Kharacternyk 3y ago
      > so if you are able to specify a short TTL for a TXT record in your domain control panel Triweb users are able to do that, but they don't necessarily know that they need to do that. For example, the Cloudflare DNS dashboard displays "auto" as a TTL by default, and one has no idea how many seconds "auto" is for a TXT record.

XCSme 3y ago

I don't understand how this is "decentralized", the first step is "Point your domain at a triweb relay server". Doesn't this make the triweb relay server the central authority?

zzem 3y ago
At the moment, it does, but we plan to release a Docker image of the relay server so that anyone would be able to spin his/her own relay or use any other existing public relay. The triweb platform is still a work-in-progress, and there is a lot left to be done, released, and documented. The Banner app is mostly just an early demo of how TWAs are built and how they may be deployed to domains, that I thought may be interesting to HN.

hunterbrooks 3y ago

Pretty cool, even if it's a bit of a toy. I'm no networking expert, but "without the need for web servers" isn't really correct because the DNS is a type of server, right?