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

[cookiengineer]

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 <3

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.

[ignoramous]

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 <3

Thanks! :D

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... Do you have a starting point to try to implement this?

I think that DNS parsing going on again in the java-layer is unfortunate because we already parse DNS packets in the golang-layer which actually implements the firewall and the dns stub-resolver.

We're undergoing a rewrite of the network stack, and I intend to cover this case with that rewrite. Btw, thanks for this detailed report, as well.

See also: #3

[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]

Hi, we have a preliminary implementation up in #354 to be released with v053g.

We do not do PTR lookups, but instead simply map from a user-space in-memory DNS cache the outgoing connection to approp resolved DNS name (within the TTL), kind of like a reverseDomainToIP lookup. Of course, this is fraught with errors, especially when a single IP may host several domains (like CDNs / VirtualHosts), which PTR records can handle just fine. Ideally, we'd avoid DNS PTR lookups altogether, but instead rely on something more fancier inspired from DNS ALG that we are looking to implement with #270

[ignoramous]

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 does Signal (over 1.1.1.1), Gamooga and InMobi SDKs (over TCP/53 to 8.8.8.8 instead to bypass DNS based blockers that leak DNS over TCP; ref), Telegram (over DoH).

For some connections, WhatsApp and Instagram also bypass DNS and connect to static-IPs. WhatsApp, in particular, also does its own time-sync (NTP).

---

In v053g (due in a week) we are introducing two new settings:

Trap all packets on port 53 coming into the tunnel and re-route it to a user-set DNS endpoint. These would appear in Network Logs with label DNS proxied.

Prevent connection to IPs not resolved by user-set DNS.

• This blocks Telegram from connecting to IPs it resolved over custom DoH,
• Blocks all connections made to IP addresses that are resolved by Android's DoT (Private DNS),
• Blocks Firefox and Chrome from connecting to IPs resolved by built-in DoH,
• Blocks Qualcomm components / WhatsApp / Instagram (if your Android has them) from communicating to preset static-IP addresses.

These appear in Network Logs with label DNS bypassed.

---

Though we do not do PTR lookups for reverse resolution, the current implementation may be sufficient enough for what you're looking for @cookiengineer? If so, I'd resolve this issue. If not, if you feel PTR lookups are absolutely required (since they may handle edge-cases better), let me know. Note, we are also working on #270 to ship by end of this year (hopefully).

Thanks.

[ignoramous]

A couple screenies from v053g

dns proxied

dns bypassed

reverse domain-to-ip

[ignoramous]

We have instead impl something very similar to RFC3089, sending RFC6598 IPs (100.64.0.0/10) or (pseudo) RFC6052 IPs (64:ff9b:1:da19:0100::/80) instead of actual IP answers for A, AAAA, SVCB, HTTPS records (not touching those records if in the additional section but do handle if they are part of SRVs or CNAMEs), and then late bind these to the actual IPs underneath the covers (IO proxy in case of TCP, packet rewrite in case of UDP). This helps us map a DNS request to one specific app. I see both TCP and UDP work without much fuss, so far.

I believe this impl (which we call ALG, which took months to perfect) is better than initiating another query for PTR records (which aren't setup for that many domains, are they?).

@cookiengineer what's your opinion? Do you think PTR lookups are still warranted despite ALG (if so, I'll keep this bug open)?

[ignoramous]

Hi @cookiengineer; do you find the current association between domain names and IPs in Rethink (screenshot), good enough? If not, we'd want to keep this feature request open to impl PTR lookups.

Also, all ears about any other feature requests you may have.

[ignoramous]

(no response)

(all: feel free to re-open)

[noe-578]

This would be cool to have. e.g., GPS makes a bunch of requests to supl.google.com, *.pool.ntp.org and 1.ssiloc.com. On the "Most contacted providers" I just see a bunch of IPs which I had to track down manually.

This would be an awesome feature, tracking an IP back to a domain.

[noe-578]

(I can't reopen, please reopen!)