This should not affect any end users, but we have moved ‘fenfox.run’ over and into our name servers. This put both of our namespaces within our infrastructure. For the next few hours, end users might see two sets of name servers responding, since it takes time for the older data to age out.
Category: Network
Post dealing with changes to how we route packets and configure our network.
Hey VTs,
Skylar needs you to crawl the network and check everything connected against our documentation. The network map had errors and some of our recent task got messed up. Please take a moment to crawl the network and let her know your findings, it would be very helpful to get a few more eyes on this.
We have reached a point where our name servers are working well enough for daily use that we feel like we can cut down on some of the duplicate functionality in our routing stack. At present, each router in our stack is running its own instance of Unbound for client DNS and this leads to a bunch of duplication that is probably not needed and just adds to our hypervisor’s workload.
Starting around 1000EST today, we will be turning off each router’s Unbound instance and will be updating profiles to point their DNS at our two name servers. If you are an end user or project member and you notice that DNS functions stop working, you should update your connection profiles to point their DNS at the following addresses:
- 204.12.237.197
- 173.208.212.205
- 2604:4300:f03:c1::2
- 2604:4300:a:6e::5
For our WireGuard users, this most likely means replacing the line “DNS = 2604:4300:f03:XX::1, 10.0.XX.1” with the line “DNS = 2604:4300:f03:c1::2, 2604:4300:a:6e::5” to retain DNS functions after today. We know that our DNS changes have been a moving target for our project and our users, but this should wrap things up on that front.