If one of the servers in a multihomed site is failed, proof shouldnt fail.

I noticed today that one of the IPs for my site failed.
Eg, I have 2 IPs for my site:
C:\Users\Sebastian>nslookup -type=A sebbe.eu.
Server: fw.sebbe.eu
Address: 2001:470:28:1c:1::1

Name: sebbe.eu
Address: 46.246.71.16
94.185.86.58
C:\Users\Sebastian>

the 46.246.71.16 server failed, then keybase sent me that my https proof was failed. I tried several times and requesting my proof from my web client and it worked wonderfully since the 94.185.86.58 server was up. Found out that when the server 46.246.71.16 went up again, the proof started working again.

Keybase should really try all the IPs listed in DNS before failing a proof, since the purpose of having multiple IPs for a domain is failover and load-balancing, eg so if one server is down, the site should still be available and considered to be "up".
Eg, if at least one IP in a multihomed site is working and presenting the proof, the proof should be considered valid.
Sometimes a recursive resolver might not always give all IPs for a domain, for example in certain round-robin configurations. Then Keybase should do a **uncached** DNS query directly to the authorative DNS server to ensure it gets the latest data. This could be done when it detects a proof "failed".

No files, tests, or entry points are named; start by locating the Keybase website-proof verification flow and its DNS resolution logic. Reproduce verification with one failed and one working address, then confirm that a proof succeeds when any advertised IP serves the proof and that the relevant DNS behavior is covered by tests.

Written by the indexing model from the issue text.