"Die CUII gibt auf." Huh. Krass! Da sieht man mal, wie sehr sich etwas Mut und Courage lohnen können - und auch dass Einzelne etwas bewirken können!
Kontext: 2024 veröffentlichte eine damals 17–Jährige die eigentlich "geheimen" Sperrentscheide von Websites der privat organisierten und nicht demokratisch legitimierten "Clearingstelle Urheberrecht" (CUII),
ein Zusammenschluss von Urheber.innen und Providern. Nun soll es wieder Gerichtsentscheide für Sperren brauchen.
https://netzpolitik.org/2025/die-cuii-gibt-auf-fuer-netzsperren-braucht-es-jetzt-einen-gerichtsentscheid/
Since DNS is on today I should note if you're a Splunk shop, the DNS data model in Enterprise Security does not include the field for TXT record values, you need to add that manually.
Then you can do high-fidelity detections such as length and base64 with conversions looking for code.
DNS TXT isn't just for malware, C2s and exfil. It can be fun too!
(Resolve-DnsName -Type TXT run-dns.never.watch).Strings | Sort
(Resolve-DnsName -Type TXT maze.never.watch).Strings | Sort
(Resolve-DnsName -Type TXT qr.never.watch).Strings -replace '#','█' | Sort
··⧸··⧸.never.watch
Ready to experience effortless #DNS management? Elevate your #domain and DNS management with automation! In this video, you'll learn how to leverage Infrastructure as Code (IaC) using #Terraform and #DNSimple to efficiently manage domains, DNS zones, and records at any scale.
https://youtu.be/b9_MnHLJlAs
Hackers exploit a blind spot by hiding malware inside DNS records https://arstechni.ca/hs9B #domainnamesystem #Security #malware #Biz&IT #DNS
We're curious ...How many IP addresses do you have in your recursive resolver list?
Hackers exploit a blind spot by hiding malware inside DNS records - Hackers are stashing malware in a place that’s largely out o... - https://arstechnica.com/security/2025/07/hackers-exploit-a-blind-spot-by-hiding-malware-inside-dns-records/ #domainnamesystem #security #malware #biz #dns
Meine Datenschutz und Privatsphäre Übersicht 2025, für alle
als PDF Datei:
https://cryptpad.digitalcourage.de/file/#/2/file/G5H5fsq35WPOoSWzEW23dHEG/
#DSGVO #TDDDG #unplugtrump
#Datenschutz #Privatsphäre #sicherheit #Verschlüsselung #Adguard
#encryption #WEtell #SoloKey #NitroKey #Email #Cybersecurity #Pixelfed #Massenűberwachung #Leta
#Google #Metadaten #WhatsApp #Threema #Cryptpad #Signal
#Hateaid #Cyberstalking #Messenger #Browser #Youtube #NewPipe #Chatkontrolle #nichtszuverbergen #ÜberwachungsKapitalismus #Microsoft #Apple #Windows10 #Linux #Matrix #Mastodon #Friendica #Fediverse #Mastodir #Loops #2FA #Ransomware #Foss #VeraCrypt #HateAid #Coreboot #Volksverpetzer #Netzpolitik #endof10 #OpenAndroidInstaller #Nobara
#Digitalisierung #FragdenStaat #Shiftphone #OpenSource #GrapheneOS #CCC #Mail #Mullvad #PGP #GnuPG #DNS #Gaming #linuxgaming #Lutris #Protondb #eOS #Enshittification
#Bloatware #TPM #Murena #LiberaPay #GnuTaler #Taler #PreppingforFuture
#FediLZ #BlueLZ #InstaLZ #ThreatModel
#FLOSS #UEFI #Medienkompetenz
Unbound 1.23.1 in now available. This security release fixes the Rebirthday Attack CVE-2025-5994.
The vulnerability re-opens up #DNS resolvers to a birthday paradox, for EDNS client subnet servers that respond with non-ECS answers. The #CVE is described here:
https://nlnetlabs.nl/downloads/unbound/CVE-2025-5994.txt
We would like to thank Xiang Li (AOSP Lab, Nankai University) for discovering and responsibly disclosing the vulnerability.
https://github.com/NLnetLabs/unbound/releases/tag/release-1.23.1
After a long and sometimes complicated route, the work on #DNS #privacy at the #IETF comes to an end https://mailarchive.ietf.org/arch/msg/dns-privacy/Lc1pvUnkaJOsbQJgA6WEY-xdhUs
A lot of work done, and real progress (QNAME minimization is now widely used, and DoT/DoH protect a lot of DNS traffic).
La meilleure synthèse technique sur cette panne, tous les détails : https://anuragbhatia.com/post/2025/07/cloudflare-dns-outage/ par @anurag
#BGP #DNS
« Cloudflare 1.1.1.1 Incident on July 14, 2025 »
Perhaps it’s time to return to DNS’s original distributed design.
https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/
Just a quickie from one of our @DomainTools researchers today that I know @cR0w will enjoy.
Malware in DNS - specifically, malware seen being assembled from DNS TXT records.
Not a "zomg new thing!" so much as a neat example in the wild.
#BGP #routage Hier, Cloudflare a cessé d'annoncer son préfixe 1.1.1.0/24 (pour une raison inconnue). Les nombreuses annonces « pirates » de ce préfixe ont alors été davantage visibles, amenant certains, apparemment à tort, à croire qu'elles étaient la cause de la panne du résolveur #DNS 1.1.1.1.
https://mastodon.gougere.fr/@bgp/114856050719978352
Car, oui, il y a encore des réseaux (Tata, par exemple) qui annoncent ce préfixe, qui ne leur appartient pourtant pas.
Cloudflare's DNS is down for me. Drove me crazy. One computer, which didn't have Cloudflare because it was connected to VPN, was working fine and another one, nada. Changed DNS and all is good.
Anyone else? #Cloudflare #DNS
DNS Esoterica - Why you can't dig Switzerland
https://shkspr.mobi/blog/2022/07/dns-esoterica-why-you-cant-dig-switzerland/
As part of my new job, I'm learning a lot more about the mysteries of the Domain Name System than any mortal should know I thought possible.
The humble unix dig
command allows you to query all sort of DNS information. For example, to see name server records for the BBC website, you can run:
dig bbc.co.uk NS
Which will get you:
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35614;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; COOKIE: 097db2ee4c92b84982083ecf62b5b5f2007906e616035113 (good);; QUESTION SECTION:;bbc.co.uk. IN NS;; ANSWER SECTION:bbc.co.uk. 900 IN NS ddns1.bbc.com.bbc.co.uk. 900 IN NS dns0.bbc.co.uk.bbc.co.uk. 900 IN NS ddns1.bbc.co.uk....
And a whole lot more. But you can go further down the DNS tree. What are the nameservers for .co.uk
?
dig co.uk NS
And you'll get your answer. You can go one further and see the nameservers for the Top Level Domain:
dig uk NS
Which replies with:
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54061;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; COOKIE: 880427eda8ff71de2ab4f43862b5b65f95e317d29cc10a8e (good);; QUESTION SECTION:;uk. IN NS;; ANSWER SECTION:uk. 159692 IN NS nsc.nic.uk.uk. 159692 IN NS dns1.nic.uk.uk. 159692 IN NS nsd.nic.uk....
And that works with every TLD. Countries like de
, generic names like museum
, and internationalised domains like 在线
. All of them work!
Except Switzerland.
Switzerland's country code is ch
- after the name Confoederatio Helvetica. Let's run the dig
on it: dig ch NS
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31910;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available
We have been refused and warned. But why does this only happen with Switzerland?
The blame - as with most modern ills - lies in the mid-1970s. The Bee Gees were storming the charts with "Jive Talkin'", the Rocky Horror Picture Show was gathering a cult following, and MIT scientists were causing chaos. Literally.
Chaosnet was an early network protocol designed for local networks. It was technically very clever but, sadly, never really took off.
However, it found its way into DNS records. Let's go back to the answer to dig bbc.co.uk NS
:
;; ANSWER SECTION:bbc.co.uk. 900 IN NS ddns1.bbc.com.
OK, the first part is the domain name. The number is the TTL. The IN
is the class. The NS says this is a nameserver record. And, finally, we get the domain of the nameserver.
But, in the class, what does IN
stand for?
"Internet", obviously. Wait... Isn't the DNS on the Internet? Why do we need to specify that these DNS records are for Internet?
Well, isn't it obvious? Because you might want records of a different network. Like, for example, Chaosnet.
And if Internet is abbreviated to IN
, what is Chaosnet shortened to? That's right! CH
.
So, dig
sees you enter ch
for Switzerland, but thinks you're asking about CH
for Chaosnet. And so it fails.
In order to query the records for ch
we need to provide an absolutely fully-qualified domain name. It's as simple as sticking a dot at the end of the domain name:
dig ch. NS
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64932;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; COOKIE: e19b9c23cdfa0f7bcf82750462b5c16b47744386c7974ffb (good);; QUESTION SECTION:;ch. IN NS;; ANSWER SECTION:ch. 164894 IN NS e.nic.ch.ch. 164894 IN NS a.nic.ch.ch. 164894 IN NS f.nic.ch.
And there we go. A failed 1970s experiment like bell-bottoms and Betamax videos - but with much longer lasting consequences.
You can see some CH
records by running like:
dig ch txt @f.root-servers.net version.bind
That will get you something like:
;; ANSWER SECTION:version.bind. 86400 CH TXT "cloudflare-f-root-20190930"
Of course, DNS doesn't only have IN
and CH
class records.
There's also Hesiod - HS
. But you already knew that, right...?