On Fri, Jan 13, 2006 at 12:57:22PM -1000, Randy Bush wrote:
at root, i am a naggumite. erik nagum was good at describing why broken things should not be patched over. it's better to amplify breakage if that's what it takes to get it fixed asap.
In this case, the 'break' is only damaging if it is in the query path. If it is not, it ultimately reaches the expiry timer and becomes a non-issue for all involved. Perpetual entropy leading to heat death is not acheived. So, serving a zone that has a very large expiry on a recursive nameserver is, in effect, putting your hand on the burner. Remember I'm on both sides of this fence; Either use a low expiry on zones hosted by recursive nameservers, or use any (probably large) expiry on authoritative-only servers.
an analogous gripe i have is "do-gooder" software, which also applies to configuration and other policies. if do-gooderism 'successfully' compensates for an error, no one notices. when it makes a mistake, everyone screams to the heavens and throws mud. e.g. remember when ejk put in an interceptor cache to give his customers seriously better performance?
Then I guess you won't be a fan of: http://www.ietf.org/internet-drafts/draft-andrews-full-service-resolvers-01....
pain is nature's way of telling us to take our hand off of the stove.
Above is an example of a software engineer (Mr. Andrews) choosing to experience a kind of pain now (the ietf standards process), for others to experience a kind of pain later (those who use rfc1918 space adopting software implementing this), and for the as112 operators to experience less pain until gradually it is retired. Pain in this universe is absolute and eternal. All you can do is choose for whom it is fair to experience how much of it. Something like the Cyclops in Krull. Choose to get left behind in the field to die peacefully, or get crushed in the stone doors saving your friends. The mechanics of the result is unimportant. The choice is. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins