pfSense, Unbound & Netflix = No go...
-
@furom Found what made the difference... :(
My player does not like this to be on;
And yes, it says quite clear that it may break a lot, but worked fine with Quad9 so why suspect it...So... Would this indicate something is not working or how should I interpret it?
-
@furom said in pfSense, Unbound & Netflix = No go...:
But the DNS-rule on netflix network creates no states...
The one to pfsense IP? That would point to devices not using pfsense for dns.. Maybe they using doh?
Even if they are redirecting you should see a state..
-
@johnpoz said in pfSense, Unbound & Netflix = No go...:
Even if they are redirecting you should see a state..
After unchecking the option above it works great again... :) Time fo celebrate with an episode of something I suppose. :)
Would be grand to know if this option should work with Unbound, or is it my player that has a problem with it? It does use the pfSense DNS btw, or at least states that it does...
-
@furom said in pfSense, Unbound & Netflix = No go...:
And yes, it says quite clear that it may break a lot, but worked fine with Quad9 so why suspect it...
Why would you think that would work when you forward.. That is a resolver option.. Forwarding isn't going to use min name - how would that work?
If you are resolving - yeah strict is going to break quite a bit of shit that can tell you for sure..
I don't see how that could work if you were forwarding at all to be honest.. I have never tested what exactly would happen when forwarding.. Well because it would be pointless to try and do qname minimization if you were forwarding..
But I might see what unbound actually does with qname on and forwarding.. I don't see how that is a valid configuration to be honest.
-
@johnpoz said in pfSense, Unbound & Netflix = No go...:
Why would you think that would work when you forward.
I thought I used the Resolver? I only said I fell back on forwarding as I didn't get Unbound Resolving to work initially. Sorry if it was confusing. It has been a bit for for me, but finally works now
-
@johnpoz said in pfSense, Unbound & Netflix = No go...:
I don't see how that could work if you were forwarding at all to be honest..
I wouldn't be surprised if it just "tolerated" it then. I have once set it and then changed to forward-mode after that I suppose, it never complained :)
-
@furom said in pfSense, Unbound & Netflix = No go...:
have once set it and then changed to forward-mode after that I suppose
yeah I would think it forwarder mode it would be ignored.. But moving back to resolver mode it would use it, but strict is going to fail on all kinds of stuff that is for sure.. There is blog about it on cloudflare I think.
If I get a chance later today document what happens when you use when resolving, non strict and then see what it does if switch over to forwarder mode.. Does it send a shit ton of extra queries or just ignore it?
-
-
@moonknight sure - but what is the 853 for... Did you have your clients using dot to talk to unbound? I don't see any point to that on your local network that is for sure.
And the redirect of dot isn't going to work.. Not with any client that actually validates who they are talking to for dot, because that is like one of the important aspects of dot or doh, validation of who your getting your dns from.
Also clients don't really do dot they do doh, so no port 853.
-
@johnpoz
yeah you are right. I probably don't need the DoT (853) rule, since the unbound is handling DoT.
I'm blocking DoH anyways from floating rule.
Thanks, then i can remove the 853 rules from my local networks :)
-
@moonknight said in pfSense, Unbound & Netflix = No go...:
then i can remove the 853 rules from my local networks :)
Sure - while sure you could setup some client on your network to use dot to talk to unbound.. I just don't see the point/value of such a setup.. I mean it is your network, who would be hostile on your network sniffing for your dns traffic? ;)
Now if this unbound was out on the net somewhere, and you wanted to forward your local dns to it via dot then that could make sense.
But redirection of dot would be designed to fail redirection. Because the dot client should validate the cert is for the fqdn or IP the client is setup to talk to.. So for example if suppose to be talking to quad9.dns.net or whatever your unbound sure would not be able to return a cert for that that the client trusted as you being quad9.dns.net..
Now you could actually do that - but how do you know what your client might be wanting to talk to - you would have to be able to generate the correct cert on the fly, and then your client would also have to trust your CA you were signing the cert with, etc.
-
@johnpoz said in pfSense, Unbound & Netflix = No go...:
@moonknight said in pfSense, Unbound & Netflix = No go...:
then i can remove the 853 rules from my local networks :)
Sure - while sure you could setup some client on your network to use dot to talk to unbound.. I just don't see the point/value of such a setup.. I mean it is your network, who would be hostile on your network sniffing for your dns traffic? ;)
Well, maybe my wife or kids
Now if this unbound was out on the net somewhere, and you wanted to forward your local dns to it via dot then that could make sense.
But redirection of dot would be designed to fail redirection. Because the dot client should validate the cert is for the fqdn or IP the client is setup to talk to.. So for example if suppose to be talking to quad9.dns.net or whatever your unbound sure would not be able to return a cert for that that the client trusted as you being quad9.dns.net..
Now you could actually do that - but how do you know what your client might be wanting to talk to - you would have to be able to generate the correct cert on the fly, and then your client would also have to trust your CA you were signing the cert with, etc.
I do use Quad9 DNS servers. I just like to have little bit more control of all the DNS traffics leaving my pfsense.
There is so many devices that have hardcoded DNS, you know, smart thigs, SmartTV, browsers, cell phones etc. I don't see the point why they use hardcoded DNS or DNS over HTTPS... It's my fu...... network
Thanks again for your Informations @johnpoz
