My answer was deliberately naive as Randy alluded to in a follow-up email. When you look at this issue, there are three competing subproblems: 1) How do I find the X server for domain Y that domain Y is running? 1A) How do I find the X server that proxies for domain Y (a subcase of 1) 2) How do I find user Z in domain Y when no server (proxy or native) is available? 3) How do I find user Z in a list of user registries? (and how do I find the definitive list of user registries?) To get a service that scales, you have to eventually get to (1). It is essential. We all agree on this: noone seriously suggests there should be one or a small number of http or email servers. As a network administrator, I (eventually) will want to run (or control the management of) the server, especially if it is critical enough. Clearly, problem (1) can and should use the DNS. And leverage the SRV records. It is the system that can be leveraged that will make the service scale. This implies, in some way, that the service uses user identifiers that are related to the domain name in some way (e.g. email address). One issue is that protocol developers often do not define the mechanism to relate service to DNS name in the protocol spec. People are left to develop it by consensus or not at all (e.g. www.domainname). To be effective, server software developers must implement it as the first action the server takes (although there may be others) so that scaling is gained by default if someone implements the option. Of course, this is necessary, but not sufficient to attracting a user base, to bootstrap the community and reach critical mass necessary to be viewed as a critical service. Thus, option 2 is necessary. A default, global context where I can register my service information on a per user basis (since I don't have a domain specific server in the early days by assumption). If you think of email, for example, we do that all the time too (hotmail, ldap, etc etc). So both solutions are necessary. Its just that new service deployment seems to ALWAYS start with option 2. Then, once you are big, it is a huge problem to change to option 1. In fact, what happens in the wild is option 2 is implemented, then people try to figure out how to instantiate a flat namespace across many user registries (where registration is at the discretion of the user, so there is NO obvious binding between user and registry - anyone ever try to actually find a user of MS Netmeeting?). If the PGP key servers implemented both option 1 and option 2 as a fall-back, then Randy could bang on the people whose keys are mission critical (and he can't get), and encourage them to register their own server. Otherwise, you live with the default. The risk with PGP key servers now appears to be that option 2 was selected, and in trying to scale the system, people are trying to grapple with instantiating a single flat registry instance structure (and operate it on the scale necessary to support per-user registration). Scaling a point user registry without hierarchy is no different than trying to scale a flat network addressing space (and we know how that worked out). If you have many flat user registries, then you have a whole other problem - how do I find user Z across many user-selected registries. And how to I find (and register) the canonical list of registries. That is in effect saying the key to look up user Z is flat - there is no hierarchy. My assertion is that such a system cannot scale anyway, so no point in trying to fix it. To speak to Randy's point - the server structure is different than the key relationships. I believe a PGP key is associated to an email address, right? If so, then what's wrong with first looking in the domain to find the keyserver, and walking up the domain tree? If nothing is found, *then* check the default (flat) user registry? (But I am not a PGP expert, so someone else pick this up if I am wrong). It gives the administrator of domain Y the option of scaling without the problem of figuring how to run a flat registry and restrict it to their community of user Zs and ensure everyone can find user Z in domain Y on server X (which really is not obvious at all). Using the DNS, of course, assumes the service has a server that has a port that can be mapped to srv records... (S/N check: This might be drifting from nanog...) Regards, Eric Carroll