![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.