11 ms·

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

by 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.
- plagiat0r 3y ago
  Let me just add one more thing why this idea seems bad to me personally. I'm not atacking you, but the idea. So the way things work today is this, the way I see it: 1. We have a physical layer -> a wire 2. We have a data link layer -> ethernet + ARP or NDP are common here 3. we have a network layer -> currently, two networks are widely used: IPv4 and IPv6 4. We have a transport layer: tcp and udp and quic 7. We have an actual data, encrypted or not. So where the DNS fits in this model? People say it is build on top of UDP, so it must be layer7, right? But because of the core function of the DNS protocol, I would put DNS into Layer3, the same as I would put ARP and NDP on layer2 even if NDP is built into IPv6. I would put it on Layer 2 solely by the function it provides. A sole purpose of the DNS is to make a connect() possible without using direct network addressess, but client use "a string" as a destination. For me this is a Layer 3 protocol, because it is a helper protocol used to establish a connection. Once you have a connection, on top of it you use other layers to transfer data reliably. Your solution puts a Layer 7 data into a Layer 3 component by using TXT records. And if there were no TXT records invented, you could still encode binary data in the AAAA records, 8 bytes at a time and hack it to store arbitrary data that a custom "client" can process in 8 byte chunks. And while clever, this is not the right tool to store layer 7 data. It is like sitting on an island with a hammer. You need to cut a tree and says: well, I can use hammer to cut the tree or I can try with bare hands. What should I do? While I agree hammer has a higher chance of succeeding, I would advice to find a sharp rock instead. Find or invent a better tool for the job.
  - quickthrower2 3y ago
    Thanks that is a cool insight about what layer DNS should be thought of as. Never even thought about this.
    - plagiat0r 3y ago
      I really do not want to start a flame war about OSI model, but I tent to bend the OSI model and interpret the "layers" by the function they presents. Another example, lets say you spin up a QuicTun, nacl-based encapsulation tunel, encrypted, running over IP + UDP as a layer7 process, in userland, there is no kernel implementation. For me, this vpn is Layer2 (when tap mode) or Layer3 (when tun mode) regardless that it uses all 7 layers to establish the tunnel. Sure it uses all layers to establish the connection but once it is done, I have layer3 device for further use. Same for DNS - for me it is Layer3 because of the crucial function it provides, so I could rather say it is functionally on the same layer as IP in a sense, it is crucial to make a connection. Does not matter that it uses all 7 layers to get me the network (A)ddress / (AAAA)ddress, it is still functionally a network layer for me. Only once this is establised, I can exchange data. And while DNS is running on layer7 - for me personally, the function it performs is "to allow connect() to a string as opposed to a network address (IP/IPv6)" and because of that, it is a Layer3 for me on the functional level, same as a VPN software to access some corporate stuff. Does not matter that VPN uses TLS and DNS under the hood and span across all 7 layers to encapsulate my data, functionally it is layer3 for me. I do a lot of corporate DNS trainings and people are surprised about this view. Software developers are unhappy that we start the "DNS course" with IP basics, unicast, anycast, 101 overview of BGP, ARIN, provider independed vs Provider Aggregatable address space. Developers would rather learn about DNS, not what an IP address is. Network guys sits happy on the course, but they are not happy to hear my view that: "there is no DNS without network and there is no network without a DNS" However, slowly but surely once the full training is finished, both sides understand that IP/IPv6 and DNS are in a symbiosis and can't be separated. We touch a lot of topics, including lack of interoperatibilty between IPv4 and IPV6, DNS64, XLAT464, etc. Sure, if you run an air-gapped network in some military facility, you can get things working without DNS, but 99.999% networks can't work without a DNS.

by zzem 3y ago

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.

plagiat0r 3y ago
Let me just add one more thing why this idea seems bad to me personally. I'm not atacking you, but the idea. So the way things work today is this, the way I see it: 1. We have a physical layer -> a wire 2. We have a data link layer -> ethernet + ARP or NDP are common here 3. we have a network layer -> currently, two networks are widely used: IPv4 and IPv6 4. We have a transport layer: tcp and udp and quic 7. We have an actual data, encrypted or not. So where the DNS fits in this model? People say it is build on top of UDP, so it must be layer7, right? But because of the core function of the DNS protocol, I would put DNS into Layer3, the same as I would put ARP and NDP on layer2 even if NDP is built into IPv6. I would put it on Layer 2 solely by the function it provides. A sole purpose of the DNS is to make a connect() possible without using direct network addressess, but client use "a string" as a destination. For me this is a Layer 3 protocol, because it is a helper protocol used to establish a connection. Once you have a connection, on top of it you use other layers to transfer data reliably. Your solution puts a Layer 7 data into a Layer 3 component by using TXT records. And if there were no TXT records invented, you could still encode binary data in the AAAA records, 8 bytes at a time and hack it to store arbitrary data that a custom "client" can process in 8 byte chunks. And while clever, this is not the right tool to store layer 7 data. It is like sitting on an island with a hammer. You need to cut a tree and says: well, I can use hammer to cut the tree or I can try with bare hands. What should I do? While I agree hammer has a higher chance of succeeding, I would advice to find a sharp rock instead. Find or invent a better tool for the job.
- quickthrower2 3y ago
  Thanks that is a cool insight about what layer DNS should be thought of as. Never even thought about this.
  - plagiat0r 3y ago
    I really do not want to start a flame war about OSI model, but I tent to bend the OSI model and interpret the "layers" by the function they presents. Another example, lets say you spin up a QuicTun, nacl-based encapsulation tunel, encrypted, running over IP + UDP as a layer7 process, in userland, there is no kernel implementation. For me, this vpn is Layer2 (when tap mode) or Layer3 (when tun mode) regardless that it uses all 7 layers to establish the tunnel. Sure it uses all layers to establish the connection but once it is done, I have layer3 device for further use. Same for DNS - for me it is Layer3 because of the crucial function it provides, so I could rather say it is functionally on the same layer as IP in a sense, it is crucial to make a connection. Does not matter that it uses all 7 layers to get me the network (A)ddress / (AAAA)ddress, it is still functionally a network layer for me. Only once this is establised, I can exchange data. And while DNS is running on layer7 - for me personally, the function it performs is "to allow connect() to a string as opposed to a network address (IP/IPv6)" and because of that, it is a Layer3 for me on the functional level, same as a VPN software to access some corporate stuff. Does not matter that VPN uses TLS and DNS under the hood and span across all 7 layers to encapsulate my data, functionally it is layer3 for me. I do a lot of corporate DNS trainings and people are surprised about this view. Software developers are unhappy that we start the "DNS course" with IP basics, unicast, anycast, 101 overview of BGP, ARIN, provider independed vs Provider Aggregatable address space. Developers would rather learn about DNS, not what an IP address is. Network guys sits happy on the course, but they are not happy to hear my view that: "there is no DNS without network and there is no network without a DNS" However, slowly but surely once the full training is finished, both sides understand that IP/IPv6 and DNS are in a symbiosis and can't be separated. We touch a lot of topics, including lack of interoperatibilty between IPv4 and IPV6, DNS64, XLAT464, etc. Sure, if you run an air-gapped network in some military facility, you can get things working without DNS, but 99.999% networks can't work without a DNS.