Nick Tait via bind-users wrote: > Hi Björn. > > Not sure if my (late) reply is any use to you, but yes my understanding > is that you could use localhost as the parental agent in the cases where > (a) the local machine also hosts the parent zone, or (b) it is a > recursive resolver. In the latter case the DNSSEC responses would be > validated (assuming of course that the local resolver does DNSSEC > validation).
Lacking replies, I investigated on my own. I spent some days figuring out how to turn on debug logging, locating a log file hidden under /var/cache instead of /var/log, and analyzing the log. I can now confirm that "parental-agents { ::1; };" works, and the debug log indicates that validation happens. I think it would be good to write that as a tip in the manual: "If BIND is configured to also be a resolver for its local host, and dnssec-validation is enabled, then "parental-agents { ::1; };" can be used to validate DS responses." > As I understand there are two schools of thought for configuring > parental-agents: > > 1. You could explicitly specify all of the parent zone name servers. In > that case all the servers are queried and the KSK rollover proceeds > once all servers are publishing the new DS record. Then I'd have to check periodically whether the parent zone has made any changes to its name servers, and update my configuration. Thus the key rollover wouldn't be automatic. > 2. You could specify a validating recursive resolver. In that case only > one authoritative name server will be queried (you won't know which) > and the recursive resolver validates the response, and the KSK > rollover proceeds if that server is publishing the new DS record. > > I suppose the theoretical risk with #1 is that because the responses > from the authoritative servers aren't validated, it would be possible > for a MITM to trick BIND into thinking that the new DS records had been > published before they actually had, which could lead to a situation > where you complete the KSK roll-over early and invalidate your zone? And then, when the parental agent polls for a CDS record, validation will fail so the DS record won't be updated. Recovery will require manual intervention through out-of-band channels. It seems like a viable denial-of-service attack, although its value is somewhat reduced because the attacker has only a limited ability to choose the time of the attack. The risk with option 2 is that there might be long delays in updating some of the parent name servers. I deem that risk very small in my case. The registry seems to be quite well run. Still, I suppose it wouldn't hurt to automatically verify that the update has reached all of the servers. > Also please note that BIND 9.19 introduces a new option: > > /*checkds*/ Yes, but it doesn't seem to change anything regarding validation of the DS record. If "checkds yes" uses *all* of the NS records, then that seems to be the automated version of option 1 above. I guess validation of the NS records depends on what's configured in /etc/resolv.conf? (In my case that would again be BIND iself.) I suppose the safest method would be to query all of the servers listed in the parent zone’s NS records *and* a validating resolver, and proceed only when all of them return the updated DS record. Maybe that could be a fourth choice for checkds? Or, since BIND already knows how to do DNSsec validation, maybe just do it? Björn Persson
pgpT2QKPQy5yq.pgp
Description: OpenPGP digital signatur
-- 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