It can get a bit hardware dependant but getting <50ms failovers from software based BFD in BIRD or FRR is fairly easy, and I've tested down to < 1ms before with hardware based BFD echo. ~50ms is the point at which a user making a traditional VOIP call won't notice the path switch.
You can get NIC's for computers (like most Nvidia/Meallanox or higher end Broadcom/Intel NIC's that do hardware BFD, and its obviously included in higher end networking kit.
You then link the BGP routes to the health of the BFD session for which that path is the next hop, and you get super quick withdrawls.
This is due to advertising standards. They are required to advertise "average speed", although how this is actually calculated is nebulous.
A&A not advertising can just say what the link speeds actually are on the product pages.
Other ISP's could do this too, but it would cause confusion having one figure on the advert and one figure on the product pages, and they might get in trouble if they link to the product pages in the adverts.
I once wrote something that did, as an internal tool.
It was basically an MPLS traceroute tool that used LOC records on RFC1918 loopbacks to plot pretty maps (well, the lines were way too straight on long range links, but ...).
It was used by marketing and basically nobody else, but it existed !
I've always thought we could put a bit of general purpose TCAM into general purpose computers instead of just routers and switches, and see what people can do with it.
I know (T)CAM's are used in CPU's, but I am nore thinking of the kind of research being done with TCAM's in SSD like products, so maybe we will get there some day.
DNSMON: Monitor the root and TLD's and other key internet domains. Does so from many locations so as to test anycast issues.
- https://dnsmon.ripe.net/
And volunteer resources to help to run other things, like https://www.as112.net/ that sinks all the PTR lookups for RFC1918 that leaks to the internet, among other things.
The idea of an IX, or IX peering LAN is simple in concept. It is a LAN (a flat, layer2 network), to which multiple ISP's can plug in routers.
Like your home LAN might have 192.168.0.1 = router, 192.168.0.2 = laptop, 192.168.0.3 = phone etc, a peering LAN will have things like 195.66.224.21 = HurricaneElectric, 195.66.224.22 = NTLI, 195.66.224.31 = Akamai, 195.66.224.48 = Arelion etc ...
So instead of all these ISP's that want to exchange traffic with each other having to assign ports and run cables in a full mesh (which quickly would get out of control), everyone connects to the "big switch in the middle" with that peering LAN on it, and they use that.
Back in the day, that might have been an actual single big switch, or a stack of switches. Now IXP infrastructures are much more complex, but the presentation to the end user is usually still a cable (or bundle of cables) that goes into something that looks to them like a "big switch".
There is a LOT more to know about this space (Peering vs Transit, PNI's, L3 internet exchanges, what Google are doing by withdrawing from IXP's), but I wanted to write a comment that didn't turn into an essay.
The general root servers generally don't support AXFR, but if you want to AXFR the root, you can do so from lax.xfr.dns.icann.org or iad.xfr.dns.icann.org.
There is work coming at the IETF to help with this.
- Draft: DELEG (a new way of doing delegations, replacing the NS/DS records).
- A draft to follow: Using the extensible mechanisms of DELEG to allow you to specify alternative transports for those nameservers (eg: DoH/DoT/DoQ).
This would allow a recursive server to make encrypted connections to everything it talks to (that has those DELEG records and supports encrypted transports) as part of resolution.
Of course, traffic analysis still exists. If you are talking to the nameservers of bigtittygothgirls.com, and the only domains served by those name servers are bigtittygothgirls ...
It can get a bit hardware dependant but getting <50ms failovers from software based BFD in BIRD or FRR is fairly easy, and I've tested down to < 1ms before with hardware based BFD echo. ~50ms is the point at which a user making a traditional VOIP call won't notice the path switch.
You can get NIC's for computers (like most Nvidia/Meallanox or higher end Broadcom/Intel NIC's that do hardware BFD, and its obviously included in higher end networking kit.
You then link the BGP routes to the health of the BFD session for which that path is the next hop, and you get super quick withdrawls.