Don't provide promiscuous proxy DNS service

[Kevin Darcy]

Jonathan de Boyne Pollard wrote:

> FA> Upon further investigation, we discovered that other people (even
> FA> competitors) were utilizing our DNS servers to perform regular
> FA> queries.
>
> JdeBP>
> http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-server-roles.html#ProxyIP
>
> KD> Why do you insist on muddying standard terminology?  [...]
> KD> [...] it's very confusing [...]
>
> That's a leading question.

Leading questions are permitted wrt a hostile witness.

> It takes an untruth as its premise.

Sez you.

> I'm not
> muddying standard terminology at all.  The term "proxy server" *is* the
> standard terminology for a server that takes queries from clients and passes
> them on to other servers.  And that is *exactly* what DNS servers such as the
> ones mentioned above do.  They take DNS requests from their clients, pass
> those requests on to zero or more other DNS servers to obtain the actual data,
> and then send back those data to the original clients when they have them.
> This is what a proxy server does.  These servers are proxy DNS servers in the
> same way that a server that takes HTTP requests and passes them on to other
> HTTP servers is a proxy HTTP server.  (In fact, DNS and HTTP have quite a lot

> in common.  This is unsurprising when one thinks about it.)
>
> There is no confusion being generated here.  The word "proxy" is being used in
> its conventional, dictionary, sense, after all.  Moreover, this is hardly a
> solecism that has no analogues elsewhere.

> The idea of a "proxy server" crops
> up all over the place in Internet documents.  One can find in the RFCs many
> references to proxy servers, including (picking a few examples at random) SNMP
> proxy servers (RFC2962), SIP proxy servers (RFC2543), RADIUS proxy servers
> (RFC2865), NFS proxy servers (RFC2624), and HTTP proxy servers (RFC2068).  Far
> from this causing confusion, using the word "proxy" to describe this
> particular sort of DNS server actually simplifies things.  One can easily
> deduce, if one is famililar with any of the aforementioned proxy servers (or
> if one has a dictionary (-:), what a "proxy DNS server" does and where it fits
> into the scheme of things.
>
> If you want terminology that results in confusion, then a prime candidate is
> the term "resolver".  It may be commonly used (albeit only in the realm of
> DNS), but it causes a vast amount of confusion because it isn't commonly used
> *to mean the same thing*.  Time and again over the years it has caused
> miscommunication, when one person has used "resolver" to mean a DNS client
> library within an application, and another person has used it to mean a
> resolving DNS proxy server.
>
> I recommend sticking to the eminently sensible terminology that is used when
> talking about all other client/server protocols, rather than perpetuating DNS
> terminological idiosyncracies whose meanings people cannot even agree upon.
> When something is a proxy server, call it a "proxy server".  That is the way
> to greater understanding.

If you want to recommend that the standard terminology be changed, then that's
fine. But the DNS lexicon was formed in standards documents which precede all of
the ones you cited, and that terminology stands until modified.

To be perfectly frank, I don't think hardly anyone would care if you called them
"proxy servers" or carrots or sofas, or whatever, except for the fact that it
appears that you're trying to use this terminology shift to prove that djbdns's
structure (in which the so-called "proxy server" component is separated from the
so-called "content server" component) is superior to BIND's.

Use whatever terminology you want, but don't try to leverage your own non-standard
terminology into a value judgment of one DNS implementation versus another. That's
illegitimate and sleazy. It's like saying "let's call 'emacs' a Mercedes-Benz and
'vi' a Neon. Since a Mercedes-Benz is obviously better than a Neon, then 'emacs'
must be better than 'vi'". Yeah, right...


- Kevin