Gaurav Jain

> The code makes sense to me even though I don't have a 100% idea of what's going on 😅 ok so whats happening here is that DNS uses compression...

> in case nothing got changed I did not use this method because things might get a bit complex if any parameter was to change. Let's see what @mhils has...

Sorry for the delayed response @meitinger , I think what you're trying to do [here](https://github.com/mitmproxy/mitmproxy/compare/main...meitinger:mitmproxy:dns-fix?expand=1#diff-aae5ae0afc72a57598bfda9aaf2a6dc9aca959680e07ebb80b318c4233773099R68-R75) is set `_orig_bytes` of a single `ResourceRecord`/`Question` to `None` if any of its attributes was...

> > For example, right now I think we will fail if the compressed message is slightly below the UDP payload limit, but after parsing and re-packing (where we don't...

> I'm just curious, why we shouldn't return unknown RRs as-is If I'm understanding things correctly, consider this example: Say response has 3 records: 1st record is a NS record(known)...

How do I tell the tests to use the updated `mitmproxy_rs`?

> that uses https://docs.rs/hickory-resolver/latest/hickory_resolver/system_conf/fn.read_system_conf.html internally This is available for UNIX only

> I'm curious whether we will run into any issues with overly long records or so, but for now this is a great way forward I don't think we'll run...

Sorry, messed up the commit history a bit while hopping between windows and linux. Should be fixed now

Can confirm that I am able to reproduce this issue Proxy debug ``` mitmdump --set proxy_debug -v [11:51:48.030] HTTP(S) proxy listening at *:8080. [11:51:50.157][127.0.0.1:52917] client connect [11:51:50.157][127.0.0.1:52917] >> Start({}) [11:51:50.157][127.0.0.1:52917]...