Tiens, #Bind ne met pas le bit AA pour les réponses venant d'une #RPZ (j'ai peut-être loupé une option). Il indique le SOA de la RPZ dans la section additionnelle de la réponse ceci dit
To all who are hosting their own #dns#authoritive server with #dnssec - what do you use in 2024?
#Ed25519 or #ECDSA-P256 or still on some #RSA algorithms? Shorter key length is especially in DNS a benefit but still not all resolvers may be able to support this in 2024?!
At ZERO GmbH, we're managing a lot of #AMPS Nodes (see: https://zero-iee.com/en/products/). Most of them are connected to our management VPN. Each of the nodes has a unique identifier (serial no.).
We've set up an internal DNS server that resolves their serial bumber-based FQDN and returns the corresponding VPN IP address. Thus it's easy to find the correct VPN and IP address to start maintenance or troubleshooting :-)
Our requirements on a DNS Server are quite low. We could have picked THE ONE, the only, the allmighty Bind DNS server - but instead we tried something different:
Yadifa. https://www.yadifa.eu
Yadifa is a less-known DNS server implementation by EURid - the nonprofit organization that powers the .eu top level domain!
We were surprised of the simplicity of Yadifa and had our DNS Server up and running in minutes! If you're looking for an easy to configure DNS server, check it out.
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
It seems that most people who manage #bind with #Ansible have given up on the RFC recommendation for SOA serials YYYYMMDDxx and just use epoch time, which means that since it's a 32-bit unsigned value per RFC1035, there are going to be a lot of #DNS problems for domain names that are still operating in the year 2106.
In case anyone else needs it, here's a quick bash script I wrote to calculate the new serial for #bind zones. At the moment, it only supports one zone per file, but I can update it to grok more than one fairly easily if it would be helpful for anyone. In case the serial has been holding you up from automating your #dns entries:
I have access to a #BIND nameserver via rndc and directly to the zone files.
Is there a way to get a list of all records in a zone? "grep" works, but with active DNSSEC, it doesn't give me just the names for future processing?
For PowerDNS, I can SELECT directly in the SQL database - but with bind?