Andrew Sullivan wrote:
we need to
ask ourselves why, in spite of the built-in resilience of DNS, relying
on DNS often makes an application less resilient. If the explanation
turns out to be exclusively things like the layer 8 and 9 issues
you're talking about, then let's work on fixing them (or come up with
a tech fix to route around that damage). I suspect, however, that
we'll find ambiguities in the specifications that make certain kinds
of implementations hard. We should fix that, too (and dnsext is
trying).
Andrew,
An easy reaction to your note is "yes, of course you are correct", but it might
be worth a small amount of additional consideration: This is an infrastructure
service that has demonstrated a long history of utility and a long history of
problems. Some of the problems have more impact than others. I'm not sure there
is any consensus about which ones, but trying to do a rough rand-ordering could
focus effort to be more efficient (and more useful.)
What we have been missing is any sort of systematic consideration of those
problems. Which are major and which are minor (for some definitions of major and
minor)? Where should community effort be put, to make substantial improvements
in DNS utility? There is the usual danger of fragmented effort, with
uncoordinated, local optimizations that ultimately do not have the desired benefit.
I take your note as highlighting the potential disparity between the DNS reality
seen by experts, versus the DNS reality seen in the larger and less expert wild.
Besides motivating analysis of what is wrong, we need to apply that perspective
at a systemic level to the effort at making improvements, so that fixes by
experts result in real, systems-level improvements.
In all likelihood, the biggest impact on DNS reliability will turn out to come
from relatively straightforward changes in administration and operation. But
there does not seem to be all that much effort in this direction and it seems
likely that a well-placed and well-touted BCP -- and perhaps some tools to test
for conformance to it -- could help more than a protocol improvement...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf