help to unblock chia
-
Well for one www.chia.net and chia.net are not the same thing.
$ dig @1.1.1.3 chia.net +short 172.67.44.5 104.22.6.173 104.22.7.173 $ dig @1.1.1.3 www.chia.net +short 0.0.0.01.1.1.3 filters on www.chia.net but not on just chia.net
.2 is also filtering it
$ dig @1.1.1.2 www.chia.net +short 0.0.0.0 -
@johnpoz i noticed that, but am getting exactly the same as you with dig.
If you go to www.chia.net or chia.net in a browser, they both auto goto https://chia.net
with the general settings as 1.1.1.1
https://chia.net workswith the general settings as 1.1.1.2 or 1.1.1.3
https://chia.net does not workwith firefox set to dns over ssl using 1.1.1.3
https://chia.net worksi am really stuck on getting to the bottom of this
-
You sure filtering even works over dot? There was a whole thread about it..
I have not tested it because to me dot or doh is a complete abomination, and without something to encrypt the sni, be it esni or ech trying to hide your dns queries from you isp via dot or doh isn't really doing that. All you end up doing is sending your queries to the 3rd party as well as your isp knowing the fqdn your going to, with always knowing which IP your going to anyway no matter what.
Now in that above thread they said there was some mention of it being enabled - but I have not actually tested it.
Keep in mind that be it you go to chia.net or www.chia.net in your browser at some point your going to get a 301 to redirect you.
Connecting to chia.net (chia.net)|104.22.6.173|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.chia.net/ [following]So your going to have to resolve www.chia.net - which isn't resolving 1.1.1.2 or .3
If your goal is leveraging clouldflare dns for there filtering - then do that. And take doh or dot out of the equation. Browsers don't do dot, they do doh, while pfsense does dot and can not do doh..
Also bringing up your other thread about doing specific forwarding for specific client - I know of no way to do that with unbound. So you either run bind that can do that, and for sure uses different caches even for the different views. Or you run multiple instances of unbound where 1 forwards to filtering, and other forwards to non filtering - and point the clients you want to do what to the respective instance of unbound.
-
@johnpoz I can't say I understand a word you said there m8.
Can you repeat the last part in idiot's English please.Are you saying 1.1.1.2 doesn't work?
But why does it work if I use it in the browser as DNS over SSL? -
@gwaitsi said in help to unblock chia:
But why does it work if I use it in the browser as DNS over SSL?
dot and doh are different - that link was saying that dot doesn't work for filtering, some people suggested it does near the end. But maybe it only works with doh and not dot. Browsers use doh..
If I find some time this morning from real work - I will try and give it a test.
-
@johnpoz would appreciate it
-
Ok suppose to be doing some real work stuff - but this was quick test.. So doing a dot test to 1.1.1.3 filters www.chia.net
user@NewUC:~/tmp$ kdig -d @1.1.1.3 +tls-ca +tls-host=family.cloudflare-dns.com www.chia.net ;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(1.1.1.3), port(853), protocol(TCP) ;; DEBUG: TLS, imported 129 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com ;; DEBUG: SHA-256 PIN: od9obscoXQND56/DikypZrJkXGvbQV5Y61QGfcNitHo= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 ;; DEBUG: SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11574 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; PADDING: 407 B ;; QUESTION SECTION: ;; www.chia.net. IN A ;; ANSWER SECTION: www.chia.net. 60 IN A 0.0.0.0 ;; Received 468 B ;; Time 2021-06-09 08:42:07 CDT ;; From 1.1.1.3@853(TCP) in 26.3 ms user@NewUC:~/tmp$I will try and do a test with doh here in a bit.. got a freaking meeting have to join - arggh ;)
-
@johnpoz what is the meaning in English pls?
Regarding filtering, 1.1.1.3 provides the services for normal users for sure.
If you try any of the search engines and enter variants of porn, etc. no results are returned at all.
This is the ideal behaviour I am looking for, in terms of the family.from the desktop
kdig -d @1.1.1.3 +tls-ca +tls-host=family.cloudflare-dns.com www.chia.net ;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(1.1.1.3), port(853), protocol(TCP) ;; DEBUG: TLS, imported 130 system certificates ;; WARNING: connection timeout for 1.1.1.3@853(TCP) ;; ERROR: failed to query server 1.1.1.3@853(TCP)couldn't find how to install kdig on pfsense
from desktop to pfsense
kdig -d @192.168.2.1 www.chia.net ;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(192.168.2.1), port(53), protocol(UDP) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 22077 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.chia.net. IN A ;; ANSWER SECTION: www.chia.net. 60 IN A 0.0.0.0 ;; Received 46 B ;; Time 2021-06-09 16:06:39 CEST ;; From 192.168.2.1@53(UDP) in 104.2 ms -
@gwaitsi said in help to unblock chia:
ERROR: failed to query server 1.1.1.3@853(TCP)
That means you could not talk to 1.1.1.3 on 853.. Your blocking it most likely.
couldn't find how to install kdig on pfsense
I wouldn't suggest that even if there was a package available somewhere for freebsd.. Unless pfsense/netgate adds that as option.. Installing unsupported 3rd party packages not good idea normally.
-
@johnpoz said in help to unblock chia:
@gwaitsi said in help to unblock chia:
ERROR: failed to query server 1.1.1.3@853(TCP)
That means you could not talk to 1.1.1.3 on 853.. Your blocking it most likely.
correct. because pfsense is the dns server the clients connect to and 53/853 and nat'd to pfsense
unbound is in forwarding with dns over ssl to 1.1.1.3 (1.1.1.1 works) -
What your clients are set to do and what a directed query is doing are different. If your only allowing clients to talk to pfsense that is fine for dns.
My point was it works via talking dot to 1.1.1.3.. So it should be filtered in pfsense... Use the pfsense dns look gui.. What do you get?
And again!! www.chia.net is blocked.. If your using 1.1.1.3 NO your not going to get to www.chia.net - which chia.net is redirect too.. So you have to be able to resolve www.chia.net
Just tested with doh.. And www.chia.net is blocked with 1.1.1.3 as well
user@NewUC:~$ q A www.chia.net @https://family.cloudflare-dns.com/dns-query www.chia.net. 1m0s A 0.0.0.0If you say it works - then your not using 1.1.1.3 or .2 since both of those block www.chia.net
-
@johnpoz so I can confirm from the pfsense dns lookup;
- I get A records for www.chia.net with 1.1.1.1 is used
- I get no A records for www.chia.net with 1.1.1.2 is used
so, in summary;
- that means cloudflare is filtering right?
- but my NAT forwarding of 53 / 853 is not working (because i can bypass with dns over ssl).
i have in the NAT rules
Interface: LAN Protocol: TCP/UDP Source Addr: * Source Port: * Dest addr: !LAN Address Dest Ports: alias = 53 853 67:68 37 123 5351:5357 NAT IP: LAN Address NAT Ports: alias = 53 853 67:68 37 123 5351:5357so what is my solution?
i want the benefit of family which makes sure the kids can't google stuff,
but i will also need some exception. but it is strange i never had a problem till this one site -
Not sure where you got the idea that you could redirect 853 queries?
Simple solution to allow for www.chia.net when your unbound is filtering it, is just create a domain override pointing to 1.1.1.1 for the chia.net.. Now anyone can look that up.. Because unbound will ask 1.1.1.1 for that
Now back to a shane configure of my network blocking all and any doh or dot from anything.. ;)
-
@johnpoz
yes, I see that fixed it. thank you ;-)why am i mistaken in thinking i could trap 853 requests?
p.s. i am no idea of what a dot or doh is. sounds like taking the p.ss ;-)
i will have to do some duckduck'ing -
@gwaitsi said in help to unblock chia:
why am i mistaken in thinking i could trap 853 requests?
You can redirect them sure.. But where you going to redirect them too? And the fqdn and certs are not going to match..
If client is wanting to talk to www.dotdns.tld, and you redirect it to say unbound listening on 853 using what for the cert.. Sure not going to be www.dotdns.tld ;)
So your client if sane should say F that -- someone is mitm my query..
See above where I did the dot query, and certs are involved.
;; DEBUG: TLS, imported 129 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com ;; DEBUG: SHA-256 PIN: od9obscoXQND56/DikypZrJkXGvbQV5Y61QGfcNitHo= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 ;; DEBUG: SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted.You can block it sure.. But redirecting them when the client should and would validate talking to the correct server is not really possible.
While sure you could mitm yourself for a specific dot server.. And the client could be setup to trust the cert your using and think its actually www.dotdns.tld - but what if they try other.dnsdot.tld, etc. etc..
-
@johnpoz point was to trap requests to outside DNS. e.g. android clients, etc.
So i think it is ok, it is breaks no? -
Yeah blocking it is fine.. I do it for both doh and dot.. Dot is easy just block port 853.. But doh can be problematic to block since its just standard 443.
But tricking a client into thinking its talking abc, while its really talking to xyz is way more tricky. Unlike with normal dns over tcp/udp 53.
-
This post is deleted!
