[dns-operations] are we adding value?

[Edward Lewis]

Caution - philosophical territory.

On Jan 15, 2013, at 18:29, George Michaelson wrote:
> 
> We're in a world where the goal is to answer questions, quickly and accurately.

In a sense I disagree with that.

In one of my first jobs my mission was to replace the tangled (pre-http) web of thin net and thick net ethernet cabling throughout a 30 building (i.e., large, sprawling) campus housing a government agency studying science, replacing the wires with a cable-based, twisted pair ethernet.  At the moment in history, my mission was neither cutting edge anymore nor had it become common place.

The cost savings were obvious, the added functionality was also obvious.  For a scientific community this seemed like an easy sell.  But no.

When I tried to get a campus-wide allocation of funds to do this from the central planning committee, I was told "the primary goal is to study science, not have a lavishly engineered infrastructure."  I left the room with a new plan to convince each and every scientist they needed the new wiring and then have them ask the central committee.

Three years later, representing three budget cycles, where requests went from branch to division to directorate back up to the central planning committee the tune changed.  Once it was seen that the primary decision makers, all of the scientists individually wanted the new wiring for their self-interest(s), the committee allocated a campus-wide budget for it.

What I learned in that time is that engineers (of any breed) often fall in love with their primary mission and want to optimize the world to achieve the ideal.  What the outside world presents that seem to be impediments or obstacles are problems and "things wrong with the world" but are really requirements we have to meet.  Often times, we may have a goal that we believe to be mandatory when in fact to the outside world, just getting towards it or near it is acceptable.

DNS'ers do want to achieve a world where answers come quickly and accurately (what ever that means). But there are two forces against us.  One is the DNS protocol itself, which is hardly the epitome of great design.  The other is rest of the world that isn't ready to sacrifice more resources to DNS than is absolutely necessary to achieve other objectives.

So we have to deal with "it." (Whatever "it" is at the moment, currently "spoofed addresses.")   We can't wait or complain that spoofed addresses are someone else's fault or that there's no governmental intervention to stop the practice.  They exist, we have to deal with that.  What can we do?  Try to whittle away at the parts of the protocol that enable undesirable behavior.  This whittling manifests itself as complexity because - well - the "clean, crisp, optimal" model of the protocol doesn't work well in it's environment, so we are stepping away from that, one step with each whittle, as complexity increases.  And we are going to keep stepping until some other force tells us to stop (because the system's complexity incurs high operational costs).

It's impossible to objectively distinguish between optimizing and adding complexity.  Optimizations are value-adds and complexity is a cost-increase...so are we adding value or just increasing complexity.  Yes (as in return code != 0).

> I'm also confused about the 'no more ANY' discussion. Maybe I over-read, but I think ANY is a useful query, and I think ending it entirely would be a mistake. ANY allows for queries where you don't know the specific payload you need. DO we really want to remove that?

In short, I believe we should remove the ANY query, over UDP.  In long...well...the rationale would take a while and deserves it's own discussion.  I'm refraining from using a quick analogy because that tack alone is not a good way to express concepts that are ill-formed.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130116/b4f6a54c/attachment.html>