> There's no way to change this, really, and one of the ways to not change
> it would be to write an RFC. USGov has its own way of doing things. ...They're welcome to run their own servers however they like.
However, if they want to arbitrarily cut off their networks from
"subversive" networks around the world, then I feel that they should ...
When I tell USG how I feel, they seem to ignore me. Your mileage may vary.
What would be useful in all this discussion would be if someone gives a
list of "good" root servers to put in my named.boot.
i.e. generally fast response time and no blocking prefixes
-Ralph
What would be useful in all this discussion would be if someone gives a
list of "good" root servers to put in my named.boot.
i.e. generally fast response time and no blocking prefixes
you don't get to choose, and you don't have to choose. put the root.cache
file that comes with bind in your config dir and use it as a "hint" zone
for ".". bind will "prime" when it starts up, which means ask the servers
in the "hint" zone for the real and current list of servers for ".". the
result will be used until its TTL is nearly expired, then the whole thing
repeats. bind will also measure the RTT to each server until it has tried
them all and then home in on the one that returns good answers fastest;
this "goodness factor" decays over time, forcing a re-sweep periodically
in case the network topology or performance changes.
i'm not sure microsoft or djbdns do this, but you mentioned named.boot,
so i'm giving you a bind-specific answer. btw, if by named.boot you mean
you're running bind4, you should upgrade to bind9 or bind8. see www.cert.org.
Kinda like ICANN, huh Paul?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell
Asking the wrong questions is the leading cause of wrong answers
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
if .../named.boot then {upgrade now}
BIND has a "goodness" chunk of code that will check connectivity
to the servers and pick a good one, it rechecks as a func of time.
is what I have in mine, seems to work well....
john brown
chagres technologies, inc
;; ANSWER SECTION:
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
True enough. But their machines could always be removed from the list of known root servers, and I don't think that there's much they could do about it.
Thus spake "Brad Knowles" <brad.knowles@skynet.be>
> When I tell USG how I feel, they seem to ignore me. Your mileage may vary.
True enough. But their machines could always be removed from the
list of known root servers, and I don't think that there's much they
could do about it.
The USG runs, directly or indirectly, 6 of the 13 root servers, including A.
That means you could only remove the USG from half the servers. One can assume
the USG would re-complete their cluster, and the "rogue" roots would flesh out
their own cluster. Since most folks haven't updated their root.cache file in a
decade, that means half the DNS servers on the Net would pick the USG cluster,
and half would pick the non-USG cluster. Once these clusters start offerring
different information, the ensuing mess would be horrific. For this reason
alone, you'd never convince any of the root operators to go along with such an
idea -- their concern is stability, not politics. I'm sure Paul will correct me
if I'm wrong on that.
S
The USG runs, directly or indirectly, 6 of the 13 root servers,
imiho, it is more important, and undesirable, that the usg controls
the *content* of the root zone.
randy