So what that means if, maybe the person in charge of the web site "cleverly" enables key pinning, then loses the keys, you fire them for incompetence but too bad your site is now unreachable for a long period, hope it wasn't important. But worse, maybe everybody you employ is smart or careful or both, but unfortunately bad guys break in, and they set up key pinning, then deliberately remove the keys. Now your site is unreachable... unless you pay them a ransom for the keys.

For non-browsers (e.g. a phone app) pinning is still very much possible, and I would say judging from what we see on community.letsencrypt.org that it does indeed function as a footgun - e.g. we had an outfit that does industrial IoT stuff and their things all believed they needed to see certificates from Let's Encrypt X3, which is a shame because X3 was retired in favour of R3 and so those things just broke until a human could reach them to perform a manual firmware update.

A DNS record to indicate which CAs may issue for a DNS name exists today, it's called CAA, and you are welcome to go set it up. However, CAA is about preventing a different issue than the one your parent was ranting about. CAA tells a trustworthy CA that you don't want them issuing, for example because their processes aren't suitable. But it does not prevent them from doing so, it would be a misissuance (policy forbids, they did anyway, that's a policy violation), but it wouldn't be impossible and is deliberately not detected by software like web browsers.

Let me give two examples, one where CAA fixes it and one where it's not applicable at all

1. [Yes this really happened] Facebook has a deal with a CA where Facebook pays them money and they have a bespoke process to issue certificates which includes ensuring the Facebook security team is happy. However, Facebook did not set CAA, and so when a contractor who didn't know any better just created a new web server something.something.fb.com and asked Let's Encrypt for a certificate, they got one. Facebook freaked out. Setting CAA would have prevented this, Let's Encrypt would say "Cannot issue, prohibited by CAA for fb.com" and the contractor asks his contact at FB, who then checks with security first and they either say "No" or get a certificate from their preferred CA. Today Facebook sets CAA.

2. Someone buys a domain example.com, and they're annoyed that the previous owner has a valid certificate for example.com which is still valid, from Entrust. So, they blacklist Entrust in CAA. This has no effect on that existing certificate, it only means the new owner can't get new certificates for that name from Entrust. The correct fix they should have done was to show Entrust that they, as the new owner, want this certificate revoked, in most cases that's just a matter of sending an email and doing what the reply says although the details vary by CA.