DNS - Unable to reverse lookup internet address

johnpoz

@michmoor said in DNS - Unable to reverse lookup internet address:

But why isnt pfSense resolving for LightSquid

Not sure, I don't use proxy - haven't used proxy on my home network since I had 2 teenage boys in the house ;) You know what sort of shit they were looking for hehehe, best way to block that sort of thing was with proxy back in the day.. If had to do it today, prob just use dns blocking.

Proxies can be useful if you want to block stuff via a full url, say https://www.somesite.tld/otherthing, but you did want to allow say https://www.somesite.tld/allowedthing/whatever

But from an educated guess is why its not working, is the mechanism that tries to resolve it is asking for an A on an IP, which there isn't normally ever going to be a A record for that..

michmoor

@johnpoz said in DNS - Unable to reverse lookup internet address:

Not sure, I don't use proxy - haven't used proxy on my home network since I had 2 teenage boys in the house ;) You know what sort of shit they were looking for hehehe, best way to block that sort of thing was with proxy back in the day.. If had to do it today, prob just use dns blocking.

LOL. So i got my 11 year old, 8 and 4. So not there yet but the days are flying by. I'll ping you for Squid advice in the next few years. haha.

I would use DNS blocking buttttt. Squid at least tells me where everyone is going. Funny enough i did had to block some programming..Roku Kids something. Wife did not want them watching it so i went right into Squid reports to find that domain and blocked it. So it did have a good use case there.
Also you got squid guard so i can be more targeted in which device i want to really cut off at the knees.

stephenw10

Works OK here:

[23.05.1-RELEASE][admin@4100-2.stevew.lan]/root: dig -x 17.253.27.202

; <<>> DiG 9.18.13 <<>> -x 17.253.27.202
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;202.27.253.17.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
202.27.253.17.in-addr.arpa. 43122 IN	PTR	uschi5-vip-bx-004.b.aaplimg.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Aug 22 17:09:05 BST 2023
;; MSG SIZE  rcvd: 100

What do you have lightsquid set to use for name resolution?

michmoor

@stephenw10
I really dont remember ever running into this problem using LightSquid. It always resolved even apple domains.

michmoor

@stephenw10
This is the weirdness im talking about.

Looking for the pointer record and this is what i get on my Ubuntu machine.

michael@netadmin:~$ dig -x 17.248.191.170

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> -x 17.248.191.170
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37250
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;170.191.248.17.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
17.in-addr.arpa.        3453    IN      SOA     usmsc2-extxfr-001.dns.apple.com.                                                                                                                                    hostmaster.apple.com. 2010133180 1800 900 2592000 7200

;; Query time: 92 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 22 15:32:12 EDT 2023
;; MSG SIZE  rcvd: 134

When i try to lookup via pfSense ..nothing.

Then there are entries that do have a PTR record and yet the LightSquid Reporting doesnt put the DNS name. Example

 dig -x 31.13.65.52

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> -x 31.13.65.52
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;52.65.13.31.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
52.65.13.31.in-addr.arpa. 557   IN      PTR     instagram-p3-shv-01-atl3.fbcdn.net.

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 22 15:39:22 EDT 2023
;; MSG SIZE  rcvd: 101

Whatever is going on here , between Squid choosing a IPv6 path [see screen shot in previous thread] and its inability to do reverse DNS , this is all related. Something is probably misconfigured but i cant figure out what it is.

johnpoz

@michmoor said in DNS - Unable to reverse lookup internet address:

When i try to lookup via pfSense ..nothing.

you do understand not all IPs have ptr records right?? It is the responsibility of who owns the IP space to create the records, not everyone does..

That is telling you there is no record specific for that IP.. but that that NS is the SOA (source of authority) for the network of anything that starts with 17.x.x.x

Maybe the phone directly connected to an IP vs asking the proxy go to www.something.tld that it would resolve to an IP?

Normally with a proxy the client asks the proxy hey go to something.whatever.tld, and the proxy looks it up and goes to that IP. If the client isn't specifically asking the proxy, say a transparent proxy and the client looks up the IP of the fqdn it wants to go to - then it would just try and go to the IP, and the proxy being a transparent proxy, etc. would just go there for the client, etc

NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
Organization:   Apple Inc. (APPLEC-1-Z)
OrgName:        Apple Inc.

Apple owns all of 17.x.x.x - if they don't want to create PTR records for every IP in the 17.x.x.x that is up to them.

But they do have PTRs for some of the IPs in that space

;; QUESTION SECTION:
;10.176.47.17.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
10.176.47.17.in-addr.arpa. 43200 IN     PTR     usmsc2-extxfr-001.dns.apple.com.

;; QUESTION SECTION:
;2.170.57.17.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
2.170.57.17.in-addr.arpa. 3600  IN      PTR     mx-in-vib.apple.com.

They seem to have only created PTRs for the IPs they want to create them for, or where it make sense too - ie NS and their Mail servers, etc.

michmoor

@johnpoz I hear what you're saying John but the problem is that when there are PTR records lightsquid for some reason isnt using it.
Example below. There is a PTR in the answer section.
Example

 dig -x   17.253.27.202

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> -x 17.253.27.202
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;202.27.253.17.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
202.27.253.17.in-addr.arpa. 43200 IN    PTR     uschi5-vip-bx-004.b.aaplimg.com.

;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Aug 22 17:09:00 EDT 2023
;; MSG SIZE  rcvd: 100

johnpoz

@michmoor why do you think lightsquad would look up PTRs?

When a proxy is set to explicit, ie the client points to it - the client should be asking the proxy hey I want to go to www.something.tld, and the proxy would lookup what IP to go too.

Explicit clients shouldn't be going to IPs directly, or asking the proxy for an IP, unless the client actually either looked up the fqdn to the IP before which it shouldn't if it has explicit proxy set, or something is using an IP vs a fqdn?

None of that really has anything to do with lightsquid trying to lookup a PTR.. its just logging where a client asked to go - if you asked to go to 1.2.3.4 be it you specifically asked the proxy to go there, or the proxy intercepted the traffic via transparent settings and went there on the behalf of the client.

michmoor

@johnpoz My understanding is that pfSense resolves the IP address to hostnames. Theres a setting for that in Squid Proxy Reports.

johnpoz

@michmoor I believe that is for clients IPs.. I don't currently have squid or squid reports or anything installed, guess I could to take a look. But anything you google for squid PTR all comes up talking about the client IP.

from back in the day, when I ran proxies for living ;) we almost always blocked direct IP access, and only specific ones were whitelisted. Not sure why a proxy would want to look up PTRs when you normally block direct IP access, etc. ;)

But for clients, you could use client names in rules that allow, deny etc. So since client IPs might change you might want to do ptr on client IPs to know if its specific client based on its name.