7 ms·
Fun with DNS TXT Records
- deleted 3y ago[deleted]
- indexerror 3y agoPretty Cool!
- deleted 3y ago[deleted]
- quink 3y agoSemi-compulsory link whenever this sort of thing comes up: https://en.wikipedia.org/wiki/Hesiod_(name_service) https://en.wikipedia.org/wiki/Hesiod_(name_service)
- PMunch 3y agoOoh, that's pretty clever. I wonder if this might be useful for things like managing cloud servers or docker clusters. Apart of course from its more obvious use of managing a set of "personal" machines (I'm picturing a computer lab for example).
- justsomehnguy 3y agoConsul can be used as a KV store. https://en.wikipedia.org/wiki/Consul_(software) https://en.wikipedia.org/wiki/Consul_(software)
- HumanOstrich 3y agoThis thread is about DNS. Nobody asked for suggestions for a KV store.
- justsomehnguy 3y agoYou have no idea how Consul works? > Registered services and nodes can be queried using a DNS interface or an HTTP interface This thread is about Hesiod, a service which provides DNS interface for databases.
- deleted 3y ago[deleted]
- HumanOstrich 3y agoApologies. I didn't realize Consul had a DNS interface and I failed to glance at the Wikipedia article you linked. That's pretty neat though.
- abhinavk 3y agoNice. I will probably post some TXT poetry for jest. Just wanted to add that the first line in the first snippet should be: >>> lorem_ipsum = b"Lorem..." Else zlib.compress() will throw a TypeError.
- theden 3y agoThanks abhinavk, updated
- jiehong 3y agomDNS uses the TXT record as a key-value store, and it’s used quite a lot: for AirPlay or for IoT with Matter devices (and many others).
- teddyh 3y agomDNS (<http://www.multicastdns.org/ http://www.multicastdns.org/>) is just the mechanism, it’s DNS Service Discovery which uses the TXT records: <http://dns-sd.org/ http://dns-sd.org/>
- LeonM 3y agoIt is a common misconception that a DNS TXT record can only contain 255 bytes. This is not true, a TXT record can actually contain much more than 255 bytes. rfc1035 defines the <character-string> string object, which consists of a length octet (byte), followed by n bytes of text. There is no null terminator. So, the maximum length of the <character-string> is 255 bytes of usable text. However, a TXT record can contain one or more <character-string> objects, which the DNS client will stitch together into one long string. For a standard DNS record, the length is ultimately limited by the rdlength property of the resource record format (rfc1035, sect 4.1.3). The rdlength is 16 bit unsigned, so the maximum payload length of a resource record is 65,536 octets (64kb). Keeping in mind the overhead of the length octet in each <character-string> object, you'll end up with a maximum of 65,280 octets of usable characters in the TXT record. This will work, but requires the DNS server to respond to TCP requests. UDP connections that are more typically used for DNS have a limit of about 1500 bytes in length.
- teddyh 3y ago> which the DNS client will stitch together into one long string. Not necessarily. In practice, yes, this is what clients looking for long SPF or DKIM records actually do. But there isn’t anything guaranteeing this if you invent your own use for TXT records.
- throwaway167 3y agoThat's really interesting. I could serve a whole site purely via DNS.
- ape4 3y agoCan a domain have multiple TXT records?
- justsomehnguy 3y ago> With only four TXT recrods that’s ~1KB of compressed data. Some demoscene intros can be stored in TXT records. A somewhat useful thing what can be stored in TXT is some some self contained script with the encoded payload eg to bypass firewall/proxy. You can even bootstrap it from one record and it can read the rest of payload itself from the other records. Edit: yep, good old iex: (Resolve-DnsName -Type TXT yourdnsname).Strings|iex
- bkor 3y agoSpotify uses (used?) DNS TXT records as well. See e.g. the following article: https://engineering.atspotify.com/2017/03/spotifys-love-hate-relationship-with-dns/ https://engineering.atspotify.com/2017/03/spotifys-love-hate... I thought they also used it in their client but cannot find a article about that.
- superkuh 3y agoI used to do things like this. Then my DNS host was bought by another company (after 18 years with them) and their new system started detecting my youtube iframe rickrolls for blindly copying/embeding whois http sites as "hacking attempts". I had to remove them or else I couldn't change my records.
- matja 3y agoAlso, every "class" has TXT records, not just the "IN" (internet class): $ host -c ch -t txt version.bind glass.its.utexas.edu version.bind descriptive text "9.11.36-RedHat-9.11.36-11.el8" $ host -c ch -t txt version.bind ns1.yahoo.com version.bind descriptive text "Yahoo"
- arshxyz 3y agoRelated: https://dns.toys https://dns.toys
- Ayesh 3y agoIdea for a password manager: alternative DoH server (with own root, it solves DNSSEC issues) with proper authentication that returns the username and password for each site as TXT records. So you can `dig` to retrieve passwords: ` dig example.com @my.crazy.password.manager.tld ` ` example.com. TXT "username=myuser;password=hunter2" You can now use tools like rsync, ssh, irc, browsers,next to piggy back in DNS to resolve passwords and private keys, even TOTPs
- Ayesh 3y agoThe most fun I had with TXT records was that putting an an XSS payload and chuckle at those "online DNS lookup" tools popping up my alert() calls.
- DaiPlusPlus 3y agoWaaay back in 2012, I wrote a TCP tunnel-over-DNS-TXT as a mental exercise for myself, as DNS traffic was (is still?) allowed through the Captive Portals that corp/academia/soulless-hospitality throw up on their Wi-Fi networks - I had it preconfigured as a tunnel for RDP traffic into my home box (WS2003) - the bandwidth was appalling (only slightly better than 56K) but the feeling of stickin' it to the man is unbeatable. It's just unfortunate now that there's no way you'll squeeze a semi-usable desktop experience through dial-up-tier RDP anymore. IIRC, I had to use 16-color mode on a 640x480-sized desktop (good enough for e-mail!). Of course, today, people just whip-out their phone's tether/hotspot.
- avar 3y agoIt's worth noting that you (re) invented what iodine does: https://code.kryo.se/iodine/ https://code.kryo.se/iodine/
- woleium 3y agoI tried the same thing, but ended up using icmp as the performance was better. Looks like there are several implementations: https://en.m.wikipedia.org/wiki/ICMP_tunnel https://en.m.wikipedia.org/wiki/ICMP_tunnel
- oriettaxx 3y agoand now is fun with Wireguard: if they only access to the internet is the DNS udp, you can easily route all traffic on it :) I set it up and it works, of course, then I tried to use it with public limited wifi (hotels, airports) but still have to find what I thought was more common: a connection where the only open DNS traffic is DNS
- TheTxT 3y agoSomeone should make another one of these "unlimited data storage with youtube, discord, etc" videos, just with DNS TXT records. Globally distributed, unlimited data storage for (almost) free!
- berkes 3y agoI guess it would be a very solid way to present shasums for binaries. Nowadays software often puts them on the same webpage that links to the binary. While that's better than nothing, having them in a TXT record makes it more secure.
- d-z-m 3y agoDNS as a password manager is kind of an own-goal, as you give the attacker the means to mount an offline attack against your encrypted passwords at the outset. They can simply retrieve the encrypted blobs over the network, and begin. Putting that aside, as instantiated by the author, there are some problems with the encryption methodology: 1. CBC doesn't provide integrity There's no guarantee given to you by the construction that the password you (successfully!) decrypted is the same password you encrypted. If you're symmetrically encrypting anything nowadays, you should be using some form of authenticated encryption. 2. `openssl enc`'s -pbkdf2 flag defaults to 10k iterations, which is off by more than an order of magnitude by today's standards for a comparable use case(protecting password vaults). 3. using PBKDF2 in the first place. There are more modern KDFs nowadays(scrypt, argon2) that are resistant to more kinds of attacks[0] that should probably be used instead. 4. using `openssl enc` in the first place. OpenSSL has always cautioned against using the `enc` command for anything serious, so I feel obligated to mention it. Sorry if this seems like I'm talking out of school, but in case any one reading was inspired to use this methodology for encrypting their own passwords, I wanted to give a proper accounting of what I think the limitations are. Off topic: is this guy a Drake fan? [0]: https://en.wikipedia.org/wiki/Custom_hardware_attack https://en.wikipedia.org/wiki/Custom_hardware_attack
- gruez 3y ago>1. CBC doesn't provide integrity Is this a serious issue for this use case? If the attacker tries to tamper with the ciphertext, chances are it will cause the decrypted plaintext to be gibberish with many invalid/unprintable ascii characters. That should alert the user that something's up.
- d-z-m 3y ago> chances are it will cause the decrypted plaintext to be gibberish with many invalid/unprintable ascii characters. Not necessarily. If the plaintext you're trying to modify is in the first ciphertext block(which in this scenario is likely the case), you can modify a byte in the IV(assuming the IV is stored alongside the ciphertext) to modify the corresponding byte in the first plaintext block without a trace. > Is this a serious issue for this use case? In my opinion this whole use case is an issue. Why give an attacker access to your encrypted passwords?
- DylanSp 3y agohttps://dyna53.io/ https://dyna53.io/ is an amusing example of (mis)using AWS's Route 53 DNS service as a database.
- pgl 3y agoI did some research on TXT records a little while back, that might be of interest: https://labs.ripe.net/author/pgl/the-joy-of-txt/ https://labs.ripe.net/author/pgl/the-joy-of-txt/
- ericra 3y agoNice article! And btw, thanks for all your work as a filter list maintainer. I know it's a lot to keep up with, and I appreciate it very much.
- gumby 3y agoAbout 25 years ago I played an adventure game someone had written entirely in DNS TXT records. You may each move with nslookup (which shows how long ago this way) > With an API, one could programatically update TXT records. Just run bind yourself and you can update your records with very simply programming!
- m3047 3y agoCreate your own adventure, all you need is python + dnspython + dns redis, and a Redis DB: https://github.com/m3047/rkvdns https://github.com/m3047/rkvdns When you start using DNS as a generalized key/value store, there are some tuning / optimizations to be aware of: * Production grade caching / recursing servers retry aggressively. There is debouncing in this implementation. * Tune your EDNS packet size (in your caching server) to make sure you aren't triggering retries unnecessarily. (And frags are bad and Francisco Franco is still dead.) * Empty non-terminals are rare enough in "happy eyeballs" use that (de) optimizations in the name of things like privacy are known to happen. You should contemplate disabling qname minimization if that's something the caching server does.
- cryptonector 3y ago> DNS as a Password Manager? Shades of the old NIS+/AUTH_DH/mech_dh scheme. That's a scheme that Sun used in 1987 for NFS security and for authentication. It goes like this: - there is a name service called 'publickey' (i.e., with a getent style API, a 'files' backend, so /etc/publickey, and a NIS+ backend for domain-based authen.) - each publickey(5) entry has: - the name ("netname") of the entity - a DH group identifier - a DH public key and - the corresponding DH private key encrypted in the entity's password To login you in the system would prompt you for a username and password, lookup your entry in the publickey(5) name service, if found then it would decrypt the private key and confirm that the public key matches. To authenticate to a remote service the system would find that service's publickey(5) entry, compute the shared DH secret, and send a message with the local and remote names, a nonce, and a proof of knowledge of the shared secret. Anyways, you could store publickey(5) in DNS, naturally, if you wanted, though that was never implemented because mech_dh simply died of disuse. It's worth noting that the DNS is mostly public. Yes, you can make zone iteration hard, but not impossible. So if you publish secrets encrypted in low-entropy keys (like typical passwords) then those will be subject to cracking. I do think mech_dh, modernized with ECDH and PQ key agreement, could make a lot of sense to revive. I could totally see a new scheme that's a cross between mech_dh, Kerberos, and JWT.
- oriettaxx 3y agoI cannot believe it: I was just asking https://www.perplexity.ai https://www.perplexity.ai for some geek examples of what I can do with TXT Records, and as an answer I've got the summary of this HN page and link (adding content to HN carry on some big responsibilities nowadays ... )
- heyitsols 3y agoMessing with DNS is so fun. I did a lightning talk on storing secrets in DNS [1] for my vpn tokens and also have a URL shortener that uses DNS as its storage mechanism [2] [1]: https://youtu.be/CpWM_eVfRBM?si=uj3qVLcW_56FdQ8Y https://youtu.be/CpWM_eVfRBM?si=uj3qVLcW_56FdQ8Y [2]: https://ols.wtf/url-shortener.html https://ols.wtf/url-shortener.html