top | item 36754366

Show HN: Use DNS TXT to share information

143 points| danradunchev | 2 years ago | reply

dig +short TXT youpay.govorenefekt.com @1.1.1.1 | fold -s

You can base64 encode an image, split to TXT records and send over Internet. Useful in certain circumstances. Like when one of the communicating parties is under severe censorship.

91 comments

order
[+] gunapologist99|2 years ago|reply
You could also securely hash a username and password together with something like argon2ID, and then authenticate users by seeing if the base64'ed TXT record exists. No need to hit an overloaded database, just dig and you'll even have the benefits of local caching with per-record TTL's!

But should you do crazy things like this? Absolutely not!

DNS is notoriously prone to MITM, injection, cache poisoning, DoS, etc. DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way.

Even though it's the foundation of almost everything we try to do securely, including the basis for TLS DV certificate (totally fungible, regardless of a hundred or so certificate authorities, including many located in authoritarian regimes!) validation:

DNS is absolutely and irredeemably broken forever, from a security perspective, and can never be fixed. As tempting (and easy) as it is to hack on it or treat it as an ultra-fast and extensible UDP remotely-accessible lookup database, just don't. (It just needs to die in a fire, probably along with SMTP.)

Unfortunately, even if someone came up with some system that could credibly replace it, that system would inevitably have a LOT of privacy and censorship trade-offs, so DNS is what we're stuck with.

Just stay very aware of the risks of encoding anything security-related inside DNS and try to minimize your reliance on it as best you can.

[+] puppetmaster|2 years ago|reply
I am just stopping by to say that this is actually a thing. It is called hesiod and works great in small, maybe air-gapped networks.

As a side note, anything security related exists in the reality of uncertainty. It is expected that sharing properly secured secrets is reasonably safe, but day after day we discover "we didn't know". Sometimes simplicity for a particular application is worth certain amount of risk.

Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...

For quick reference: - https://en.m.wikipedia.org/wiki/Hesiod_(name_service) - https://jpmens.net/2012/06/28/hesiod-a-lightweight-directory...

[+] 8organicbits|2 years ago|reply
> DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way.

Adoption is extremely poor, usability is horrible, and the approach used is quite dated, but I'm not sure DANE and DNSSEC are insecure. Did you have a reference on the latter?

[+] blechinger|2 years ago|reply
I agree with the idea that one should not trust DNS with any information one does not want public. I'm not totally convinced DNS is irreparably broken though. What are your thoughts on DNS over HTTPS?
[+] fanf2|2 years ago|reply
There are a bunch of awkward limitations, tho:

The order of records associated with a name is undefined, so if you spread your data across multiple records, you need to add ordering metadata.

The total size of the records must be less than 64 KiB - they have to fit within a DNS message, which has a limited size.

You can put all your 64K ish data into one TXT record, but it has to be split into strings of up to 255 bytes.

You can invent your own record type to contain raw binary data without the sequence-of-strings requirement.

You can use multiple names (eg, numbers) to get past the size limit and to be explicit about the correct order.

[+] hashstring|2 years ago|reply
I think that a lot of offensive tools to tunnel IP over DNS actually overcame these limitations in real time, at the expensive of throughput [1]. It obviously does require agreeing on some sort of protocol on both sides though.

[1] https://github.com/yarrick/iodine

[+] runjake|2 years ago|reply
It was pretty common for orgs to use TXT and HINFO (“host info”) records up through the 1990s.

I still use them at work to provide hints and more information but the current fleet of IT workers don’t really grok anything beyond A and PTR.

You’re just using DNS as intended. :-P

[+] whartung|2 years ago|reply
> the current fleet of IT workers don’t really grok anything beyond A and PTR.

Part of this, though is also who is "in control" of the server.

Most of the times, DNS is on the other side of the bastion, managed by Network Ops, and out of reach of Joe Developer. Perhaps a reasonable situation, fat finger DNS and Bad Things can happen. However, Joe Developer has carte blanche access to things like HTTP servers and with that they were allowed to go hog wild.

So, the innovation in the HTTP space exploded as it was a safer place to dabble to the point that every solution was viewed through the lens of HTTP.

In the end, devs don't know DNS because they don't need to know DNS, and even if they did, the Powers in NetOps weren't going to let them have their grubby fingers on it anyway.

[+] Eduard|2 years ago|reply
What are some neat things to place in TXT and HINFO records that time seems to have forgotten about?
[+] Hnrobert42|2 years ago|reply
The iodine protocol allows bi-directional ipv4 traffic over DNS.

