Almost certainly. I've looked at failure reports for several other countries on #DownDetector, and the problem seems to have been limited to the UK. In any case, #Quad9 seems to be up again now.
I've edited my original message, but — no shade — edits take a while to propagate.
Edit: it seems to be working again.
#Quad9 seems to be in trouble:
https://downdetector.co.uk/status/quad9/
Right now, I'm seeing a weird mix of services that still work and others that don't. I'm expecting that to degrade as the afternoon wears on unless they can bring it up again soonish.
Thx @lina for exposing the #Copyrightmafia's #DNS-based #internetcensorship:
https://cuiiliste.de
As for circumvention: Just use #OpenNIC's DNS servers...
The sheer #Zensursula-Style bullshit is the #IllicitActivity! #ISP|s should have no right to interfere with any traffic (except to defend their own infrastructure from getting hacked) unless explicitly requested by customers to do so.
I do wish @ooni would take a look at the CUII blocklist and add that to their #OONIprobe to test for.
@Tutanota @jonah @chillybot
People who know Switzerland have often said that it is a false assumption that privacy is more secure there. Too bad for the services like #Quad9 that have made efforts to establish themselves there.
@quad9dns Only the fundamental non-storage of personal data from the outset and the non-storage of logs can help.
I switched my PiHole upstream DNS from Google to Quad9. Let's see how it goes and if I see any difference.
One less Google service in my house
@earl - I lurked on some of the working group meetings and posted about it occasionally. Some immediate thoughts are also in my timeline. Interestingly, #DNS4EU does not block #Russian news outlets, that are sanctioned by the #EU. Also, the performance on the threat protected service is noticably slower than the unfiltered service. The unfiltered service in en par with #Cloudflare or #Quad9
Hope that helps, have fun with the project!
As of today, #DNS4EU is live. A project that started somewhat of 3 years ago. Now, it's public and live, promising secure and resilient service to #EU citizens, strengthening the #European #cyberresiliency .
More here.
I queried my own domain name out of interest. The EU protective resolver resolves in 340 ms, whereas #Cloudflare and #Quad9 both resolve within 50 ms.
The unfiltered resolution however resolves within 50 ms as well, revealing that the filtering introduces a slight performance penalty.
@quad9dns @rapha3l @marcel @abuse_ch
Also this only applies to the filtered
& secured
#DNS servers.
default filtered DNS by #Quad9
9.9.9.9
149.112.112.112
2620:fe::fe
2620:fe::9
secured quad9 servers
9.9.9.11
149.112.112.11
2620:fe::11
2620:fe::fe:11
unfiltered quad9 DNS
9.9.9.10
149.112.112.10
2620:fe::10
2620:fe::fe:10
See https://www.quad9.net/service/service-addresses-and-features for details.
The unfiltered ones do not filter any results, thus they should only be used for those that i.e. filter their results themselves.
I've always used a non-ISP DNS and I've tried many #DNS providers in the past but I have settled on #Quad9. @quad9dns
I used to just use it via the browser settings (DNS over HTTPS, DoH) but today I decided to install the profile on my #macOS instead.
I'm using the HTTPS (not TLS) option: 9.9.9.11 (#DNSSEC, Threat-Blocking, with ECS).
They mentioned a tool which is quite neat showing DNS leaks: https://github.com/brianshea2/addr.tools
On my Android I use it via #netguard: https://github.com/M66B/NetGuard
#Quad9 hat eine Grafik, die den Einbruch des Internetverkehrs in Spanien und Portugal gestern visualisiert.
Ihre drei Serverstandorte waren scheinbar mit funktionierender Notstromversorgung ausgestattet. Im Gegensatz zu – mutmasslich – diversen Internetanbietern. Wie im Wallis werden da jetzt wahrscheinlich die Notfallszenarien an vielen Stellen nochmals überdacht.
https://mastodon.social/@quad9dns/114416276417809952
Received an email by the #NANOG mailing list in which they raise a pretty concerning thing: Apparently, #Spain started to intercept or nullroute certain IP addresses of #CDN providers. The intent is to fight #piracy during #football matches.
Do the people who pass the list of IP addresses even understand the significance of blocking a bunch of #CDN networks of various providers? Seriously?! It #censors access to tens of thousands of legitimate #websites which is blatantly accepted as a #collateral to help out some shady sports association in their #copyright?
How much shadier can a decision be? Since this is a thing, maybe they can think about taking down entire regions in Spain the next football match?
The amount of collateral damage in the name of copyright is ridiculous. The #EuropeanUnion really has to step-up their game in addressing those concerning developments. I read about multiple such blatant decisions so far. Eyeing at you, #Quad9 and #Sony...
Hmmmm.
Ist das jetzt #ATT die da irgendwie im #Cloudflare 1.1.1.1 DNS-Traffic drin rumfummeln oder ist die Performance vom Cloudflare-Resolver generell so grottig?
Einfach mal nen
while true; do dig @1.1.1.1 $Domain
laufen gelassen.
Die Domain selbst hat nen TTL von 86400.
Der Authoritative NS steht drüben in Europa; d.h. bei ner Query Time von um die 300msec hat er drüben anfragen müssen. - Was mich aber nen bisschen wundert sind die höheren dreistelligen und vierstelligen Werte
;; Query time: 8 msec
;; Query time: 480 msec
;; Query time: 684 msec
;; Query time: 648 msec
;; Query time: 8 msec
;; Query time: 4 msec
;; Query time: 152 msec
;; Query time: 160 msec
;; Query time: 320 msec
;; Query time: 12 msec
;; Query time: 152 msec
;; Query time: 308 msec
;; Query time: 624 msec
;; Query time: 156 msec
;; Query time: 8 msec
;; Query time: 4198 msec
;; Query time: 8 msec
;; Query time: 1340 msec
;; Query time: 24 msec
;; Query time: 8 msec
;; Query time: 12 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 12 msec
;; Query time: 356 msec
;; Query time: 632 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 148 msec
;; Query time: 268 msec
;; Query time: 444 msec
;; Query time: 160 msec
;; Query time: 472 msec
;; Query time: 8 msec
;; Query time: 772 msec
;; Query time: 160 msec
;; Query time: 308 msec
;; Query time: 8 msec
;; Query time: 32 msec
;; Query time: 24 msec
;; Query time: 12 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 320 msec
;; Query time: 36 msec
;; Query time: 640 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 156 msec
;; Query time: 208 msec
;; Query time: 316 msec
;; Query time: 160 msec
;; Query time: 2746 msec
;; Query time: 160 msec
;; Query time: 652 msec
;; Query time: 476 msec
;; Query time: 312 msec
;; Query time: 468 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 12 msec
;; Query time: 8 msec
;; Query time: 1863 msec
;; Query time: 8 msec
;; Query time: 44 msec
;; Query time: 8 msec
;; Query time: 468 msec
;; Query time: 12 msec
;; Query time: 628 msec
;; Query time: 8 msec
;; Query time: 8 msec
;; Query time: 4754 msec
Wenn ich die authoritative NS direkt anfrage gibt's keine wirklichen Schwankungen.
#Quad9 liefert mir das in mehr oder weniger konstanten 8-15ms (~200-300ms wenn sie die Domain noch nicht im Cache haben).
Losing my mind over #DNS bullshit. Seems that DNS servers (#Quad9) return different answers depending on the connection method, with built-in randomness.
dig +tcp <domain> @9.9.9.9 → always correct IP
Anything else, no +tcp or +edns=0, +bufsize=4096 returns either the outdated or the correct IP, less erratic without edns and smaller bufsize.
So I guess I somehow need to d̶i̶s̶a̶b̶l̶e̶ ̶e̶d̶n̶s̶ o̶r̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶e̶ ̶"̶m̶y̶ ̶D̶N̶S̶"̶ ̶t̶o̶ ̶o̶n̶l̶y̶ ̶q̶u̶e̶r̶y̶ ̶v̶i̶a̶ ̶T̶C̶P̶.̶ use a better DNS server.