[sitefinder-tech-discuss] VeriSign technical people??

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

[Editorial comments first]

So much for this list... more than 24 hours into the list, two or three
technical issues (one solid, one policy vs policy based on tech requirements,
one meta-tech issue). No responses from VeriSign technical people.

In the absence of any other technical discussions on the list, I will post
this issue as a "last straw" issue. No response from VeriSign, will be taken
as failure of good faith, and indication that the list should properly be
ignored by the technical community.

And conversely, a response which does not address the heart of the technical
issue at hand, or which neither acknowledges the inherent problem nor provides
any "solutions surrounding the operational impact of wildcards", can only be
taken as actual evidence of contradiction of the assertion that "there is no
data to indicate that the core operation of the Domain Name System or
stability of the Internet".

[End editorial comments]

DNS is *not* the Internet.

In fact, the Domain Name System was developed, well into the life of the
(mostly) public IP infrastructure, in order to handle scaling issues.

And, there is no requirement upon any Internet-connected host, to use, or
participate in, DNS.

However, the protocol elements of DNS were devised specifically so that it
could *interoperate* with other name<->IP mapping mechanisms; this is
precisely why NXDOMAIN exists.

So, given an enterprise environment where, inside the company, a domain
is used privately, but, for security reasons (or any other valid reason),
it is not implemented via DNS, but by some other means (even /etc/hosts).

Clearly, inside the enterprise, a single domain is scalable. And, in order
to access outside Internet hosts, DNS needs to be used. And also from
a security perspective, the company wants to ensure that DNS is used
preferentially over the /etc/hosts file(s), so that it isn't possible to
"spoof" any host entry for a real, external host.

In this instance, the company would search DNS first, and in the case of
their ("private") domain, would *require* an NXDOMAIN to be returned,
so that their /etc/hosts entries are queried.

This situation is (a) valid; (b) illustrates the key issue (DNS is *not* the
monopoly mechanism for implementing name->IP mappings, although from a
registration point of view, it is virtually necessary that namespace collisions
do not occur); and (c) has no scalable work-around.

There are other, similar scenarios that can be equally envisioned; such as
use of NIS and DNS for private and public versions of the same domain, which
have similar requirements on NXDOMAIN and search order, where keeping data
*out* of DNS is a design requirement.

DNS was created to solve scaling problems; in this instance, the mere addition
of TLD wildcards to .net and .org, *creates* one or more scaling problems,
which are operational in nature (eg deployment of either code or configurations
enterprise wide, for *any* conceivable work-around).

I have not subscribed to the list, but will monitor it via the archive.
Responses are welcome, but please cc: the list.

And NB: I do *not* give permission for my email address to be used for anything
other than personal, private, non-automated use; do not SPAM me.
-- 
Brian Dickson