Should I set parental-agents to localhost?

[Björn Persson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230924/5aa29343/attachment.sig>