[Enhancement] Integrate Domain (PTR lookup) for IPs in Network Log

Hey,

first off: this is an amazing app! I discovered it around a week ago and this is such a nice concept, I really like it ❤️

I found myself using termux a lot of times, and doing a dig -x <IP> in order to find out what kind of IPs those were, and what kind of domain points to them in order to find out which webservice the App(s) are talking to.

In the case of WhatsApp, for example, I disabled Google Analytics via AppWarden and wanted to make sure that those servers are not being talked to. WhatsApp always does DNS requests internally with a statically set DNS (8.8.8.8 and 8.8.4.4 so they use dns.google) and I’m kinda unsure whether or not this leads to the App working their way around DNS blocking.

So yeah, as WhatsApp also has a huge cluster in various IP ranges, something like a Domain (if it could be resolved via PTR query) would be very nice, as it helps users to find out which services are related to the App.

It probably would lead to enhancing the DnsPacket implementation in order to support more DNS types - as the record data encoding for PTR differs from A/AAAA.

PS: Do you have a starting point to try to implement this? I’d love to contribute, though my time is limited to the weekends (due to my job forbidding to work on Open Source at work hours) and I’m currently building my own Web Browser - so it might take a while for me.

[cookiengineer]

If you need inspirations for it, I lately implemented a DNS parser that is namewreck safe (stack overflow/buffer overflow attacks by abusing message compression pointers): https://github.com/tholian-network/stealth/blob/X0-DNS/stealth/source/connection/DNS.mjs

I had to implement it in node.js in my case; and there weren’t really any DNS parsers available that were implemented in a spec compliant way. I skipped lots of flags for DNS packets (authorative answers, TTL etc.) because most ISPs that I tested it with actually override those values anyways - so they’re kind of useless in the sense of trusting them to be correct.

As vodafone (my ISP) is hard-blocking the port 853, I am currently implementing the RFC 8484 with the wireformat that’s being sent as base64url encoded data (because they can’t block port 443).

DNSSEC support is a different story, I still believe there’s a potential attack surface with namewreck to fake DNSSEC cookies (aka abusing a buffer overflow to shift parsing context) - but haven’t gotten around to it yet.

[ignoramous]

A couple screenies from v053g

dns proxied

dns bypassed

reverse domain-to-ip