It appears that I'm about to add Karl to my mailproc rules since he really does belong next to Jim Fleming. But before I do that...
Well, the LONG TERM solution is to secondary and list the "known to be good" roots.
In what order? With 1,000,000 name servers (remember, you're talking LONG TERM here) this is a hell of a lot of SOA queries against the first server in the list.
You CAN run the cache file if you want -- but then you get the same problem that everyone else has -- that the IANA needs to change the roots too, and guess what -- there's a boatload of cache files out there.
Or you could use existing technology (invented by Mark Andrews in this case) and solve the REAL problem without also dealing with Karl's odd politics: zone "." { type stub; file "root.cache.stub"; masters { 192.36.148.17; 192.203.230.10; 128.8.10.90; 192.33.4.12; 128.9.0.107; 128.63.2.53; 198.41.0.4; 198.41.0.11; 198.41.0.10; 192.112.36.4; 192.5.5.241; }; check-names warn; allow-update { none; }; allow-transfer { any; }; allow-query { any; }; }; That's on BIND 8.1. If you're running BIND 4.9.5 it's a lot simpler. What this does is do a ". NS" query (with UDP) and store the results. If there is no answer, the "masters" list becomes like a "forwarders" for the zone, which in this case makes it just like an explicated hint zone.
Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other than this. I'm not worried about the load.
You should be worried about what you'll do when its address changes. That is, you would have to worry if this name server was ever going to matter in the larger scheme of things, which it is not.