Will PFB handle ODOH? iOS 15.1 and Monterey Hide IP address bypassing PFB DNSBL
-
@bmeeks Right Apple HW is not cheap stuff though and I am sure the cost of "free" services are built in. But Apple does give a LOT away at no extra charges, think iMessage and millions of FactTime calls during Covid (continuing).
As to the providers, from what I read in the Cloudflare blog (and other ODOH explanations I found) no one entity can match the request to who made it. If you find otherwise please let us know. Thanks again.
-
@mariog I think they are mutually exclusive. Hide your IP means some kind of proxy, with forwarding of DNS to some service provider. There is no resolving to root servers, and no DNSSEC. No getting 'the answer' from an authoritative server, you have to trust whatever the DNS server is doing. Pick your poison.
For me, I see no real 'hiding', someone somewhere sees you, whether it's the company providing the proxy service, or the root servers if resolving. Maybe in a restrictive country you would rather use a proxy service, but me, seeing my DNS is not a big deal, it's better for me to resolve with DNSSEC to authoritative servers.
I just don't see the point of it, from where I sit. The proxy sees you.
-
@mariog said in Will PFB handle ODOH? iOS 15.1 and Monterey Hide IP address bypassing PFB DNSBL:
I am currently running pfsense 2.4.5 and the old pfblocker not devel. I plan to upgrade once I get a new machine since I don't want to make any changes now (family critical time).
It should be the other way around ;) First the 'security' related updates like your pfSense, then stuff like pfBlocket-devel (which isn't "devel" any more for more then a year - the "-devel" in the name is just maintained so the upgrade path doesn't beak.)
Then, if needed, upgrade your iOS and/or any OS.Btw : didn't even know 15.1 was already out. I'm still on 14.x .... as I'm noting using a recent Apple device (iPhone X and older iPad).
If you have a very recent iPhone 13, then ok, you'll be needing 15.x probably.I read PFB may be able to handle normal DOH but don't know
PFB can do many things, doesn't have MITM capabilities. So it boil down to "is the (DNS) IP listed, and so yes, it will get blocked.
If some OS/device wants to uses "DNS over TLS" then pfSense, and any other hop on the path that is not the destination, can not see the info transmitted.
Blocking this traffic is the only solution, and you still have to hope that the device will fall back to the classic DNS operation = asking the upstream router = pfSense to do the DNS resolving. If they doesncan't / don't, then it' game over for that device.
"pfBlockerNG" becomes a tool for users that want to use it, like an opt-in - users that want to change their default device settings so they can benefit from local network services like pfBlockerNG.The rest will get all the adds - and see that 'forbidden' site, etc. And we as pfSEnse admins can't do anything about it.
That is : If you don't want that X sees Y on the Internet, then don't give X access to your network. That way, the issue isn't yours any more. ( we all know that Y will see what he wants so see, so why trying to forbid something ? Like : "Here is the newest Tesla, but please, not over 70 Miles please ... - Yeah ..... right :;" )I suspect that Apple might force its devices to use some 'remote' DNS, as, and they are right, it's 'better' for the end user to not rely on unknown DNS resolvers. Apple want to protect the users of their devices (I guess). We, as admins for our pfSense, won't be able to see any DNS traffic any more. As we can't see web browser traffic since "https" became a thing.
We can always set up our own (!) devices to trust a local proxy, but devices that are not under our control can ..... not be controlled to what they see any more.Keep in mind, that from a users point of view, "local router admins" as we are, can also have 'bad' intentions with the browser history, DNS lookup etc of our local users.
The button @keyser showed is more a slide button that says : "do you trust the local router devices" If you don't, you can use "TLS" all outgoing traffic.What also happens in the future : the captive portal, as it is implemented right now, will fail, as it is based on classic DNS operations, not some DOx trick.
The "Captive portal 2" (DHCP based) is already proposed. -
@gertjan Thanks to all for the replies. After much searching it is with regret I found there is probably never going to be a way to "have your cake and eat it too"! At least anytime soon.
Since the source web page has URLs for ADs, and ODOH causes encryption before going to PFBlocker, there is no way to stop ADs using DNSBL. That's a bummer because DNSBL stopped did not require a DNS request to be made. So you eliminate the DNS request for the AD as well as the ADs response.
If you use PFBlockers IP blocking of ADs, you have to allow the AD URL to be looked up before blocking it. Yes it cuts down on ADs, but adds a DNS lookup of the AD URL, and a lot of lookup time in PFB.
I will stick with PFSense doing DNS via unbound, and let PFB see ADs. But crossing my fingers someday someone will figure out how to make cake we can eat.
-
Most DoH DNS servers are known, which means they are listed !
So, if a LAN clients insists on using one of these, it will hit 'the wall' and finally fall back to the basics : classic DNS to the local gateway == pfSense. There, the resolver thus pfBlockerNG will do it's work as usual. -
@gertjan I think we're talking apples and oranges. ODOH adds the "Oblivious" layer to DOH, also I don't know what you mean by "listed". When you say "classic DNS", I am pretty sure that means we lose IP Privacy which is not any different that what I have now.
If anyone who has an Apple device that has Hide IP Address On, AND has PFBlocker blocking ADs on that device using DNSBL, please let us know how it was accomplished. That would be a miracle. It would be a lot better than blocking IPs after they are resolved, which will add more response time compared to DNSBL.
Thanks again to all responders and hope this issue gets solved someday.
-
Since Monterey upgrade, I'm now seeing two DoH servers being hit :
-
mask.icloud.com
-
mask-h2.icloud.com
Both being handled by "Oneoffdallas_DoH" feed.
By disabling ad-hoc options on Safari, it seems to "solve" the issue.
-
-
@huskerdu No it does not solve the issue I describe. That is something else. Thanks for trying.
-
@mariog said in Will PFB handle ODOH? iOS 15.1 and Monterey Hide IP address bypassing PFB DNSBL:
also I don't know what you mean by "listed"
Listed (known) in pfBlockerNG :
-
@mariog I run Monterey, 7 y.o. iPad w/ 15.1, iPhone X w/ 15.1
My devices are set to hide IP from trackers. I am not using ipV6, not sure if that matters.
My devices use Quad 9 for dns (via pfSense). I do not use dnssec. pfBlocker is at 3.1.0 and DNSBL runs in unbound python mode.I get a few ads, but rarely. I mostly get popup's complaining that I'm blocking ad's. If I do see ad's I figure it is because I do not have a lot of feeds defined in DNSBL. Not always, but on occasion I do notice a bit of latency in Safari on iPad or Mac (rarely use iPhone at home, screen is too small to be useful). If 10 sec or so goes by w/o a page load I do a refresh and that usually brings a page up. I have not noticed if ad's are on the page when this happens but now I will pay attention.
I just clicked around a site I never go to and did not see any ads and all the pages loaded very quickly. That site was cnn so I imagine it's loaded with ads.
I don't know if this is helpful or not, I'm not that knowledgable about this topic.
