EU want to control everything and 5 eyes watching you out!
-
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
I'd specifically like to know if it's possible to run a DNS server on your own local network, _that actually has the zone information of the root DNS servers(for .com,.net,.org) domains.
When you use unbound "as it should be" then the big 13 are already hard coded into the binary. The article calls the the root.hints file - the falmous 'bind' resolver has actually such a file in the config directory.
Their host names and IP's (see table on the wiki page) never change.Maybe it's possible to create your own root server locally. All it contains is a list with all the known "official" Top Level domain servers - the ones that know all about com. org. net. etc etc. About 730+300 of them. As the article states, root server access is rather rare.
TLD access happens all the time. As thousands of domain names are created every second, you'll be having a hard time keeping the content of all of them synced up locally.
TLDs are, I guess copy-cloned all of the Internet. For example, the com. TLD has several (like many) clones on the Internet. The root server will give you probably one that is close to your 'WAN' IP.
The job of the TLD is : it gives your resolver a list with all the domain names servers know for a domain name. There are always at least 2 of them.
These domain name serves will give you the final answer to the question : what is the IPv6 of www.facebook.com.
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
I want it to have duplicate information that the big internet DNS servers have, but I'd like that information locally on my DNS server.
Oh... that is exactly what unbound does. It caches every request ever made ones, and keeps it into the local (unbound pfSense) local DNS cache.
When you check
soon to be expired DNS info will get refreshed when the TTL goes to zero.
So, ones you've asked www.facebook.com and the IP was obtained, the next request, later on, will not need any 'outside' interaction.
So, basically, you only have to wait ones for a DNS request to be completed. Afterwards, the info will be avaible locally forever.
One golden rule : don't (have) unbound get restarted often
Btw : other, non local DNS resolvers, like the DNS servers of your ISP, or the commercial ones, are not needed anymore. That said, everything is done so people believe they need them .... because (private) DNS info is a real cash cow.
-
@Gertjan Than why, when I use pfSense Unbound in default state with default options can not reach some sites they are blocked. It mean my ISP block them on DNS level?So unbound anyway asking some info from my ISP?Is it possible to bypass this without set third party dns in general settings and use Unbound in default state not as dns forwarder?
-
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
Than why, .... my ISP block them on DNS level?
Why they do this .... and lets go one step lower : why did you chose this ISP, is something I can not know.
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
can not reach some sites
What some sites ?
What happens do you see when you dig the info ?
Example :[24.03-RELEASE][root@pfSense.bhf.tld]/root: dig www.facebook.com +trace +nodnssec ; <<>> DiG 9.18.20 <<>> www.facebook.com +trace +nodnssec ;; global options: +cmd . 52505 IN NS e.root-servers.net. . 52505 IN NS a.root-servers.net. . 52505 IN NS i.root-servers.net. . 52505 IN NS g.root-servers.net. . 52505 IN NS k.root-servers.net. . 52505 IN NS m.root-servers.net. . 52505 IN NS h.root-servers.net. . 52505 IN NS l.root-servers.net. . 52505 IN NS f.root-servers.net. . 52505 IN NS b.root-servers.net. . 52505 IN NS c.root-servers.net. . 52505 IN NS d.root-servers.net. . 52505 IN NS j.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. ;; Received 844 bytes from 2001:dc3::35#53(m.root-servers.net) in 312 ms facebook.com. 172800 IN NS a.ns.facebook.com. facebook.com. 172800 IN NS b.ns.facebook.com. facebook.com. 172800 IN NS c.ns.facebook.com. facebook.com. 172800 IN NS d.ns.facebook.com. ;; Received 288 bytes from 192.41.162.30#53(l.gtld-servers.net) in 28 ms www.facebook.com. 3600 IN CNAME star-mini.c10r.facebook.com. ;; Received 74 bytes from 185.89.219.12#53(d.ns.facebook.com) in 39 msBtw :
+trcae because I want to see what happens.
+nodnssec because I don't want to see all the DNSSEC stuff, something that facebook.com doesn't support (as they don't mind being spoofed - or something like that)You can clearly see the initial 'big 13' listed.
Dig (bypasses unbound completely) chose one of them :Received 844 bytes from 2001:dc3::35#53(m.root-servers.net) in 312 ms
which is quiet incredible : m.root-servers.net is in Japan - and me in France
The answer from m.root-servers.net was a list of TLDs that handle "dot com".
Dig chose
;; Received 288 bytes from 192.41.162.30#53(l.gtld-servers.net) in 28 ms
and l.gtld-servers.net gave me the list of the facebook.com domain name servers.
Di chose;; Received 74 bytes from 185.89.219.12#53(d.ns.facebook.com) in 39 ms
and d.ns.facebook.com gave me back a CNAME :
www.facebook.com. 3600 IN CNAME star-mini.c10r.facebook.com.
From there on, the request wasn't finshed yet.
As dig default to asking for an A (IPv4) record, it will now start to interrogate the domain name servers of facebook (the ns.facebook.com servers)
Likedig star-mini.c10r.facebook.com +trace +nodnssec Aand this time no need to get for the root servers (the asnwer was cached - but dig digged anyway as it bypasses unbound) neither the TLD (same thing) so it (unbound) would go directly to the facebook domain servers to obtain :
star-mini.c10r.facebook.com. 60 IN A 163.70.128.35 ;; Received 72 bytes from 129.134.30.12#53(a.ns.facebook.com) in 21 msThese request use mostly UDP, maybe some TCP, and go to remote DNS servers using port 53.
An ISP could do whatever it wants with your traffic, true.
Maybe they don't want you to visit facebook.
Seriously ?And, you are using a VPN, right ? So your ISP can't block anyting as they can't 'see' what you do.
And that rules out your ISP.A native, original, no thrills, no gadgets (so no VPN, no forwarding, no pfBlockerng, no squid or amavis, nothing) clean pfSense will work just fine.
An example : you saw the recent N#rdVPN thread on this forum ? How this VPN decided to completely f#ck up your DNS requests ? After all, they also discovered that your DNS data is worth big €/$ so they intercept your DNS, and they did a bad job doing so.
For the record, lets repeat it again : people are actually paying for this VPN punishment.@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
Is it possible to bypass this without set third party dns in general settings and use Unbound in default state not as dns forwarder?
That is the defaut setup.
unbiound uses the root servers, and doesn't care about the DNS upstream ISP router - if your pfSense using DHCP on its wan. pfSense doesn't use (it throws it away) the DNS you got from your ISP.
pfSense doesn't need you to use any forwarder.
pfSense / unbound resolves out of the box. And doing so, it can give you a nice bonus : if DNSSEC is supported, it will use it.Just be aware : the classic DNS resolving goes out of the internet non encrypted.
So : when will the original DNS system, as it exist since 1970 ? - use TLS ?
The question has been asked many times already (fire up Google ans check yourself).
Answer : probably never. because : basic UDP and TCP DNS traffic is very small, most often less then one internet packet. TLS needs "one 1000" more "CPU" resources, and way more bandwidth.
Btw : 100 times more resouces also means 1000 times more energy needed : nice, DNS is now safe, and not free anymore.
Current infrastructure isn't ready yet for the "all TLS". -
@Gertjan said in EU want to control everything and 5 eyes watching you out!:
Why they do this .... and lets go one step lower : why did you chose this ISP, is something I can not know.
This is not only my ISP, this law going by whole EU, for example russian.rt.com!
-
@Gertjan said in EU want to control everything and 5 eyes watching you out!:
What some sites ?
What happens do you see when you dig the info ?; <<>> DiG 9.20.2 <<>> www.russian.rt.com +trace +nodnssec
;; global options: +cmd
. 86361 IN NS d.root-servers.net.
. 86361 IN NS e.root-servers.net.
. 86361 IN NS f.root-servers.net.
. 86361 IN NS g.root-servers.net.
. 86361 IN NS h.root-servers.net.
. 86361 IN NS i.root-servers.net.
. 86361 IN NS j.root-servers.net.
. 86361 IN NS k.root-servers.net.
. 86361 IN NS l.root-servers.net.
. 86361 IN NS m.root-servers.net.
. 86361 IN NS a.root-servers.net.
. 86361 IN NS b.root-servers.net.
. 86361 IN NS c.root-servers.net.
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 1 mswww.russian.rt.com. 1 IN A 10.42.254.3
;; Received 70 bytes from 170.247.170.2#53(b.root-servers.net) in 0 ms
I did set unbound default option and did to pass traffic without VPN and result cannot reach this site and a lot of other sites!
pfSense plus 24.11 on Topton mini PC
CPU: Intel N100
NIC: Intel i-226v 4 pcs
RAM : 16 GB DDR5
Disk: 128 GB NVMe
Brgds, Archi -
@Gertjan said in EU want to control everything and 5 eyes watching you out!:
if your pfSense using DHCP on its wan. pfSense doesn't use (it throws it away) the DNS you got from your ISP.
Not clear , do I need to set WAN dchp or static? Because any of these 2 options working for me!
-
Is that so ?
Why not asking some one else to test :
Verdict :
https://www.zonemaster.net/en/result/93a5d5b513f81ccbrt.com exists.
russian.rt.com doesn't. Even rt.com doesn't announce it. Or there are geo restrictions happening.Try again with a (VPN) IP in Moscou ?
dig russian.rt.com +trace +nodnssecJust .... time out. For some reason "rttv.ru" domain names serves won't give me an answer.
What was it that you say ?
Oh, yeah ...EU want to control everything ....
Right.
Because dot ru domain name servers are in Europe now ? -
@Gertjan So it mean without VPN and/or third party dns provider impossible to reach this site?Because tried to pass all traffic over VPN and use Unbound in default state cannot reach this site and only set to third party DNS provider in general settings assist me to get this site. I'm really mad. If use all time VPN have bufferbloat and limiters don't work as expected for gaming.
-
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
Because tried to pass all traffic over VPN and use Unbound in default state cannot reach this site
If "all traffic" goes out over the VPN connection, then this included DNS requests initiated by unbound.
This means that the dns root servers, the TDL servers and the domain name servers will see the VPN end point IP as the requesting IP.
This can make connection possible that didn't work before.But, and we always knew it, and now we are sure : the Russians are not stupid.
As the Europeans, the Americans, the Chinese etc etc, every knows all the VPN end point IPs. So, if a DNS request was reaching a Russian domain name server, it knows that it comes from an VPN IP. And these are (check Russians recently adopted laws) now refused.
So you need to use plan B.
Do not use a main stream commercial VPN ISP (actually, never use them anyway, as it is such a BS).
Go contact a person in Russia with an ordinary internet connection using an ordinary Russian ISP.
Ask him if you can set up a VPN server on his equipment.
From now on you use a this Russian IP, like all the Russians.
Use this VPN end point and ..... Russian sites are now all ok for you.
Be aware : be careful with what you do with this VPN connection. If you 'do' something with that IP that doesn't please the locals, they won't knock on your door, but your Russian friend's door. The Black Helicopter scene.
Consequences can be, how to say, pretty huge, not like here in Europe (I presume of course).
Be ware that a incoming VPN connection - from your place to some Russian ISP 'civilian' as the end point, can be detected.Btw : I used the word Russia and Russian here as an example.
But it could be France and frenchmen, or China and Chinese. Take your pick. -
@Gertjan I do think that is blocking by Russia. Because i can get other not political sites if use VPN( and even without VPN). I think EU is blocking. But don't understand how it's working. If even i set in unbound "outgoing network interface" to go over VPN anyway cannot reach some sites. Only assist to set dns resolver in forward mode and set third party DNS provider as cloudflare for example which do not filter any dns request.
-
@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
I think EU is blocking
You have a VPN, right ? So there is no reason to "think", you can test for yourself.
Why wait ?
Fire it up pointing to Ankara (Turkey) or, dono, Cairo (Egypt) or Bhanka (Bangladesh) and try again.
It still doesn't work ? You need to keep on looking why, but you've just excluded 'EU'. Except if you believe that your VPN can be MITM'ed.
It does work ? Then you still do not have a proof it was 'EU' (blocking) : it could be the VPN end point that was accepted, and not the previous one you used.I'm not implying EU doesn't block things. They probably are.
We lost the piratebay.com remember ? :)@Antibiotic said in EU want to control everything and 5 eyes watching you out!:
cloudflare for example which do not filter any dns request.
cloudflare probably accepts all DNS request.
But do they have access to "everybody" and "everywhere" ? So, this boils down to : do you get an answer for "everybody" and "everywhere" ?
You could rephrase that to a simple : you - and me - are always filtered.
