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.
https://github.com/m3047/rear_view_rpz/blob/b17cf943ccd7498d...
[1]: https://www.netmeister.org/blog/dns-size.html#:~:text=65536%20bytes%20DNS%20payload%20%2B%202%20bytes%20size%20%3D%2065538%20bytes
[2]: https://news.ycombinator.com/item?id=39257147It'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.
You could even do this over UDP if you really wanted, just merging a bunch of 1200-byte records together
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.
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.
else if (c.slice(4, 4+4) == "ftyp") f="avif";
And that also leaves out the common things like MX records.