You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We add a trust assumption on Google DNS HTTPS service when generating proofs (even for server side now), but the verifier is free to validate the "pubkey" by their own means.
This is fine for most cases but not ideal; in the ideal scenario, we default to this Google key, but also try to fetch the key directly via a DNS query if we can -- if that fails, fine we go with google, if it succeeds then we verify that both keys are the same and output a scary warning if they aren't (but still proceed with Google as a default). Basically, we want a user to be able to tell if something is going wrong i.e. Google is censoring that key for whatever reason. IMO, we can add this as a future feature request, and merge this in for now in order to unblock and immediately resolve SSR rendering issues. Do you agree?
I think we can use google & cloudflare at the same time to make sure DNS is accurate (both via DNS over HTTPS)
Note that the dns package causes issues with SSR. See full discussion on #210.
The text was updated successfully, but these errors were encountered:
Note that the dns package causes issues with SSR. See full discussion on #210.
The text was updated successfully, but these errors were encountered: