Jamil
Jamil
> Our gateways and relays should always be fine but for example, the admin could enter a bogus IPv6 DNS server address in which case we would erroneously discard the...
I think one thing that might be handy is for Gateways to report their IPv4/IPv6 connectivity to the portal. It would only need to check for a publicly-accessible route. Most...
> > Perhaps discarding the socket right away is a bit too brutal? There could be network topologies in which packets to some hosts are not reachable but to others...
> We could proactively query them for a Firezone specific record maybe? Even if they don't have the record, getting a response means they are up. That is basically what...
Changing assignees since I think @conectado should be freed up sooner. Not critical bug would be good to knock out some logging bugs / tech debt
Assigning @thomaseizinger to confirm whether forwarding change recently could affect this.
@jameswinegar - if you wouldn't mind, could you confirm whether you had *both* IPv4 and IPv6 DNS upstream servers defined when this issue occurred? Or only IPv6? If the former...
Feedback from customer is that he had _both_ IPv4 and IPv6 upstreams defined when this issue occurred. > I have IPv4-only due to my ISP just tested setting only an...
I believe what may have happened here is that hickory was handling this for us? This would explain why this is now a recent issue even though customer's env has...
If we don't have a valid IPv4 or IPv6 socket we shouldn't advertise these as sentinels.