It 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.

Waaay 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.

DNS 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

The 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.

Semi-compulsory link whenever this sort of thing comes up:

https://en.wikipedia.org/wiki/Hesiod_(name_service)

Spotify uses (used?) DNS TXT records as well. See e.g. the following article: 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.

Also, 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"

> 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

I 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.

I 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/

> 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 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.

Someone 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!

Related: https://dns.toys

Idea 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

I cannot believe it:

I was just asking 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 ... )

About 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!

Create your own adventure, all you need is python + dnspython + dns redis, and a Redis DB: 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.

I 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.

Nice. 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..."

https://dyna53.io/ is an amusing example of (mis)using AWS's Route 53 DNS service as a database.

Messing 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

[2]: https://ols.wtf/url-shortener.html

mDNS 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).

Pretty Cool!