https://github.com/yarrick/iodine

[+] c7DJTLrn|2 years ago|reply
This is pretty good for bypassing captive portals on public Wi-Fi access points. Sometimes you can use it to get Internet for free without paying. These days most are more clever and will block everything other than the default gateway until you sign on.
[+] EnglishLFC|2 years ago|reply
It's always amusing when someone discovers DNS TXT records. ClamAV has been using them to announce the latest versions for more years than I care to remember.

$ dig +short -t txt current.cvd.clamav.net "0.103.8:62:26972:1689593340:1:90:49192:334"

For anyone interested, Freshclam interprets this as:

Latest ClamAV version: 0.103.8 Latest Main DB version: 62 Latest Daily DB version: 26972 UNIX Timestamp 1689593340

...and then some other version numbers and things I don't remember, one is probably a bytecode DB version 334, f-level 90 maybe.

Anyway, nothing new, works as designed. You can do all kinds of neat tricks with it. DNS has a lot going on that most people don't (ab)use.

[+] hannob|2 years ago|reply
That is... interesting that they do not even use HTTPS or any type of signature for that info.

So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?

[+] RajT88|2 years ago|reply
Timely. I've been noticing on flights that the in-flight wifi uses a squid proxy to block you until you pay - but most of the time, you'll get whatever data from the DNS Forwarder even if you haven't paid yet.

I've been noodling on how to build a simple proxy off DNS to test on my next flight.

[+] andrelaszlo|2 years ago|reply
A regular proxy on port 53 might work? Is it necessary to actually use DNS?

Otherwise there's https://github.com/yarrick/iodine

Edit: seems like others have recommended it already. I got it working in a hotel room once after giving up on the utterly broken ToS acceptance page for the WiFi.

[+] xabi|2 years ago|reply
This reminds me of a very curious way in the past of distributing small programs/scripts using finger, attaching it base64 encoded in the .plan

  % finger xabi
  Login: xabi              Name:
  Directory: /home/xabi                Shell: /usr/bin/zsh
  On since Mon Jul 17 11:20 (CEST) on pts/0 from xxx.xxx.xxx.xxx
   1 second idle
  No mail.
  Plan:
  Latest version of my code (base64 encoded):

  -------- 8< ----------- 8< -----------------
  SGVsbG8gd29ybGQK
  -------- 8< ----------- 8< -----------------
[+] knagy|2 years ago|reply
I have a vague memory about a security talk where they used TXT records to deliver a payload to a machine and they had to write such code that the rows returned in the TXT records could be run in any order because the order the TXT records are returned is not deterministic.

I couldn't find the talk, but I found this nice article: https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-ca...

[+] badrabbit|2 years ago|reply
OP, this is trivial to detect. DNS command and control is a thing malware/attackers use which among other things include TXT records,DoH, long A or AAAA records and many other creative ways, my fav right now being using a CNAME chain to encode information (no single request is too large or suspicious.

In my experience, bypassing censorship does not mean doing unusual things like this but things like browser extenstions that stego your message in legitimate requests .

[+] ngc6677|2 years ago|reply
what do you mean by CNAME chain? sounds interesting
[+] 1vuio0pswjnm7|2 years ago|reply
"Like when one of the parties is under severe censorship."

What if the censor hijacks DNS queries. This is also done outside the realm of censorship, e.g., hotel wifi networks.

[+] candiddevmike|2 years ago|reply
Relying on DNS is not recommended when under severe censorship
[+] PinguTS|2 years ago|reply
Why, if it is encrypted?
[+] breakingcups|2 years ago|reply
DPI will make short work of your unencrypted DNS records..
[+] 8organicbits|2 years ago|reply
And encryption wouldn't help much either if this approach became popular enough. It's pretty rare to request TXT records in "normal" end user traffic so it's reasonable to either fully block TXT lookups or flag them as suspicious.
[+] nigamanth|2 years ago|reply
Hmm, isn't this how like GitHub / other services can check whether you own a domain. What are the advantages of this over other ways of sharing information like a TXT file or a database?
[+] exabrial|2 years ago|reply
If only we could put TCP port numbers in DNS to avert an ipv4 availability crunch and effectively expand the address space to 48bits… one can dream. Apparently impossible.
[+] threesevenths|2 years ago|reply
You can they are called SRV records but browsers don’t really support lookups that way.
[+] sgjohnson|2 years ago|reply
It doesn’t expand the IPv4 space in any way, shape or form.