Hmm le .va est géré par le "Saint-Siège", mais le Vatican gère aussi des #gTLD via le Pontificium Consilium de Comunicationibus Socialibus (c'est listé en latin chez l'IANA)
.catholic
.католик
.كاثوليك
.天主教
4× catho donc a priori (pas vérifié le TLD en mandarin, mais vu les 3 autres...)
D'ailleurs l'IANA listant le Siège apostolique comme gestionnaire du .va, ça signifie que le domaine est géré par le pape et la curie. Ça se voit à l'emblème pontifical : il y a les clés #DNSSEC utilisées dessus !
Édit : le .va n'est pas signé (pour un catholique, ça la fout mal de pas savoir signer). Je suppose que l'authenticité des données est assurée par l'infaillibilité papale. Ou dieu 🤔🤔
On est dans les locaux de l'#ESGhttps://www.esg.fr/ Comme c'est une école de commerce, on leur pardonnera le fait que le résolveur #DNS du Wifi "guest" soit 8.8.8.8. (Au moins, comme ça, on a #DNSSEC.)
OK, I know a little about DNS but wildcards + #DNSSEC are out of my league. Nevertheless, I'm pretty confident that this TYPE65283 shenanigans Cloudflare is using in its #NSEC RR does not come from the RFCs 🤔
Thinking about my (still WIP) #PiHole setup. AFAICT, the guide for #DoH with #cloudflared at https://docs.pi-hole.net/guides/dns/cloudflared/ only coveres using DoH between the PiHole and the upstream DNS provider (e.g., Cloudflare, Google, etc.). But if I want to use DoH between my browser and my PiHole, I seem to need another DoH Proxy, which makes request flow like this:
incoming on dns.ljrk.org:443 (traefik reverse proxy)
forwarded to 127.0.0.1:80 (DoH Proxy #1)
upstream classic DNS resolver on 127.0.0.1:53 (PiHole)
forwards any non-blocked requests to 127.0.0.1:5053 (DoH Proxy #2)
upstream DoH DNS resolver such as 1.1.1.1:443/dns-request
Of course, most PiHole setups are local and I'll probably end up opening dns.ljrk.org only through a #TailScale/#HeadScale#VPN, but my browser may still prefer to speak DoH instead of RFC1035. I'm also not sure how #DNSSEC plays into this...
@ljrk why DoH also from pihole forward? Wouldn't be DoT enough? What is the point of DoH used exclusively over #VPN? Dnsmasq can do #dnssec validation, pihole should be able to do it. If it runs on Server, why not use iterative resolution without forwarders on step 4?
Hey @Vivaldi noticed that vivaldi.net is one of the all-greens on Hardenize.
I'd move my mails to vivaldi.net, but I have size worries, still use other providers, & own domain.
Do you have any plans to implement paid size plan, & features like automatic IMAP fetch, external sending SMTP, own domain management?
"Consequenties van de wildgroei aan DNS-functies met bijbehorende RFC's zijn de toenemende complexiteit (vanwege interferenties tussen verschillende functies), steeds minder mensen die het protocol doorgronden, en de afnemende kwaliteit en veiligheid van implementaties."
"The consequences of the rampant growth of DNS functions and accompanying RFCs are increasing complexity, a growing shortage of people who fully understand the protocol, and decline in the quality and security of implementations."
My @nlnetlabs#unbound#docker image has been updated to #OpenSSL 3.1.1 including my build bases which got updated to #Alpine 3.18.0. The images version reads 1.17.1-5.
My #DNS hosting provider is having a major issue with #DNSSEC, so all of my domains are down. :blobcateyes:
Sigh. Removed DS records. All should be back up and running in 24h or so. Some are already back up and running.
Yes, I will re-enable DNSSEC as soon as stuff is back up.
Yes, this is a serious consideration for anyone thinking about to enabling DNSSEC.
Yes, I do hope one day this will get solved better and DNSSEC will not be so brittle.
Quad9 does deserve our support.
But even better in terms of freedom is running your own local recursive resolver (e.g. #Unbound, possibly combined with #PiHole), which also allows you to do DNSSEC validation on/near the endpoint.