[HN Gopher] Fun with DNS TXT Records
___________________________________________________________________
Fun with DNS TXT Records
Author : theden
Score : 167 points
Date : 2023-11-26 04:57 UTC (18 hours ago)
(HTM) web link (thoughts.theden.sh)
(TXT) w3m dump (thoughts.theden.sh)
| indexerror wrote:
| Pretty Cool!
| quink wrote:
| Semi-compulsory link whenever this sort of thing comes up:
|
| https://en.wikipedia.org/wiki/Hesiod_(name_service)
| PMunch wrote:
| Ooh, 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 wrote:
| Consul can be used as a KV store.
|
| https://en.wikipedia.org/wiki/Consul_(software)
| abhinavk wrote:
| 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..."
|
| Else zlib.compress() will throw a TypeError.
| theden wrote:
| Thanks abhinavk, updated
| jiehong wrote:
| 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).
| teddyh wrote:
| mDNS (<http://www.multicastdns.org/>) is just the mechanism,
| it's DNS Service Discovery which uses the TXT records:
| <http://dns-sd.org/>
| LeonM wrote:
| 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.
| teddyh wrote:
| > _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 wrote:
| That's really interesting.
|
| I could serve a whole site purely via DNS.
| ape4 wrote:
| Can a domain have multiple TXT records?
| LeonM wrote:
| Yes.
|
| Though you'd probably need to label them, or you'd run into
| the same UDP length issues. Also, there is no guarantee in
| order the records are returned.
| Geezus_42 wrote:
| Yes, if you spend time in SMTP land you will see lots of
| domains with multiple TXT records for things like SPF and
| DKIM. Also, services like Barracuda, Gsuite, O365, etc that
| use a TXT record to verify you control the domain. Let's
| Encrypt uses that mechanism as well.
| FiveNinjas wrote:
| Yup - you can do a lot with a TXT record.
|
| dig txt @vps7.pgregg.com artofwar.pgregg.com |sed 's/" "//g'
| |sed 's/`n/\n/g' |less
| semiquaver wrote:
| > UDP connections that are more typically used for DNS have a
| limit of about 1500 bytes in length.
|
| UDP datagrams can be up to 64K using IP fragmentation, but the
| original DNS protocol limits UDP payload sizes to 512 bytes.
| Using EDNS, payloads may be as much as 4096 bytes.
| tonymet wrote:
| Great research and interesting. DNS TXT has great potential for
| Query / response like teletext on European TVs in the 1990s
|
| Any effort to restore the internet as a diffused & usable
| information resource (rather than an advertising network) would
| be beneficial.
| voytec wrote:
| > It is a common misconception that a DNS TXT record can only
| contain 255 bytes
|
| I got a flashback of a long-ish email exchange with a certain
| DNS parking provider, related to publishing public 4096bit DKIM
| keys...
| fanf2 wrote:
| DNS also has an overall message size limit of 65535 bytes, so
| if you try to create a max-size TXT record, the server will not
| be able to answer queries for it, nor transfer the zone to
| secondary servers.
| justsomehnguy wrote:
| > 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 wrote:
| 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.
| superkuh wrote:
| 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.
| matja wrote:
| 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"
| arshxyz wrote:
| Related: https://dns.toys
| oriettaxx wrote:
| oh, thanks! I was just going to ask this link
| oriettaxx wrote:
| my colleague just asked if there is a way to query chatgpt
| using DNS :) :)
| Ayesh wrote:
| 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.
| jzombie wrote:
| Haha
| j0hnyl wrote:
| That's amazing. How long ago was that?
| sroussey wrote:
| The most fun I had with DNS was having the Great FireWall of
| China start blocking Walmart's mx record IP addresses for their
| email (back when they just did an IP block based on DNS
| resolution of a blocked domain).
| Ayesh wrote:
| 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
| DaiPlusPlus wrote:
| 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.
| avar wrote:
| It's worth noting that you (re) invented what iodine does:
| https://code.kryo.se/iodine/
| woleium wrote:
| I 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
| oriettaxx wrote:
| and 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 wrote:
| 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!
| koliber wrote:
| You might enjoy Tom7's "Harder Drive" video. It's pure geek
| comedy: https://www.youtube.com/watch?v=JcJSW7Rprio
| berkes wrote:
| 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.
| ipython wrote:
| As long as it's signed in some form- dns is trivial to mitm
| (save for dnssec)
| d-z-m wrote:
| 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
| gruez wrote:
| >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 wrote:
| > 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?
| jmholla wrote:
| > 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.
|
| Can you talk more about this? I can't find anything in the
| OpenSSL wiki and my searching skills haven't revealed much
| except about the possibility of the ciphertext being modified
| when using AES-256-CBC.
| DylanSp wrote:
| https://dyna53.io/ is an amusing example of (mis)using AWS's
| Route 53 DNS service as a database.
| huslage wrote:
| DNS is a database. This is just the culmination of its role.
| pgl wrote:
| 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/
| ericra wrote:
| Nice 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 wrote:
| 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!
| m3047 wrote:
| 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.
| cryptonector wrote:
| > 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 wrote:
| 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
| ... )
___________________________________________________________________
(page generated 2023-11-26 23:02 UTC)