Je gagne combien pour signaler qu'il n'y a pas #DNSSEC sur leur nouveau domaine, à l'heure où une nouvelle attaque (#MaginotDNS) en a rappelé l'utilité ?
@uastronomer@mensrea so .ZADNA do require the Hosting Provider to submit the DS/DNS Key Record to them - they will only accept it from you, if you self-host. This to ensure the chain of trust is not broken. Really amazing service from https://www.domains.co.za - they offer #DNSsec out of the box and the whole process to register, transfer the domain and it being active, took less than 45 Minutes. #SouthAfrica#domains_co_za
I'm using 1.1.1.1 as a resolver for my home WiFi and this morning nothing was loading.
Turns out their resolvers didn't know how to parse the new #ZONEMD records. Some resolvers used an older cached version, which in turn failed because of the #DNSSec signature expired.
@fj "Of course #DNSSec was to blame." That was just the consequence, and I would posit without it, the problem would even have lasted longer. The real problem as idscussed in article is a new record type in zone (ZONEMD), coupled to CloudFlare downloading the zone locally (which is fine), and parsing it... but choking on the new record type, hence keeping a stale version of the zone, with (DNSSEC) signatures starting to expire.
The Internet Namespace Security Observatory. Nice #DNSSEC-centric visualizations and statistics based on SecSpider data from
Eric Osterweil. https://inso.gmu.edu/
Random #DNS fact of the day : 129 out of the 1465 domains in the root zone (roughly 8.8%) have a TXT record. Most of them (52, 40.6% of the records) are just : "Generation Time: <UNIX timestamp>" (eg. as. TXT)"
Some of them are more explicit (see cg. TXT or tm. TXT)
@afnic puts a crytpic message in its zone, surely the number of changes since last update (see fr. TXT, eg. "296 RRs processed [25/09/2023 13H10:42" please note the ugly date format "H" :P )
Just noticed that the #DNSSEC toolkit from #BIND gives a 0 TTL to NSEC3PARAM RR
The tool I use, ldns-signzone, gives a 3600 TTL to my domain's NSEC3PARAM, which seems to follow the rule applied to NSEC/NSEC3 records ie the rule for negative response from RFC 2308 (cf. RFC 9077)
🤔
That is not a problem as I don't use any salt, so it won't change unless RFC 9276 recommendation is reverted.
Was also 3600 back when I generated a new salt each time I signed the zone. Eg
1311 are using NSEC3. That's 89.5% of all TLDs and 96.8% of all signed TLDs
644 are following RFC 9276's recommended #NSEC3 parameters. That's 43.9% of all TLDs, 47.5% of all signed TLDs and 49.1% of all signed TLDs using NSEC3
I guess last time a new RR Type was introduced in the #DNS root zone was back in 2010 when all the #DNSSEC related stuff was added (and the root zone signed) 🤔
Totally missed that information : a new #KSK for the root zone was generated during Root KSK Ceremony 49 last April. It's still a RSA 2048-bits key and it's keytag is 46211 if I read the log correctly