While reconstructing my membership file from de facto
"unauthroized" log entries and then retrofitting DNS names,
I've always had a few entries that I could never quite identify.
The root cause appears to be from this membership line:
http://keys.n3npq.net/status/info/sd-27509.dedibox.fr
where a peer of "pool.sks-keyservers.net" appears.
Good: know I know where the log entries are coming from.
SInce that DNS name maps into the currently defined pool,
this (and I suspect other) SKS key servers appear and disappear
in my (and others) logs, usually without any success at peering
with the currently defined conventional policy of a pre-arranged
agreement to peer.
I personally think that peering against "pool.sks-keyservers.net"
isn't really all that insane if there were some modest changes
to use SRV weights (or similar) to prefer "fastest" key servers
to peer against, and there were some modest resource caps
so that one did not suddenly start peering with every other
key server on the planet.
On a somewhat related note (before I dig into OCAML), can anyone
state the retry loop algorithm that is currently implemented for
non-responding peers? The reason for the question is that
the retry loop is what would need adjustment to prefer "fastest"
and there may already be code implemented to avoid non-responders
with a back-off retry algorithm implemented that would be easy to
adjust.
DOes anyone have strong objections if I attempt a try-and-see
implementation with a key server that peers against
pool.sks-keyservers.net 11370
hth
73 de Jeff
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
