Re: How filter with RPZ only A and AAAA type records ?
On Tue, 9 Aug 2022, sub zero wrote: Short question, is it possible to filter with BIND RPZ only A and type records? If yes, how? A similar question was asked recently on the DNS Firewalls list at Redbarn (http://lists.redbarn.org/pipermail/dnsfirewalls/) Short answer is no, or at least not that I know of. But maybe sort of. You can certainly return some RPZ generated answer (A record), but things like e.g. NXDOMAIN and passthru are done with CNAME and apply to the FQDN. I note that returning NXDOMAIN for an rtype and an answer for a different rtype for the FQDN is not conformant with how the DNS is supposed to behave (the conformant answer is success+ANSWER:0 not NXDOMAIN). Short questions don't always result in short answers. ;-) You might try the DNS Firewalls list, you might also see if you can come up with a scenario and functional tests; that might help people give a better answer. -- Fred Morris, internet plumber -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
Hi Magnus, On 10-08-2022 11:13, Magnus Holmgren wrote: Hi, I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and at the same time switched from auto-dnssec maintain to a dnssec-policy with RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the old keys and with unlimited lifetime to avoid confusing BIND). Though it seems to take longer than expected to finish a key rollover, even taking into account propagation delay, TTLs, and retire-safety, the old keys were eventually removed from the first zone. One zone I'm still waiting for, and that rollover started Friday. One question: Is it necessary to use rndc dnssec -checkds or is that only meant as a backup, and named is supposed to query the parent for DS records automatically? That depends if you have set up parental-agents. If not, then you need to run 'rndc dnssec -checkds'. The last zone, milltime.se, has become stuck. sudo rndc dnssec -status reports that the old keys are removed from the zone and the new keys are omnipresent, but the log says "zone milltime.se/IN (signed): Key milltime.se/RSASHA1/22971 missing or inactive and has no replacement: retaining signatures." Never mind. I was too quick switching to NSEC3, which is incompatible with the old key. Switching back to NSEC allowed the rollover to complete. Still, shouldn't BIND have been able to figure this out on its own? It kept using NSEC because of the incompatible key, and it kept the incompatible key needed to verify the NSEC records. Catch-22? (Yes, I've read about the questionable merits of NSEC3.) I think we could improve named-checkconf to error out on a policy that uses NSEC3 with an incompatible algorithm yes. Thanks for the suggestion. The subject of the mail seems to indicate a different problem than the body, or am I missing something? Best regards, Matthijs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
Hi, I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and at the same time switched from auto-dnssec maintain to a dnssec-policy with RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the old keys and with unlimited lifetime to avoid confusing BIND). Though it seems to take longer than expected to finish a key rollover, even taking into account propagation delay, TTLs, and retire-safety, the old keys were eventually removed from the first zone. One zone I'm still waiting for, and that rollover started Friday. One question: Is it necessary to use rndc dnssec -checkds or is that only meant as a backup, and named is supposed to query the parent for DS records automatically? The last zone, milltime.se, has become stuck. sudo rndc dnssec -status reports that the old keys are removed from the zone and the new keys are omnipresent, but the log says "zone milltime.se/IN (signed): Key milltime.se/RSASHA1/22971 missing or inactive and has no replacement: retaining signatures." Never mind. I was too quick switching to NSEC3, which is incompatible with the old key. Switching back to NSEC allowed the rollover to complete. Still, shouldn't BIND have been able to figure this out on its own? It kept using NSEC because of the incompatible key, and it kept the incompatible key needed to verify the NSEC records. Catch-22? (Yes, I've read about the questionable merits of NSEC3.) -- Magnus Holmgren, utvecklare MILLNET AB, Datalinjen 1, 583 30 Linköping Direkt: 013-470 40 09 Växel: 013-470 40 00 Support: 013-470 40 19 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
