[sitefinder-tech-discuss] Scaling issues - elaboration on existing scenarios

[Brian Dickson <briand@chateau-briand.net>]

As a pre-emptive follow-up on my own earlier post, I will present some
typical scenarios which are likely to affect the impact on scaling and
cost, for specific "enterprises", which could include ISPs, multinational
corporations, telcos, and government and gov-like entities.

Any of these sorts of entities, can, and likely does, use ".net" TLD for
their infrastructure, even if they happen to have ".<country-code>",
".edu", ".gov", or other TLDs, for their "services" net-presence.
As such, at least for .net, these issues are relevant, and conclusions
related to wildcard impact apply to these scenarios.

First, there is the non-universality which is automatically introduced
when deploying work-arounds. (This is independent of specifically *why*
such a work-around is needed, or *how* the the non-wc resolver deployment
is achieved to support any work-around that relies on non-wc resolvers.)

Without TLD wildcards, (pretty much) every resolver functions the same.

It is only in working around wildcards, ie deploying non-compliant
resolver software on an ad-hoc basis to "mask out" these wildcards, that
any resolver *topology* issues arise. (If every resolver is the same,
it doesn't particularly matter what the topology is, other than local
effects induced by arbitary choices of topology.)

Once the split between resolvers which do and do not honour wildcards
occurs, you have two distinct, and quite likely discontiguous,
sets of resolvers. Like oil and vinegar, little islands of one or the
other. How many depends on the relative topologies of autonomous
entities with similar policies.

For any enterprise to have deterministic behaviour, if it wishes to have
non-WC resolver functionality, its resolver paths must traverse at least
one non-wc resolver prior to the "real" root servers. And in fact, any
client must use such a non-wc resolver to do any recursion, since non-recursive
responses from a non-wc might result in a tld-wc server next being queried.

This places a significant burden on any geographically-large enterprise,
which has a need to deploy any work-around.

For, due to the speed of light, either signficant delays are likely to
be experienced in querying centralized non-wc recursive resolvers (for
example, possibly involving one or more satellite hops with 1/2 second each
for DNS lookups, or 200+ ms delays on intercontinental terrestrial links),
or a signifant deployment of non-wc resolvers needs to occur in a roughly
proportional geographic basis. In a highly aggregated topology, where each
"hub" supports an extreme number of long-haul links, which is typical in
the satellite market, the aggregation multiplier is also the cost multiplier.

In the most extreme cases, VPNs with hundreds or thousands of small sites,
would each need such a server, or suffer significant delays. Keep in mind
that the "user experience", even for successful DNS queries, requires at
least one, and possibly several, DNS lookups, the delays in reaching local
web sites, are likely to give a poor "feel" to the user, as if the pages
were as far away as the resolver.

(BTW, these are not hypothetical examples; I would be specific, but I am
bound by NDA from former employers against giving proprietary information
or specific details. And if you want other typical examples of low-cost,
very-large-scale VPN networks, consider IP-VPN-based cash-machines that
use dial-up or low-speed links.)

Second, there is the issue of resolver software.

Not all software in use, is open-source; in many cases, particularly in
goverment (ie lowest-bid) situations, binary-only licenses, possibly without
support contracts or with contracts which have expired, are likely deployed
throughout an enterprise.

Updating software may not be possible, may be prohibitively expensive,
or may only be possible via both hardware and software solutions.
(Typical support contracts are all-or-nothing; even if you want to deploy
updates to only a few of your servers, you have to pay for them all.)

And then there are all the heterogenous-support and "moving target" support issues,
often with insufficent or inadequately skilled, trained, or experienced employees.
(This is particularly true outside of North America and Western Europe.)

And honestly, any work-around that costs even a *dime*, is cost borne not by
VeriSign but by other entities; as such, it is inappropriate to impose this
burden without the general agreement of not just the majority, but a consensus
of virtually all parties involved. Sixty-eight percent does not cut it, nor does
even 85%. Cherry-picking respondents (eg "most commercial anti-spam vendors", or
"Most dial-up ISPs", or any self-selecting group of respondents), is entirely
inappropriate for what is a shared global infrastructure, operated on a contract
basis.

And regardless of any prejudicial disposition, cost *is* a technical issue.
Particularly when it is a direct, hard, bottom-line cost, and not just an
issue of employee time spent.
--
Brian Dickson