How does either solve this if the bad actor is able to inject routes at will? Just redirect whois.iana.org to their servers. Then they can prevent you from accurately determining who the registrar is in the first place.
Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?
This isn't something I was aware of, and I'm not having much luck in finding out the implementation details.
> Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?
I can imagine a zillion different approaches... most obvious (not necessarily the best) one being to ask an IANA server over a normal TLS connection whether it should expect a TLD's records to be signed. And you can obviously cache that response for a while.
Remember the point here is to validate domain ownership, which everybody already understands to be a big deal. If you can't get any trustable response from anybody, then I would expect it is your duty to refrain from issuing a certificate for that domain.
There are some drafts, and some NICs that have custom WHOIS solutions over custom authenticated protocols that don’t integrate with the normal WHOIS functionality.
But the larger issue is that there is no global integrated WHOIS system – e.g. to view a WHOIS record for a .de currently you need to solve a captcha and provide a valid reason (and can’t do it automated).
