🥷 Hackers exploit a blind spot by hiding malware inside DNS records • @arstechnica
｢ That’s because traffic for DNS lookups often goes largely unmonitored by many security tools. Whereas web and email traffic is often closely scrutinized, DNS traffic largely represents a blind spot for such defenses ｣
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 -Server 9.9.9.9).Strings | Sort(Resolve-DnsName -Type TXT qr.never.watch -Server 9.9.9.9).Strings -replace '#','█' | Sort··⧸··⧸.never.watchAfter 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).
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.
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/
Plusieurs articles sur cette panne semblent avoir été écrits par des stagiaires incompétents (une IA n'aurait pas réussi à produire autant de conneries, il faut des vrais humains bio pour cela).
Les deux meilleurs : celui qui disait que 1.1.1.1 était géré par Google, et celui qui disait que les sites Web étaient en panne car hébergés par Cloudflare (seul le résolveur DNS était en panne).
Un exemple d'un article écrit par des clowns : "Multiple websites on 1.1.1.1 server down"
https://www.hindustantimes.com/world-news/cloudflare-dns-outage-multiple-websites-on-1-1-1-1-server-down-company-reacts-101752533050143.html
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.
Ok so another DNS question:
I (my employer) got a server on ip1 but for reasons we migrated stuffs on it to serv on ip2.
We changed the DNS reccords so that service.domain.com points to ip2 now. It's been more than a week, and if I use say 1.1.1.1 has a DNS server, it works fine.
However if I use whatever DNS server my work dhcp server is pointing me to, service.domain.com is still pointing at ip1.
What gives ?
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.
Una de les primeres coses quan configuro un servidor Ubuntu Server és instal·lar #Unbound per a tenir resolució de noms (#DNS) en local, així el servidor no ha de fer peticions DNS als servidors DNS de Google, Cloudfare etc 😀 (per privacitat).
En el seu dia vaig escriure un tutorial que segueix sent vàlid:
https://blog.mastodont.cat/2024/01/11/resoldre-ips-localment-amb-unbound/
We have a retired SafeNet Luna 4 #HSM in the office for testing our Nameshed HSM code, but we're having a bit of a hard time obtaining a PKCS#11 Linux library / SDK for it.
(Plan B would be someone giving us testing access to their Thales Luna)
Is there anyone who can help @ximon18 out? Sharing is caring. 💚 #DNS#DNSSEC#OpenSource
Our quarterly staff highlight - meet one of our team members, often behind the scenes, but critical to our operations, our infrastructure, and most importantly your security!
Quad9's Senior Operations Engineer, Michał “rysiek” Woźniak @rysiek
https://quad9.net/news/blog/staff-highlight-michal-rysiek-wozniak/
A space for Bonfire maintainers and contributors to communicate
