Oh, this reminds me of a Chrome extension I wrote to distribute Web content (images, html, js, anything) over DNS: https://blog.zorinaq.com/cdn53-a-super-distributed-cdn/ It implements the fake TLD .cdn53: when visiting http://zorinaq.com.cdn53 the extension intercepts the request, sends a DNS query for the TXT record for "_cdn53.zorinaq.com" and the response contains the HTML content, or any content, and it can be up to ~65 kb in size. It's super-distributed as it will naturally be cached by all DNS resolvers worldwide that hit the domain...
I worked in the networking group for a cloud computing company. You've heard of them. We didn't charge for (some) DNS traffic, so some customers figured out how to use DNS as a transport mechanism to skirt around paying data transfer fees. It would essentially be a DoS attack which affected EVERY customer, so a few could save tiny fractions of their overall spend. A peer team of mine had to deal with the mess. That team had > 100% annual staff turnover, because they just made the oncall staff deal with the problem every time it showed up rather than ever solve the core issue of having a DoS vector masquerading as a feature.
Those can be business decisions too though. It depends on whether or not the real / lucrative customers will notice, or maybe the noisy customers who will be all over twitter because a dev figured they'd make a big change like this on their own.
Throttling and tiering can definitely affect more people than you might suspect (like spiky services) and considering data and use are important.
In a corporate environment you must use only the company DNS internal resolver and they are the only one that should go outside on port 53.
This is a basic security measure to detect and block every attempt of DNS tunnelling or exfiltration
AFWall+ on Android is an example of this - even if an app is blocked, as long as it has Internet permission it can still make DNS requests, allowing for two-way communication despite the firewall.
But ideally it'd be blocked and all traffic would go through an internal caching resolver, right? To reduce internal latency and load on outside servers, but also to have records if needed and to block whack requests or responses if needed.
For the bad apple one; I tried something like that, it works if you're directly querying the authoritative DNS server, but if a cache is involved the records will be re-ordered by randomisation (even in some cases with TTL=0). That's why I ended up doing this as a single very long record, because then it can be cached without worrying about reordering.
The cap for record size is 64KB, but you can have an arbitrary number of records, so larger images should be possible by combining multiple TXT record responses into one.
A DNS message cannot exceed 64K, but multiple messages can be transmitted over TCP. That's the way AXFR (zone transfer) is done: one question, multiple responses.
I put a link to[1] in the article, which was previously discussed here[2] with a correction to that article. Basically there's a 2 byte length header on TCP DNS responses, limiting the payload (i.e. the DNS message inside) to 64 KiB.
Also with EDNS0, you can send larger messages over UDP, too, because you aren't restricted to a single UDP payload, but can send multiple datagrams.
It's pretty cool how this tech has evolved. UDP has become so much more reliable that you can even do SSL over UDP, with a complex mechanism meant to account for dropped packets during the handshake process.
After many years of "4096 ought to be enough for anybody", the default max UDP size in BIND 9 was reduced to 1232. Frags are bad; jumbos are good, but frags are bad!
I used to do a lot of consulting work at locations with extremely locked down networks. I could use iodine + wireguard to punch through most firewalls, slow, but effective.
The only real place I got iodine to work was 40k feet above the ocean. Even then it was only good enough to telnet into an SMTP server to send an email. Most of the time it's failed for me.
This means that the security department is not doing a good job: things like iodine can be detected easily by a NGFW or by an analysis on DNS logs. This is a quite basic security posture.
Back when I was using it similarly to the other poster (say, 15 years ago) that wasn't the case. It's still a great litmus test of security posture today.
Just using DNS for data exfiltration, in general, is usually pretty fruitful. I wrote a "live off the land" data exfil script for Windows once, using the certutil and nslookup commands to base64 encode data and ship it out to my off-site DNS server.
I'll have to try it against a Palo Alto NGFW sometime and see what alarms I trip. I honestly never thought to try.
MFA is quite more complex to implement, especially if legacy applications are involved. Applying a basic DNS security monitoring is not hard, you can even implement with few policies on the border FW and something like an ELK stack.
The most difficult part is implementing an appropriate process
You can also create a REST API that accepts domain names and returns IP addresses! Then you can make a webserver that uses the REST API to get the IP address of the image you want to display!
This is cool and all but due to malicious actors abusing this avenue, firewalls as well as endpoint agents will detect and block this. If you create a serious solution that uses this that is, it's great for home use and experimentation I guess.
HEIF is just the usual container for AVIF encoded data, similar to how AV1 encoded data might commonly be in an MP4 or MKV container. HEIF might easily get conflated with HEIC, which is Apple's implementation of HEIF specifically for HEVC encoded data. Too many damn "HE"s, if you ask me.
If you run "strings" you should see "av01Image" pretty early on in the HEIF header, which is what signals it's really an AVIF file. Tools like "file" may possibly not be updated to look for that yet, so could just report the container alone.
Huh, my image viewer claimed it's HEIC specifically. My camera also seems to conflate HEIC and HEIF in the settings. It provides HEIF as a format option, when I guess it should be specifying which codec is actually being used. I had no idea HEIF isn't tied to just HEIC though.
Because I didn't feel like parsing the HEIF to check it's actually AVIF. I'm pretty sure browsers aren't that bothered about the file extension or MIME type for images.
FUN! And who knows, maybe this will lead to something later. Many discoveries or inventions were built on things people didn’t know the use of at the time.
Question can also be interpreted as "why does DNS even allow this" which is fair as it only purpose should be to convert a domain name address into a 32 bit number. The answer is partially in the link on TFA. I guess they had their reasons.
I mean DNS has had different record types for as long as I can remember, txt records in specific allowed the protocol to be extensible without everyone having to update their software to support new record types.
And that also leaves out the common things like MX records.
Oh, this reminds me of a Chrome extension I wrote to distribute Web content (images, html, js, anything) over DNS: https://blog.zorinaq.com/cdn53-a-super-distributed-cdn/ It implements the fake TLD .cdn53: when visiting http://zorinaq.com.cdn53 the extension intercepts the request, sends a DNS query for the TXT record for "_cdn53.zorinaq.com" and the response contains the HTML content, or any content, and it can be up to ~65 kb in size. It's super-distributed as it will naturally be cached by all DNS resolvers worldwide that hit the domain...
Good idea. Probably nowadays this would not work due to changes in chrome extension API? They have limit a network interception API.
I worked in the networking group for a cloud computing company. You've heard of them. We didn't charge for (some) DNS traffic, so some customers figured out how to use DNS as a transport mechanism to skirt around paying data transfer fees. It would essentially be a DoS attack which affected EVERY customer, so a few could save tiny fractions of their overall spend. A peer team of mine had to deal with the mess. That team had > 100% annual staff turnover, because they just made the oncall staff deal with the problem every time it showed up rather than ever solve the core issue of having a DoS vector masquerading as a feature.
Wouldn’t the solution be to just start charging for excessive DNS traffic?
Potentially yes, but that's a business decision which the on-call developer cannot deal make on behalf of the business.
There's a lot of stuff the dev team can do that are not strictly business decisions though. Rate limits, QoS, etc.
Those can be business decisions too though. It depends on whether or not the real / lucrative customers will notice, or maybe the noisy customers who will be all over twitter because a dev figured they'd make a big change like this on their own.
Throttling and tiering can definitely affect more people than you might suspect (like spiky services) and considering data and use are important.
The wild part of DNS is that port 53 is typically open on firewalls and is excellent for data exfiltration/infiltration.
In a corporate environment you must use only the company DNS internal resolver and they are the only one that should go outside on port 53. This is a basic security measure to detect and block every attempt of DNS tunnelling or exfiltration
Even if you use the internal resolver you could exfiltrate the data.
Yes, but an internal resolver has filtering and must be heavy monitored. If the DNS logs are sent to a SIEM you will be detected quickly
I mean most of the time said company resolvers have a service that block either suspicious requests, or only allow whitelisted domains.
AFWall+ on Android is an example of this - even if an app is blocked, as long as it has Internet permission it can still make DNS requests, allowing for two-way communication despite the firewall.
Is it? Most firewalls I see allow no inbound by default (although all outbound)
I assume they were referring to outbound.
But ideally it'd be blocked and all traffic would go through an internal caching resolver, right? To reduce internal latency and load on outside servers, but also to have records if needed and to block whack requests or responses if needed.
highly detectable though. modern ngfw's are all over this.
And it typically works on captive portals too before payment.
Very cool. I have done similar for playing Bad Apple as well as Doom over DNS:
https://youtu.be/AJ2Q12vYojY
https://youtu.be/GoPWuJR6Npc
Cool!
For the bad apple one; I tried something like that, it works if you're directly querying the authoritative DNS server, but if a cache is involved the records will be re-ordered by randomisation (even in some cases with TTL=0). That's why I ended up doing this as a single very long record, because then it can be cached without worrying about reordering.
The cap for record size is 64KB, but you can have an arbitrary number of records, so larger images should be possible by combining multiple TXT record responses into one.
A DNS message cannot exceed 64K, but multiple messages can be transmitted over TCP. That's the way AXFR (zone transfer) is done: one question, multiple responses.
https://github.com/m3047/rear_view_rpz/blob/b17cf943ccd7498d...
I put a link to[1] in the article, which was previously discussed here[2] with a correction to that article. Basically there's a 2 byte length header on TCP DNS responses, limiting the payload (i.e. the DNS message inside) to 64 KiB.
Also with EDNS0, you can send larger messages over UDP, too, because you aren't restricted to a single UDP payload, but can send multiple datagrams.
It's pretty cool how this tech has evolved. UDP has become so much more reliable that you can even do SSL over UDP, with a complex mechanism meant to account for dropped packets during the handshake process.
After many years of "4096 ought to be enough for anybody", the default max UDP size in BIND 9 was reduced to 1232. Frags are bad; jumbos are good, but frags are bad!
Right, but you aren’t limited to one DNS call. You could have the javascript resolve multiple text records, then combine them together.
You could even do this over UDP if you really wanted, just merging a bunch of 1200-byte records together
There's also the Iodine project if you want to tunnel raw IPv4 over DNS [53]
[53] https://github.com/yarrick/iodine
I love iodine.
I used to do a lot of consulting work at locations with extremely locked down networks. I could use iodine + wireguard to punch through most firewalls, slow, but effective.
The only real place I got iodine to work was 40k feet above the ocean. Even then it was only good enough to telnet into an SMTP server to send an email. Most of the time it's failed for me.
This means that the security department is not doing a good job: things like iodine can be detected easily by a NGFW or by an analysis on DNS logs. This is a quite basic security posture.
Back when I was using it similarly to the other poster (say, 15 years ago) that wasn't the case. It's still a great litmus test of security posture today.
Just using DNS for data exfiltration, in general, is usually pretty fruitful. I wrote a "live off the land" data exfil script for Windows once, using the certutil and nslookup commands to base64 encode data and ship it out to my off-site DNS server.
I'll have to try it against a Palo Alto NGFW sometime and see what alarms I trip. I honestly never thought to try.
That's make sense 15 years ago. Right now even the SOHO appliances have the DNS inspection feature.
Lol no it isn't. Most companies don't even have MFA across the board, much less do anything with DNS security beyond maybe a blacklist.
MFA is quite more complex to implement, especially if legacy applications are involved. Applying a basic DNS security monitoring is not hard, you can even implement with few policies on the border FW and something like an ELK stack. The most difficult part is implementing an appropriate process
You can also create a REST API that accepts domain names and returns IP addresses! Then you can make a webserver that uses the REST API to get the IP address of the image you want to display!
This is cool and all but due to malicious actors abusing this avenue, firewalls as well as endpoint agents will detect and block this. If you create a serious solution that uses this that is, it's great for home use and experimentation I guess.
I wonder is it possible to create a HN clone over DNS?
How about LLM chat over DNS? https://github.com/accupham/llm-dns-proxy
The image is actually HEIF not AVIF :)
HEIF is just the usual container for AVIF encoded data, similar to how AV1 encoded data might commonly be in an MP4 or MKV container. HEIF might easily get conflated with HEIC, which is Apple's implementation of HEIF specifically for HEVC encoded data. Too many damn "HE"s, if you ask me.
If you run "strings" you should see "av01Image" pretty early on in the HEIF header, which is what signals it's really an AVIF file. Tools like "file" may possibly not be updated to look for that yet, so could just report the container alone.
Huh, my image viewer claimed it's HEIC specifically. My camera also seems to conflate HEIC and HEIF in the settings. It provides HEIF as a format option, when I guess it should be specifying which codec is actually being used. I had no idea HEIF isn't tied to just HEIC though.
To be fair I did lazily do:
Because I didn't feel like parsing the HEIF to check it's actually AVIF. I'm pretty sure browsers aren't that bothered about the file extension or MIME type for images.Images over DNS over DNSCrypt over a DNS relay accessed via a VPN acting as a gateway to Tor. Maximum security.
Yes, but why? :)
FUN! And who knows, maybe this will lead to something later. Many discoveries or inventions were built on things people didn’t know the use of at the time.
Exactly.
Question can also be interpreted as "why does DNS even allow this" which is fair as it only purpose should be to convert a domain name address into a 32 bit number. The answer is partially in the link on TFA. I guess they had their reasons.
I mean DNS has had different record types for as long as I can remember, txt records in specific allowed the protocol to be extensible without everyone having to update their software to support new record types.
And that also leaves out the common things like MX records.
Because I want my DKIM signatures to be literal signatures.
Why not? This is exactly what hackers and tinkerers do.
Better question: Why not? :)